В современной разработке программного обеспечения роли четко распределены: разработчики пишут код, системные аналитики формируют требования, а QA‑инженеры обеспечивают качество. Но что происходит, когда компания решает нарушить это равновесие и нанять опытных разработчиков без QA бэкграунда в отдел тестирования? Наш опыт показал, что это может привести к неожиданным результатам.

Исходная ситуация в компании

В нашей компании руководитель имеет разработческий бэкграунд, поэтому в производственных процессах основную ответственность за все этапы создания продукта несут разработчики. Quality Assurance инженеры выполняют вспомогательные роли, по сути являясь лишь Quality Checker'ами, не имеющими решающего голоса в процессе разработки.

При этом в компании наблюдается катастрофическая нехватка QA‑инженеров и системных аналитиков при переизбытке разработчиков. Один тестировщик обычно работает на 5–7 активно пишущих код разработчиков. В условиях явного недостатка аналитиков всю работу по формированию требований вынуждены делать разработчики.

Проблемы с требованиями и документацией

Документация в компании пишется очень слабо, так как разработчики не привыкли к её формированию. При этом все знания о продукте сосредоточены именно у них. От системных аналитиков поступают лишь базисные требования, они перерабатываются разработчиками, но те не выдают четко описанные спецификации так как это должны делать аналитики.

В результате тестировщики вынуждены идти к разработчикам и в частных беседах получать требования. Это накладывает серьезный отпечаток на работу QA‑команды, которая должна не только тестировать новые функции, проводить регрессионное тестирование и создавать автотесты, но и заниматься сбором и систематизацией требований.

Эксперимент: разработчики в роли QA

Руководитель компании решил, что отдел QA нужно усилить профессионалами с девелоперским бэкграундом. Учитывая, что на рынке сейчас много свободных разработчиков с большим опытом, он нанял в Quality Assurance несколько специалистов с 15-летним стажем разработки. Один из них был назначен лидом команды.

Руководство справедливо предполагало, что опытные разработчики смогут эффективнее выполнять роль QA и это создаст дополнительный импульс в повышении качества продукта. Все замерли в ожидании того, как QA‑команда «рванет к светлым высотам».

Неожиданные результаты

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

Часть тестировщиков через несколько месяцев не выдержала постоянной пропаганды того, что «мануальщина — это плохо, автоматизация — это хорошо» и уволилась. Это усугубило и без того сложную ситуацию, ведь когда QA‑инженер обслуживает 7 активно пишущих разработчиков, у него едва хватает времени на проверку новых функций, не говоря уже о нормальной автоматизации.

Специфика подхода разработчиков к тестированию

Разработчики, перешедшие в QA, начали писать автотесты, которые по подходу напоминали юнит‑тесты — это типичный подход девелоперов к тестированию. Для остальных QA‑инженеров это стало удивлением, поскольку обычно QA оставляет юнит‑тестирование разработчикам, а сам занимается интеграционными тестами.

Понимание специфики подхода разработчиков к тестированию пришло, когда на презентации своих автотестов один из бывших разработчиков представил обширные тесты, которые покрывали весь код, над которым он работал несколько месяцев. Когда ему задали вопрос, почему он тестировал функциональность, которую по требованиям не нужно было покрывать (так как она реализована в другом блоке), он с улыбкой ответил: «Я не читаю требования перед тем, как тестировать. Я не доверяю разработчикам и покрываю все сплошным ковром».

Это вызвало настоящий шок среди тестировщиков, ведь для них первое правило тестирования — изучить требования, чтобы сфокусировать силы на покрытии тех функций, которые действительно нужны.

Когнитивные диссонансы и противоречия в подходах

С самого начала взаимодействия с новыми тестировщиками, имеющими опыт разработки, у меня как у тестировщика возникло несколько когнитивных диссонансов. Первое, что настораживало — разработчики‑тестировщики в корне не доверяли своим коллегам‑разработчикам и имели с ними очень плохие контакты. Казалось бы, должно было быть наоборот, ведь разработчик должен понимать разработчика, но, похоже, разработчик в роли тестера относится к обычному разработчику с недоверием.

Новые тестировщики постоянно говорили о том, что разработчики всё делают неправильно и плохо. Это лишало их важного взаимодействия с командой разработки, а ведь именно разработчики из‑за специфики компании являлись носителями основных требований к продукту.

