how perform test documentation reviews 6 simple steps qa process
Досега всички знаем, че за тестер, Документация е неразделна част от ежедневието му. Има претоварване на тестови артефакти, които се създават, преглеждат, одобряват, използват, поддържат и разпространяват. Винаги имаме ясни процеси, изложени за това как да създадем документ, как да го използваме, на кого трябва да отиде и т.н.
Чрез тази статия ще хвърлим малко светлина върху малката, но важна тема - Рецензии.
Прегледът също е форма на тестване - частта за проверка на V&V, наречена също статично тестване.
Какво ще научите:
- Видове отзиви
- Стъпка 1: Определете критериите
- Стъпка 2: Извършете проверката
- Стъпка 3: Запишете вашите резултати
- Стъпка 4: Споделете, обсъдете и внедрете необходимите промени
- Стъпка 5: Контрол на версиите на включените документи
- Стъпка 6: Излезте и използвайте документа по предназначение
- Точки за запомняне
- Над теб
- Препоръчително четене
Видове отзиви
- Преглед на собствената ви работа - Самопроверка
- Рецензия
- Надзорна
Ако валидирането е половината от практиките на тестване, тогава верификацията е другата, но често насоките са мътни - така че нека променим това СЕГА. Обща практика ли е със статиите в STH, ще започнем с въпросите, Какво? Защо? Как
избройте и обяснете поне две неща, които можете да постигнете, като тествате софтуер за проблеми със сигурността.
Какво преглеждаме?
Всичко създадено трябва да бъде прегледано. По-долу са някои от често разглежданите артефакти:
- План за изпитване
- Тестови сценарии
- Тестови шаблони
- Тестови случаи
- Данни от теста
- Доклади ... и т.н.
Защо да преглеждате?
По същата причина ние тестваме софтуера, Например,
- За разкриване на грешки
- За да проверите за пълнота
- За да сте сигурни, че стандартите и указанията се спазват или не ... и т.н.
Как да прегледате?
Следват списъка на участващите дейности:
- Определете критериите - Имате контролен списък какво да търсите?
- Извършете проверката
- Запишете вашите резултати
- Споделяйте, обсъждайте и прилагайте необходимите промени
- Контрол на версиите на участващите документи
- Излезте и използвайте документа по предназначение.
Сега ще обсъдим всяка стъпка в раздела „Как“ - с други думи, процеса за нейното изпълнение.
(Повечето от нас тестери не харесват текстовия процесор, нали? За нас това или означава много повече работа, или някаква управленска задача на високо ниво, която трябва да свършим, дори и да не искаме - за в името на някакво съответствие, за което нямаме представа. Но, повярвайте ми, когато излезете с процес, който работи и е достатъчно просто, за да разберем защо трябва да го правим, може да бъде забавно! Просто играйте заедно с мен.)
Процесът на партньорски проверки и надзорни проверки е един и същ според мен, тъй като супервизорът също е партньор въпреки по-високото назначение.
Стъпка 1: Определете критериите
# 1) Какво очаквате да намерите? Можете да търсите неща като:
- Правописни грешки (Звучи прекалено глупаво? Не мисля, че веднъж написах „Ср. Обект“ вместо „Уеб обект“ в една от статиите си - Променя изцяло значението. Почти го прави твърде глупаво, за да се приема сериозно.)
- Съответствие на формата / шаблона
- Покритие на функционалност и коректност
- Лесно разбиране
- Следвани стандарти - конвенции за именуване, последователно номериране ... и т.н.
# две) Направете контролен списък - Контролните списъци са много гъвкави. Тя може да бъде толкова сложна като контролен списък за преглед или толкова проста като списък с хранителни стоки. Всичко, което е необходимо, е известно време, за да го направите и след като го направите, е толкова просто, колкото да проверите ВКЛЮЧЕНО или ИЗКЛЮЧЕНО.
# 3) Как да докладвам резултатите? - Изберете каквото е удобно, за предпочитане метод, който може да бъде записан и проследен.
- Понякога това може да бъде толкова просто, колкото добавянето на допълнителна колона в Excel листа с тестови случаи и писане на нещо в червено, когато не е това, което трябва да бъде.
- Може да бъде от уста на уста
- Списък в имейл
Стъпка 2: Извършете проверката
# 1) Използвайки контролния списък, който сте направили по-рано, проверете документа и предоставете отзивите си.
Стъпка 3: Запишете вашите резултати
# 1) Отново, използвайки метода, определен в стъпка 1, запишете и отчетете резултатите си.
# две) Когато докладвате вашите коментари или предложения за промяна, не се отнасяйте по никакъв начин с това, както да докладвате за дефект. Не пренебрегвайте нищо. Бъдете подробни.
# 1) Никой не обича да му се казва, че работата му е неправилна или непълна. Затова имайте предвид следните насоки, когато предоставяте отрицателна обратна връзка.
- Осигурете конструктивна критика - Не забравяйте да не бъдете критични към човека, но посочвайте недостатъци в този продукт
- Не се конкурирайте - само защото той включи 30 коментара за преглед на вашите тестови случаи, не се опитвайте да го победите.
- Мотивирайте да подкрепите вашите коментари
# две) Получете излизане.
# 3) Направете промените
Стъпка 5: Контрол на версиите на включените документи
# 1) Не изтривайте по-старите версии на нито един от документите. Назовете ги по подходящ начин и ги съхранявайте в централизирана папка на проекта. В крайна сметка това са доказателствата за цялата ни работа
Стъпка 6: Излезте и използвайте документа по предназначение
# 1) След като всички промени бъдат включени, версията е запазена, дайте възможност на процеса на преглед и преминете към използването на документа за това, за което е създаден.
# две) Друг въпрос, който възниква, е - проверяваме ли отново след направените промени? Колко пъти ще продължи този процес - работа - преглед - поправка - и след това преглед отново? Докога?
Въпроси и отговори за интервю за интервю за sql за опитен PDF
Не, прегледът не трябва да се случва отново и отново. Това е дейност за контрол на качеството, която се фокусира върху проверката дали помощниците за тестване са създадени правилно или не. Както винаги, документите с нулев дефект са невъзможни. Така че разумно ниво на преглед - еднократно от партньор е приемливо.
Ето, готово. Не е ли просто този процес?
Точки за запомняне
- Всеки проект не трябва да следва този формализиран метод за преглед, но дори и да има неформален метод, тези стъпки ще ви помогнат да зададете очакванията и да ви насочат.
- Тестова документация прогнозите за времева линия обикновено се основават на времето, необходимо за създаване и преглед на документите, така че той е вграден в него, въпреки че не винаги го разпознаваме.
- Прегледът не е процес, който се ограничава до екипи за ръчно тестване. Екипите за автоматизация също изпълняват кодови инструкции, ревюта на проекти и др.
И накрая, така изглежда един типичен документ за коментарни прегледи за тестови случаи. Коментарите са в червено. Не непременно истински коментари, но нещо, което да покаже как се прави.
Примерен документ за преглед на тестови случаи: (щракнете, за да увеличите изображението)
Над теб
И така, все още ли смятате, че процесите са плашещи? Изпълнявате ли рецензии във вашите проекти? Моля, споделете своя опит, предизвикателства, въпроси и коментари по-долу.
За автора: Това е публикация от Swati Seela - експерт по ръчно и автоматизирано тестване с над 9 години опит в индустрията . Тя е и инструктор на нашия курс за обучение по софтуерно тестване.
Ако искате да научите тестване на софтуер от експерти, проверете графика за предстоящата ни партида и повече за този курс на тази страница .
Препоръчително четене
- 4 стъпки към разработването на мисленето за гъвкаво тестване за успешен преход към гъвкав процес
- Как да извършите тестване на софтуерни продукти - подробен процес и методи с примери
- Тестване на бизнес процеси (BPT) - Как да опростим и ускорим процеса на тестване с помощта на BPT
- Генерирайте жива документация с кисели краставички за Specflow Feature Files
- Ръководство за документация за тестване на софтуер (защо е важно)
- Какво трябва да знае QA тестерът за процеса на управление на пускане и внедряване
- Команда Grep в Unix с прости примери
- 6 най-важни стъпки за подобряване на отчетите от тестовете