Software Testing as a Social Science (Caner) - частина 2

#testing #caner

В першій частині нотаток зі слайдів Кема Канера ми розбирались з тим, що таке тестування та як воно повʼязане із соціальними науками. Сьогодні ми продовжимо переглядати слайди й подивимось на важливість контексту, сценаріїї та складнощі у виявленні помилок.

Про техніки та контекст

Техніка тестування - це рецепт по створенню тестів. Сюди входять тестування домену, ризиків, сценаріїв, та ін. Канер зазначає, що існує близько 150! різних технік. (Варто пошукати той перелік технік. Чи це тільки маркетинговий трюк?)

Контекст - різний в кожному проєкті. Тому для кожного проєкту, тестувальнику треба розібратись:
- які цілі та критерії якості на проєкті
- які ресурси є в наявності
- що входить в проєкт та де він може потенційно збоїти
- які можуть бути причини помилок та хто зацікавлений в тому, щоб помилок не було
- як зрозуміти які результуючі змінні - важливі, а якими - можна знехтувати
- як досліджувати чи навіть спростити помилки, щоб переконати зацікавлену сторону в тому, що це проблема та швидше її вирішити

(Тут варто нагадати, що Кем Канер - один з творців "школи" context-driven software testing.)

Про тестування на основі сценаріїв

Ідеальний сценарій базується на історії того, як програма використовується, включаючи мотивацію користувача. Історія повинна мотивувати зацікавлену сторону в тому, щоб виправити помилку в сценарії. Історія має бути реалістичною та використовувати складне середовище чи набір даних. Чим складніше історія, тим легше оцінити результат сценарію.

Звідки брати ідеї створення сценаріїв?
- Згадайте життєвий цикл обʼєктів в системі
- Запишіть та проаналізуйте можливих користувачів та їх мотивацію
- Перелічіть список можливих та неможливих системних подій
- Взнайте в користувача про типові кейси взаємодії з продуктом
- Подивіться на подібні системи в конкурентів (а також звернення користувачів з проблемами)
- Шукайте послідовності: люди (або система) зазвичай виконують завдання X у заданому порядку. Які найпоширеніші послідовності завдань у досягненні X?

(Хтось взагалі користується scenario-based testing усвідомлено?)

Виявляти помилки - не просто.

Хоча розробник зазвичай знаходить більшість багів, тестер шукає помилки в "сліпих зонах" розробників. Щоб тестувати більш ефективно, треба базуватись на теорії того, чому люди роблять помилки.

Існує феномен "ненавмисної сліпоти" - люди (часто) не бачать того, на що не звертають уваги. Програми ж (завжди) не бачать того, чого їм сказали не бачити. Це призводить до появи помилок, що не відтворюються.

Навіть, якщо ми покрили весь функціонал тестами, додаткові побічні ефекти (дані, ресурси та час) стають новими причинами для проявлення принципу Гейзенберга. (Взагалі принцип Гейзенберга - цікава тема. Знайшов декілька дослідницьких робіт. Частково, це повʼязане із flaky тестами).

Навіть, якщо ми знайшли помилку - то не значить, що помилку будуть виправляти. Рішення про виправлення базується на аналізі витрат та вигоди.

Саме тому важливо ретельно описувати знайдені помилки - тим самим показуючи ефективність тестера. Зверніть увагу на технічну якість опису, імпакт аналіз, переконливість та зрозумілість.

Цікаво, чому Канер вимірює ефективність тестувальника у вмінні описати баг. Чи згодні ви з таким твердженням?

На цьому все. До нових зустрічей!