qa software testing checklists
Контролни списъци за тестване на софтуера за QA
Днес ви представяме още един качествен инструмент, който толкова често се използва недостатъчно, че си мислехме, че ще преработим подробности за него с надеждата той да си върне изгубената слава. Това е ‘Check List’.
Определение: Контролен списък е каталог на елементи / задачи, които се записват за проследяване. Този списък може да бъде подреден в последователност или може да бъде хаотичен.
Контролните списъци са неразделна част от нашето ежедневие. Използваме ги в различни ситуации - от пазаруване на хранителни стоки до списък със задачи за дневните дейности.
Какво ще научите:
Общ преглед на контролните списъци за тестване на софтуера за качество
Веднага щом стигнем до офиса, винаги правим списък с неща, които трябва да направим за този ден / седмица, като по-долу:
- Попълнете работен лист
- завършек документация
- Обадете се на офшорния екип в 10:30 сутринта
- Среща в 16 ч. И т.н.
Когато и когато даден елемент от списъка е завършен, вие го заличавате, премахвате от списъка или маркирате елемента с отметка - за да отбележите завършването му. Не е ли твърде познато за нас?
Това обаче ли е всичко, за което може да се използва?
qa водещи интервюта въпроси и отговори pdf
Можем ли да използваме контролни списъци в нашите ИТ проекти официално (по-специално QA) и ако да, кога и как? Това е, което ще бъде разгледано по-долу.
Аз лично се застъпвам за използването на контролни списъци по следните причини:
- Той е универсален - може да се използва за всичко
- Лесно за създаване / използване / поддръжка
- Анализирането на резултатите (напредък на задачата / състояние на изпълнение) е супер лесно
- Много гъвкав - можете да добавяте или премахвате елементи, ако е необходимо
Както е общата практика, ще говорим за аспектите „Защо“ и „Как“.
- Защо се нуждаем от контролни списъци? : За проследяване и оценка на завършеността (или неизпълнението). За отбелязване на задачи, така че нищо да не се пренебрегва.
- Как да създадем контролни списъци? : Е, това не може да бъде по-просто. Просто напишете всичко точка по точка.
Примери за контролни списъци за QA процеси:
Както споменах по-горе, има някои области в областта на осигуряването на качеството, където можем ефективно да приложим концепцията на контролния списък да работи и да постигнем добри резултати. Две от областите, които ще видим днес, са:
- Преглед на готовността за изпитване
- Кога да спрете тестването или контролния списък с критерии за изход
# 1) Преглед на готовността за тест
Това е много често срещана дейност, която се извършва от всеки QA екип, за да определи дали има всичко необходимо, за да премине във фазата на изпълнение на теста. Освен това това е повтаряща се дейност преди всеки цикъл на тестване в проекти, които включват множество цикли.
За да не се сблъскаме с проблеми след започване на фазата на тестване и да разберем, че сме влезли във фазата на изпълнение преждевременно, всеки QA проект трябва да извърши преглед, за да се установи дали има всички необходими данни за успешното тестване.
Контролен списък улеснява тази дейност перфектно. Позволява ви да съставите списък на „необходимите неща“ преди време и да прегледате всеки елемент последователно. Можете дори да използвате повторно листа, веднъж създаден, и за следващи тестови цикли.
Допълнителна информация: Прегледът за готовност на теста обикновено се създава и прегледът се извършва от представител на екипа за QA. Резултатите се споделят с личните ръководители и останалите членове на екипа, за да се определи дали тестовият екип е готов или не да премине във фазата на изпълнение на теста.
По-долу е даден пример за примерен контролен списък за проверка на готовността за изпитване:
Критерии за преглед на готовността за изпитване (TRR) | Състояние |
Всички изисквания са финализирани и анализирани | Свършен |
План за тестване създаден и прегледан | Свършен |
Подготовка на тестови случаи Свършен | |
Преглед на тестовия случай и изписване | |
Тестови данни наличност | |
Тестване на дим | |
Направено ли е тестване за здравословно състояние? | |
Екип, наясно с ролите и отговорностите | |
Екип, запознат с резултатите, които се очакват от тях | |
Екип, запознат с Протокол за комуникация | |
Достъп на екипа до приложението, инструменти за контрол на версиите, Тестово управление | |
Екипът е обучен | |
Технически аспекти - сървър1 е обновен или не? | |
Определени са стандарти за докладване на дефекти |
Сега всичко, което трябва да направите с този списък, е да маркирате като готово или не.
# 2) Контролен списък с критерии за изход
Както показва името, това е контролен списък, който помага при вземането на решение дали дадена фаза / цикъл на изпитване трябва да бъде спряна или продължена.
Тъй като продукт без дефекти не е възможен и ще трябва да се уверим, че тестваме във възможно най-добрата степен за дадения период от време - създава се контролен списък с ефекта по-долу, за да се проследят най-важните критерии, които трябва да бъдат изпълнени да се счита фазата на изпитване за задоволителна.
Критерии за изход | Състояние |
Изпълнени 100% тестови скриптове | Свършен |
95% степен на преминаване на тестови скриптове | |
Няма отворени критични и дефекти с висока тежест | |
95% от дефектите със средна тежест са затворени | |
Всички останали дефекти се анулират или документират като заявки за промяна за бъдещо издание | |
Всички очаквани и действителни резултати се записват и документират с тестовия скрипт | Свършен |
Всички показатели на теста се събират въз основа на отчети от HP ALM | |
Всички дефекти се регистрират в HP ALM | Свършен |
Бележката за закриване на теста е попълнена и подписана |
Контролен списък за тестване
Ще стартирате ли нов проект за тестване? Не забравяйте да проверите този контролен списък за тестване във всяка стъпка от жизнения цикъл на вашия проект. Списъкът е предимно еквивалентен на плана за тестване, той ще обхваща всички стандарти за осигуряване на качеството и тестване.
Контролен списък за тестване:
- Създаване на системни и приемни тестове ()
- Започнете създаването на тест за приемане ()
- Идентифицирайте тестовия екип ()
- Създаване на работен план ()
- Създаване на тестов подход ()
- Свържете критериите за приемане и изискванията, за да формирате основата на теста за приемане ()
- Използвайте подмножество от тестови случаи на системата, за да оформите част от изискванията за тест за приемане ()
- Създайте скриптове за използване от клиента, за да докажете, че системата отговаря на изискванията ()
- Създайте тестов график. Включете хора и всички други ресурси. ()
- Провеждане на тест за приемане ()
- Стартиране на създаването на тест на системата ()
- Идентифицирайте членовете на тестовия екип ()
- Създаване на работен план ()
- Определяне на изискванията за ресурси ()
- Идентифицирайте инструментите за производителност за тестване ()
- Определяне на изискванията за данни ()
- Постигнете споразумение с Център за данни ()
- Създаване на тестов подход ()
- Определете всички съоръжения, които са необходими ()
- Получаване и преглед на съществуващ тестов материал ()
- Създайте опис на тестови елементи ()
- Идентифицирайте състоянията, условията, процесите и процедурите на проектиране ()
- Определете необходимостта от тестване на базата на код (бяла кутия). Идентифицирайте условията. ()
- Идентифицирайте всички функционални изисквания ()
- Край на създаването на инвентара ()
- Стартиране на създаване на тестова кутия ()
- Създаване на тестови кейсове въз основа на опис на тестови елементи ()
- Идентифициране на логически групи от бизнес функции за новата система ()
- Разделете тестовите случаи на функционални групи, проследени за тестване на инвентара ()
- Проектирайте набори от данни, за да съответстват на тестови случаи ()
- Край на създаването на тестова кутия ()
- Преглед на бизнес функции, тестови случаи и набори от данни с потребители ()
- Вземете подписка за тестовия дизайн от ръководителя на проекта и QA ()
- Дизайн на крайния тест ()
- Започнете подготовка на теста ()
- Получаване на ресурси за поддръжка на тестове ()
- Очертайте очакваните резултати за всеки тестов случай ()
- Получаване на тестови данни. Проверка и проследяване на тестови случаи ()
- Подгответе подробни тестови скриптове за всеки тестов случай ()
- Подгответе и документирайте процедурите за настройка на околната среда. Включете планове за архивиране и възстановяване ()
- Крайна фаза за подготовка на теста ()
- Тест за провеждане на системата ()
- Изпълнение на тестови скриптове ()
- Сравнете действителния резултат с очаквания ()
- Документирайте несъответствия и създайте доклад за проблем ()
- Подгответе фаза за поддръжка ()
- Повторно изпълнение на тестовата група след отстраняване на проблем ()
- Създайте окончателен доклад за теста, включете списък с известни грешки ()
- Получаване на официална подписка ()
Контролен списък за автоматизация
Ако отговорите положително на някой от тези въпроси, тогава тестът ви трябва да бъде сериозно обмислен за автоматизация.
В # 1) Може ли да бъде дефинирана тестовата последователност от действия?
Отговор: Полезно ли е да се повтаря последователността от действия много пъти? Примери за това биха били тестове за приемане, тестове за съвместимост, тестове за ефективност и тестове за регресия.
В # 2) Възможно ли е да се автоматизира последователността на действията?
Отговор: Това може да определи, че автоматизацията не е подходяща за тази последователност от действия.
В # 3) Възможно ли е да се „полуавтоматизира” тест?
Отговор: Автоматизирането на части от теста може да ускори времето за изпълнение на теста.
В # 4) Същото ли е поведението на тествания софтуер с автоматизацията и без нея?
Отговор: Това е важна грижа за тестването на производителността.
въпроси за ръчно тестване на интервю за 5 години опитВ # 5) Изпробвате ли аспекти на програмата, които не са от UI? Отговор: Почти всички функции, които не са с потребителски интерфейс, могат и трябва да бъдат автоматизирани тестове.
В # 6) Трябва ли да провеждате едни и същи тестове на множество хардуерни конфигурации?
Отговор: Изпълнявайте ad-hoc тестове (Забележка: В идеалния случай всяка грешка трябва да има свързан тестов случай. Ad hoc тестовете се правят най-добре ръчно. Трябва да се опитате да си представите себе си в реални ситуации и да използвате софтуера си, както би направил вашият клиент. Тъй като са намерени грешки по време на ad-hoc тестване трябва да се създадат нови тестови случаи, за да могат да се възпроизвеждат лесно и да могат да се извършват регресионни тестове, когато стигнете до фазата на Zero Bug Build.)
Ad-hoc тест е тест, който се извършва ръчно, когато тестерът се опитва да симулира реалното използване на софтуерния продукт. При провеждането на ad hoc тестване ще бъдат открити повечето грешки. Трябва да се подчертае, че автоматизацията никога не може да замести ръчното тестване.
Точки за отбелязване:
- Горните два са примери за демонстриране на използването на контролни списъци QA процеси , но използването не е ограничено до тези две области.
- Елементите във всеки списък също са индикатори, които дават представа на читателите за това какъв вид елементи могат да бъдат включени и проследени - списъкът обаче може да бъде разширен и / или уплътнен при необходимост.
Наистина се надяваме, че горните примери са успешни при пренасянето на потенциала на контролните списъци към QA и IT процесите.
Така че, следващия път, когато имате нужда от прост инструмент, който е полуформален, опростен и ефективен, надяваме се, че сме ви ориентирали към даване на шанс на контролните списъци. Понякога най-простото решение е най-доброто.
Препоръчително четене
- Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
- Тестване на софтуер QA Assistant Job
- Курс за тестване на софтуер: Към кой институт за тестване на софтуер трябва да се присъединя?
- Изборът на софтуерно тестване като кариера
- Тестване на софтуер Техническо съдържание Writer Работа на свободна практика
- ISTQB Тестване за сертифициране Примерни въпроси с отговори
- Някои интересни въпроси за интервю за тестване на софтуер
- Обратна връзка и рецензии на курсове за софтуерно тестване