Жила-была компания, разрабатывавшая программные продукты. И были в ней тестировщики. И тестировали они денно и нощно, а продукт был отстойным. То они какое-то требование пропустят и не заметят, а пользователь жалуется, и тестировщики виноваты: надо внимательнее требования читать. То багу критичную, возникшую за 2 часа до релиза, не найдут, и снова это их вина: тестировать надо больше. Пользователь не доволен даже реализованными требованиями: а почему вы их не протестировали? Продукт работает медленно в окружении заказчика: а почему вы это не выявили? Выпущенные ошибки беспокоят пользователя: а почему вы не донесли достаточно внятно информацию об их критичности? Долго команда и тестировщики так и сосуществовали. И всем, даже тестировщикам, казалось такое положение вещей правильным. Они всё время работали над собой, ища, как они могут решить ту или иную проблему. Потому, что считали такие проблемы СВОИМИ. Но как-то раз древний мудрец по разработке ПО проходил мимо их офиса. Заглянул он к ним, увидел происходящее, и заявил: “Ребята, вы, конечно молодцы… Но вы решаете чужие проблемы!”. “Как так?”, – удивились тестировщики. “А вот так», – ответил мудрец, – “давайте я покажу, как это работает в более зрелых компаниях”. И вместе с ними нарисовал примерно следующую табличку:
| Проблема | Как её решать правильно | Как её могут компенсировать тестировщики |
| Недостаточно хорошо выявляются требования | На проекте обязательно должна быть роль бизнес-аналитика, который общается с пользователями, анализирует целевую аудиторию, и прорабатывает наилучшие способы решения пользовательских задач. | Тестировщики могут тестировать требования, и, не имея достаточного контакта с пользователями, придумывать, что в этих требованиях не так, и как это можно улучшить. |
| Недостаточно точно фиксируются требования, в результате чего их тяжело понимать разработчикам и тестировщикам | Ввести управление требованиями в соответствие с ключевыми критериями хороших требований: атомарностью, трассируемостью, измеримостью и т.д. В этом случае прямо по требованиям можно помечать их статус готовности и качество их работы. | Ходить по всей команде и выяснять, что и как должно правильно работать. Создавать чек-листы, чтобы нивелировать риски пропуска функционала в тестировании. Поддерживать в актуальном состоянии тестовую документацию, чтобы обрабатывать изменения в ПО. |
| Сборки часто плохого качества, в них много ошибок | Внедрить юнит-тесты и TDD, ревью кода. Контролировать стабильность каждой сборки на уровне разработки. | Тестировать 100500 раз одно и то же, проверяя, что ничего не сломалось. Максимально сокращать сроки тестирования за счёт автоматизации. |
| Продукт сложно поддаётся системной (высокоуровневой) автоматизации | Заложить тестируемость на уровне архитектуры продукта. Предоставлять стабильные интерфейсы для автоматизированного тестирования. | Писать плоход в плохотестах, разрабатывать множество костылей, делать неэффективные автотесты и тратить на них уйму своих ресурсов. Разрабатывать модульные и юнит-тесты за разработчиков, у которых нет на это времени, а интерфейсные тесты кликать мышкой. |
| Маленькое тестовое покрытие, нехватка комбинаторных тестов и тестов на нестандартные ситуации | Глубокое юнит-тестирование. Совместное обсуждение архитектуры продукта тестировщиками и разработчиками для понимания необходимости тех или иных тестов. | Фигачить больше тестов, в надежде, что какие-то из них окажутся полезными. Повторять их запуски многократно. Расширять команду тестирования за счёт студентов. |
| Большая длительность релизного цикла, медленная разработка | Чистый код и грамотный техлид, внедряющий инженерные практики. Совместная командная работа над качеством. | Быстрее тестировать. Раньше находить ошибки. Расширять команду. Приоритизировать тесты и отбрасывать всё на что не хватает времени, зажав кулачки “лишь бы это не оказалось важным”. |
Тестировщики смотрели на табличку, которая получилась у мудреца, и удивлялись. — Но если в нашем процессе всё будет, как ты предложил в колонке с “правильным” решением, то мы будем не нужны? — Будете, – ответил мудрец. – Но вы не будете выполнять мартышечий и бессмысленный, малоэффективный труд. Вы сможете больше внимания уделять исследовательскому тестированию нового функционала, разработке грамотных и стабильных автотестов, и внедрению метрик и практик качества. — Но ведь такого “хорошего” процесса не бывает! Это же миф! — Хи-хи, – улыбнулся мудрец. — Я видел такие компании. Я знаю, какой тяжёлый путь они прошли, и эти сложности были связаны в основном с кашей в головах участников процесса, а не с реальными проблемами. В этих компаниях работать приятно, а продукты вызывают гордость команды. — Но как нам найти такую компанию? — Не надо искать. Сделайте это в своей компании! Да, вы просто тестировщики. Но вы и так уже достаточно давно занимаетесь тем, что решаете ЧУЖИЕ проблемы. Так начните их решать правильно! Промойте мозги своему начальнику, покажите ему эту статью. Отправьте его на конференцию, пусть отвлечётся от своей псевдополезной деятельности. Выявите, какая проблема у вас самая сильная – и предложите её решения, познакомьтесь с правильными действиями в этой ситуации, и начните это внедрять сами. Иначе вы так навсегда и останетесь козлами отпущения, виноватыми за чужие проблемы – и ни капельки не влияющими на качество продукта!