how write an effective test summary report
Просто ръководство от 12 стъпки за създаване на ефективен обобщен отчет на теста с примерен шаблон за обобщен тест:
Няколко документа и доклади се подготвят като част от Тестване. Някои са Тестова стратегия док , План за изпитване док , План за управление на риска , План за управление на конфигурацията и др. Сред тези обобщени доклади за изпитване е един такъв доклад, който се изготвя след приключване на тестването.
Опитах се да обясня целта на ' Обобщен отчет на теста ' и при условие а примерен шаблон за обобщен тест на тест, заедно с действителен отчет за изтегляне.
Какво ще научите:
Какво е обобщен отчет на теста?
Както знаем, тестването на софтуер е важна фаза в SDLC и също така служи като „Порта за качество“ на приложението, за да премине и сертифицирано като „Can Go Live“ от екипа за тестване.
Резюме на теста е важен резултат, който се изготвя в края на проект за тестване или по-скоро след приключване на тестването. Основната цел на този документ е да обясни различни подробности и дейности относно тестването, извършено за проекта, на съответните заинтересовани страни като старши мениджмънт, клиент и др.
Като част от Ежедневни отчети за състоянието , резултатите от ежедневните тестове ще бъдат споделяни със заинтересованите страни всеки ден. Но Резюмето на теста предоставя консолидиран отчет за извършените до момента тестове за проекта.
Препоръчително четене=> Как да докладвате интелигентно изпълнение на тест (изтегляне на шаблон за доклад за състоянието)
Да приемем, че ако клиентът, който седи на отдалечено място, трябва да разбере резултатите и състоянието на проект за тестване, който е бил изпълнен за период от, да речем например - четири месеца, Резюмето на теста ще реши целта.
Това също е артефакт, който трябва да бъде подготвен като част от CMMI процес .
Какво съдържа резюмето на теста?
Типичен Шаблон за тестов отчет ще съдържа информацията по-долу, но въз основа на формата и практиката на всяка компания, съдържанието може да варира. Дал съм и реални примери за по-добро разбиране.
В края на тази статия можете да изтеглите извадка от резюме на тест.
12 стъпки Ръководство за писане на ефективен обобщен отчет на теста
Стъпка # 1) Цел на документа
Например, Този документ обяснява различните дейности, извършени като част от Тестването на приложението „ABCD Transport System“.
Стъпка # 2) Преглед на приложението
Например, „ABCD Transport System“ е уеб-базирано приложение за резервация на автобусни билети. Билети за различни автобуси могат да бъдат резервирани чрез онлайн съоръженията. Информацията за пътниците в реално време се получава от „Централна система за съхранение“, която ще бъде препратена преди потвърждаване на резервацията. Има няколко модула като Регистрация, Резервация, Плащане и Отчети, които са интегрирани, за да изпълнят целта.
Стъпка # 3) Обхват на тестване
- В обхвата
- Извън обхвата
- Артикули не са тествани
Например, Проверка на функционалността, която се нуждае от свързаност с приложение на трета страна, не може да бъде тествана, тъй като свързаността не може да бъде установена поради някои технически ограничения. Този раздел трябва да бъде ясно документиран, в противен случай ще се приеме, че тестването е обхванало всички области на приложението.
- В обхвата: Функционалното тестване за следните модули е в обхвата на тестване
- Регистрация
- Резервация
- Плащане
- Извън обхвата: Тестване на производителността не е направено за това приложение.
- Елементи, които не са тествани: Проверката на свързаността със системата на трета страна „Централна система за съхранение“ не беше тествана, тъй като свързаността не можа да бъде установена поради някои технически ограничения. Това може да се провери по време на UAT (User Acceptance Testing), когато връзката е налична или може да бъде установена.
Стъпка # 4) Показатели
- Брой планирани срещу изпълнени тестови случаи
- Брой пропуснати / неуспешни тестови случаи
- Брой установени дефекти и тяхното състояние и тежест
как да станете изпитател на продукти
- Разпределение на дефекти - модулно
Стъпка # 5) Видове проведени тестове
- Тестване на дим
- Тестване на системната интеграция
- и Регресионно тестване
Забележка:Ако са направени няколко кръга на тестване, подробностите могат да бъдат включени и тук.>
Например,
да се) Тестване на дим
Това тестване се правеше всеки път, когато се получи компилация (внедрен в тестова среда) за тестване, за да се уверите, че основната функционалност работи добре, може да се приеме Build и тестването да започне.
б) Тестване на системната интеграция
- Това е тестването, извършено на тестваното приложение, за да се провери цялостната работа на приложението съгласно изискванията.
- Тествани бяха критични бизнес сценарии, за да се гарантира, че важната функционалност в приложението работи по предназначение, без никакви грешки.
° С) Тестване на регресия
- Тестването на регресия се извършваше всеки път, когато се използва нова компилация за тестване, която съдържа поправки на дефекти и нови подобрения, ако има такива.
- Тестването на регресия се извършва за цялото приложение, а не само за новата функционалност и корекции на дефекти.
- Това тестване гарантира, че съществуващата функционалност работи добре след отстраняване на дефекти и се добавят нови подобрения към съществуващото приложение.
- Тестови случаи за нова функционалност се добавят към съществуващите тестови случаи и се изпълняват.
Стъпка # 6) Тествайте среда и инструменти
Например,
Стъпка # 7) Уроци
Например,
Стъпка # 8) Препоръки
Например,
- Административен контрол за инструментите за управление на дефекти може да бъде предоставен на офшорния мениджър на тестове за предоставяне на достъп до екипа за тестване.
- Всеки път, когато администраторът на място не е необходимо да се свързва с молби, когато възникнат, като по този начин спестява време поради географската разлика в часовия пояс.
Стъпка # 9) Най-добри практики
Например,
- Повтарящата се задача, изпълнявана ръчно всеки път, отнема много време. Тази задача беше автоматизирана чрез създаване на скриптове и стартиране всеки път, което спести време и ресурси.
- Тестовете за дим бяха автоматизирани и скриптовете бяха стартирани, което работи бързо и спестява време.
- Подготвени бяха скриптове за автоматизация, за да се създадат нови клиенти, където трябва да се създадат много записи за тестване.
- Критичните за бизнеса сценарии се тестват отделно върху цялото приложение, което е жизненоважно, за да се удостовери, че работят добре.
Стъпка # 10) Критерии за изход
(iI) Всички критични дефекти са затворени и т.н.>
Например,
- Всички тестови случаи трябва да бъдат изпълнени - Да
- Всички дефекти в критични, големи, средни тежести трябва да бъдат проверени и затворени - Да .
- Всички открити дефекти в тривиалната тежест - План за действие, изготвен с очаквани дати на закриване.
Никакви дефекти на Severity1 не трябва да бъдат „ОТВОРЕНИ“; Само 2 дефекта на сериозност2 трябва да бъдат „ОТВОРЕНИ“; Само 4 дефекта Severity3 трябва да бъдат „ОТВОРЕНИ“. Забележка: Това може да варира в зависимост от проект. Планът за действие за откритите дефекти трябва да бъде ясно споменат с подробности за това кога и как те ще бъдат отстранени и затворени.>
Стъпка # 11) Заключение / Подписване
Например, Тъй като критериите за изход бяха изпълнени и удовлетворени, както е споменато в раздел 10, това приложение се предлага от „Тестващ екип“ да започне на живо. Трябва да се извърши подходящо тестване за приемане от потребител / бизнес преди „Go Live“.
Стъпка # 12) Определения, съкращения и съкращения
=> Изтеглете примерен обобщен отчет на теста:
Натиснете тук за да свалите примерен шаблон за доклад за тест с пример.
Малко точки, които трябва да се отбележат при подготовката на обобщения отчет на теста
- Като част от Изпълнението на теста, съберете цялата необходима информация за извършеното тестване. Това ще помогне за изготвянето на обобщен отчет на теста.
- Научените уроци могат да бъдат обяснени в детайли, което ще покаже отговорността, поета за решаването на тези проблеми. Също така, това ще бъде препоръка за предстоящи проекти, за да се избегнат тези.
- По същия начин споменаването на най-добрите практики ще изобрази усилията, положени от екипа, освен редовното тестване, което също ще се третира като „добавяне на стойност“.
- Споменаването на показателите в графична форма (диаграми, графики) ще бъде добър начин за визуално представяне на състоянието и данните.
- Не забравяйте, че обобщеният отчет на теста трябва да споменава и обяснява дейностите, извършени като част от тестването, за да разберат по-добре получателите.
- Ако е необходимо, могат да се добавят още няколко подходящи раздела.
Заключение
Резюмето на теста е важен резултат и фокусът трябва да бъде върху изготвянето на ефективен документ, тъй като този артефакт ще бъде споделен с различни заинтересовани страни като висше ръководство, клиент и т.н.
След извършване на изчерпателно тестване, публикуването на резултатите от теста, показатели, най-добри практики, научени уроци, заключения относно „Go Live“ и т.н. са изключително важни, за да се представят това като доказателство за извършеното тестване и заключението от теста.
Също така предоставихме за изтегляне проба от протокола за изпитване. Това е идеален пример за това как да се подготви ефективен доклад с резюме на теста!
За автора: Това е пост за гост от Баскар Пилай. Той има около 14 години опит в управлението на тестове и от край до края на тестване на софтуер. Сертифициран от CSTE тестващ професионалист, обучител, работи в IT специалности като Cognizant, HCL, Capgemini и в момента работи като мениджър на тестове за голям MNC.
Моля, уведомете ни вашите коментари / въпроси / мисли.
Препоръчително четене
- Как да напиша седмичен отчет за състоянието на тестване на софтуер
- Примерен шаблон за доклад за изпитване за приемане с примери
- Как да отчитате интелигентно изпълнение на тест - (Изтеглете шаблона за отчет на състоянието)
- Примерен шаблон за тестови случаи с примери за тестови случаи (Изтегляне)
- Ръководство за документация за тестване на софтуер (защо е важно)
- Как да напиша добър доклад за грешка? Съвети и трикове
- 6 най-важни стъпки за подобряване на отчетите от тестовете
- Как да напиша документ за тестова стратегия (с примерен шаблон за тестова стратегия)