how report test execution smartly
Отчитане на състоянието на софтуерното тестване
„Споразумението, че определена информация, в определен формат, ще бъде изпратена от определен екип / индивид през определени интервали от време до определени членове - е като ръкостискане - признание, че без значение какъв е резултатът от дадена задача в ръка, ще бъдете информирани за това, по-рано, отколкото по-късно. '
урок за Visual Studio Team Foundation Server 2015
Това е първият раздел от клетвата на ИТ специалист. Е, шегувам се! Няма клетва, но ако имаше такава, това със сигурност щеше да оглави списъка с елементи в нея. Нали?
Отчетността и прозрачността (A & T) са от съществено значение за всеки ИТ проект на различни нива - ниво проект, ниво екип, ниво задача, а също и индивидуално ниво. Как да се уверим, че тези атрибути са изпълнени? Отговорът е - общуване, по-формално- Отчитане на състоянието !
На индивидуално ниво не изпращаме ли всеки ден доклади, най-вече EOD, за да съобщаваме за изпълнението (или неизпълнението) на ежедневните ви задължения. Това доказва, че вие всъщност сте „наясно“ с какви задължения трябва да започнете.
Какво ще научите:
Ежедневен доклад за състоянието
Информацията, която трябва да бъде част от „Ежедневния доклад за състоянието“ на дадено лице, е:
- Какво прави днес?
- Какво планирате да правите утре?
- Срещали ли сте някакви проблеми през деня си? Ако отговорът е да, как ги разрешихте или те все още са отворени?
- Имате ли нужда от входове за утре? Ако да, от кого и какви са те?
Получателят на този имейл / отчет обикновено е мениджър, също така членовете на екипа могат да бъдат CC’ed в някои случаи - това зависи от комуникационния протокол, който екипът следва.
Доклади от тестовете
Сега е време да получите конкретни данни и да научите всичко за отчетите, които екипите за тестване / QA изпращат.
Екипите за тестване изпращат различни доклади на различни фази в STLC.
- Състояние на тестовия план
- Състояние на тестовата документация
- Състояние на тестовото изпълнение (състояние на дефект)
План за тестване : Достатъчно е да общувате с останалите екипи по проекта, когато се създава план за тестване или когато се прави значителна промяна в него.
Тестова документация : Нека всички екипи знаят кога са започнали проектирането на тестовете, събирането на данни и други дейности, както и кога са приключили. Този доклад не само ще ги информира за напредъка на задачата, но също така ще сигнализира на екипите, които трябва да прегледат и осигурят подписване на артефактите, че те са следващи.
Изпълнение на теста : Изпълнението е фазата на проекта, когато екипът за тестване е основният фокус - положително и отрицателно - ние сме както героите, така и злодеите.
Типичен ден по време на тестовия цикъл не се прави, освен ако не се изпрати Ежедневният доклад за състоянието. В някои отбори те биха могли да се споразумеят за седмичен отчет, но изпращането му ежедневно е норма.
Също така не е необичайно всеки ден (или седмица) да се провежда среща по състоянието, за да се представи състоянието на екипа за осигуряване на качеството на заинтересованите страни.
Следователно режимът на отчет за състоянието може да бъде:
- Имейл / документ
- Среща / презентация
- И двете - ежедневна електронна поща и седмична среща или така.
Отчет за състоянието на тестовото изпълнение
Ежедневен / седмичен отчет за изпълнение на теста:
Какво е? По принцип това е съобщение, изпратено, за да се установи прозрачност за дейностите на екипа за QA през деня по време на тестовия цикъл - включва както информация за дефекти, така и информация за изпълнение на тестови случаи.
На кого трябва да отиде? - Обикновено екипът за разработка, екипът за поддръжка на околната среда, бизнес анализаторът и екипът на проекта са получателите / участниците в срещата. Планът за тестване е най-доброто място за намиране на тази информация.
Какво съдържа отчетът за състоянието на тестовото изпълнение? - 10 точки
- Брой тестови случаи, планирани за този ден
- Брой изпълнени тестови дела - този ден
- Брой изпълнени тестови случаи като цяло
- Брой дефекти, срещани през този ден / и съответните им състояния
- Брой срещани дефекти до момента / и съответните им състояния
- Брой критични дефекти - все още отворени
- Престой на околната среда - ако има такъв
- Витрини - ако има такива
- Прикачване на лист за изпълнение на теста / Връзка към Инструмент за управление на тестове където са поставени тестовите случаи
- Прикачен файл към отчета за грешки / връзка към инструмента за дефекти / тест / управление, използван за управление на инциденти
Горните 10 точки, ако забележите отблизо, са суровите данни. Съобщаването на факти е едно, а съобщаването на някои „умни“ факти е друго . Как да прецизираме тази информация?
- Показва цялостното състояние с цветен индикатор. Например, Зелено - навреме, оранжево - Малко назад, но може да поеме забавянето, червено - забавено.
- Включете някои прости показатели като Pass% от досегашните тестове, плътност на дефектите,% от тежки дефекти; правейки това, вие не просто давате цифри, а всъщност давате поглед върху качеството на продукта, който тествате.
- Ако значителна фаза е завършена - подчертайте това.
- Ако има критичен дефект, който ще блокира всички / част от бъдещото изпълнение - подчертайте това.
- Ако използвате презентация, не забравяйте да включите няколко графики за по-добро въздействие.
Например, долната графика е представяне на броя на отворените дефекти, модулно :
Освен тях по желание можете да включите и:
- Какви са дейностите, планирани по-нататък?
- Имате ли нужда от приноси от някой от другите екипи и ако да, какво?
И накрая, няколко насоки за подпомагане на процеса:
- Бъдете кратки и същевременно завършени
- Уверете се, че резултатите, които отчитате, са точни
- Използвайте точки, за да направите отчета много четим
- Проверете отново, за да включите точната дата, тема, списък и прикачени файлове.
- Ако отчетът е твърде голям и има твърде много фактори за докладване: поставете го на общо място като файл и изпратете връзка в имейла вместо самия файл. (Уверете се, че получателите имат разрешения за достъп до това местоположение и файла)
- Ако това е среща за състоянието - Бъдете подготвени за презентацията, пристигнете навреме и най-важното, поддържайте равномерен тон (не се гордейте с дефектите - те като цяло са „лоши новини“).
Примерен доклад за състоянието
Доклад за състоянието на QA тестване:
Следвайки тези насоки, стигнахме до отчета за състоянието по-долу.
За удобство на нашите читатели сме включили 3 листа, които предават различни нива на информация, която те могат да предадат.
Лист 1 - е обобщение на цялостното състояние на проекта.
Лист 2 - е повече за индивидуалните подробности за състоянието на тестовия случай.
Лист 3 - е примерен доклад за грешка.
най-добрият безплатен изтеглящ видео за YouTube
Изтеглете това Примерен шаблон за Xls доклад за състоянието с трите листа. (Щракнете с десния бутон върху връзката и изберете „Запазване на връзката като ..“, за да изтеглите)
За автора - Това е статия от члена на екипа на STH Суати Сиела. Можете да научите повече за нея на нашия Страница на курса за тестване на софтуер .
Споделете вашите коментари и въпроси с нас по-долу.
Препоръчително четене
- Как да напиша седмичен отчет за състоянието на тестване на софтуер
- Как да актуализирате дистанционно състоянието на изпълнението на тестовия случай чрез селен - Урок # 3
- Как да напиша ефективен обобщен отчет на теста (Примерен отчет за изтегляне)
- Примерен доклад за грешка
- Примерен шаблон за доклад за изпитване за приемане с примери
- Стандартна библиотека с шаблони (STL): Кратко въведение
- Създаване на генерични лекарства и тестове - Урок №22 за селен
- Примерен шаблон за тестови случаи с примери за тестови случаи (Изтегляне)