Comments 27
Продукт я так понимаю не рискует прибылью в случае негативного фидбека от клиентов? В таком случае да, можно выкатывать такое. Но если за каждый баг компания расплачивается репутацией и рублём, лучше позволить себе тестировщика имхо
Расскажите это Microsoft. У вас пропали файлы, не печатает принтер или перестала запускаться ОС, ни чего, скоро мы это починим.
Тут такая штука. Не ошибается тот, кто ничего не делает. Если пробовать что-то менять, то всегда есть риск допустить ошибки, что-то ухудшить или даже сломать.
Можно жить по принципу "работает - не трогай", но в долгосрок это превращает команду и проект в болото и легаси, если не реагировать на постоянные изменения внешней среды. Из такого болота потом сложно вылезти, и конкурентность сильно падает, изменения становятся долгими и дорогими.
Некоторые крупные компании следуют принципу "move fast and break things". Да, это несёт риски, и клиентам конечно не нравится, когда качество страдает, но и альтернатива в виде проигрыша конкурентам и закрытия бизнеса не радует. Как всегда, где-то посередине стоит искать баланс, подходящий для вашей команды.
Котики классные! Рисовали нейросетью?
Из моего опыта подобного перехода, только мы не отказались от тестировщиков, а сразу начали их учить писать автотесты:
Писать тесты это навык, много разработчиков умеют писать только unit tests, если им сразу дать разрабатывать интеграционные и end-to-end получаем только позитивные кейсы и без corner cases.
В первые пару месяцев такого перехода количество багов в продакшн у нас увеличилось, потом снизилось.
Lead Time сократилось, но дело не только в автотестировании, была еще постройка CD и уход от SCRUM. CI был у продукта с самого начала.
При этом Team Capacity для бизнес задач тоже уменьшилось и не возвращалось на первоначальный уровень полгода. По рузальтатам анализа выяснилось, что просто начали делать больше работы, которую раньше откладывали на потом: технический долг, рефакторинг, автотесты, IaC.
Работа команды разработки без тестировщика может вызывать проблемы в процессе разработки программного обеспечения. Без тестировщика, возможно, не будет достаточного контроля качества продукта, что может привести к ошибкам и сбоям, которые могут повредить удовлетворение клиентов и имидж компании. Все равно что запускать сервис 24 на 7 без дежурной смены.
Можно так конечно:
-каждый член команды может обладать навыками тестирования, что позволит определить и устранить ошибки на ранних этапах процесса разработки.
-использование автоматических тестов и инструментов для управления кодом, таких как Git, может помочь уменьшить риски, связанные с отсутствием тестировщика.
На практике это полная Жжжж.
QA это не столько тесты гонять, сколько про стратегию обеспечения качества (если у вас не так, то это просто был неправильный QA). Тут часто цитируют Сунь-Цзы:
Стратегия без тактики - это самый медленный путь к победе. Тактика без стратегии - это просто суета перед поражением
Когда есть функциональные и нефункциональные требования, для которых определены измеримые атрибуты качества, построены тест планы с четким пониманием что за тест-кейсы в них содержатся и зачем они там нужны, то кому писать автотесты или хелсчеки вопрос тактический.
Я часто вижу в командах такую ситуацию. Разработчики сильно погружены в детали, для того чтобы хорошо держать рамки снаружи. Тим лид же считает, что ему по долгу службы не положено заниматься подобными вещами. В итоге проект, оставшись без QA, ещё какое-то время летит по инерции на прежних наработках и ребята рапортуют об успехах. Но за этим стоит постоянно наростающая энтропия - вариация на тему техдолга.
Разрабы часто не понимают что такое QA. Хуже всего когда QA не понимает что такое QA...
Задача команды обеспечения качества наладить процессы так чтобы минимизировать возникновение багов, а не стоять с огромной сеткой перед продакшеном в попытках остановить ловину из жуков. Когда тестеры тупо реакционно регрессят по пол месяца и находят кучу багов это не круто. И надо либо менять таких тестеров, либо дать им возможность наладить процессы, а не заставлять ловить баги.
В целом, вы по факту и сделали работу отдела QA. Наладили процесс как нужно. Всё что осталось - взять таки человека с сеткой на подстраховку, чтобы ловить то что не отловят автотесты и сами разрабы.
Тут большой вопрос - нанимают в отдел QA или обычного тестировщика. Второй момент - это ограничения в полномочиях. Например меня в команду наняли как классического тестировщика и мои полномочия при выстраивании процессов сильно ограничены. Я могу предложить идею, но заставить ее применять у меня полномочий никаких.
Никогда такого не было, и вот опять...
Мы сделали самое простое решение. Просто закрыли отдел тестирования...
(с) QIWI Ведущий платёжный сервис нового поколения в России
https://habr.com/ru/company/qiwi/blog/717370/
Только какое отношение изложенное имеет к тематическому разделу "ненормальное программирование", если в изложенном нет ни строчки кода, ни техник программирования, сложно понять...
мое скромное имхо сбоку: тестировщик, который умеет писать автотесты - это не тестировщик, а программист. но программист обычно хочет писать новые полезные фичи, а не покрывать тестами легаси, поэтому тут и возникает такое внутреннее противоречие
Из фронтенда у нас только админка
Именно это вам и позволило отказаться от тестировщика. И то лишь поначалу.
сейчас хотим себе фуллстек‑QA с упором на автотесты
В вашем случае это, вероятно, прокатит.
Но вообще говоря, fullstack-QA — это примерно такой же миф, как многозадачность, работа только в офисе, или только с 09:00.
Именно поэтому и существуют раздельные вакансии QA Automation & QA Manual.
Вспоминаем Генри Форда: "Каждый должен заниматься своим делом и достигать в нем высокого мастерства".
Говорят, в гугле большинство команд работают без тестировщиков.
Поправлю: в Google они просто иначе называются — Software Developer Engineer in Test. По сути, тот же тестировщик-автоматизатор.
Сервисы проверяются автоматическими тестами, а если баг проскакивает на прод, то его просто исправляют и дописывают тесты.
Со всеми ли багами так поступают?
А если баг трудновоспроизводимый?
А если для его исправления потребуется чуть ли не весь модуль переписать?
Пользователи в это время будут терпливо ждать? Пара-тройка таких факапов и люди скорее откажутся от такого сервиса.
Дописали интеграционных тестов, чтобы в рамках каждого сервиса была надёжно покрыта вся основная функциональность.
А не основная функциональность как покрыта?
А производительность? А безопасность? А прочие виды тестирования?
Плюс мы договорились, что теперь, делая задачу, разработчик покрывает её тестами, проверяя весь свой код.
Это очень серьезная, стратегическая ошибка! Практика тестирования как раз на том и построена, что человеку проще замечать ошибки других, чем свои собственные. Иначе, например, в издательствах не существовало бы должности корректора.
Кроме того, "самотестирование" требует высокой ответственности. Вы уверены, что в команде всем разработчикам не всё равно, что там попадет в production? Уверены, что так будет всегда?
снижение накладных расходов и рост скорости поставки уже дадут ценность
Угу, за счет снижения качества, если не сейчас, то в перспективе. Руководство, как я понял, не против эксплуатации пользователей в роли подопытных кроликов бесплатных тестировщиков? Ах да, у вас же внутренний сервис… Но ведь речь о "крупной финтех-компании, отвечаем за небольшую часть сервисов, на которых работают продукты с миллиардным оборотом"!
И осталось неясным, за счет чего удалось увеличить скорость поставки, если разработчики стали тратить время на тесты.
Разумеется, разработчикам понравилась идея отказа от тестировщика.
Во-первых, большинство предпочитает разрабатывать новые фичи и совершенствовать hard skills, а не баги фиксить.
Во-вторых, не надо переключать контекст с той самой разработки на те самые баги.
Красота! )
негативные сценарии — что делать, если твой код что-то поломает после релиза.
Негативные сценарии — это невалидное поведение юзера, а не то, что вы написали.
Пример: вместо ожидаемых в запросе цифр пользователь (случайно) отправляет буквы.
для идеала нужен еще ручной тестировщик, который будет искать неавтоматизированные сценарии и баги на постоянной основе, не вмешиваясь при этом в прохождение pipeline.
Это как?
Качество субъективно не просело.
Тем не менее, качество работы прода нас устроило.
А что сказали те, кто пользуются вашим продуктом?
разработчики не всегда заводят баги, когда замечают проблему самостоятельно на тестовом стенде до релиза в прод.
Я даже не знаю, как такое комментировать...
лучше погружаются в требования, держат в голове смысл и цель своих изменений и покрывают это тестами.
Нагрузка возросла. А зарплата прибавилась? )
или хотя бы всегда иметь код, готовый к релизу (continuous delivery).
Это не continuous delivery, это continuous integration.
Суммируя наш опыт, вам стоит пробовать перейти на автоматический регресс, если:
Статья называется "Полгода без тестировщика". Поэтому ваш опыт должен показать, можно без него обойтись, или нет. А вы про автоматический регресс...
То же про опрос. Причем здесь "Был ли у вас подобный опыт замены ручного тестирования автотестами", если ожидаемый вопрос "Был ли у вас подобный опыт отказа от тестировщика?".
Подводя итог, главное — чтобы от тестировщиков не отказались корпорации типа Боинга. Самолеты и так довольно часто падают.
Но за статью спасибо. Отличный пример того, как делать не надо.
Хорошо, что в конечном итоге вы решили оставить тестировщика. Другими словами, с чего начали, к тому и вернулись )
Привет, спасибо за такой объёмный комментарий!
Приходилось работать с QA fullstack и знаком с опытом многих коллег, у кого они есть в команде. Можете раскрыть, в чём их мифичность?
Понимаю, что есть более узкие специализации, но не везде подходят отдельные автоматизатор и ручник, т. к. это 2 разных человека, для небольшой команды это обычно нерентабельно.
Очень похоже на то, как работают фулстек-разработчики: либо для экономии ресурса берут одного разработчика, который может делать и фронт и бэк, либо вся команда состоит из таких же фулстеков.
Насколько я знаю, это позволяет конструктивно закрывать потребности в некоторых командах, да и самим фулстекам так работать часто нравится - не все обязательно хотят быть чистыми бэкендерами или писать только фронт. То есть это вин-вин и для работника, и для компании/команды.
Это не continuous delivery, это continuous integration.
Имел в виду всё-таки continuous delivery (подробнее раз, подробнее два), хотя там пожалуй легко было понять не так. Идея в том, что классно иметь релиз сервиса по клику в любое время дня и ночи, или полностью автоматический релиз на каждый коммит.
Вы уверены, что в команде всем разработчикам не всё равно, что там попадет в production? Уверены, что так будет всегда?
Если кому-то у меня в команде станет всё равно, что попадает в прод, это будет значить, что я как тимлид не справился со своими прямыми обязанностями. Я пожалуй сгорю от стыда, в первую очередь перед собой.
В общем, это очень ненормальная ситуация для команды нашего типа, очень много вещей должно пойти не так, чтобы кто-то начал так относиться.
Поэтому ваш опыт должен показать, можно без него обойтись, или нет
Да, пожалуй. Наш показал, что мы обойтись можем, но в долгосрок хорошо бы иметь хотя бы небольшой ресурс своего fullstack QA, хотя бы 0.25 ставки. И для команды, и для проекта это будет оптимально в долгосрок.
Хорошо, что в конечном итоге вы решили оставить тестировщика. Другими словами, с чего начали, к тому и вернулись
Наша жизнь без QA помогла нам лучше, конкретнее понять нашу потребность и получить много нового опыта. Мы теперь уже не те, что раньше. По-другому смотрим на обеспечение качества, участвуя всей командой. Больше понимаем в этом самом качестве после такой продолжительной фокусировки на нём. Лучше понимаем, зачем нам QA, чего мы ждём от человека в этой роли.
Так что на мой взгляд мы сделали несколько шагов вперёд, и очень классно, что теперь это часть нашего опыта.
Спасибо за развернутые ответы!
Можете раскрыть, в чём их мифичность?
Вроде бы уже объяснил, но попробую другими словами.
Будущее за узкой специализацией. Потому что в наше время чуть ли не ежедневного появления новых технологий, фреймворков и инструментов по-другому нельзя: "только мы не успели освоить одно, как тут же не успели освоить другое" )
Вы бы согласились на операцию по удалению аппендицита, если бы её проводил хирург-стоматолог? Вот и я нет.
Впрочем повторю, в ваших условиях fullstack может и подойти. Продолжая аналогию, будет достаточно врача общей практики )
классно иметь релиз сервиса по клику в любое время
Да, это CD. Но вы говорите "всегда иметь код, готовый к релизу". Это CI.
Я пожалуй сгорю от стыда, в первую очередь перед собой.
Речь не о вашей персональной ответственности, а о рисках для бизнеса. Пока вы будете сгорать от стыда, пользователи будут страдать от багов, просочившихся на прод.
Так что на мой взгляд мы сделали несколько шагов вперёд, и очень классно, что теперь это часть нашего опыта.
Бесспорно, любой опыт полезен, даже негативный.
Но перед катом статьи вы четко обозначаете ее тему: "Больше полугода мы проработали без тестировщика в команде, и сейчас пора посмотреть, что из этого получилось". В результате вы пришли к выводу, что тестировщик вам всё же необходим. То есть с точки зрения штатной единицы и ФОТ ничего не поменялось. Я об этом.
В любом случае, хорошо что решили поделиться своим опытом и написать статью.
К слову, статья безупречна с точки зрения правописания (ну, почти) — приятно читать.
Насчёт фуллстека не соглашусь, но тут вопрос насколько фуллстек. Например ручник с навыком автоматизатора на одном языке выглядит вполне реализуемо, хотя конечно времязатраты на ручные автотесты будет тормозить развитие в авто. А вот полиглоты меня напрягают))) я за время обучения в Нетологии успела пощупать 3 языка и к концу обучения один из них уже почти полностью забыла. мне кажется язык программирования это та вещь с которой надо практиковаться постоянно, по крайней мере большинству.
Кажется, статью правильнее было бы назвать "Полгода с нормальными процессами и CI/CD", может, при таком подходе и с тестировщиком было бы не хуже :)
Добавлю что от автотестов есть ещё один плюс. Они заставляют разработчиков отвечать за результат задачи, а не спихивать проверку на тестеров. Одно это значительно уменьшает кол-во багов.
>>> Из фронтенда у нас только админка
Действительно, именно специфика продукта позволила отказаться от наличия тестировщика. Подобно тому, как при езде на машине от запасного колеса отказаться сложно и невыгодно, а при езде на велосипеде запасное колесо не очень-то и нужно.
Мне кажется в названии неоднозначность. По факту вы заменили ручного тестировщика на автоматизатора, а так как тестировщика автоматизатора у вас не было, то создали виртуального из девелоперов. Часто следующий шаг - гибридные роли: dev/auto, auto/dev. Так балансировать легче и риски меньше.
Ощущения после прочтения статьи: была команда с безответственными разработчиками, которые делали кучу багов, не запариваясь (ведь там дальше тестировщик всё поймает), но при этом злились на тестировщика, что он отвлекает бояр-кодеров от их работы своими багами.
Убрали негодного тестировщика, разработчики почуяли, что пахнет жареным и стали более ответственными (тут чудеса, конечно).
Наладили наконец-то нормальные процессы (почему тестировщик мешал это сделать раньше - не понятно), размазали роль тестировщика по команде.
И теперь ищут другого тестировщика, чтобы собрать обратно роль тестировщика в отдельном человеке...
Круг замкнулся :)
У меня создалось такое впечатление, что у автора или проблемы с процессами в команде, или нехватка ресурсов. Например - почему у тестировщика уходит 3 дня на проверку задачи? Конечно, бывают сложные задачи, но в моем понимании если на проверку задачи (без учёта тест-анализа) уходит больше 1,5-2 дней, то её явно стоит декомпозировать, если это возможно.
Кратковременный результат может быть неплох, но как уже писали выше разработчик как правило смотрит на продукт через призму кода и выдергивать его из этого состояния означает притормаживать его развитие как разработчика.
Полгода без тестировщика