Всем привет! Я занимаюсь автоматизацией тестирования уже больше 10 лет. Нельзя сказать, что я вижу весь рынок - в конце-концов я подолгу работаю на своих проектах, а не прыгаю между ними. Так что даже за десятилетие успел посмотреть не так много. Но в последнее время я начал замечать тенденцию, которая мне не очень нравится - тестирование все больше уходит к разработчикам.
Возможно, на самом деле все иначе, а у меня работает известное искажение, когда ты во всем окружающем мире ищешь подтверждение своей теории. Видите ли вы то же, что вижу я?
Дисклаймер:
Я давно работаю на своем проекте. Езжу по конференциям и иногда почитываю статьи, но не претендую на объективный взгляд на рынок. То, что я изложу ниже, - исключительно мое мнение и ни в коем случае не всесторонний анализ. Поправьте меня, если я неправ.
Пирамида тестирования
Все мы знаем эту картинку:
Часть тестирования - например, юнит-тесты - всегда лежали на плечах разработчиков. Можно представить, что где-то там, между юнит- и интеграционным тестированием - и был уровень разделения ответственности между разработчиками и тестировщиками. Но я заметил, что в последнее время на разработчиков вешают и следующие уровни пирамиды. Она как будто смещается в сторону разработки. Вот пример: https://habr.com/ru/companies/maxilect/articles/722142/
Вижу в этом нарушение принципа, согласно которому каждый должен заниматься своим делом, поскольку он может делать его хорошо. Разработчикам, конечно, в такой схеме предлагают некие курсы, которые вводят в общее понимание тестирования - как писать кейсы, как покрывать ими приложение. Но хватает ли этого?
Я очень люблю свою профессию и уверен, что если разработчиком можно стать, то тестировщиком нужно родиться. Некоторым вещам невозможно научиться - нужно, чтобы мозги работали определенным образом. Тестировщику нужна не только техническая база, но также внимательность, усидчивость и критическое мышление. Полно внимательных людей, кто не готов быть усидчивым, и наоборот, усидчивые, но не внимательные (хотя с первого взгляда кажется, что вещи эти связаны). Счастье, если случайно задачи тестирования падают на разработчика, который имеет нужные качества, просто в свое время почему-то выбрал другой путь. Но чаще это не так. Я вижу, что люди даже иногда горят тестированием, не обладая при этом всем необходимым.
Попытка объяснить
Кажется, что разработчиков с годами становится все больше. Это и логично - у компаний появились деньги и объяснение, что эта работа действительно столько стоит. Они предлагают все больше рабочих мест с хорошим доходом. Так что выпускники (да и не только выпускники - все, у кого есть силы) идут в разработку.
Отдельные публичные персоны даже высказываются о том, что рынок близок к насыщению. Помнится Греф сравнивал ситуацию с разработчиками с ростом популярности юристов и экономистов в начале нулевых. Спорное утверждение, но, возможно, ему виднее.
Есть в разработке насыщение или нет, судить не возьмусь. Но в тестировании такого насыщения нет точно - на рынке никогда не было слишком много квалифицированных тестировщиков. Такое ощущение, что их количество вообще не меняется. А поскольку разработчиков все больше, доля тестировщиков естественно падает.
Возможно, преобразование тестирования из специальности в роль, которую можно выдать разработчику, аналитику или даже техническому писателю, объясняется как раз желанием покрыть имеющиеся задачи малым количеством квалифицированных специалистов. Тестировщик (как специалист) начинает руководить качеством, а задачи, связанные с автоматизацией тестирования падают на коллег.
Как это на практике
У меня складывается ощущение, что команды, которые начинают эксперименты с тестированием, сами до конца не определились, что же они хотят. Ощущение, будто тестировщик (который, как я писал выше, руководит качеством) должен подойти к разработчику, выдать подзатыльник и сказать: “Делай хорошо!”. И все заработает. Кажется, что при этом тот, кто “рожден тестировщиком”, должен научить разработчика тоже “быть рожденным”. Мне результат этого кажется сомнительным.
Со стороны разработчиков, кажется, ситуация настолько же странная. Разработку и так пытаются всячески ускорить - конкуренция на рынке высока, компании пытаются друг у друга урвать долю клиентов, выпуская решения как можно быстрее и с большим количеством фич. Всю эту нагрузку разработчики тянут и без всякого тестирования. А когда на разработчиков перекладывают часть задач по тестированию, он же все равно должен тратить время и на решение собственных задач - пилить те самые фичи, которых нужно все больше и больше. Где на все взять время?
В итоге я вижу в целом падение качества на рынке. В приложениях, которыми пользуются миллионы, как эдакие пузыри, всплывают ошибки, которые чинят только через месяцы. Это огромный срок для таких решений. Но замечаю я это не в одном приложении какой-то компании, а повсеместно.
Ответа, как это должно работать на самом деле в современных условиях бизнеса, у меня нет. Возможно, как раз так и должно быть, и тогда смещение пирамиды тестирования вполне в порядке вещей.
А как вы думаете?
P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на нашу страницу в VK или на Telegram-канал, чтобы узнавать обо всех публикациях и других новостях компании Maxilect.
Комментарии (14)
panzerfaust
27.06.2024 09:57+5В итоге я вижу в целом падение качества на рынке
Странный у вас вывод. Я тот самый разработчик, на которого "взвалили" все от юнитов до интеграционных тестов. Как результат - у нас почти нет багов на команде бэкенда. Никто не бегает с горящей дупой и не затыкает дыры на проде. А значит больше времени на проработку фичей, рефакторинг, апгрейд зависимостей и прочие вещи, которые на хабре традиционно считаются чем-то нереальным. Я сейчас даже подумал, что не согласился бы работать в команде с более слабой культурой тестирования. К хорошему привыкаешь.
iverzin
27.06.2024 09:57На одном из самых первых проектов, в далеком прошлом я спросил начальника: "А мы будем тестировать то что делаем?" Он очень удивленно посмотрел на меня и ответил: "А зачем? Мы сразу будет без ошибок писать".
Вам есть куда стремиться.
Batalmv
27.06.2024 09:57+4Я прочитал и статью, на которую вы ссылались, и вашую Скажу так:
Попробовать работать без тестировщиков - Д-а-а-а-а-а-а!!!! Во-первых новый опыт. Во-вторых практика показала, что тестировщики все равно требования не покрывают и баги вылезают.
Т.е. получается, что усложняются процессы, тратится время, а толк неясен
-----------------------
Но все упирается, как по мне, в чуток иной вопрос. А именно в необходимость проверки написанного кода, собранного в виде приложения на соответствие требованиям. Для этого надо чтобы мистер Х
прочитал эти требования
осознал
определил для себя противоречия, серые зоны, места, требующие уточнения
подготовил тестовые сценарии и данные
выполнил проверки
Этот список понятно не претендует на полноту, но такой цели и не ставится. Вопрос в том, ху из мистер Х
И вот тут есть главная проблема, которая не зависит от роли человека в команде:
если аналитик реально не проработал требования - то уже есть проблема в начальной точке
если разработчик не поработал с требованиями - то код будет точно так себе
если тестировщик на поработал с требованиями - то итог его тестирования будет мало кому нужен
Т.е. все упирается "работа с требованиями".
-----------------
Соответственно задача "нужны тестировщики или нет" трансофрмируется в задачу, какая часть команды "работает" с требованиями, а какая - нет и почему. И от ее решения зависит, нужны ли тестировщики.
Если к примеру, разработчик просто делает таски из Джиры по тому, что написано и "не парит" - точно кто-то нужен после него. А вот если нет ...
Т.е. решение сводится к тому, как стимулировать разработчика больше работать с требованиями, о чем во многом и говориться в статье, на которую вы ссылаетсь
---------------
Теперь к изначальному вопросу. Скажу откровенно и фиг меня кто переубедит (шутка конечно, но в ней есть доля правды и реального опыта), что ничего уникального в навыкам и умениях тестировщика нет.
Технически обычно разработчик на голову выше, по знанию предметной области там же обитает аналитик. Исключения редки, и обычно встречаются в роли опытного лида, который сидит в конторое много лет, попадает в баги даже с завязанными глазами еще до того, как пришел релиз, и вообще - смысла идти куда-то нет, так как платят норм, должность руководящая и тебя и так все уважают, потому что есть за что. Да, такие спецы есть, но их никто убирать не будет, наоборот. Ну и обычно с такими лидами связана либо сложная предметная область, либо система или набор систем, где знания для их тестирования безценны
Но раз в общей массе никаких hard skills за средним тестировщиком нет, его единственная ценносте - это как раз умение "работать с требованиями" и закрыть все, о чем не подумали те, кто до него. Но тут зависит от состава команды, при сильном лиде, который шарит и в предметной области и знает, как вложить это знание дозированно другим разрабам - я думаю, отказаться от тестировщиков в пользу разрабов будет воможно. Иначе ... чуда не будет
Аналитик, даже классный, просто загнется пасти каждого разраба
-----------
По опыту ... я вообще работал, когда у нас и аналитиков то не было, не то что тестировщиков. Лид вполне мог снять требвования, закрыть вопрос ТЗ и т.д. Просто были реальные "универсальные" бойцы, которые могли и решение развернуть, и в командировку метнуться для пусконаладочных работ, и код написать/проверить. И все работало.
Поэтому только разработчик пока незаменим, пока пишет код. Остальные - как собертся паззлик
iverzin
27.06.2024 09:57Я вам больше скажу. Даже разработчик не обязателен. Знавал конторы где они были чисто номинально, а бюджеты осваивали.
Thomas_Hanniball
27.06.2024 09:57+1"Тестирование уплывает на сторону разработки".
Да, всё так и есть. Вам не показалось. Такое смещение, действительно, сейчас происходит в области разработки ПО.
Причина простая - внедрение в компаниях методологии Devops, где почти всё тестирование становится автоматизированным и встроенным в конвейер разработки ПО.
Мало того, даже задачи по эксплуатации получившегося ПО тоже постепенно ложатся на плечи разработки или DevOps\SRE, а не на команду эксплуатации, как это было раньше.
Считается, что такой подход:
- Позволяет избегать проблем в общении между dev и ops, dev и тестировщиками.
- Уменьшает количество людей в цепочке создания ценностей, что увеличивает скорость работы и избавляет от лишней бюрократии.
- Повышает ответственность разработчиков за результат своей работы.
- Заставляет разработчиков создавать ПО с оглядкой на удобство его дальнейшей эксплуатации.
- Ускоряет time-to-market, что очень радует бизнес.
Chelyuk
27.06.2024 09:57Мир изменился. Я чувствую это по воде. (с)
Просто всё больше и больше мир зависит от программных продуктов. А как следствие - продукты усложняется. Из этого же вытекает, что команда разработки - это уже не просто разработчик и тестировщик. Есть Software Development Engineer, Software Development Engineer in Testing, QA Engineer, Business Analytic, Product Owner, Project Manager, Test Manager, Software Architector, Test Architector, Solution Architector, Electronic Engineers, Mechanic Engineer, HW Test Engineer, System Test Engineer, DevOps Engineer, DevSecOps Engineer etc.
Тут уже не так просто провести линию и сказать кто из этих ролей тестировщик, а кто разработчик.
Но концептуально, эти роли нельзя смешивать, потому как мышление противоположное.
Из своего опыта я видел только такие случаи. Мышление разработчика: один раз сработало - значит работает.
Мышление тестировщика: один раз не сработало - значит не работает.
И так и должно быть, а потом уже возникает коммуникация и в этом споре рождается истинна.
Вероятно существуют разработчики, знакомые с всевозможными пирамидами тестирования, всеми видами и типами тестирования, а также владеющими всеми методиками. Но, лично мне такие не попадались. Максимум, что я видел, они создали очень много различных тестов. Но когда, подходит вопрос, а какие тесты собственно нужно запускать и в каких случаях. Самый частый ответ - все и всегда. И вот тут как раз и приходят на помощь pair wise таблицы, граничные значения, классы эквивалентности, распределение quality gates, построение пирамиды под продукт, а не просто взять из книги/интернета, определение какие виды тестирования закрыть самим, а где подключить подрядчиков ну и Test Plans соответственно. И чтобы всё это подгадать к нужному релизу. Ну и время тест рана не стремилось к бесконечности.
Плюс до сих пор не осел туман войны Agile universal team VS Universal Engineer. Уж очень последнего хочется бизнесу, чтобы не разбираться во всех ролях перечисленных вначале, ну и чтобы не нужно было каждого из них хотя бы по 2, чтобы и в отпуск можно было сходить, а работа не встала, ну и ревьювить результат кто-то должен.
domix32
27.06.2024 09:57Огромное количество разработки ведётся по очень хиленько описанному ТЗ - "хочу фичу Х". Энтерпрайзы покрупнее, имеющие некоторый контролируемый цикл разработки имеют и достаточно понятный план разрабоки имеют также и аналитиков, которые формируют ТЗ для разработчика. Берусь утверждать, что в большинстве кампаний занимающиеся какой-то разработкой аналитиков не имеют по различным причинам: где-то количество экспериментов на единицу времени больше, где-то кампания слишком маленькая, чтобы держать ещё и аналитика пр. Поэтому разраб тут же становится сам себе аналитик и заодно и тестировщик со всеми вытекающими.
Doman
27.06.2024 09:57Да, тестирование уходит к разработчикам.
Это не новость, достаточно почитать "Как тестирую в Google", вышедшую аж 12 лет назад. Такой подход, при правильной организации, позволяет выкатывать фичи намного быстрее при приемлемом уровне качества. На последнем Heisenbug была хорошая лекция "Тестирование умерло" с объяснением происходящего и карьерными перспективами для тестировщиков и QA:
В итоге я вижу в целом падение качества на рынке
Качество ПО - это соответствие ПО ожиданиям заказчика. Скорость имплементации фичей - одна из ключевых метрик. С точки зрения бизнеса, быстрый релиз с некритичными багами предпочтительнее отполированной фичи в несколько раз медленнее. А значит, что качество на рынке растёт ¯\_(ツ)_/¯
Captain_Jack
27.06.2024 09:57Спасибо за алаверды на мою статью годичной давности. Я с тех пор получше разобрался в вопросе и попробовал этот подход в новой команде, так что есть что добавить.
Действительно, тестирование переходит к разработчикам, тебе точно не кажется.
Дополню твою картину своей перспективой как разработчик, и со стороны процесса разработки в целом.
Во-первых, сама пирамида тестирования, как на картинке, уже устарела для многих типов современного ПО. Это больше не эталон для всего, а возможно никогда им и не был. Но это отдельная тема, может напишу про это статейку, в двух словах не расскажешь.
Во-вторых, классический подход 10-летней давности, когда разработчик производит код, а тестировщик его проверяет, и они потом радостно кидаются друг в друга багами и фиксами, уж очень неоптимален. На коммуникацию и ожидание друг друга уходит дофига времени, а толку от этого очень мало. Тут явно можно лучше.
В-третьих, даже автотесты тоже дают неприятно длинный цикл обратной связи. Тестировщики обычно уносят все автотесты куда-то в отдельный проект, и тесты гоняются например раз в день по ночам. И опять начинаются разборы по утрам, из-за кого у нас сегодня упали автотесты, заводятся баги, фиксятся и так по кругу. И есть ещё интересные эффекты, которые приносит такой подход.
У тестов, которые пишут разработчики, есть ряд приятных свойств:
- разработчик пишет тест прямо одновременно с задачей, и релизит задачу только когда тесты прошли. То есть не возникает этого порочного большого круга между заливанием кода, его проверкой и исправлением, код уже проверен, всё.
- разработчик может поменять строчку кода, и тут же выполнить полный регресс на своей машине за 5 минут, а не ночью. И опять не надо заводить баги и фиксить их, потому что разработчик пофиксил всё сразу за 5 минут, увидя что тесты не проходят
- тесты меняются вместе с кодом, опять же одновременно
- все тесты проходят, не надо каждый день разбираться с упавшими тестами
- релизный цикл становится гораздо короче
Короче говоря, снимается целый слой суеты, испорченных телефонов, ожидания друг друга. А взамен появляется хорошее покрытие регрессом, который очень хорошо поддерживает проект в долгосрок, и всегда актуален.
Для меня классно работает синергия, когда тестировщик пишет тест-кейсы на задачу ещё перед тем, как я начал писать по ней код, а я реализую его тест-кейсы прямо в тестах сервиса, если это возможно. Это помогает и мне сориентироваться и реализовать всё сразу по требованиям, и тестировщика погружает в задачу ещё до того, как написан код и потрачены дни на разработку.
Captain_Jack
27.06.2024 09:57И конечно и мануальное тестирование, и автотесты, и UI-автотесты - всё это всё ещё нужно. Просто прибегать к ним лучше тогда, когда либо по-другому нельзя, либо когда это реально более выгодно, чем разработчику писать эти тесты. А не просто клепать автотесты на всё без разбора, или мануалить весь регресс, задерживая релиз на дни и недели.
И бывают места, где так делать выгодно, но на среднем энтерпрайз-проекте сейчас этого нужно не так много, особенно среди кучи микросервисов, которые перекладывают json-ы и которые мы релизим независимо.
breakingtesting
Тестировщик не может руководить качеством. Тестировщик может находить несоответствие требованиям.
Даже если представить, что есть примитивный критерий качественности/некаяественности - «несоответствие в больше чем 5% бизнес требований признак некачественности » - всё, что может тестировщик - выявить эти несоответствия/завести баги. Дальше нужно влияние на соседние процессы - аналитики, поставки, разработки. У обычного тестировщика этого влияния нет. Без влияния на соседние процессы руководить/управлять качеством не получится. Не каждому тимлиду тестирования позволят на эти процессы влиять.
iverzin
Тестировщик это инструмент, как датчик метана у шахтеров. А вот как этим инструментом пользуются - это уже отдельный разговор. Сейчас всё вокруг скатывается в "пофиг, пляшем" и тестирование в IT это частный случай. Но тестирование, не делается из-за этого менее значимым, даже если кому-то эти "всякие снипы-хрипы" и не нравятся.
breakingtesting
Мне кажется, у вас сложилось неправильное впечатление, что своим комментарием я принижаю чью-то значимость. Совершенно не принижаю, однако продолжу говорить, что тестировщик не может «руководить качеством». Это просто факт.
iverzin
Датчик и не может ничем руководить. Датчик подает сигнал, а как вы на него реагируете - это уже другое дело. Если процесс построен так что пока не будут пофикшены все критические баги, то релиза не будет - это один вариант реакции. Если тимлид может это проигнорировать - это другой.