Привіт. Нещодавно ми писали про перший розділ ISTQB Syllabus і сьогодні вирішили написати трохи детальніше про принципи тестування. Їм вже більше 50❗️ років і вони все ще актуальні! Про них варто пам’ятати як новачкам, так і експертам:
1️⃣ Тестування демонструє присутність дефектів, але не їх відсутність. Не можна довести, що в програмі немає багів, але тестуючи, можна зменшити імовірність знаходження багу користувачами
2️⃣ Вичерпне тестування неможливо. Протестувати програму з усіма можливими комбінаціями вхідних значень неможливо за скінченний проміжок часу. Навіть для простих програм типу калькулятор це означало б перевірку операцій з усіма дійсними числами від -∞ до +∞. Саме тому тестери використовують техніки тест дизайну та аналізують ризики
3️⃣ Раннє тестування економить час і гроші. Чим швидше в життєвому циклі ми знаходимо баг, ти простіше і дешевше його пофіксити. Статичне тестування вимог набагато дешевше, ніж повне регресійне тестування системи після баг фіксу перед релізом. Раннє тестування зараз ще відносять до shift left
4️⃣ Дефекти часто скупчуються разом. Зазвичай, знайшовши 1 помилку в певному модулі програми, імовірність знайти там ще баги – зростає. Тут знову нам допомагає аналіз ризиків 🤓
5️⃣ Остерігайтеся парадоксу пестицидів. Якщо одні й ті самі тести проводити багато разів – імовірність знайти дефект зменшується. І це є одним з аргументів на користь переваги ручного тестування перед автоматизованим, оскільки мануальний тестер завжди робить варіації початкового плану
6️⃣ Тестування контекстно залежне. різні програми ми тестуємо по різному. Тестування автопілоту літака вимагає серйознішого підходу та зусиль ніж черговий, навіть дуже класний, інтернет магазин. Саме тому, чим більше досвіду ми маємо, тим більше ми цінуємось, оскільки знаємо різні контексти (доменні знання)
7️⃣ Відсутність помилок – це помилка. Дехто може думати, що тестери можуть знайти багато багів, їх пофіксять і багів більше не буде. Але принципи 1️⃣ та 2️⃣ кажуть нам, що це не можливо. Більш того, знаходження і фікс великої кількості багів може привести до хибної впевненості, що програма якісна. Насправді ж, навіть система, яку протестували і не знайшли багів може виявитись нецікавою користувачам і нікому не потрібною 🤷♀️
Як вам? Не застаріли принципи? Може не згодні з якимись? Може треба додати нові? Напишіть нам в коментах!
А ще знайшов картинку про баги, стару, як ті принципи 😎