Второй тревожный момент — они не ставили во главу угла тестирования требования. У них отсутствовала культура, которая формируется у профессиональных тестировщиков: требования в основе всего. При любом подходе к тестированию сначала нужно иметь четкие требования — описанные или найденные самостоятельно. Без требований нельзя приступать к тестированию, тем более к написанию автотестов.

У тестировщиков‑разработчиков этого понимания не было. Они не обращались к разработчикам и аналитикам для уточнения требований. На вопросы о наличии требований они отвечали: «Мы сами умные, мы пойдем в код, который написали разработчики, и там всё увидим». Это вызывало удивление, но на тот момент мы просто ждали, что будет дальше.

Еще один настораживающий момент — написание автотестов. Разработчики‑тестировщики сразу установили высочайшие стандарты написания кода с непременным использованием PageObject фреймворков, с «чистым кодом», следующим принципам DRY и SOLID. Они требовали полного соблюдения объектно‑ориентированного программирования с множеством уровней абстракции.

Это удивляло, потому что на проекте, который постоянно развивается, автотесты с большим уровнем абстракции всегда страдают от «premature abstraction» — преждевременной абстракции. Высокий уровень абстракции негативно влияет на поддерживаемость тестов. Когда требования быстро меняются, чтобы исправить тесты, нужно проходить через все эти уровни абстракции.

Для развивающегося кода я предпочитал inline‑тестирование: в одном файле всё — и обращение к клиенту, и верификация, и создание моделей без абстракции. Такие тесты, хоть и выглядели громоздкими, были понятны и легко поддерживались.

Я пытался отстоять свою точку зрения на фреймворк для автотестов, но разработчики‑тестировщики сказали фразу, которая меня насторожила: «Лучше иметь не работающий код, но очень понятный, который можно отредактировать, чем непонятный, но работающий код». Стало ясно, что для них важнее не функциональность, а «чистота» кода по их представлениям.

В результате все старые автотесты были признаны негодными, созданы новые репозитории с новыми фреймворками. Со временем эти опасения подтвердились: создание «чистого кода» вылилось в крайне медленную разработку автотестов и их полную неподдерживаемость. Поскольку код продукта очень быстро менялся, чтобы поддерживать базу автотестов, приходилось постоянно переписывать все абстрактные классы.

Пренебрежительное отношение к требованиям привело к тому, что разработчики‑тестировщики начали покрывать автотестами абсолютно неважные и даже несуществующие функции. Для покрытия одного проекта, на который обычному тестировщику требовалась неделя, у них ушло три месяца. Они покрыли абсолютно всё автотестами, и 90% этой работы было абсолютно не нужно.

Выводы

Проведенный эксперимент позволяет сделать ряд важных выводов о том, почему разработчики не могут эффективно выполнять роль QA‑инженеров:

1. Фундаментальное различие в подходах. Разработчики и тестировщики имеют принципиально разные подходы к работе с продуктом. Разработчики ориентируются на код и техническое совершенство, тогда как QA‑инженеры фокусируются на требованиях и пользовательском опыте.

2. Отношение к требованиям. Профессиональные QA‑инженеры ставят требования во главу угла тестирования, в то время как разработчики‑тестировщики склонны игнорировать их, полагаясь на собственное понимание кода.

3. Подход к автоматизации тестирования. Разработчики переносят в тестирование практики разработки кода (высокая абстракция, следование принципам SOLID, DRY), что может быть контрпродуктивно для поддерживаемости тестов при быстро меняющихся требованиях.

4. Распределение ресурсов. Разработчики‑тестировщики нерационально используют ресурсы, тратя время на покрытие автотестами малозначимой или даже несуществующей функциональности.

5. Коммуникационные барьеры. Парадоксально, но разработчики в роли тестировщиков склонны не доверять другим разработчикам, что создает дополнительные коммуникационные барьеры в команде.

6. Дисбаланс между автоматизацией и мануальным тестированием. Чрезмерный акцент на автоматизацию в ущерб мануальному тестированию приводит к уходу опытных мануальных тестировщиков и дополнительной нагрузке на оставшихся.

7. Эффективность и скорость работы. Стремление к «идеальному коду» для автотестов значительно замедляет процесс тестирования и создает проблемы с поддержкой этих тестов при изменении кода продукта.

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