Більшість проєктів, на яких вам доведеться працювати, скоріше за все будуть за методологією Agile.
Індустрія розробки програмного забеспечення все більше схиляється до дотримання саме цієї парадигми, а класичний Waterfall продовжує втрачати свою актуальність. Чому так відбувається — тема для окремої статті. Єдине, що вам потрібно наразі знати — це так, і саме тому кожному тестувальнику треба знати основні відмінності процесу тестування згідно з різними методологіями.
Як було раніше
Раніше все відбувалось дуже послідовно і очевидно. Спочатку відбувалась ініціація проекту, тобто підготовка до його реалізації. Потім, власне, розробка програмного забеспечення. І лише після цього продукт попадав в руки команди тестування, яка перевіряла його на працездатність, відповідність вимогам, зручність, тощо. Тестувальники мали доступ до вже готового продукту й були останньою ланкою перед релізом продукту.
Такий підхід здається дуже зрозумілим і раціональним, коли мова йде про розробку продукту, до якого ми маємо дуже чіткі вимоги, строки, бюджет і взагалі маємо уявлення, як його розробляти. Проте вся ця схема стає не такою вже й логічною, коли ми переходимо до розробки інноваціних речей, які потребуватимуть регулярного оновлення, корегування, тощо. І, звісно, регулярного тестування.
Основні відмінності
Ось, в принципі ми і підібрались до першої і, мабуть, основної відмінності. Під час розробки за Agile, ми імплементуємо процес тестування у весь проєкт, від його початку і до самого кінця. Тестування функціоналу відбувається протягом кожного спринту або ітерації розробки ПО. Поки розробники розробляють, тестувальники тестують.
Друга відмінність — тестувальники перестають бути окремим ізольованим юнітом і стають частиною команди розробки. Вони на більш ранніх етапах починають свою роботу, ближче співпрацюють з розробниками і залучають усіх учасників проєкту до контролю якості продукту. Часто на таких проєктах тестувальники також беруть участь у формуванні вимог до продукту, орієнтуючись на потреби користувача.
Методи тестування згідно з Agile
Acceptance Test Driven Development (ATDD). Якщо дуже спрощено, це коли ми спочатку розробляємо приймальний тест, а потім розробляємо такий функціонал, який може його пройти. Цей метод базується на тісній співпраці тестувальника, розробника і користувача (або бізнес-аналітика). Разом вони мають узгодити між собою вимоги до продукту і описати сценарії, за якими він буде працювати. Тільки після цього розробники можуть переходити до роботи, коли ми точно знаємо як має бути реалізована певна функція.
Behaviour Driven Development (BDD). Попередня методологія допомагає нам у розробці певного модулю, але вона не враховує взаємодію цих умовних частин продукту. Саме для цього була розроблена BDD методологія, основна відміна якої полягає у тому, що та ж сама команда з розробників, тестувальників і користувачів створюють складні сценарії, намагаючись передбачити поведінку користувача. Ці сценарії і виконують роль основних вимог до розробки продукту.
Дослідницьке тестування. Один з найкреативніших і найцікавіших підходів до тестування загалом. Воно передбачає суміщення етапу тест-дизайну з самим проходженням і дозволяє тестувальнику бути хаотичним і більш наближеним за своєю поведінкою до реального користувача. Цей спосіб допомагає освіжити погляд на продукт і зекономити час на документації, адже за умов дотримання саме такого підходу, тестувальник не фіксує що і як він проходив, лише знайдені дефекти. Способів проведення дослідницького тестування безліч, а їх розкриття вимагає ще однієї статті, тож раджу вам поцікавитись цим питанням за нагоди.
Сесійне тестування. Це, перш за все, спосіб управління і систематизації дослідницього тестування. Хаотичність має свої переваги, але в рамках проєкту все ж таки має бути приборкана. В рамках цього підходу процес тестування розбивається на сессії, кожна з яких має свою мету, обмежена в часі і передбачає проведення аналізу отриманих результатів. Таке стуктурування хаотичного тестового досвіду іноді дає дуже приголомливі результати.
Висновки
На прикінці цієї невеликої статті я б хотів зазначити те, що, на мою думку, більше за все відрізняє тестування за аджайл — це спроба тестувальника відійти від амбіцій «перевірити все» і наблизитись до роботи з тим функціоналом, який дійсно важливий для користувача.
Це спроба тестувальника не просто безсенсовно знаходити все нові і нові баги, а шукати ті, які є дійсно критичними для бізнесу. Це розумна і відповідальна приоретизація і робота на продукт і команду, а не проти неї.
Саме це і є втіленням принципів Agile.
