Комментарии 17
Тестировщик (как специалист) начинает руководить качеством
Ощущение, будто тестировщик (который, как я писал выше, руководит качеством)
Тестировщик не может руководить качеством. Тестировщик может находить несоответствие требованиям.
Даже если представить, что есть примитивный критерий качественности/некаяественности - «несоответствие в больше чем 5% бизнес требований признак некачественности » - всё, что может тестировщик - выявить эти несоответствия/завести баги. Дальше нужно влияние на соседние процессы - аналитики, поставки, разработки. У обычного тестировщика этого влияния нет. Без влияния на соседние процессы руководить/управлять качеством не получится. Не каждому тимлиду тестирования позволят на эти процессы влиять.
В итоге я вижу в целом падение качества на рынке
Странный у вас вывод. Я тот самый разработчик, на которого "взвалили" все от юнитов до интеграционных тестов. Как результат - у нас почти нет багов на команде бэкенда. Никто не бегает с горящей дупой и не затыкает дыры на проде. А значит больше времени на проработку фичей, рефакторинг, апгрейд зависимостей и прочие вещи, которые на хабре традиционно считаются чем-то нереальным. Я сейчас даже подумал, что не согласился бы работать в команде с более слабой культурой тестирования. К хорошему привыкаешь.
Я прочитал и статью, на которую вы ссылались, и вашую Скажу так:
Попробовать работать без тестировщиков - Д-а-а-а-а-а-а!!!! Во-первых новый опыт. Во-вторых практика показала, что тестировщики все равно требования не покрывают и баги вылезают.
Т.е. получается, что усложняются процессы, тратится время, а толк неясен
-----------------------
Но все упирается, как по мне, в чуток иной вопрос. А именно в необходимость проверки написанного кода, собранного в виде приложения на соответствие требованиям. Для этого надо чтобы мистер Х
прочитал эти требования
осознал
определил для себя противоречия, серые зоны, места, требующие уточнения
подготовил тестовые сценарии и данные
выполнил проверки
Этот список понятно не претендует на полноту, но такой цели и не ставится. Вопрос в том, ху из мистер Х
И вот тут есть главная проблема, которая не зависит от роли человека в команде:
если аналитик реально не проработал требования - то уже есть проблема в начальной точке
если разработчик не поработал с требованиями - то код будет точно так себе
если тестировщик на поработал с требованиями - то итог его тестирования будет мало кому нужен
Т.е. все упирается "работа с требованиями".
-----------------
Соответственно задача "нужны тестировщики или нет" трансофрмируется в задачу, какая часть команды "работает" с требованиями, а какая - нет и почему. И от ее решения зависит, нужны ли тестировщики.
Если к примеру, разработчик просто делает таски из Джиры по тому, что написано и "не парит" - точно кто-то нужен после него. А вот если нет ...
Т.е. решение сводится к тому, как стимулировать разработчика больше работать с требованиями, о чем во многом и говориться в статье, на которую вы ссылаетсь
---------------
Теперь к изначальному вопросу. Скажу откровенно и фиг меня кто переубедит (шутка конечно, но в ней есть доля правды и реального опыта), что ничего уникального в навыкам и умениях тестировщика нет.
Технически обычно разработчик на голову выше, по знанию предметной области там же обитает аналитик. Исключения редки, и обычно встречаются в роли опытного лида, который сидит в конторое много лет, попадает в баги даже с завязанными глазами еще до того, как пришел релиз, и вообще - смысла идти куда-то нет, так как платят норм, должность руководящая и тебя и так все уважают, потому что есть за что. Да, такие спецы есть, но их никто убирать не будет, наоборот. Ну и обычно с такими лидами связана либо сложная предметная область, либо система или набор систем, где знания для их тестирования безценны
Но раз в общей массе никаких hard skills за средним тестировщиком нет, его единственная ценносте - это как раз умение "работать с требованиями" и закрыть все, о чем не подумали те, кто до него. Но тут зависит от состава команды, при сильном лиде, который шарит и в предметной области и знает, как вложить это знание дозированно другим разрабам - я думаю, отказаться от тестировщиков в пользу разрабов будет воможно. Иначе ... чуда не будет
Аналитик, даже классный, просто загнется пасти каждого разраба
-----------
По опыту ... я вообще работал, когда у нас и аналитиков то не было, не то что тестировщиков. Лид вполне мог снять требвования, закрыть вопрос ТЗ и т.д. Просто были реальные "универсальные" бойцы, которые могли и решение развернуть, и в командировку метнуться для пусконаладочных работ, и код написать/проверить. И все работало.
Поэтому только разработчик пока незаменим, пока пишет код. Остальные - как собертся паззлик
"Тестирование уплывает на сторону разработки".
Да, всё так и есть. Вам не показалось. Такое смещение, действительно, сейчас происходит в области разработки ПО.
Причина простая - внедрение в компаниях методологии Devops, где почти всё тестирование становится автоматизированным и встроенным в конвейер разработки ПО.
Мало того, даже задачи по эксплуатации получившегося ПО тоже постепенно ложатся на плечи разработки или DevOps\SRE, а не на команду эксплуатации, как это было раньше.
Считается, что такой подход:
- Позволяет избегать проблем в общении между dev и ops, dev и тестировщиками.
- Уменьшает количество людей в цепочке создания ценностей, что увеличивает скорость работы и избавляет от лишней бюрократии.
- Повышает ответственность разработчиков за результат своей работы.
- Заставляет разработчиков создавать ПО с оглядкой на удобство его дальнейшей эксплуатации.
- Ускоряет time-to-market, что очень радует бизнес.
Мир изменился. Я чувствую это по воде. (с)
Просто всё больше и больше мир зависит от программных продуктов. А как следствие - продукты усложняется. Из этого же вытекает, что команда разработки - это уже не просто разработчик и тестировщик. Есть 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, чтобы и в отпуск можно было сходить, а работа не встала, ну и ревьювить результат кто-то должен.
Огромное количество разработки ведётся по очень хиленько описанному ТЗ - "хочу фичу Х". Энтерпрайзы покрупнее, имеющие некоторый контролируемый цикл разработки имеют и достаточно понятный план разрабоки имеют также и аналитиков, которые формируют ТЗ для разработчика. Берусь утверждать, что в большинстве кампаний занимающиеся какой-то разработкой аналитиков не имеют по различным причинам: где-то количество экспериментов на единицу времени больше, где-то кампания слишком маленькая, чтобы держать ещё и аналитика пр. Поэтому разраб тут же становится сам себе аналитик и заодно и тестировщик со всеми вытекающими.
Да, тестирование уходит к разработчикам.
Это не новость, достаточно почитать "Как тестирую в Google", вышедшую аж 12 лет назад. Такой подход, при правильной организации, позволяет выкатывать фичи намного быстрее при приемлемом уровне качества. На последнем Heisenbug была хорошая лекция "Тестирование умерло" с объяснением происходящего и карьерными перспективами для тестировщиков и QA:
В итоге я вижу в целом падение качества на рынке
Качество ПО - это соответствие ПО ожиданиям заказчика. Скорость имплементации фичей - одна из ключевых метрик. С точки зрения бизнеса, быстрый релиз с некритичными багами предпочтительнее отполированной фичи в несколько раз медленнее. А значит, что качество на рынке растёт ¯\_(ツ)_/¯
12 лет прошло, а до сих пор из крупных только в гугле и нет тестировщиков отдельных.
А всё из-за огромного штата разрабов.
У них и нет такого понятия как узкая специализация разработчика. Сегодня пишешь на петухончике, завтра на JS. Но до сих пор есть python разработчики и Java/Kotlin.
После выхода книги, многие пытались повторить этот путь, но ничего не вышло на сегодняшний день и в компаниях где не было тестирования, теперь оно всё чаще появляется. В том же АТОЛ целый отдел создали интеграционного тестирования из-за крупного факапа.
Спасибо за алаверды на мою статью годичной давности. Я с тех пор получше разобрался в вопросе и попробовал этот подход в новой команде, так что есть что добавить.
Действительно, тестирование переходит к разработчикам, тебе точно не кажется.
Дополню твою картину своей перспективой как разработчик, и со стороны процесса разработки в целом.
Во-первых, сама пирамида тестирования, как на картинке, уже устарела для многих типов современного ПО. Это больше не эталон для всего, а возможно никогда им и не был. Но это отдельная тема, может напишу про это статейку, в двух словах не расскажешь.
Во-вторых, классический подход 10-летней давности, когда разработчик производит код, а тестировщик его проверяет, и они потом радостно кидаются друг в друга багами и фиксами, уж очень неоптимален. На коммуникацию и ожидание друг друга уходит дофига времени, а толку от этого очень мало. Тут явно можно лучше.
В-третьих, даже автотесты тоже дают неприятно длинный цикл обратной связи. Тестировщики обычно уносят все автотесты куда-то в отдельный проект, и тесты гоняются например раз в день по ночам. И опять начинаются разборы по утрам, из-за кого у нас сегодня упали автотесты, заводятся баги, фиксятся и так по кругу. И есть ещё интересные эффекты, которые приносит такой подход.
У тестов, которые пишут разработчики, есть ряд приятных свойств:
- разработчик пишет тест прямо одновременно с задачей, и релизит задачу только когда тесты прошли. То есть не возникает этого порочного большого круга между заливанием кода, его проверкой и исправлением, код уже проверен, всё.
- разработчик может поменять строчку кода, и тут же выполнить полный регресс на своей машине за 5 минут, а не ночью. И опять не надо заводить баги и фиксить их, потому что разработчик пофиксил всё сразу за 5 минут, увидя что тесты не проходят
- тесты меняются вместе с кодом, опять же одновременно
- все тесты проходят, не надо каждый день разбираться с упавшими тестами
- релизный цикл становится гораздо короче
Короче говоря, снимается целый слой суеты, испорченных телефонов, ожидания друг друга. А взамен появляется хорошее покрытие регрессом, который очень хорошо поддерживает проект в долгосрок, и всегда актуален.
Для меня классно работает синергия, когда тестировщик пишет тест-кейсы на задачу ещё перед тем, как я начал писать по ней код, а я реализую его тест-кейсы прямо в тестах сервиса, если это возможно. Это помогает и мне сориентироваться и реализовать всё сразу по требованиям, и тестировщика погружает в задачу ещё до того, как написан код и потрачены дни на разработку.
И конечно и мануальное тестирование, и автотесты, и UI-автотесты - всё это всё ещё нужно. Просто прибегать к ним лучше тогда, когда либо по-другому нельзя, либо когда это реально более выгодно, чем разработчику писать эти тесты. А не просто клепать автотесты на всё без разбора, или мануалить весь регресс, задерживая релиз на дни и недели.
И бывают места, где так делать выгодно, но на среднем энтерпрайз-проекте сейчас этого нужно не так много, особенно среди кучи микросервисов, которые перекладывают json-ы и которые мы релизим независимо.
Я почти согласен с вашими словами, если бы не одно "но". Видимо, вам удалось поработать с сильными командами разработчиков или хорошими лидами и менеджерами, которые смогли наладить процессы. Однако, исходя из моего опыта, хорошая команда разработчиков, которая может писать качественный код, правильно анализировать требования, писать качественные юнит-тесты и API-тесты, — это редкость. Я знал сеньоров-разработчиков, которые за 7 лет ни разу не писали юнит-тесты или API-тесты. Иногда ко мне приходит история, и я возвращаю её с 15 багами. Да, там проблемы не только в разработке: разработчик написал код, написал тесты, код прошёл ревью у трех человек, и всё равно 15 багов.
Проблема в том, как подходят к анализу требований, дизайна, внимательности, желанию разобраться, как юзер будет это использовать, продумать входные данные, покрыть все исключения. Поэтому и нужны тестировщики. Я ни разу не слышал от разработчиков фразы: "А какую проблему юзера решает эта фича?" или "Как именно юзер будет с этой фичей работать?"
Миллион лет назад тестировщики были очень разные — тест-дизайнеры, тест-аналитики, тестировщики руками (те самые, которые «как обезъяны»), автоматизаторы.
Со временем первые два с рынка исчезли, потому что тестировщикам впарили вменили в обязанности самостоятельно анализировать требования, делать тест-аналитику и тест-дизайн.
Под анализом требований сегодня подразумевают «их надо прочитать», потому что обычно требований нет, софт уже пилят, пора тестировать…
С тест-аналитикой было ещё проще — оказалось, что не очень-то оно и надо, софт теперь обновляется так быстро, что аналитика больше мешает, нежели помогает.
А понятие «тест-дизайн» сегодня редуцировано до «надо написать тест-кейсы». Просто примени разбиение «чего-то» на классы эквивалентности да с граничными значениями — это единственные основы, без которых в тестировании вообще никак. А лучше пиши код, сразу будешь ещё и автоматизатором.
Теперь про всё то, о чём вы сказали. Да, так и есть. Ведь если программисты сразу будут писать тесты… они же пишут юнит-тесты? Ну пусть пишут и всё остальное, какая разница-то… Только быстрее!
Поэтому да, вы правы.
Как пирамида тестирования уплывает на сторону разработки