ATDD: 3 ошибки, которые допустили я и мой тестировщик

Началось все с того, что мне пришлось работать с одной веб-конторой и заказчиком, которые понятия не имели об автоматическом тестировании.

К сожалению, ситуация на рынке такова, что, если ты имеешь дело с веб-студией, заточенной под PHP, то в 80% случаев это говнокодинг программисты кодируют без использования автоматических тестов (как модульных, так и пользовательских).

Мой же проект был написан на ASP.NET, и нужны были тесты уровня приложения (application-level tests). По идее, разработкой этих тестов должны заниматься сами пользователи (при поддержке программистов). Причем тесты должны писаться и запускаться для функциональности, которая еще не существует. Такой стиль называется разработкой, основанной на тестах уровня приложения (ATDD, Application Test-Driven Development).

К сожалению, реальность немного суровее, чем пишут в учебниках. И в моем случае ни пользователи, ни разработчики не знали об автоматических тестах, тем более, что тесты нужно писать до написания кода. Кстати, в той компании до сих пор все тестирование проводится вручную и является самым слабым звеном в разработке, из-за которого тормозится выпуск как продуктов, так и апдейтов к ним. Если эта статья заслужит респект, то, надеюсь, она заставит задуматься как заказчика, так и разработчиков об изменении своего взгляда на качество разработки ПО в компании.

Я же со своей стороны поделюсь своим опытом, как мне удалось добиться написания автоматических тестов уровня приложения от компании, которая ни разу этого не делала и не знала об этом.

Итерация 1. Мной было написано подробное ТЗ, что именно нужно автоматически протестировать + выслан видеоурок, как писать автоматические тесты для веб-интерфейсов (был использован Selenium IDE). И, как Вы думаете, что мне пришло в ответ? Тестировщик просто написала, что у нас «есть баги».

Итерация 2. То, что нужны именно автоматические тесты, тестировщику было донесено отдельным сообщением. И, хвала небесам, автоматические тесты все же появились, но они были, мягко говоря, далеки от идеала.

3 ошибки, которые допустили я и мой тестировщик

Ошибка 1. Названия тестов не отражали их содержание. Т.е. тесты были именованы в духе Phone1, Email2 и пр. вместо того, чтобы назвать их, например, EmailHasIllegalChars. Т.е. при прогоне тестов, если какой-то тест не срабатывает, хотелось бы видеть из названия, что именно поломалось, а не лезть внутрь теста и не тратить время на выяснение того, что же он на самом деле тестирует.

Ошибка 2. Тесты не заканчивались оператором assert. Если честно, для меня это было шоком. Т.е. фактически IDE просто считывала ввод и по сути тест ничего автоматически не проверял, перекладывая проверку вывода на плечи тестировщика. Видимо, человеку, который первый раз пишет подобные тесты, действительно тяжело смириться с тем, что тестировщику не нужно самому следить за тестами и оценивать их результаты; тесты нужно только писать таким образом, чтобы они заканчивались каким-то булевским выражением (подойдут операторы assert или verify).

Ошибка 3. Тесты не были сохранены в один набор. Тестировщик передала мне OVER9000 маленьких файликов без единого Test Suite. Собирать их потом в один набор как-то не айс.

Конечно, это были, прежде всего, мои ошибки как менеджера. К сожалению, я больше разработчик, чем эффективный менеджер. Поэтому на 2-ой итерации мое терпение закончилось, и вышеописанные ошибки были исправлены уже мной.

Тем не менее, этот опыт показывает, что можно работать с любыми тестировщиками и добиваться от них нужного результата. Поэтому, если Вам нужно будет что-то протестировать, а под рукой будет только фриланс с исполнителями сомнительной компетенции, возьмите вышеописанное на заметку и включите в ТЗ, чтобы повысить качество результата.