Когда все владеют качеством, никто этого не делает
За последние несколько лет я заметил растущую тенденцию в компаниях-разработчиках программного обеспечения, когда высшее руководство заявляет, что роли обеспечения качества в компании больше не существуют. Затем весь отдел контроля качества либо увольняется, либо переводится на традиционные роли разработки программного обеспечения. Все теперь просто инженеры-программисты, и качество принадлежит каждому.
Это ошибка.
Я бы сказал, что идея о том, что качество принадлежит всем, хоть и положительна по своим намерениям, глубоко ошибочна по одной важной причине: качество принадлежит всем, но никому не принадлежит.
Да, каждый программист должен гордиться своей работой. Да, каждый инженер-программист должен тщательно тестировать свой код как вручную, так и с помощью автоматических тестов. Да, каждый инженер-программист должен рассматривать не только счастливый путь, но и искать крайние случаи и случаи, когда что-то может пойти не так. Все эти вещи хороши.
Но у инженеров-программистов и QA-инженеров просто разные взгляды. Инженеры-программисты хотят что-то создавать. QA-инженеры хотят увидеть, как они могут что-то сломать. Инженеры-программисты вынуждены предоставлять новые функции. Инженеры по контролю качества должны обеспечить бесперебойную работу приложения для клиентов.
Так почему бы просто не обучить инженеров-программистов качественному мышлению, скажете вы? Конечно, это нормально. Просто знайте, что переход между этими двумя образами мышления в течение дня — немалый подвиг. Управлять временем между разработкой программного обеспечения и задачами контроля качества тоже непросто.
Также есть разница в наборе навыков. Обычно ожидается, что инженеры-программисты будут иметь опыт работы с одним или двумя языками программирования и фреймворками в технологическом стеке компании и уметь создавать продукты с помощью этих инструментов. Ожидается, что QA-инженеры будут иметь опыт тестирования таких фреймворков, как Selenium, Pytest, Cypress или Playwright, и уметь писать надежные наборы тестов с помощью этих инструментов.
Так почему бы вам просто не обучить инженеров-программистов другой среде тестирования? Конечно, это нормально. Просто знайте, что вы добавляете это в список всего остального, что должны делать инженеры-программисты. Мы все должны быть полноценными инженерами, экспертами как в области фронтенд-, так и бэкэнд-разработки, безопасности, доступности, локализации, DevOps, а теперь и тестирования.
Как звучит поговорка? «Мастер на все руки — не мастер ни в чем».
Или вы предпочитаете альтернативную концовку? «Мастер на все руки не мастер ни в чем, но часто лучше, чем мастер в одном».
Ученые спорят о происхождении этой фразы, но в целом признают, что вторая строка была добавлена позже. Тем не менее, нельзя отрицать, что в постоянно расширяющейся и гиперспециализированной области разработки программного обеспечения просто невозможно стать мастером во всем. Да, мы можем научить инженеров-программистов использовать дополнительные среды тестирования, но их опыт никогда не будет таким глубоким, как у тех, кто занимается исключительно контролем качества.
Самая большая проблема возникает при тестировании сквозных функциональных частей, созданных несколькими командами. Без QA-организации возникают вопросы собственности.
Кто отвечает за проверку этой функциональности? Кому принадлежит обновление и поддержка общего набора тестов? Кто определяет, какой уровень покрытия является приемлемым, и кто обеспечивает соблюдение этого требования? Как насчет фактической инфраструктуры набора тестов и обслуживания конвейера? Кто владеет этим?
В общем, популярное руководство состоит в том, чтобы создавать самоорганизующиеся многофункциональные команды, которые могут работать независимо друг от друга, создавая, тестируя, развертывая и поддерживая свои собственные зоны ответственности. Это хороший совет.
Но совет начинает ломаться, как только вы достигаете каких-либо границ, которые необходимо проверить между командами. Без формального ответственного за обеспечение качества общие тестовые наборы и сквозные тесты придут в упадок. Стандарты перестанут применяться. Покрытие уменьшится. Качество снизится. Энтропия неизбежна.
Я видел, как это произошло. Дважды.
Избавляться от всех ваших QA-инженеров — ошибка.
