«Звичайно окрема», - відповість більшість читачів. Така відповідь вкладається в їхню картину світу, тому що «так працювали завжди».
Так працювали завжди
Ця фраза зазвичай означає наявність продукту, вже працює на продакшені або тільки зарелізитися, але написаного без модульних та інтеграційних тестів. Без страхувальної мережі з тестів, зміни вносяться довго, дорого і з великою кількістю нових багів. Такий проект у світі розробки прийнято називати «легасі».
Компанія розуміє, що обійтися без страхувальної мережі не можна, тому створюється QA-відділ, який зазвичай не забезпечує якість продукту, а лише контролює його. З QA-відділом розробник може спокійно займатися улюбленою справою - писати код, адже відповідальність за якість тепер несе виділений відділ! Відбувається класичне «перекидання коду через стіну» до відділу тестування:
QA-відділ пише сотні black-box тест-кейсів на вже готову функціональність, які необхідно проходити під час регресії. А також, якщо продукт продовжує розвиватися, сотні тест-кейсів на нову функціональність, які пізніше додаються в регресію.
Проходження кожного тест-кейсу ручне, тому процес тестування займає багато часу. Кількість тест-кейсів у регресії з природничих причин постійно зростає, і приймається рішення про створення всередині QA-відділу команди автоматизації.
Оскільки новоспечена команда набиралася через необхідність прискорити цикл регресії, який складається з black-box тестів, то й автоматизація відбувається на рівні black-box: через GUI або API. Автоматизація через GUI найбільш болюча і дорога через крихкість і низьку швидкість тестів, але часто починають саме з неї.
Тим часом, факт створення нової команди ніяк не впливає на команду розробки: вона все також продовжує віддавати в тестування неякісний продукт, ігноруючи написання модульних та інтеграційних тестів. Враховуючи величезну кількість black-box сценаріїв, що знаходяться в черзі на автоматизацію, отримуємо анти-патерн тестування Ice-Cream Cone, в якому кількість найповільніших і найдорожчих GUI-автотестів набагато більше кількості дешевих і швидких модульних та інтеграційних тестів.
Нестабільних і повільних за своєю природою GUI-автотестів з кожним релізом стає все більше, а значить більше ресурсів йде на їх підтримку, що веде до розширення команди автоматизації. Департамент забезпечення якості зростає, але не забезпечує належне зростання якості продукту, що випускається. Ви дійсно хочете так працювати завжди?
В чому проблема?
Одна з головних причин виникнення ситуації, описаної вище, - це відсутність культури розробки, в якій кожен розробник несе відповідальність за написаний ним код. А навіть мінімальна відповідальність розуміє під собою необхідність упевнитися в працездатності коду перш ніж радісно вигукувати: «Моя робота готова!».
Eye Driven Development є найпростішим способом упевнитися в працездатності коду, але не найоптимальнішим. Простий цей спосіб тим, що не передбачає практично ніякої інтелектуальної роботи: ми тестуємо руками додаток, сервіс, клас і т. д. з точки зору кінцевого користувача, не розглядаючи граничні значення, класи еквівалентності, негативні сценарії, сценарії з різними рівнями permissions та інше. Такий спосіб не дає швидкого зворотного зв'язку при розробці, не дозволяє перевірити сутність на різноманітній вибірці даних, займає багато часу і не покращує якість продукту.
Найбільш оптимальний спосіб - це написання автотестів на розроблюваний код. Говорячи про відповідальність за код, не важливо, коли написані автотести: до або після самого коду. Головне, що дає такий спосіб - це впевненість у тому, що робота дійсно завершена і можна переходити до іншого завдання. Враховуючи інші переваги у вигляді швидкого зворотного зв'язку, можливості перевіряти сутність на великій вибірці, а також високої швидкості, автотести, написані розробниками, є відмінним інструментом для поліпшення якості продукту.
Працюємо не так як завжди
Пропоную подумки змоделювати можливий розвиток подій в команді, члени якої несуть відповідальність за написаний код.
У нас є продукт, що вже працює на продакшені або тільки-но готується зарелізитися, який покритий модульними та інтеграційними тестами. Код постійно вдосконалюється, а нова функціональність додається без страху зламати вже наявну. Щоб переконатися в працездатності розроблюваної функціональності більше не потрібно «перекидати код через стіну» у відділ тестування і втрачати час, чекаючи вердикту, після чого повторювати ітерацію знову і знову.
QA-відділ вже створений і активно бере участь у процесі розробки, займаючись дійсно забезпеченням якості продукту, що випускається. При розмові про забезпечення якості, як мені здається, зручно керуватися Testing Quadrants:
Використовуючи Testing Quadrants, тестування можна розбити на 4 категорії.
Перша категорія - це тестування реалізації продукту, що створює страхувальну мережу для команди розробки. Ця категорія відповідає за низькорівневе тестування за допомогою модульних та інтеграційних тестів і дозволяє зрозуміти розробникам, що з технічної точки зору вони роблять речі правильно (Do Things Right). Очевидно, що низькорівневі тести є повністю автоматизованими і пишуться командою розробки, оскільки лежать в її сфері інтересів.
Друга категорія - це тестування бізнес-функцій продукту, що створює страхувальну мережу для команди розробки. Тут мова йде про такі види тестування як Examples, Story Tests та інші, спрямовані в першу чергу на створення правильної комунікації між бізнесом і командою розробки, і дозволяють команді зрозуміти, що вона робить правильні речі (Do Right Things), які дійсно потрібні бізнесу.
Автоматизування Examples або Story Tests представляє з себе End-to-End тести, які тестують не складні сценарії використання інтерфейсу, а лише бізнес-логіку, але через інтерфейс, який доступний кінцевому користувачеві. Оскільки ця категорія тестування все ще лежить у сфері інтересів розробки, то автоматизація лягає на плечі команди розробки.
Третя категорія - це тестування бізнес-функцій продукту, які критичні для сприйняття якості продукту кінцевим користувачем. У цю категорію потрапляють дослідницьке тестування, тестування складних сценаріїв використання продукту, тестування юзабіліті, альфа- і бета-тестування. Тести з цієї категорії лежать повністю на плечах QA-команди, а їх автоматизація неможлива або занадто складна.
Якщо говорити безпосередньо про дослідницьке тестування і тестування складних сценаріїв, які можуть знаходити функціональні помилки, то варто зауважити, що будь-яка знайдена помилка є помилкою в коді і може бути покрита відповідними модульними або інтеграційними тестами. Про це добре написав Мартін Фаулер, а я дозволив собі вольності в перекладі:
I always argue that high-level tests are there as a second line of test defense. If you get a failure in a high level test, not just do you have a bug in your functional code, you also have a missing or incorrect unit test. Thus I advise that before fixing a bug exposed by a high level test, you should replicate the bug with a unit test. Then the unit test ensures the bug stays dead.
Я стверджую, що високорівневі тести - всього лише друга лінія оборони. Високорівневий тест, що впав, означає не тільки порожній у коді продукту, а й відсутність відповідного модульного тесту або помилку у вже наявному. Моя вам порада: перш ніж фіксувати, знайдений високорівневим тестом, відтворіть його за допомогою модульного тесту, і ви попрощаєтеся з багом назавжди.
Четверта категорія - це тестування реалізації продукту, яка критична для сприйняття якості продукту кінцевим користувачем. Зазвичай до цієї категорії потрапляють навантажувальне тестування, тестування продуктивності, тестування безпеки та надійності системи. Таке тестування проводиться з використанням спеціальних інструментів, найчастіше написаних під потреби конкретного проекту. По-хорошому, інфраструктурою для проведення подібних тестів займається DevOps-відділ, а розробкою відповідних інструментів -
окрема команда. Причому інструменти повинні дозволяти проводити тести на вимогу (Testing as a Service).
Так як створений QA-відділ тепер відповідає не тільки за контроль якості продукту, але і за забезпечення якості, то в його обов'язки входить:
- Допомога розробникам при написанні тестів з першої категорії
- Участь у формуванні Examples і Story Tests під час спілкуванні команди розробки з представниками бізнесу
- Проведення дослідницького тестування та тестування складних сценаріїв
- Проведення тестування юзабіліті та робота з фідбеком від користувачів
Нескінченного зростання регресійних ручних black-box тест-кейсів не відбувається, тому що більша їх частина покрита в першій і другій категоріях командою розробки. У такому випадку у нас формується правильне ставлення тестів або, як це прийнято називати, «піраміда тестування»:
Зростання кількості регресійних ручних тестів мінімальне, автоматизація на рівні модульних, інтеграційних та GUI тестів здійснюється командою розробки. Причому кількість GUI-тестів невелика, вони описують не складні сценарії використання GUI, а роботу бізнес-логіки через користувальницький інтерфейс, а значить є менш крихкими і більш дешевими в підтримці. Відділ QA дійсно займається забезпеченням якості, отримуючи і працюючи з фідбеком від користувачів, проводячи дослідницьке тестування, тестування нової функціональності за допомогою складних сценаріїв, а також допомагаючи розробникам спілкуватися з бізнесом. Тестування в проекті автоматизовано ефективніше ніж у першому випадку, але команда автоматизації всередині QA-відділу так і не з'явилася.
І я повторю питання: «Automation QA - це окрема команда?»
