Часом, тестуючи велику кількість нових Фітч тестувальники забувають навіть про найважливіші принципи в тестуванні і тим самим роблячи багато стратегічних і поведінкових помилок в тестуванні ПО.
У цій статті нагадаю загальновідомі і основні принципи про які не слід забувати, коли тестируете будь-яке додаток або нову Фітч
Основні принципи в тестуванні ПО
З безлічі принципів, які напевно для себе виділив кожен тестувальник займається тестуванням ПЗ є основні на думку спільноти тестувальників, які і хотілося б виділити:
1) Повне тестування неможливо жодним з тестувальників. Думаю що всі розуміють що протестувати всі можливі випадки і комбінації просто неможливо, звичайно якщо це не тривіальний випадок.
Всі випадки просто не можуть бути включені в тест сьют, так як це зайняло б у нас дуже багато часу і, зрештою, не варто було б нам таких зусиль. Якщо кожен тестувальник сяде і ретельно продумає всі сценарії і якщо віддати цю Фітч для тестування іншому тестувальників, то він як правило знаходить ще купу можливих сценаріїв і кейсів, які можна включити. Тому в тестуванні ПО прийнято проаналізувати продукт або нову Фітч після чого сфокусувати зусилля в тестуванні на більш ризикові і пріоритетні випадки і ділянки нашого продукту.
2) Скупчення багів. Якщо брати продукт і розбити його по модулях, то в процесі тестування можна помітити що основна частина багів лежить в одному або декількох модулях продукту, отже можна відзначити ефект скупчення багів. Як правило таке можна спостерігати в абсолютно різних продуктах. Для того щоб ефективно протестувати наш продукт, слід розподілити свої зусилля в тестуванні з реальної щільності багів в модулях продукту, якщо ж тестуємо вперше, то пропорційно очікуваній щільності. Згодом тенденція з накопиченням багів може зміняться від модуля до модуля. Це слід відстежувати і перерозподіляти зусилля в подальшому тестуванні.
3) Ефективність раннього тестування. Дуже важливо щоб тестування починалося як можна раніше і передбачає можливість помилки які може зробити розробник.
Перед тим як розробляти і тестувати той чи інший продукт, слід з'ясувати всю специфіку, можливі конфлікти в специфікації, неможливість нової фітчи взаємодіяти з іншим модулем, переконатися що тестувальник, розробник і продакт овнер однаково правильно розуміють як це буде реалізовано. Запам'ятайте ніж раніше знайдуться баги тим дешевше їх виправити.
4) Парадокс пестициду. Якщо написавши тест кейси, проганяти їх багато багато разів, то в кінцевому рахунку ці кейси не допоможуть нам знайти нові баги. Тому існує практика в тестуванні коли переглядають і модернізують тест кейси щоб зловити якісь нові баги. Тест кейси можуть ускладнюватися, бути різнобічними так щоб охопити всі компоненти, модулі нашого продукту, що в свою чергу допоможе нам знайти більше цікавих і нових багів.
5) Тестування залежить від нашого продукту. Існує багато програм, продуктів і до кожної з них слід підходити індивідуально в плані тестування. В якихось більше зусиль в тестуванні потрібно на безпеку, в якихось на юзабіліті. Тому не варто гребти всі продукти під одну гребінку і тестувати по якомусь одному шаблоном.
6) Тестування показує наявність багів в продукті але ніяк не їх відсутність. Багато хто думає що якщо новий функціонал пройшов стадію тестування, значить все - багів вже немає. В цьому і полягає помилкове судження. Тестування лише знижує ймовірність наявності багів в продукті. Отже, в процесі тестування багато багів може бути пропущено і це не буде означати що якщо продукт пройшов тестування, то зараз цей продукт на 100% працює коректно.
7) Продукт добре протестований і начебто немає очевидних багів, то це хороший продукт. Іноді тестріруя і вишукуючи функціональні баги, ми забуваємо подивитися з іншого боку і запитати а чи потрібно це користувачеві. Якщо ця Фітч не відповідає очікуванням користувача і його потребам, то який би якісний наш продукт не був - це вже не так важливо.