Якщо ви працюєте з проектом з використанням BDD зі 100% охопленням історій користувачів автоматизованими тестами приймання, яка б роль роль тестера / перевірки якості?
Я думаю, я уявляю, що розробники писали б тести прийняття спільно з власником продукту, повідомте мені, якщо це здасться дурним припущенням.
Відповіді:
Можливо, я занадто старомодний, але навіть найсучасніші методи розробки чи обробки не можуть замінити інший набір очей, свіжих очей, перш ніж випускати продукт своєму клієнту.
Навіть якщо ваш продукт є просто API для іншого розробника, ви можете використовувати QA, щоб вважати користувача API, надаючи сценарії тестування / використання, про які ви чи ваш клієнт не думали заздалегідь.
Якщо ваш продукт сильно базується на користувальницькому інтерфейсі, безумовно, ви хочете, щоб інша людина (це не ви або хтось із вашої команди) шукала остаточного результату, перш ніж надсилати його клієнту.
Як і будь-яке інше казкове слово в нашій галузі, BDD - навіть зі 100% покриттям - не має жодної срібної кулі .
100% покриття не те саме, що 100% перевірене.
Я бачив, як людина, що відповідає за якість, у проекті ATDD як хтось, хто допоможе написати тести та виконати інші типи тестування, які досі існують. Тобто випробування на інтерфейс користувача, випробування на руйнування та випробування навантаження / напруження.
Але я ніколи не працював над проектом ATDD.
Завдання QA полягає в тому, щоб зламати додаток, робота розробників - це не зламати його. Тому вони пишуть свої тести з іншого погляду. Наприклад, розробники пишуть тести, щоб побачити, чи відбудеться очікувана поведінка, QA пише тести, щоб побачити, що відбувається, коли користувачі роблять те, що розробник ніколи не вважатиме, що користувач зробить. Крім того, розробники часто неправильно трактують вимоги, і тести щодо забезпечення якості виявляться, коли їх інтерпретація відрізняється від того, що розробник думав, що це означає, а потім збираються разом із зацікавленими сторонами проекту, щоб визначити, що є правильним тлумаченням. Тести, написані розробниками, які писали код, часто мають великі сліпі плями, оскільки у розробника була велика сліпа пляма. Наприклад, він може перевірити те, що відбувається 97% часу, але не крайові випадки.
У попереднього роботодавця роль QA полягала в тому, щоб не тестувати продукт, а гарантувати розробникам, по суті, те, що вони сказали, що вони збираються зробити стосовно попередньо визначених тестів приймання, які були визначені QA.
Власник продукту, з іншого боку, не мав абсолютно нічого спільного з тестуванням. Справа з тестуванням на будь-якому рівні IMHO не є роллю власника продукту.
У якийсь момент ви повинні мати впевненість у своїх працівниках; стримування та противаги хороші, але вам не доведеться форсувати рішення в межах циклу розвитку, яке насправді стосується лише невеликого набору робочої етики працівників.
У ідеальному світі я бачу співпрацю з розробниками та QA, які формалізуються разом із написанням тестів на прийняття. QA має внести в таблицю різні аспекти, як і команда розробників. Контроль якості повинен мати руку в пиріг в дитинстві і залишатися задіяним протягом усього циклу. З іншого боку, власник товару повинен залучати QA для розуміння того, який поточний стан продукту, ризиків тощо ... та зосередитись на продукт цілісно; не конкретні нюанси, що складають виріб.
З мого досвіду: ми використовували Тестовий блок, щоб покрити більше 90% коду. Були також інтеграційні тести та погодинні побудови. jBehave тести на BDD.
Роль QA: - прийняття розповідей користувачів для тестування - написання коду за кроками - дослідницьке тестування з використанням плагіна RestClient для IDEA (таким чином ми знайшли кілька основних помилок)
Частина BDD застосовує підхід 3 Amigos, коли зацікавлені сторони співпрацюють для вироблення критеріїв прийняття. QA / Dev може написати код кроку, щоб зробити сценарії виконаними як тести прийняття. Де значення QA для виконання вручну тих же тестів прийняття, які інструмент BDD виконає автоматично? Додане значення QA полягає у валідації цих приймальних випробувань та проведенні ручних розвідувальних випробувань за межами сценаріїв прийнятих тестів. Дублювання зазвичай дасть однаковий результат.
Розробники не переписують вимоги та характеристики, QA не переписують код програми ... можливо, для QA не доведеться виконувати ті самі сценарії, що розробники виконуються як тести прийняття. Настав час Девам надіти якусь шапку QA!