Пишемо тест-кейси
Книга: Як тестують у Google
Пишемо тест-кейси
Тестувальники Google створюють дуже багато тест-кейсів, які визначають вхідні дані (від загальних умов до конкретних значень) для тестування програми. Тест-кейси можуть будуватися і на основі історій користувача, і прямим перетворенням можливостей продукту: робота з ними не залежить від їх походження. На відміну від коду та автоматизації, які керуються загальною інфраструктурою, тест-кейси досі пишуться локально кожною командою. Нещодавно з'явився інструмент, який змінить ситуацію.
Найчастіше тест-кейси зберігалися в електронних таблицях та документах. Команди, які працюють за швидкими методологіями з короткими циклами випуску, не дуже дбають про збереження тест-кейсів. Як тільки виходить нова фіча, скрипти починають падати і тести доводиться переписувати заново. Тому документа, який можна використати, а потім із чистим серцем видалити, цілком достатньо. Формат такого документа не підійде для конкретних тест-кейсів з діями, але згодиться для опису контексту тестової сесії. Такі випробування зазвичай менш регламентовані і, насправді, просто вказують, які фічі необхідно досліджувати.
Звичайно, є команди, які зберігають тестові процедури та дані у досить складних таблицях. Деякі навіть копіюють дані ACC-аналізу в електронні таблиці, тому що вони, бачите, гнучкіші, ніж Google Test Analytics. Але такий підхід потребує дисципліни та цілісності у команді, адже робота одного тестувальника може обмежити роботу іншого. Великим командам з їхньою плинністю потрібен інший підхід. Потрібна структура, яка переживе будь-якого учасника команди.
Електронні таблиці все ж таки зручніше документів, тому що в них є відповідні стовпці для процедур, даних іпозначок про результати. Їх легко налаштувати під себе. Google Sites та інші різновиди онлайнових вікі-систем часто використовують для транслювання тестової інформації іншим зацікавленим людям. Їх легко використовувати спільно та редагувати.
Зі зростанням Google у багатьох команд зростали обсяги тест-кейсів, ними потрібно було краще керувати. Деякі документи з тест-кейсами виросли до таких розмірів, що навіть пошук у них неможливий. Потрібен був новий підхід. Наші тестувальники побудували систему на основі кількох комерційних продуктів та доморощених систем управління тест-кейсами, знайомих їм за попередніми місцями роботи. Систему назвали Test Scribe.
Test Scribe зберігає тест-кейси у жорсткій структурі. Можна увімкнути або виключити тест-кейс із конкретної тестової сесії. Реалізація була примітивною, і ентузіазм щодо її використання швидко згас. І хоча багато команд залишили щось від неї і поралися з цим кілька кварталів, ми її таки поховали. 2010 року Джорданна Корд, старший розробник у тестуванні, написала нову програму. Це була система Google Test Case Manager (GTCM).
Мал. 3.10.Домашня сторінка GTCM зосереджена на пошуку
GTCM створили, щоб зробити процес написання тестів простіше, створити гнучкий формат тегів, який можна адаптувати під будь-який проект, спростити пошук та повторне використання тестів. І – найважливіше – інтеграція GTCM з рештою інфраструктури Google. Подивіться на знімки GTCM (мал. 3.10–3.14). На рис. 3.11 показано сторінку створення тест-кейсу. Можна створювати довільні розділи або мітки, тому GTCM підтримує будь-які схеми, від класичних тестів до дослідницьких турів, «огірків»[40] та описів історій користувача. Деякі тестові команди навітьзберігають фрагменти коду та дані прямо в тест-кейсах GTCM. GTCM допомагає в роботі будь-яким тестовим командам і враховує їх представлення тест-кейсів.
Мал. 3.11.Створення проекту в GTCM
Мал. 3.12.Створення тесту в GTCM
Мал. 3.13.Перегляд тест-кейсів при пошуку Chrome у GTCM
Мал. 3.14.Простий тест-кейс для діалогового вікна About у Chrome
Метрики, отримані від GTCM, дають уявлення про те, що відбувається із тест-кейсами загалом. Можна спостерігати за графіками загальної кількості тестів та результатів тестів на рис. 3.15 та 3.16. Загальна кількість тестів наближається до асимптоту. Це тому, що Google закриває старі проекти, орієнтовані на ручне регресійне тестування разом із їх тестами. Крім того, GTCM в основному містить ручні тести, а багато команд замінюють ручні методи тестування на автоматизацію, краудсорсинг або дослідницьке тестування. Тому загальна кількість тест-кейсів у внутрішній базі TCM зменшується, хоча покриття при цьому збільшується. Кількість проведених тестів також збільшується, оскільки у цій галузі домінують кілька великих команд, котрим ручне тестування обов'язково (наприклад, команда Android).
Мал. 3.15.Зміна кількості тестів з часом у GTCM
Загальна кількість проведених ручних тестів, як і слід очікувати, збільшується (рис. 3.16).
Мал. 3.16.Зміна кількості результатів тестів з часом у GTCM
Подивимося графік кількості багів, показаний в GTCM (рис. 3.17). Він цікавий, але ще може показати всю картину. Google пропонує інженерам свободу дій. Одні команди відстежують, які баги було знайденоякі тест-кейси, а інші не вважають ці дані корисними для свого проекту. Деякі баги створюються в системі автоматично, не всі вони знайшли в ході ручного виконання тестів.
Мал. 3.17.Зміна загальної кількості багів, заведених у ході виконання тестів GTCM, з часом
Основною вимогою до GTCM із самого початку була наявність чіткого та простого API. Насправді і у системи TestScribe був API, але він базувався на SOAP, а схема автентифікації була настільки недружньою, що нею мало хто користувався. Крім того, з підвищенням внутрішнього рівня безпеки цей режим автентифікації став непридатним. Ці проблеми вирішилися, коли GTCM з'явився RESTful JSON API.
Команда розробки збирається незабаром відкрити GTCM для зовнішнього використання. Ми сподіваємося перевести цю базу даних тест-кейсів на модель відкритого коду, щоби підтримувати її всім світом. Система GTCM проектувалась з розрахунком на продовження використання ззовні. Вона побудована на базі Google App Engine для забезпечення масштабованості і для того, щоб інші компанії могли розгорнути свою копію системи. Внутрішня структура GTCM зроблена так, щоб відокремити більшу частину логіки та інтерфейсів користувача від Google App Engine, щоб люди могли портувати систему. Слідкуйте за Google Testing Blog, якщо хочете дізнатися більше про цей процес.