Перевод рассказа Кристины Жеквони, QA-лида из Paylocity (бухгалтерский софт), о ее опыте в руководстве автоматизацией. Если коротко, то вот признаки правильного автотеста:
- Тестируются лишь реально важные вещи
- Автотест падает, когда должен падать
- Надежность
- Тест легко поддерживать
- Быстро выполняется
- И в нужное время
«Недавно встречалась с коллегами, обсуждали улучшение своих процессов Continuous Delivery. Размышляли, как измерять свой прогресс в автоматизации тестирования. Первая идея которая была выдвинута — всегда точно знать покрытие кода.
Я ответила — нет. Измерение покрытия не очень поможет: покрытие не показывает, хороши ли тесты. А только показывают, какая часть кода покрыта тестами.
Следующим предложением был подсчет количества строчек кода написанных автотестов. И я снова не согласилась. Это тоже не поможет. Точно как количество страниц в книге не говорит нам, интересна ли она, так и количество строчек тестов ни о чем не свидетельствует.
Ок, отвечают мне они. А если опираться на количество самих тестов? Это должно хотя бы приблизительно должно показывать качество тестирования.
И снова нет, говорю я. У тебя может быть сотни тестов, и каждый из них в принципе может быть ненадежен, или например тестировать немного не то, что нужно.
И тогда они спросили: как же надежно оценить качество автоматизированного тестирования в проекте? Я подумала и решила обозначить свои критерии. Обсуждение — welcome.
1. Тестируются лишь реально важные вещи
Можно писать автотесты, тестирующие вообще все, но в реальности надо тестировать только то, что важно. Любой код требует довольно много времени на поддержку, не очень хорошо писать тесты ради галочки.
Например, подобные вещи тестировать вообще необязательно; ты тестируешь новую страницу в приложении, видишь что заголовок «Фамилия» написан как «Фамлимия». Заводишь на это баг, разработчик его фиксит, а ты проверяешь все ли ОК теперь. Какова вероятность, что в будущем такая ошибка снова возникнет? Очень маленькая. Так что нет смысла писать, например, автотесты проверки правильности написания слов в приложении.
2. Автотест падает, когда должен падать
Новички в автоматизации иногда забывают проверить, не падают ли автотесты, когда они должны упасть. Это случалось и со мной, когда я была новичком в тестировании, и писала автотесты на JavaScript. Как-то раз я долго писала тест и, когда написала, радовалась, что он проходит. Потом разработчик попросил проверить, не упадет ли тест, при невалидных входных данных. Он не падал! Оказалось, что я не понимала некоторые особенности промисов (если тебе они тоже непонятны, то читаем о них здесь на английском или лучше здесь). Я проверяла в тесте, существует ли промис, а надо было проверять значение которое он возвращает. Тесты на 100% проходимые независимо от их реальной корректности — хорошо выглядят в тест-репорте, но не имеют никакой практической ценности.
3. Надежность
Каждый тест должен быть на 100% надежен. Это в идеале, к этому идеалу нужно стремиться. Некорректные тесты должны исправляться или удаляться. Такой тест не дает полезной информации: он “упал” потому что есть баг, или просто сам тест “не очень” ?
4. Тест легко поддерживать
Набор автотестов со спагетти-кодом — неприятный сюрприз для тех кто будет потом этот код сопровождать. При каждом изменении кода тестируемого приложения кода, соответствующие тесты тоже надо переписывать, что требует часов, а то и дней рабочего времени. Код в тестах должен быть «чистым», упорядоченным, «не повторять себя» и легко читаться.
5. Быстро выполняется
Набор регрессионных тестов, который выполняется целый рабочий день — это не то, чего ждет команда. Нужны тесты, выполняющиеся как можно быстрее, чтобы команда быстрее поняла, где проблемы. Ускорять автоматизацию можно несколькими способами. Лучше всего делать больше API-тестов, вместо UI-тестов; а в API-тестах стараться больше тестировать саму логику функций. Есть еще банальные пути: например параллельное выполнение тестов.
6. Тест выполняется в нужное время
Хороший тестировщик стремится провести как можно больше тестов и как можно быстрее. Не всегда это эффективно. Smoke-тесты — хороший способ «срезать углы» при недостатке времени, например, когда приближается деплой. Вообще, мы у себя в QA-отделе делаем довольно мало smoke-тестов, но все равно довольно четко видим, как ведет себя билд. Нормальная практика — запускать большой набор регрессионных тестов когда позволяет время, например, запускать такой тестовый набор ночью.
Как видишь, разобраться, какой автотест хороший — не так просто, отталкиваясь лишь только от метрик. Надо хорошо изучить продукт, понимать главные фичи, уметь быстро оценивать тест на качество кода и валидность.”
Подробнее об автоматизации тестов
Возможно будут интересны Ловушки автоматизации (и 9 советов, как в них не попасть)
