Как пирамида тестирования уплывает на сторону разработки
Всем привет! Я занимаюсь автоматизацией тестирования уже больше 10 лет. Нельзя сказать, что я вижу весь рынок — в конце-концов я подолгу работаю на своих проектах, а не прыгаю между ними. Так что даже за десятилетие успел посмотреть не так много. Но в последнее время я начал замечать тенденцию, которая мне не очень нравится — тестирование все больше уходит к разработчикам.
Возможно, на самом деле все иначе, а у меня работает известное искажение, когда ты во всем окружающем мире ищешь подтверждение своей теории. Видите ли вы то же, что вижу я?
Как нейросеть представляет себе погружение пирамиды тестирования на сторону разработки
Дисклаймер:
Я давно работаю на своем проекте. Езжу по конференциям и иногда почитываю статьи, но не претендую на объективный взгляд на рынок. То, что я изложу ниже, — исключительно мое мнение и ни в коем случае не всесторонний анализ. Поправьте меня, если я неправ.
Пирамида тестирования
Все мы знаем эту картинку:
Часть тестирования — например, юнит-тесты — всегда лежали на плечах разработчиков. Можно представить, что где-то там, между юнит- и интеграционным тестированием — и был уровень разделения ответственности между разработчиками и тестировщиками. Но я заметил, что в последнее время на разработчиков вешают и следующие уровни пирамиды. Она как будто смещается в сторону разработки. Вот пример: https://habr.com/ru/companies/maxilect/articles/722142/
Вижу в этом нарушение принципа, согласно которому каждый должен заниматься своим делом, поскольку он может делать его хорошо. Разработчикам, конечно, в такой схеме предлагают некие курсы, которые вводят в общее понимание тестирования — как писать кейсы, как покрывать ими приложение. Но хватает ли этого?
Я очень люблю свою профессию и уверен, что если разработчиком можно стать, то тестировщиком нужно родиться. Некоторым вещам невозможно научиться — нужно, чтобы мозги работали определенным образом. Тестировщику нужна не только техническая база, но также внимательность, усидчивость и критическое мышление. Полно внимательных людей, кто не готов быть усидчивым, и наоборот, усидчивые, но не внимательные (хотя с первого взгляда кажется, что вещи эти связаны). Счастье, если случайно задачи тестирования падают на разработчика, который имеет нужные качества, просто в свое время почему-то выбрал другой путь. Но чаще это не так. Я вижу, что люди даже иногда горят тестированием, не обладая при этом всем необходимым.
Попытка объяснить
Кажется, что разработчиков с годами становится все больше. Это и логично — у компаний появились деньги и объяснение, что эта работа действительно столько стоит. Они предлагают все больше рабочих мест с хорошим доходом. Так что выпускники (да и не только выпускники — все, у кого есть силы) идут в разработку.
Отдельные публичные персоны даже высказываются о том, что рынок близок к насыщению. Помнится Греф сравнивал ситуацию с разработчиками с ростом популярности юристов и экономистов в начале нулевых. Спорное утверждение, но, возможно, ему виднее.
Есть в разработке насыщение или нет, судить не возьмусь. Но в тестировании такого насыщения нет точно — на рынке никогда не было слишком много квалифицированных тестировщиков. Такое ощущение, что их количество вообще не меняется. А поскольку разработчиков все больше, доля тестировщиков естественно падает.
Возможно, преобразование тестирования из специальности в роль, которую можно выдать разработчику, аналитику или даже техническому писателю, объясняется как раз желанием покрыть имеющиеся задачи малым количеством квалифицированных специалистов. Тестировщик (как специалист) начинает руководить качеством, а задачи, связанные с автоматизацией тестирования падают на коллег.
Как это на практике
У меня складывается ощущение, что команды, которые начинают эксперименты с тестированием, сами до конца не определились, что же они хотят. Ощущение, будто тестировщик (который, как я писал выше, руководит качеством) должен подойти к разработчику, выдать подзатыльник и сказать: «Делай хорошо!». И все заработает. Кажется, что при этом тот, кто «рожден тестировщиком», должен научить разработчика тоже «быть рожденным». Мне результат этого кажется сомнительным.
Со стороны разработчиков, кажется, ситуация настолько же странная. Разработку и так пытаются всячески ускорить — конкуренция на рынке высока, компании пытаются друг у друга урвать долю клиентов, выпуская решения как можно быстрее и с большим количеством фич. Всю эту нагрузку разработчики тянут и без всякого тестирования. А когда на разработчиков перекладывают часть задач по тестированию, он же все равно должен тратить время и на решение собственных задач — пилить те самые фичи, которых нужно все больше и больше. Где на все взять время?
В итоге я вижу в целом падение качества на рынке. В приложениях, которыми пользуются миллионы, как эдакие пузыри, всплывают ошибки, которые чинят только через месяцы. Это огромный срок для таких решений. Но замечаю я это не в одном приложении какой-то компании, а повсеместно.
Ответа, как это должно работать на самом деле в современных условиях бизнеса, у меня нет. Возможно, как раз так и должно быть, и тогда смещение пирамиды тестирования вполне в порядке вещей.
А как вы думаете?
P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на нашу страницу в VK или на Telegram-канал, чтобы узнавать обо всех публикациях и других новостях компании Maxilect.
