Коли слід завершити тестування?
Початок - половина справи. Це правило застосовно практично до будь-якій сфері діяльності, і навіть до тестування ПО.
Найчастіше на початку проекту тестувальники випромінюють ентузіазм, складаючи документацію (стратегія тестування, план тестування або тест-кейси).
Але в подальшому нерідко виникають складнощі. По завершенні першого раунду тестування, тестувальники зазвичай знаходять купу багів, а потім підходять до другого етапу кілька розслабленими. Має місце т.зв. людський фактор і загальнолюдська тенденція, коли стає нудно виконувати повторні операції.
У подібних ситуаціях у багатьох виникає відчуття того, що вони роблять монотонну роботу, і, як наслідок, втрачається інтерес до продовження тестування вже знайомого ПО. І під час третього, приблизно, раунду над тестувальником невблаганно нависає питання: «Коли ж все-таки потрібно припиняти тестування?»
Кожен тестувальник хоча б раз задавався таким питанням, розширена версія якого виглядала б так:
«Коли, на якому етапі і як припиняти тестування?»
Багато тестувальники вважають, що не існує якихось особливих умов, що вказують на те, що тестування слід завершити. Але щоб відповісти на це питання, доведеться проаналізувати тестову активність від початку до кінця.
Припустимо, стоїть завдання протестувати новий проект.
- Команда тестувальників отримує вимоги.
- Потім слід планування і розробка.
- Готується і перевіряється документація по тестуванню.
Тестування, раунд # 1)
Команда тестувальників приступає до тестування, як тільки їй передають щойно створений програмний продукт.
На етапі тестування тестувальники виконують різні сценарії, намагаючись зламати ПО і виявити дефекти. (Оскільки додаток нове і проходить оцінку вперше, показник виявлених дефектів буде порівняно високим).
Розробники усувають дефекти і повертають розробку тестувальникам для повторного тесту.
Тестировщики проводять проводять перевірку на предмет наявності дефектів, потім переходять до регрессионному тестування.
Як тільки серйозні дефекти усунені і ПО демонструє стабільну роботу, команда розробників випускає наступну версію.
Тестування, раунд # 2)
Тестировщики розпочинає другий раунд тестування і повторюють те, що виконувалося під час першого раунду.
Під час цього процесу, як правило, виявляються ще деякі дефекти.
Дефекти усуваються розробниками і додаток знову вирушає на перевірку.
Тестировщики проводять повторні тести і регресійні тестування тих частин розробки, які не зазнали змін.
Це можна продовжувати до нескінченності. Раунд 3, 4, 5 ... до тих пір, поки програмне забезпечення абсолютно не очиститься від багів.
Графічно цей процес можна зобразити таким чином:
Але представляється теоретично можливим знайти абсолютно всі дефекти? Це питання на мільйон доларів, але спробуємо на нього відповісти.
Більшість додатків влаштовані складно, тому фронт їх тестування досить великий. Не те щоб виявити абсолютно всі дефекти зовсім неможливо, але для цього знадобиться вічність.
Навіть після того, як більшість багів в ПО знайдені, ніхто не зможе з упевненістю заявити, що додаток стало безперечним.
Більш того, таке завдання не стоїть. Мета тестування ПО - переконатися, що воно функціонально і працює так, як заплановано. Досягається це за рахунок спроб злому або пошуку відхилень від очікуваного поведінки.
У додатків може бути безліч дефектів, і проводити тестування ПО до повного їх усунення непрактично. Ніколи не знаєш, який з багів виявиться останнім.
А якщо «припинення тестування, після повного усунення дефектів» тепер не є критерієм, тоді з чого ж слід виходити?
Спробуємо розібратися, які чинники слід вважати найбільш важливими?
Рішення про припинення тестування зазвичай залежить від часу (яке є в розпорядженні), бюджету і необхідної тривалості тестування.
Найчастіше рішення завершити тестування приймається, коли закінчився час / бюджет, або ж коли всі тестові сценарії виконані. Але це компромісне рішення, яке може бути на шкоду якості.
Припустимо, необхідно протестувати програмний модуль, на цю роботу виділено певний бюджет. Час: 1 місяць. Загальна кількість тестових сценаріїв: 200.
Перший тиждень. Ви досягли успіху - в перший же день знайшли дефект Show Stopper. Але тестування зупинилося на 3 дні. Перевіряти інші сценарії ви не можете, поки не буде усунений виявили баг. Втративши час, ви знову приступаєте до роботи.
До кінця тижня перевірено 20 сценаріїв і знайдено ще кілька небезпечних багів.
Тиждень 2. Ви починаєте тестування, ретельно вишукувати дефекти. За другий тиждень знаходите кілька багів 1-го, 2-го і 3-го рівня критичності. За цей час вдалося перевірити 70 сценаріїв.
Тиждень 3. До початку третього тижня всі дефекти з високим пріоритетом усунені, але тепер до виконання поточних сценаріїв додається ще і повторний огляд раніше виявлених багів. За третій тиждень ви охопили 120 сценаріїв, і знайшли ще кілька багів. Тепер залишається шукати тільки дефекти третього порядку.
Тиждень 4. До початку четвертого тижня необхідно перевірити ще раз дефекти і 80 залишилися сценаріїв. До кінця тижня ви перевірили 180 сценаріїв; всі дефекти з високим пріоритетом були усунені і протестовані повторно.
Дані про проведеному тестуванні поміщаються в таблицю: