Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

«Ответственность должна быть на инженерах, которые пишут код». Почему в People.ai отказались от QA-команды и что это дало

[От редакции. Чтобы разговор получился интересным, мы пригласили провести интервью Дмитрия Шпаковского, Senior Software Engineer in Test в SurveyMonkey, специалиста с 10+ годами опыта в индустрии, автора книги «Modern Web Testing with TestCafe»]

Четыре года назад в People.ai решили отказаться от QA-команды, и с тех пор каждый разработчик должен сам не только писать, но и тестировать свой код. Интересно, что после этих изменений, как рассказали нам в компании, релизы существенно ускорились, количество багов уменьшилось, а те, которые появляются, фиксить намного легче.

Мы пообщались с СТО People.ai Андреем Аксельродом и Data Engineer Татьяной Луцаевской, которая раньше была в составе команды QA. Расспросили их подробнее о том, при каких условиях этот подход работает, какие были сложности, когда тестированием занимались не разработчики, а также стоит ли, по их мнению, начинать свою карьеру в QA.

Татьяна Луцаевская и Андрей Аксельрод

Команда People.ai разрабатывает Revenue Operations and Intelligence платформу, которая повышает эффективность бизнеса с помощью искусственного интеллекта. Система автоматизирует сбор и анализ данных деловой активности и превращает их в рекомендации, которые ведут к более успешным продажам. Компания была основана в 2016 году Олегом Рогинским. Сейчас в ней работает порядка 200 человек, из них почти 50 инженеры. Есть ряд офисов в разных городах: в Киеве, Торонто, Сан-Франциско, Нью-Йорке и Лос-Анджелесе. Техническая команда находится в Сан-Франциско, Киеве и Торонто.

«Главное, что нам нужно было сделать — уйти от схемы „релиз каждую вторую неделю“»

— Как выглядел процесс разработки до решения отказаться от QA-команды? Какие были основные сложности? Какой был тогда состав инжиниринг-команды?

Татьяна: Мы отказались от QA в августе 2017 года. На тот момент в команде было не больше 12–15 инженеров. В основном все в Украине. Также было три QA в Украине и один в Сан-Франциско (еще один специалист работал на part-time из Сан-Франциско, но только до 2016 года).

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

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

Сложных ситуаций было много. Могло, например, что-то сломаться в core-части, от которой зависят другие системы, и при тестировании появлялось множество багов (feature-флаги у нас были, но с core-частью они не помогут). При этом бывало, что у Олега Рогинского, нашего фаундера, через несколько дней после планирования релиза уже был назначен customer call, на котором он должен был презентовать новую фичу. Но часто из-за багов он не мог это сделать. Тогда либо приходилось переносить созвон, либо зачастую разработчики ночами не спали и чинили что-то. Потом говорили: «Олег, только не нажми случайно на эту штучку, мы тут еще дофикшиваем». Такое было почти с каждым релизом.

— Решение отказаться от QA было как-то связано с экономической ситуацией, кризисом или это было чисто техническое решение?

Андрей: Решение я принял, когда пришёл в компанию 4 года назад и реорганизовал инженерную команду. С деньгами это вообще никак не связано — только с правильной организацией работы.

— Как выглядит процесс разработки сейчас, после отказа от QA? Какие кардинальные изменения произошли?

Андрей: QA-команда у нас перестала существовать как класс. Мы предложили всем переквалифицироваться в инженеров и поддержали в этом. Два человека пошли по этому пути, еще двое ребят решили уйти из компании и продолжать карьеру в QA.

Что очень интересно — качество продукта без отдельной QA-команды даже улучшилось, хотя можно было бы предположить обратное. Главное, что нам нужно было сделать — уйти от схемы «релиз каждую вторую неделю». Это ключевое. Раньше у нас был 2-недельный релиз, который всегда растягивался на третью неделю, потому что никто не успевал все сделать. Потом весь объем кода, который три недели писала команда, заливался в продакшн. Понять, где именно возникли проблемы — а они возникали — было практически невозможно. Тогда мы фиксили баги, а на четвёртую неделю наконец-то что-то рабочее запускали.

Получается, что цикл выхода нового кода в продакшн — месяц вместо запланированных двух недель. Две недели — это уже безумно много, месяц — вообще нереально. Стартапы так работать не могут и не должны. Одна из самых важных вещей — это скорость реакции на фидбэк, скорость цикла: выбрасываешь на продакшн, получаешь обратную связь от пользователя, обрабатываешь ее, делаешь что-то новое, выбрасываешь снова, снова смотришь отзыв. Чем быстрее этот жизненный цикл, тем быстрее стартап находит Product-Market Fit.

Давайте сравним два стартапа. Один заливает код 10 раз в день и получает оперативную обратную связь на то, что было залито. Получается, что полный цикл может быть закрыт за 1–2 дня. То есть у первого стартапа будет больше 100 циклов за год. Второй делает релизы раз в месяц — и у него выходит 12 циклов за год. Какая компания будет успешнее, сделает продукт, который будет больше нравиться пользователям?

Еще один важный момент — перенос ответственности. Когда у вас отдельные команды — QA и инженерная, кто ответственный за ошибку? Инженер, который сделал ошибку, или QA, который не нашёл ее и запустил в продакшн? Дима, как ты думаешь?

— Риторический вопрос, но я как последователь ISTQB, буду немножко адвокатом QA в этом случае. Постулат такой, что ты никогда не найдёшь 100% багов и это нормально, твоя роль как QA — максимально снизить риски, но не устранить всё, потому что время у нас не бесконечное. И второй постулат говорит о том, что качество — это общее дело, поэтому ответственность лежит равномерно на всей инженерной команде, QA — такие же инженеры, как и остальные разработчики.

Андрей: Я уважаю твою точку зрения, при этом считаю, что ответственность должна быть на инженерах, которые пишут код. Что происходит, когда ответственность общая? Знаешь высказывание «у семи нянек дитя без глаза»? Именно так и случается, потому что, на ком ответственность — абсолютно непонятно. Инженер говорит: «Ну, QA дотестит». А QA не в состоянии всё дотестить, он же не сидит у программиста в голове и не понимает, как работает каждый Loop Statement. Поэтому ответственность всегда на инженерах, и нужно было, чтобы они полностью осознали, что больше не будет человека, который сможет найти баг. Я это называю babysitting.

Еще один момент — что происходит в случае emergency, если ответственность размыта? Допустим, ночью возникла проблема. Что сделает нормальный инженер? Ночью что-то исправит на скорую руку, а утром встанет и первым делом полностью решит проблему. Если же ответственность будет, например, на SRE, он что-то там ночью сделает, но инженер следующим же утром эту проблему наверняка решать не станет. Он ее не прочувствовал. Поэтому важно, чтобы ответственность была на тех людях, которые пишут код. И, соответственно, любые фиксы приходили инженерам и не было никаких недопониманий с 7 няньками.

«Появилось правило: все фичи должны быть обязательно покрыты unit-тестами»

— Какой раньше использовали подход к разработке? Как поддерживалась синхронизация распределенной команды?

Татьяна: Это было больше похоже на гибридную модель. Мы старались работать по Scrum, но, например, не проводили некоторые ретроспективы.

У нас было несколько разработчиков в Украине и еще два разработчика — в Сан-Франциско. Иногда случалось так, что украинская команда начинала что-то тестировать, а потом утром американская команда это замечала и говорила: «А мы это уже оттестировали». В этом плане синхронизация была немного нарушена, мы старались больше синкапиться на митингах. Проблема была из-за того, что планирование релиза происходило батчами, каждый брал свою часть работы, шел в свой уголок и делал, лишь бы успеть к релизу.

Сейчас мы серьезно отладили Scrum-процесс, поэтому и распределенная работа происходит эффективно, работоспособность не снижается. Сейчас имеем качественное планирование, и специалисты уже не идут договариваться между собой и делать что-то отдельно. Я бы сказала, что при правильном Scrum-процессе работа значительно улучшилась.

— Как выглядело распределение структуры тестирования до отказа от QA и после? Я имею в виду пирамиду тестирования unit — integration — end-to-end.

Татьяна: До отказа от QA у нас в основном тестировали только QA. Ответственные инженеры могли добавить какие-то unit-тесты, но такого требования к ним не было.

Сейчас, если в редких случаях нужно что-то протестировать, перепроверить — это дело Technical Support команды. У нас есть QA-канал в Slack, но там чисто support-вопросы. К примеру: «Ребята, я не понимаю, как эта вещь работает» или «Я думаю, у меня баг». В 90% случаев это вопросы от новичков — Sales или Customer Support.

Разработчики тестируют свой код сами. Если кто-то делает commit, это обязательно должен проверить кто-то еще из команды. Есть чек-лист, по которому мы идем. Например, создали какие-то новые функции — надо проверить, на каждую ли функцию есть unit-тесты. Деливерим маленькими итерациями, чтобы было легче ревьюить PRы. Я в бэкенд-команде, мы пишем unit-тесты, функционально-интеграционные тесты.

Каждый инженер формирует свой подход к тестированию, в зависимости от того, чем он занимается. Также мы пользуемся up-time системами, например PagerDuty. Если сломается что-то критическое — получаем alert. Разработчики по очереди следят за уведомлениями, кто дежурит — тот и отвечает за решение проблемы. Сейчас у нас каждый инженер на on-call неделю. Раньше дежурили сутки, но в некоторых командах пошло перекидывание ответственности: сейчас уже поздно, следующий посмотрит проблему. Поэтому сделали on-call на неделю.

Есть очень маленький процент ручного тестирования — только если нужно edge case проверить. Но в основном этим Support-команда занимается, когда что-то хочет перепроверить, посмотреть, исследовать. Немало внимания мы уделяем мониторингу качества данных. В каждой команде это есть.

— Как вы делали переход от состояния «unit-тесты есть только у трудолюбивых счастливчиков» до «всё покрыто unit-тестами». Как доносили это команде и как масштабировали? Как выделяли время и ресурсы под это?

Татьяна: Как раз в том году, когда мы отказались от QA, нанимали новых инженеров, многих из Кремниевой долины. Им ничего не нужно было объяснять, они знают, что должны сами тестировать код. С этим не было проблем.

Со временем у нас появилось правило: все фичи должны быть обязательно покрыты unit-тестами. Если вдруг кто-то скажет: «Мне нужно срочно это зарелизить, но я тесты добавлю потом», Senior-инженеры, лиды просто не пропустят такой PR. Они скажут: «Окей, возьми ещё один день, напиши, пожалуйста, эти тесты сейчас».

— То же касалось и legacy-кода, на котором не было тестов, но он работал? То есть вы выделяли конкретных людей, которые доставали этот код и покрывали тестами?

Татьяна: Нет, отдельно мы этого не делали, все было в процессе. Допустим, вы добавляете новую фичу и она завязана на другие. Что-то падает — вы идете, фиксите и пишете тесты на уже существующие фичи, от которых она зависима. Тут дело только в ответственности. Таким образом, мы покрывали legacy code тестами постепенно.

«У нас изменилась культура ответственности за свои действия»

— Какие сложности возникают сейчас, после отказа от QA?

Татьяна: Не сказала бы, что сейчас есть сложности. Все-таки прошло уже 4 года с тех пор, как мы отказались от QA. Многие инженеры поменялись, пришли новые. Они уже точно знают, что должны сами тестировать свой код. Просто если раньше программисты еще долго исправляли за собой ошибки, то сейчас они меньше это делают, но пишут больше тестов.

Андрей: Из сложностей — у нас до сих пор есть проблема с тем, чтобы была стабильная среда для интеграционного тестирования. Это то, чему нам стоит уделять больше внимания. Но в целом мы очень удачно перешли на новый режим работы. Инженеры, которые его не принимали, со временем ушли. Сейчас это уже всем очевидно: ты, как инженер, делаешь собственное тестирование как часть процесса разработки. Когда деплоишь код в продакшн, должен руками проверить, работает ли он. На собеседования иногда приходят инженеры, которые считают, что QA должен ходить за ними и бейбиситить, но редко.

— Что изменилось в требованиях к разработчикам при найме и как вы распознаёте «своих» людей, которые точно подходят в команду?

Андрей: У нас изменилась культура ответственности за свои действия. Мы ищем инженеров, которым она подходит. Можно задать кандидату вопрос о QA: какой у него взгляд на эти вещи. Если человек говорит: «Я считаю, что должен быть QA», я его спрашиваю: «Как вы относитесь к тому, что у нас его нет». И тогда уже обсуждаем это, и человек либо принимает эту философию, либо нет.

То же самое про being on-call. В Долине все инженеры знают, что они ответственны за дежурства. В Украине время от времени встречаются специалисты, у которых нет понимания, что это нужно делать. Мне кажется, это отчасти из-за аутсорсингового мировоззрения.

Где-то через месяц после того, как берем нового человека, я всегда задаю ему вопрос: «Совпали ли ваши ожидания о компании, которые сформировались во время собеседования, с тем, что вы получили, когда вышли на работу?». Для меня очень важно, чтобы ожидания и реальность совпадали. Это значит, что мы не завышаем оценку компании на интервью. Несколько раз мы не сказали про on-call на собеседованиях, и, когда инженеры присоединялись к команде, это для них стало сюрпризом. Очевидно, они этого не делали раньше. Поэтому мы адаптируем процесс найма так, чтобы у людей не было диссонанса и они знали, чего ожидать.

— Какие у вас технические требования к разработчикам, какой стек нужно знать, может, в этот стек добавилось что-то в связи с необходимостью тестировать?

Андрей: Мы не требуем конкретный стек, мы считаем, что любой Senior-инженер должен писать на нескольких языках программирования. Мы ищем generalists, которые прежде всего заинтересованы в том, чтобы развивать компанию, и уже во вторую очередь — в конкретных технологиях. Мы используем те, которые нужны для решения задач, исходя из проблем бизнеса. Поэтому ищем инженеров, способных переключаться между разными языками и находить правильные технологии под конкретные бизнес-потребности.

Если посмотреть на наш стек, там есть Java, Scala, Python, Spark и еще миллион всего. Ищем ли мы людей, которые пишут конкретно на Python? Нет. Мы верим, что любой инженер может быстро начать писать на Python без особых проблем. Большинство специалистов в Кремниевой долине имеют такое же мировоззрение, и они абсолютно свободно переключаются между разными языками программирования.

Есть специалисты, которые приходят и говорят: «Хочу писать только на Java». Это означает, что человек не совсем подходит под нашу культуру. Он заинтересован в том, чтобы развивать свои навыки в определённом направлении, а не в том, чтобы помочь строить компанию. В то же время такой подход помогает инженерам развиваться в разных направлениях.

У меня есть определенная философия о том, кого нанимать в стартапы. Сейчас мы middle stage startup, тогда — 4 года назад — были early stage. Так вот, многие early stage стартапы либо не могут себе позволить нанять Senior-специалистов, либо у них не получается. Зачастую они говорят: «У нас мало денег, поэтому возьмем джуниоров». Я считаю, что это огромная ошибка. Senior-инженеры будут работать гораздо быстрее, лучше и не сделают большого количества ошибок, которые потом надо будет всем расхлебывать.

Другой момент — когда берёте Junior-инженера на работу, вы создаете своего рода контракт с ним. Он помогает вам построить бизнес, вы помогаете ему вырасти. У early stage стартапа нет процессов, чтобы помочь человеку расти. Его бросают в воду и говорят: плыви. Есть люди, которые выплывают, a есть те, кому слишком сложно.

Когда компания подходит к middle stage, уже есть условия, чтобы создать win-win ситуацию, когда и джуниор помогает расти компании, и у него есть ментор, процессы, благодаря которым он не сделает слишком много ошибок.

«Релизы существенно ускорились»

— После отказа от QA замедлились релизы? Получается, что теперь девелоперу, кроме разработки, нужно ещё и тестировать, выделять на это время.

Андрей: Релизы существенно ускорились. Итерации в разработке стали намного быстрее за счет continuous deployment. Заметно уменьшилось количество ошибок, которые мы находим после релиза.

— А как делает сам девелопер, когда берет себе тикет? Например, он говорит: «Раньше я это мог сделать за один день, но теперь мне надо еще потестировать, поэтому нужно полтора дня или два». Или же как был один день, так и остался?

Андрей: Это не обсуждается вообще, всегда подразумевается, что тестирование включено в эстимейт. Разработчик несет ответственность за просчет времени на выполнение той или иной задачи — это приводит к комитменту и правильному отношению к работе.

— То есть, когда QA были, то точно так же девелоперы комитились и подразумевалось, что тестирование они тоже сделают, но оно не делалось, правильно?

Андрей: Не делалось. Потому что были няньки QA.

— Cотрудникам, которые были QA, предложили новые позиции? Сколько из них перешло на новые позиции, сколько покинуло компанию?

Татьяна: На момент принятия решения у нас было четыре QA: три специалиста в Украине и одна я в Сан-Франциско. Два человека решили дальше продолжать работать QA и ушли. QA Automation инженер перешла в команду разработки, быстро выросла в Senior-инженера. Я перешла в Data Science команду.

— После того, как изменилась парадигма и девелоперы стали более вовлечены в тестирование, вы делали какую-то обучающую программу, курсы — что-либо, чтобы помочь им получить больше экспертизы в тестировании?

Андрей: Нет, не делали. На тот момент мы были маленькой компанией, не было достаточно ресурсов для этого. Но у нас были инженеры, которые хорошо знакомы с таким подходом и умели это делать. И вот они показывали пример, менторили тех, кто учился.

— Эта трансформация в основном происходила через ревью pull requests или, может, вы делали pair programming либо ещё какие-то техники применяли?

Татьяна: В основном через pull requests, много учимся на комментариях. К pair programming прибегали не очень часто. В основном у нас ребята, которые умеют все делать сами и им хочется самим разбираться. С другими специалистами мы просто созванивались и действовали так: один пишет, а другой комментирует, либо один пишет, а другой спрашивает. Но обычно все прокачивают скилы через коммиты и комментарии.

В нашей команде тогда было два инженера, которые пришли из Google. Там любят оставлять очень много комментариев по улучшению кода: eсли код great, его нужно сделать perfect. Некоторые другие инженеры научились этому и тоже такой подход теперь практикуют.

— Как изменился бюджет инжиниринг-департамента после отказа от QA?

Андрей: Освободившийся бюджет уходил на рост команды. Но его и освободилось не так много. Всего два человека ушло, там и говорить не о чем.

«Я считаю, что инженеры могут видеть разные edge-кейсы и даже лучше, чем QA»

— Что произошло с тест-артефактами, которые уже были: что с ними сейчас, кто их поддерживает, если они остались?

Татьяна: Раньше у нас было огромное количество тест-кейсов: от 50 до 100 на каждый репозиторий, каждый компонент продукта. Теперь, после отказа от QA, у нас нет конкретных тест-кейсов, просто весь функционал покрывается тестами сразу.

Старые тест-кейсы были некоторое время. Возможно, на них смотрели ребята, которые только пришли в компанию. Когда мы уже начали покрывать все тестами, специалисты, которые хотели разобраться, как работает конкретный аспект продукта, просто открывали папку «tests». Там можно все узнать. Давние тест-кейсы уже стали нерелевантными.

Андрей: Я бы так сказал: код становится документацией.

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

Андрей: Говорят, что инженеры настолько близки к коду, что не могут его эффективно тестировать и видеть все edge-кейсы, по сравнению с QA, которые думают более комплексно про разные юзкейсы. Я не уверен, что принимаю этот аргумент. Я считаю, что инженеры могут видеть разные edge-кейсы и даже лучше, чем QA, потому что они пишут этот код и продумывают эти юзкейсы по ходу дела. И один из трюков, которые мы используем, — тест-кейсы продумываются еще на этапе написания дизайн-документа для проекта. Когда вы еще не начали писать код, смотрите более целостно на то, что нужно сделать. И это позволяет потом не быть слишком предвзятым к своему коду.

Татьяна: Если посмотреть, например, на наши спринты и квартальные планинги, каждая новая фича начинается с OnePager. Пишем максимум на 1–2 страницы, что она будет выполнять, какая будет архитектура, проверка. У нас есть отдельная секция, где говорится о том, какие проблемы это может вызвать. Затем в гугл-доке вся команда комментирует это, приглашаются ребята из других команд, особенно если фича касается и их.

После того как мы уже начали заниматься фичей, разработчики создают PRы. У нас в GitHub в каждом репозитории обязательно есть проверка — нужно, чтобы кто-то из команды апрувнул код. Если приходит кто-то извне, создаёт PR, то только человек из команды может его одобрить. Если это делает специалист из этой же команды, другой член команды должен заапрувить.

При этом, когда другие инженеры смотрят на код и не знают его достаточно хорошо, они будут задавать вопросы. Например: «Я не понимаю, как это работает, объясни мне, почему именно так нужно?» То есть мало того, что в ванпейджерах много обсуждений, ребята со свежим взглядом спрашивают о чем-то и искренне стараются разобраться.

— Когда приходит новый разработчик в команду, вы снабжаете его документацией? Или у вас есть какой-то процесс, когда старшие разработчики вводят его в курс дела проекта?

Татьяна: У нас уже давно есть onboarding buddies. Выделяем человека, который вводит новичка в курс дела и вплотную с ним работает некоторое время. Также для новых инженеров есть обязательное требование: в первые два дня сделать свой первый коммит. Чтобы человек не потратил две недели на чтение документации, а сразу же влился в работу.

Legacy code не весь покрыт документацией — я буду честна. И не все команды планируют в ванпейджерах, но все стараются это делать сейчас. Ванпейджеры — тоже своего рода документация.

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

— Есть какой-то процент покрытия кода тестами, который вы постоянно поддерживаете?

Татьяна: Сейчас порядка 70% кода покрыто тестами. Пару лет назад это был очень маленький процент.

Андрей: Мы не сразу ввели Code coverage и надо понимать, что эта метрика не всегда означает то, что важно. Code coverage не гарантирует качество кода, она гарантирует только то, чтобы определённое количество строк кода было пройдено, грубо говоря. Но она даёт общее понимание, насколько команды используют автоматическое тестирование. И когда мы говорим про 70%, я считаю, что от 70 до 80% — это достаточно хорошо. На мой взгляд, всё, что больше 80% — избыточно и не означает, что качество самих тестов повышается. Дима, ты с этим согласен?

— Я считаю, что 70-80% это оптимально, больше — уже перебор. По end-to-end фронтенд-тестам — они перешли к кому-то в наследство? То есть кто-то из девелоперов продолжает их поддерживать или от них просто отказались?

Татьяна: Фронтенд поменялся довольно сильно, поэтому я уверена, что там все заменили новыми тестами.

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

«С каждым годом количество юзеров у нас стремительно росло, а количество багов практически не менялось»

— Есть ли статистика по тому, сколько багов обнаруживали пользователи после релиза, когда была QA-команда и сейчас?

Татьяна: К сожалению, у нас в Jira не было такого тега раньше, что тикет пришёл именно с Zendesk (платформа для менеджмента саппортных тикетов — ред.), мы добавили это позже. Но я посмотрела эту статистику вручную. До того как мы отказались от QA-команды, за 2017 год было довольно много багов, которые были созданы и саппорт-командой, и разработчиками. Из них примерно 70% — это «у меня не грузится, что-то перестало работать». 30% — это «скажите, пожалуйста, как высчитать эту метрику. Мне кажется, она неправильная».

В 2018 году, когда у нас уже не было QA, количество ошибок в целом увеличилось в 2,5 раза. И при этом количество ошибок в разработке уменьшилось. Где-то 80% багом были с реквестом «что насчёт этой метрики, у меня такой вот edge-кейс, как бы вы это заапрувили» и так далее. То есть большинство ошибок уже касалось характеристики данных. И уже почти не было такого, что что-то не работает, не грузится и так далее.

И что самое интересное: с каждым годом количество юзеров у нас стремительно росло, а количество багов практически не менялось. Всего на 20–30 тикетов больше с каждым годом. В 2018–2020 годах примерно одинаковое количество багов. Нужно учитывать, что и саппорт-команда очень выросла из двух человек до 10–15. То есть в целом количество ошибок уменьшилось намного.

Андрей: Очень сложно коррелировать, но по ощущениям, когда QA-команда перестала существовать, мы не почувствовали особых изменений в негативную сторону. Скорее наоборот: мы стали быстро реагировать на то, что просачивалось в production. Когда у вас маленькое изменение кода — вы сразу видите, где проблема. И ее намного легче и быстрее фиксить.

— Какие дальнейшие планы по развитию компании, команд и улучшению процессов?

Андрей: Мы продолжаем активно нанимать людей. Когда команда растет, соответственно должны эволюционировать, становиться более зрелыми процессы. Каких-то серьезных изменений с точки зрения QA мы не планируем. На данный момент наша культура хорошо работает, и мы будем развиваться в том же направлении.

— По Retention rate у вас есть какая-то статистика? Сколько человек в среднем уходит из компании за год, например? И сколько присоединяется за год?

Андрей: Есть, но я так сходу не вспомню цифры. Что я скажу: во-первых, мы растем очень быстро. Инженерная команда увеличилась на 60% в первом квартале текущего года. 2020-й был очень тяжелый для всех. Я это вижу не только по People.ai, но и по другими компаниям, с которыми общаюсь. Людям нужно живое общение. Специалисты выгорали в прошлом году. Поэтому я очень жду возврата к условиям, когда можно спокойно общаться друг с другом, приходить в офис. Всем этого сильно не хватает.

— Есть ли какие-то лайфхаки для борьбы с выгоранием, которые можешь выделить?

Андрей: В компании мы ввели recharge days. Каждый квартал мы даём всем сотрудникам 2–3 дня в дополнение к выходным. А если есть какой-нибудь праздник ещё, то получается 5–6 выходных дней подряд. Почему это лучше, чем отпуск? Когда уходишь в отпуск, жизнь не замирает. И ты либо во время отдыха мониторишь Slack, email, либо по возвращению, когда всё будет завалено делами и надо справиться с этим. Когда вся компания уходит на recharge days, дела не накапливаются — все отдыхают, и в этом ключевая разница.

Recharge days дают хороший результат. Я бы всем рекомендовал ввести что-то подобное. При том, что у нас есть безлимитные отпуска и мы даже поощряем людей их брать — не все берут. Mы следим, чтобы не проходил очень длительный промежуток времени, когда человек не берет отпуск. Вот эти recharge days, которые заставляют взять перерыв, помогают.

— Когда закончатся карантинные меры, вы будете возвращаться в офлайн или будете продолжать работать удаленно?

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

Уже сейчас, когда набираем специалистов, мы обращаем намного меньше внимания на их место нахождения. У нас есть люди в Харькове, во Львове, Херсоне, Днепре, Черновцах. Время от времени мы собираем всех сотрудников из Украины в Киеве, чтобы у них была возможность пообщаться, особенно когда кто-то приезжает из Сан-Франциско. До пандемии сотрудники часто ездили из Киева в Кремниевую долину и наоборот. Мы даже арендовали в Сан-Франциско постоянно две квартиры.

«QA знают продукт от А до Я, и это их суперсила»

— Что вы думаете про парадигму Software Developer in Test (SDET), когда есть человек, который занимается разработкой, но больше по части инфраструктуры, оптимизации процессов, коммуникации с командой, изготовления инструментов, чтобы упростить тестирование?

Андрей: Да, у нас есть команда, которая занимается Engineering Efficiency. Они ответственны и за инструменты для тестирования.

— И напоследок, может быть, вы сформулируете какие-то советы для людей, которые работают QA в других компаниях, как им оптимально дальше развиваться и расти?

Татьяна: Я уже знаю, что Андрей скажет, run :)

Андрей: Я думаю, тебе не понравится мой ответ. Я считаю, что QA может быть первой ступенькой для того, чтобы начать карьеру в IT. Но я никак не могу рекомендовать людям там задерживаться. С этого можно начинать, если нужно, но я бы не советовал идти в QA. А если вы там, то стоит переквалифицироваться так же, как это делали некоторые ребята у нас.

Татьяна: В свою очередь, я бы хотела дать совет. Я была в команде QA, это было добровольное желание. Но если бы я сейчас начинала карьеру в IT, то сразу бы пошла в девелоперы. Рекомендую начать с более легкого для вас направления и затем переходить в то, что интереснее. Например, некоторым инженерам сначала проще даётся фронтенд-разработка, чем бэкенд и так далее.

QA имеет хорошую базу, чтобы вырасти в инженера либо пойти в Data Science. Я в прошлом тестировала данные, отлично изучила проблемы с ними. И сейчас у меня остался майндсет такой, что нужно 1000 раз все перепроверить — это класный подход для дата-аналитика. Когда работаешь с огромным количеством данных, когда нужно постоянно коммуницировать их Executive-команде, клиентам, обязательно надо, чтобы это были качественные данные. Я сама проверяю каждую цифру. Опыт тестировщика в этом очень помогает.

Андрей: Есть ряд направлений, в которых ex-QA обычно очень успешны. QA знают продукт от А до Я, и это их суперсила. Часто инженеры так не знают продукт, как тестировщики. У нас QA перешли в инженеры и дата-сайентисты. Я видел также успешные переходы в продукт, Client Services, Technical Support.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось12
До обраногоВ обраному3
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Огромное спасибо за статью.
Всегда интересно узнать как происходят процессы оптимизации и трансформации качества в разных компаниях.

Есть несколько вопросов \ комментариев по содержанию статьи:

1. До момента расформирование тестировщиков — никаких видеов тестов почти не было, кроме ручных? Судя по проблемам внедрения функциональностей в Core систему не хватало интеграционного тестирования.
2. Если возникал вопрос ответственности за ошибку («это QA виноват — нет это DEV виноват») — то почему не внедрили ответственность всей скрам команды? Если пропустили багу, все сидят тестируют, фиксят и тд? В таком случае не будет «перекладываний» ответственности.
3. Правильно ли я понял, что работу QA «размазали» между разработчиком, саппортом и конечными пользователями?
4. Какие метрики позволили сказать, что при устранении отдела тестирования багов стало меньше и качество стало лучше?
5. Проводя параллели с компаниями в Долине и практикой on-call. У вас так же как и в Долине достойная компенсация и +100-200% к зп опционами дается? Или «работай как в Долине, получай как в Украине»?
6. Изменение отношения к юнит тестам не зависят от того, есть ли у Вас тест инженеры или нет. Зависит «культуры разработки» на всех уровнях. Простой блок на мердж при снижении покрытия кода ниже 70% может «привить» эту культуру. При условии того, что менеджмент не давит фичами «на завтра».
7.Полностью согласен с Вашим подходом «быть инженером, а не разработчиком на языке %%%»!
8. Внедрение CICD процессов могло произойти и с наличием тестировщиков. При Continuous Deployment никакого мануального тестирования не подразумевается — сразу в прод автоматически.
9. То есть «убрав» отдел тестирования — у Вас никто не обучал как правильно тестировать, техникам тестирования? Просто — «пишите тесты»? Никто не ведет статистику того, какие фичи покрыты и на каком уровне?
Отдельно взятый инженер не всегда может охватить весь продукт и понять последствая того или иного фикса.(Фокус инженера ограничен).
10. Кто занимается поддержкой end-to-end автотестов и обычных тестов? Как Вы боретесь с flaky тестами?

Всю статью прослеживается нотка, что отдел QA — причина бед не частых и обьемных релизов, отсутствия приемлемого coverage, культуры написания unit тестов dev специалистами.

Очень забавная история, каким образом команда QA виновата в отсутствии CI/CD, а главное каким образом отказ от QA команды решил проблему его внедрения))
Опять же если узким местом для позадачного деплоя было регрессионное тестирование(чек того что старый рабочий функционал не ломаем), то кто останавливал автоматизировать этот процесс и избавится от ручного регресса? От отказа QA команды регресс то моментально не пропал))
Кто мешал развивать культуру написания unit тестов dev специалистами? Представляю как QA бубнит «ребята, не пишите тесты, есть же мы, мы и без тестов все сами проверим».

Странно, что недостаточно оптимизированные/автоматизированные процессы в команде слили на QA.
Даже если после отказа от QA «хуже не стало» (не холиварю за то нужна QA команда или нет) , обьяснять достижения о появлении абсолютно нормальных процессов в команде тем что, мы отказались от QA — какие-то странные параллели.

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

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

p.s. у меня у самого команда успешно работает без QA. я просто не уловил логику действий СТО

Это еще ничего, у меня был один PM который сильно пушил фичу к сроку который он без нас пообещал заказчику. После нашего аргумента что мы может и успеем написать, но вот тестировщикам времени не хватит точно, он сказал что надо тогда просто писать код без багов :-D

196 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Андрій дуже хороший інженер і лідер. Явно є глибоке розуміння особливостей роботи і вміння доносити хороші ідеї до людей. Респект

Мав сьогодні розмову з нашим QC-інженером (ні, не про цю статтю), і згадав ще один цікавий і важливий нюанс з того проєкту, де я мав нещастя працювати без QC-команди.

Через те, що девелопери, як не крути, все ж таки набагато більше люблять писати код, ніж дизайнити і ганяти вручну тесткейси, в кодовій базі того стартапу прямо дууже яскраво було видно, наскільки там цвіла і пахла культура «ПРАЦЮЄ — НЕ ЧІПАЙ!».

Там були сотні прикладів відверто поганих інженерних рішень у коді, про котрі на той час їх автори вже і самі були чудово в курсі, що так робити не треба. Але ті рішення там залишалися, обростали костилями, гальмували, робили імплементацію деяких нових фіч або неможливою, або вкрай дорогою (і такою, що на фініші множила складність ще на десять).

Було би цікаво дізнатися у співробітників People.ai, чи не відчували вони подібних проблем у себе. І якщо ні — то як їм це вдалося? Юніт-тести це круто (і на згаданому мною проєкті з ними було досить сумно, що, звісно, усугубляло проблему), але навіть якби вони там були — більшість насправді серйозних архітектурних провтиків того проєкту фіксити без проведення нормального регрешену було би самогубством.

То ж як ви це розрулюєте у себе?

Кто-нибудь, скажите этим людям, что QA — это не определенная позиция, а роль, а они у себя внедрили SDET, хотя им нужно было Continuous Testing & TestOps (ну, ребята сами пишут что проблемы были с релизами и продом). Я понимаю, конечно, что комментить постики — не процессы оптимизировать, но тут явно нарушены причинно-следственные связи. Роль QA у вас осталась, это раз. Упразднили онли ручное тестирование — это двас. И, на сколько я понимаю, у вас не было нормального тест анализа и дизайна и с присутствием «КУА команды», исходя из фразы

«И один из трюков, которые мы используем, — тест-кейсы продумываются еще на этапе написания дизайн-документа для проекта.»

. Потому как это вовсе не «трюк», а основа(!) грамотного тест-дизайна. Как говорится, это классика, это знать надо! Короче, улучшения качества вы добились (и то, это еще выяснить надо, потому как качество — это не только кол-во найденых и пофикшеных багов) сугубо за счет реорганизации дев процессов и внедрения QA культуры и QC инструментов в разработку, но никак не за счет отказа от выделенных QC инженеров (тут я решаю назвать это грамотно, наконец). Так же интересно как отнеслись разработчики к той новости, что им теперь еще нужно заниматься тест-дизайном. Не верю я в понятие «человек-мультитул», да еще и без доплаты лол.
Резюмируя вышесказанное, уверен, что если добавить к проделанным изменениям грамотную QC тиму (пусть даже это будет всего пара человек), которая будет качественно пилить тест-дизайн и планирование, а так же выполнять необходимые виды тестирования на всех необходимых уровнях (сомневаюсь, что для продукта достаточно юнит и аксептанс тестов) и, все-таки, будет индикатором готовности продукта для выхода в прод (а это главное, Карл!), то как минимум разработка пойдет быстрее, а как максимум у менеджмента будет полная раскладка по состоянию продукта в целом, состоянию фич, состоянию спринта и т.д.

Нідайбох потрапити в таку контору, де топ-менеджмент не знає, що на unit-тестах тестування не закінчується. Воно цим тільки починається :-D

Довольно типичная статья небольшой компании, которая постоянно изобретает велосипеды, для сокращения расходов и повышения доходов. Одни избавляются от QA, другие все пытаются его внедрить. И те и те видят в этом серебряную пулю, которая убьет все проблемы. Штат инженеров «почти 50 инженеры». Скажите, каким образом ваша модель поможет компании где «почти 100 инженеры» и выше? На разных масштабах нужны разные инструменты. Маленькая компания может например использовать менеджеров как тестеров+менеджеров+аккаунтов, а девелоперы и тестируют и разрабатывают. Является ли это чем-то сверхъестественным? Нет. Статья — пиар про изобретение велосипеда.

Из статьи показалось, что раньiе процессы вообще не работали, потом вдруг начали что-то настраивать, в итоге с какими-то настроенными процессами работа идет лучше, чем раньше в полном хаосе. Крайними оказались QA.

Підтримую, аналогічна думка склалася і в мене після прочитання.
Процеси не були налаштованні тому що так звані «Сініори» (котрих набрали на початку стартапу) котрі мали це зробити цього не зробили, через що спрінт у два тижні постійно розтягувався до чотирьох, хоча можливо при цьому також було варто розширити команду девелоперів та тестувальників бо команда фізично не справлялася зі заданим темпом роботи — звідси виникають сумніви у кваліфікації даних людей котрі на початках не змогли налагодити процеси, виглядає так що насправді це були Джуніори а не Сініори.
У кінцевому результаті «всіх собак» повісили на тестувальників, програмістів «перекваліфікували» у програмістів-тестувальників (просто люди «добровільно» почали робити більше роботи за ті ж гроші), хоча як хтось дуже розумно написав у коментарях нижче, написання юніт-тестування це насправді не тестування, тестування це дуже глибокий та широкий процес.
Також сподобалось «онлайн моніторинг» — коли людина цілий тиждень 24 години на добу повинна бути на зв`язку і забути про своє особисте життя, хіба не простіше найняти на це окремих людей а не завантажувати і без того завантажених програмістів-тестувальників?
«По Retention rate у вас есть какая-то статистика? Сколько человек в среднем уходит из компании за год, например?» — пишуть, що статистика є, але при цьому цифри не називають, значить текучість кадрів висока.
«Людина не повинна знати одну мову програмування, вона повинна переключатися між мовами » - клас, мало того що програмісти самі тестують так ще й переключаються між мовами програмування, і в кінцевому результаті не будуть жодної мови знати добре.

P.S. Дякую за статтю. Для себе зрозумів у якій компанії я б не хотів працювати, хоча мене б і так не взяли сюди, я ж не програміст:)

. Мы планировали фичи, как правило, на две-три недели вперед. Это довольно большой кусок работы, занимались им всей командой, затем тестировали и показывали клиентам — выбирали конкретный день для релиза.

Вы серьезно на 3 недели вперед не умеете планировать? В детский сад.

В целом согласен с подходом, что без QA жить можно, это дисциплинирует, и в определённом контексте полезно (там описан гораздо более целостный подход, который в корне отличается от данной статьи). Поэтому критика по поводу причины и следствия вполне справедливая: как ниже уже заметили, для того, чтобы внедрить нормальную инженерную культуру, разгонять QA необязательно. Это же дело технического менеджмента — организовывать нормально работу, а не «сидит QA нянька, поэтому программист плохо оценивает и плохо тестирует». Чем-то напомнило недавнюю статью про 4-дневную рабочую неделю как бонус, когда менеджмент тоже решил весьма своеобразно пофиксить процессы путём (фактически) закручивания гаек а-ля «выплывет или потонет». Так и здесь: QA не мешали писать тесты и учитывать все факторы в оценке — это промах менеджмента, т.к. написать простой алогритм оценки с перечнем всех факторов достаточно легко. Может, я не прав, но, кажется, банально повышать эстимейты для тестов и проверок в случае присутствия QA просто никто бы не позволил в виду неформальных установок — тем более, стартап и постоянный прессинг новыми фичами... Попасть в такой круговорот и перестать объективно воспринимать реальность очень легко. Поэтому интереснее всего, что говорили обо всём этом технические лидеры команд? Ну, т.е. месяц плохо, два плохо, год плохо — и?.. В таких случаях нужно банально остановиться, разгрести завалы и отстроить процессы — вполне возможно, что раньше компания просто не могла или менеджмент не хотел себе этого позволить, а QA просто вовремя под руку подвернулись.

Из сложностей — у нас до сих пор есть проблема с тем, чтобы была стабильная среда для интеграционного тестирования.

Полноценная тестовая интегрированая среда может быть недостижима в общем случае с ростом объема и сложности системы.

Перестать тестировать функционал на тестовых средах не думали? Все тестирование либо в изоляции (CI, local dev workstation) либо на продакшине с фича-тоглами и прочими канари-релизами.

mgurov.github.io/...​n-production/#related-art — пара мотивирующих ссылок.

Пробовали, делаем. Есть фича-флаги, есть конфиг-флаги, есть b-пользователи. Тестовая среда все-равно нужна. Не все возможно протестировать, как минимум из соображений безопастности;

Хорошая статья, и тема жизненная. Согласен на 100% что, к сожалению, наличие тестировщика в команде часто негативно влияет на качество или на скорость выпуска продукта, а чаще — на оба показателя.

Очень занимательно читать стройный хор «да как так можно, точно загубите все, как же дорогих девелоперов на тестирования тратить!» в комментариях. Даже Чернобыль, вижу, приплели.

На европейских конференциях по тестированию сквозной темой последних лет являются «shift left» и «QA specialist as a coach, not a tester»- т.е. сам факт того, что тестирование по-старому не работает уже принят коммьюнити, и опыт многочисленных продуктовых компаний показывает что высокое качество без тестировщиков-привратников (gatekeeping) вполне достижимо.

В корне не согласен с комментаторами о том, что практика «разработчики сами тестируют» работает только с уровнем выпускников MIT из силиконовой долины. Как раз 80% средней медианы QA-няни вредны. Джунам — тем тестеры да, нужны, ибо не ведают что творят. Высококлассным специалистам лишняя пара глаз не мешает — могут и с и без.

Кажется, вы вообще не понимаете что такое и зачем нужно тестирование, и чем оно отличается от QC и QA.

Обоснуй. Почему кажется? Потому что считаю что тестирование могут проводить не специально для этого отведенные люди?

Просто сначала вы говорите про наличие «тестировщика» в команде и его негативное влияние, а потом говорите что тестирование проводить, все-таки, нужно, но его могут выполнять и девелоперы. Но вы упускаете из виду, что тестирование (не говоря уже о QC и QA активностях) не ограничивается тестированием кода (статическим анализом, юнит-тестами, интеграцией), которое могут и должны(!) проводить разработчики. Есть другие виды тестирования на других уровнях, кроме модульного, которые выполняются для достижения уймы совершенно различных целей. Тестирование — не просто поиск ошибок в коде, а опробация софта на предмет чего-либо/соответствия какому-либо поведению. Проводится оно не только для нахождения багов в коде, но и для проверки соответствия установленной бизнес-логике, работоспособности при стабильных и экстремальных нагрузках, интегрируемости в системы и взаимодействия с дургими системами/сторонними продуктами, проверки обратной совместимости, удобства использования. Если мы коснемся QC, то поймем, что часто кто-то, например менеджмент (если он грамотный), хочет быть в курсе состояния дел и иметь постоянно в своем распоряжении картину происходящего с продуктом (правильные ли у нас требования, правильно ли они интерпретированы разработчиками, какие фичи имплементированы, какие уже можно пускать в продакшен, какие нужно дорабатывать, какие проявили себя как нежизнеспособные, где у нас слабые места и уязвимости или где они могут возникнуть, я уже не говорю о сборе всевозможных метрик...), ну в общем, мониторить.
Не будет тут черного и белого, типа тестировщики — это плохо, СДЕТ — панацея. Всё зависит от ваших целей. Понятно, что если у вас маленький проект или стартап, то у вас будут одни приоритеты, и вы примените одну стратегию/методологию, в которой у вас смогут выполнять минимально необходимое тестирование опытные разработчики. Но, если у вас сложный (что называют complicated) продукт с уймой зависимостей, интеграций, над которым работают несколько команд, время которых на вес золота — вы будете распоряжаться ресурсами иначе, и возможно, наймете целый отдел контроля качества. Цель у вас что там, что там всегда будет одна — максимально экономить деньги (ведь QA, QC, Test Engineering — это всё про методы экономии денег, и все несогласные — либо тупые, либо врут), принцип будет один и тот же: превенция неисправностей/ошибок, а так же максимально быстрая их локализация и устранение, методы достижения будут разные и зависят исключительно от способности грамотно распорядиться ресурсами.

На европейских конференциях по тестированию сквозной темой последних лет являются «shift left» и «QA specialist as a coach, not a tester»

Что касается «shift left», эта стратегия вообще не про отказ от тестировщиков, а про смещение фазы тестирования в начало SDLC и распараллеливание с дизайном и разработкой. «QA specialist as a coach, not a tester» — тоже не про отказ от тестировщиков как класса, а про разделение ролей QA и test engineer. QA — это вообще не должность. Это процесс.

Как раз 80% средней медианы QA-няни вредны.

Вредны они только тем, кто возлагает на них часть ответственности за СВОЮ работу или надеятся, что кто-то за них что-то проверит. QA — это когда все отвечают за качество: и разработчики, и тестировщики, и менеджмент.
На примере статьи скажу, что ребята вроде оптимизировали процессы и все заработало лучше, но исходя из того, что я увидел, у них все еще не хватает целого пласта проверок. Если они считают что им это и не нужно — ок, но не нужно сразу писать статью на ДОУ, претендуя на изобретение панацеи.

Очень круто расписал! Приятно, интересно следить за ходом мысли профессионала

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

Полностью согласен. Тестирование в частности, и качество продукта в общем — это широкий спектр задач, который не должен (и не может) быть ответственностью тестировщиков или выделенных отделов качества (как бы мы их не называли).

Если мы коснемся QC, то поймем, что часто кто-то, например менеджмент (если он грамотный), хочет быть в курсе состояния дел и иметь постоянно в своем распоряжении картину происходящего с продуктом (...), ну в общем, мониторить.

Ну да. Где это противоречит статье или моему комментарию? Другой вопрос — как это мониторить, и тут отделы качества не всегда помогают т.к. часто излишне сфокусированы на узком определении этого качества через колличество багов обнаруженных / пропущенных. По крайней мере в моем опыте.

Понятно, что если у вас маленький проект или стартап, то у вас будут одни приоритеты, и вы примените одну стратегию/методологию, в которой у вас смогут выполнять минимально необходимое тестирование опытные разработчики. Но, если у вас сложный (что называют complicated) продукт с уймой зависимостей, интеграций, над которым работают несколько команд, время которых на вес золота — вы будете распоряжаться ресурсами иначе, и возможно, наймете целый отдел контроля качества

Ну уверен, что ты хорошо понимаешь проблему описанную в статье. Выделенные тестеры (будь то внедренные в комманду или выделенные в отдельный отдел) становятся узким горлом как раз при росте сложности системы и интеграции частей ее, обычно становясь (невольно) препятствием к frequent delivery.

Цель у вас что там, что там всегда будет одна — максимально экономить деньги

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

ведь QA, QC, Test Engineering — это всё про методы экономии денег

в подходящем контексте — да, но не всегда. Это как дизайн — совсем без дизайна плохо, но можно и переинженерить.

все несогласные — либо тупые, либо врут

с таким сильным аргументом не поспоришь🙂

Вредны они только тем, кто возлагает на них часть ответственности за СВОЮ работу или надеятся, что кто-то за них что-то проверит. QA — это когда все отвечают за качество: и разработчики, и тестировщики, и менеджмент.

100%. Только вредны они ВСЕМ, а не только тем разработчикам которые привыкли пробрасывать таски «тестеры разберутся — на то они у нас и есть». И собственно убрать тестировщиков или отдел QA (потому что разрабы все равно прочитают как «отдел тестирования») — это наиболее эффективный метод эту ответственность вырасти. По аналогии с ездой на велосипеде — пока с трехколесного на двухколесный не пересядешь — держать равновесие толком не научишься.

«Убрать», кстати — не значит уволить. Тестировщики обычно владеют большим пластом доменного знания, просто увольнять их глупо. Дать другую роль и обязаности. Как и в обсуждаемом случае, насколько я понимаю, произошло.

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

Откуда это видно, что у них не хватает этих проверок? Вполне возможно, эти проверки есть — но не классифицируются как «software testing/QA» — вижу такое в продуктовых компаниях, когда большая часть тестирования/мониторинга происходит как органическая часть bizops/devops.

Если они считают что им это и не нужно — ок, но не нужно сразу писать статью на ДОУ, претендуя на изобретение панацеи.

Ну, не нужно так к ним жестко. Где они претендовали на панацею? Почему не нужно писать статью? Где бы мы это обсуждение проводили, где твои комменты так понравились «Sergey Setti Laravel ninja»?

Возращаясь к своему вопросу, не вижу из твоего ответа почему я не понимаю для чего нужно тестирование. Скорее, по основным вопросам у нас точки зрения совпадают:
— тестирование это намного шире, чем просто нахождение багов в коде
— тестирование в частности и качество в общем — это общая ответственность и не должна быть головняком только отдельно назначенных индивидуумов.

Отличие вижу в тактических подходах построения процесса software delivery, что само по себе сильно зависит от фазы развития организации, инженерного и бизнес-контекста. Типа заводить QC команду в engineering или покрывать этот аспект в рамках общего бизнеса.

Я же написал, кажется. Потому что изначальный менее подробный комментарий меня обескуражил радикальностью утверждения «QA/QС не нужны». Сейчас я согласен, в большинстве вопросов взгляды у нас с вами сходятся.

Но, вы сами говорите

Отличие вижу в тактических подходах построения процесса software delivery, что само по себе сильно зависит от фазы развития организации, инженерного и бизнес-контекста. Типа заводить QC команду в engineering или покрывать этот аспект в рамках общего бизнеса.

А это уже отличается от изначального посыла в первом комментарии :)

В любом случае, разница лишь в том, что я больший приверженец выделения по возможности QC команды (именно команды или роли в команде, а не отдела), а вы — ее упразнения. Возможно, это следствие того, что я всю свою сознательную (и небольшую относительно вашей) карьеру провел в роли Software Test Engineer , а вы, судя по профилю на линкдин — в роли Software Engineer, и видим мы проблемы в первую очередь с точки зрения роли, в которой нам приходилось их решать, и личного опыта, который формировался возможно где-то в схожих, а возможно и в кардинально разных условиях. Но суть этого уже не столь важна. Я могу понять вашу позицию и тезисы о том, что

Выделенные тестеры (будь то внедренные в комманду или выделенные в отдельный отдел) становятся узким горлом как раз при росте сложности системы и интеграции частей ее, обычно становясь (невольно) препятствием к frequent delivery.

Я понимаю механизм, по которому они становятся этим узким горлом, но ведь и это тоже поддается оптимизации, и для этого есть перераспределение уровней тестирования, разные способы избегания exhaustive и over testing и т.д. Но это уже отдельная бесконечная тема для обсуждений.

Во втором развернутом комменте я увидел интересную аргументированную альтернативную позицию, что радует и расширяет кругозор. Я не привык к действительно предметным аргументам, когда речь идет о таких вещах как качество софта, продукта и QA как явлении. Странно, но коллеги из сферы непосредственно тестирования и обеспечения качества часто имеют очень разобщенные (и очень часто некорректные ) трактования этим понятиям.

Что касается вышеупомянутой компании и этой статьи, я сомневаюсь, что они действительно глубоко продумывали реструктурирование. Сложилось впечатление, что тестеры у них были какой-то оторванной от общих процессов субстанцией, и им не нравилось, что тестеры дискаверили баги в тот момент, когда у всех остальных был запланирован офигенно удачный кастомер-колл и легкий непринужденный релиз. А тут тестыры со своими багами, уу собаки, убрать! Вот они не мудрствуя лукаво и пораспихивали остатки тестирования (качество которого и так было под большим вопросом) по разным промежуткам SDLC, да еще и статейку на ДОУ выкатили, какие молодцы, посмотрите!

Подчеркну, это всё исключительно моё ИМХО, разжевывание почвы которого потянуло бы на еще одну не менее объемную (и возможно не менее убогую) статейку на ДОУ, за сим что либо аргументировать по этому поводу я отказываюсь :D
Я ни разу не претендую на авторитетность своего мнения, я не СЕО, не СTO, не НЛО и даже не 23х-летний тимлид, чтобы рассказывать как кому проекты пилить. Может ребята реально сделали прорыв, и через пару лет я буду стачивать зубы скрипя челюстью от осознания своей некомпетентности, пока толпы айти менеджеров будут расхватывать бестселлеры Андрея и Татьяны под названием «Как тестировщики не давали нам жить», кто знает...

Определенный смысл есть. Знаю массу проектов которые загнулись из-за репортов QA

А те где QA были юзеры — живы до сих пор.

Тут главное не рушить тонкую грань и слушать фидбек.

А как репорты могли загнуть проект? Это всего лишь фидбэк. А вот что будет делать менеджмент с этим фидбэком — это другой вопрос.

Он действует по флоу — двигает девам, девы перестают клепать фичи, чекуют багу а она не воспроизводиться. Минус час времени. 8 баг и можно идти домой.

Если прям столько багов не воспроизводится, это уже вопрос к профессионализму QA. Об этом нужно говорить не дожидаясь ретроспектив или чего-то ещё.

В идеальном мире QA работают идеально.

Никто не идеален. Но если в команде норм атмосфера, где люди прислушиваются к коллегам — то многие проблемы удаётся решить.

С финансовой стороны нет промаха? Обязаноти QA теперь выполняют Dev-ы, ЗП которых выше QA.

Ты разраб, пишешь что-то сложное в чем QA не шарит, в большенстве так и есть. Он тебя будет дергать и тратить твое время.

Пусть бизнес-аналитика дёргает. Разраб тут при чем?

Є супер рішення, хай код пишуть QA і тоді можна зекономити на девах!

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

10к зарплата, думаю бажаючих багато)

Встал ночью и поправил 😆👏🔥 как к вам попасть на работу?) Такие статьи писать это гениальный ПР🥇

Не думаю що така компанія довго так пропрацює. Або розробники тут виконують роль QA, або користувачі виконують роль QA, але як клас вони однозначно існують. І в певний момент комусь це набридне і він скаже своє «фе», причому доволі голосно. І ще: розробник відповідає за код з технічної сторони, тестер — зі сторони бізнес-логіки, тому вони доповнюють один одного а явно не заважають. Якщо була проблема в комунікації між розробникам та тестерами, то розігнати відділ тестерів не найкраще рішення...

Виталий, возможно, но крайне мало вероятно. Это глобальный тренд и реакция на него вполне предсказуемая, очень хорошо описана доктором Элизабет Кюблер-Росс (ссылка ниже).

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

За 7 лет работы в продуктовых компаниях США (Google, Indeed, People.ai) Я видел 0 команд, у которых был выделенный QA, но видел много команд SDET, которые делают инструменты которыми пользуются разработчики.

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

модель Элизабет Кюблер-Росс — t.ly/figV

Я не знаю что там нагадала Элизабет-Кросс, но когда у нас однажды не стало QA по инновационной методике, запрошенной заказчиком:

1) первые месяцы я лично писала чеклисты для проверки продакшена, (увлекательное занятие), расшарила их со всеми, проверяли руками прод после релизов (потому что тесты тогда были не полные, к примеру 80% покрыто а 20% нет, и тесты все равно НЕ гоняются на продакшен серверах а там может НЕ работать по некоторым причинам даже если работало на sandbox)

2) стали писать чеклисты перед началом задачи (прописывать все эдж кейсы которые нужно учесть и протестить) и дополнять этот чеклист когда задача закончена и стали очевидны еще какие-то кейсы. Убеждались что все эти кейсы покрыты тестами (во время код ревью смотришь по всем ли кейсам есть соответствующий тест).

3) сильно критичные функции все равно проверялись на проде руками после релиза

В этом процессе:
— чеклисты мог бы писать QA а не программисты с лидом
— руками перепроверять прод могли бы QA
— я заметила что лично у меня теперь головной боли больше, чем когда я знала что строгий и непреклонный QA не пропустит ни единой ничьей бажины на прод и потестит api с разными наборами данных а не с 1-2. А теперь это мой головняк: следить за чеклистами и прописанными эдж кейсами в каждой таске («учел ли Василий в его коде что при входных даных Х и У там нужно по-особому обрабатывать? а учел ли что если одновременно придет N запросов оно не выдержит? а вот это... а вот то....») просто потому что человек который не очень давно (2-4-6 и иногда даже 8 месяцев) на проекте — еще не может учесть все-на-свете тк у него нет еще полной картины. После 6-8 мес уже качественно продумывают все кейсы сразу. Но и то... сильно зависит от того спешил человек, или нет, в пятницу продумывал эдж кейсы или в понедельник.

И я вам напомню: средний по индустрии срок работы программиста на проектах сейчас равен 2 года. А значит команда из 4х человек кого-то теряет или получает регулярно (раз в полгода)... и «наша песня хороша начинай сначала» садись пиши и продумывай эдж кейсы по таске вместе с новенькими в их тасках

Я могу включит режим «мневсеравно» и оставить проработку эдж кейсов на совести того кто делает таску, но за упавший прод получим пилюлей все, а не только какой-нибудь Василий который работает у нас 3 месяца и не учел что если придет 2 запроса параллельно то там все упадет. А что будет при регулярных факапах на проде? К примеру раз в неделю? Не потеряет ли наш заказчик свой бизнес из-за оттока клиентов по причине ненадежности работы сайта?

Елена, интересная история, QA потом вернули?

Без QA прожили полтора года. Я вот в пятницу сложила все полномочия и передала новому лиду. У меня все полтора года без QA было ощущение, что 50% работы бывшего QA на мне (на этапе постановки задач нужно сильно больше кейсов проговаривать и обсуждать, делать вместе эти чеклисты, на этапе приемки сильно внимательнее смотреть теперь не только код, но и тесты — не только их наличие, но и качество, после релиза спрашивать Вась ты ж продакшен проверил?). Будет ли этим заниматься новый lead — время покажет ) Спросим через полгода

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

Я хз #чтомыделалинетак и почему это ощущается в 2 раза напряжнее чем жить с QA. Может большие компании типа google, в отличие от небольшого проекта на 5 человек имеют возможность: (а) на каждого новичка выделить по старичку (б) проводить всем поступающим в компанию тренинги как писать качественные тесты (в) делать даже маленькие ченджи две недели, пусть девелопер сидит пишет на свои 2 строчки изменений тесты хоть до посинения, плюс-минус две недели не горит (г) пропускать каждый PR через 3-4-5 ревьюверов а не через 1-2 которые и так уже зашиваются

За эти полтора года проект потерял в качестве? Количество тикетов/жалоб клиентов увеличилось/уменьшилось?

Вам пишут "

это ощущается в 2 раза напряжнее чем жить с QA

"
А вы про качество продукта спрашиваете. Вы точно Staff Engineer?

Я коли йшов тестером пару років назад, мені теж знайомі розробники говорили, що ця професія проіснує максимум до пів-року і як такого класу QA не буде. Вже змінив кілька компаній, і роботи наразі лише прибавляється. Тому тренди — трендами, а реалії — вони інші.

Виталий, ваши знакомые разработчики серьезно ошиблись )). Я думаю всегда буду проекты для которых наличие QA это отличный вариант.

И если в недалеком прошлом команду без QA можно было рассматривать как нонсенс, то сейчас все больше компаний адаптируют это модель. Модель работает для больших и средних компаний. People.ai подтверждение того, что модель работает для стартапов.

Где можно посмотреть на тренд отказа от QA? Как можно проверить наличие такого тренда?

А я в своїй сфері діяльності бачив 0 команд без окремого QA, і це глобальна тенденція, не тільки в україні. Реакція передбачувана, описана Е. Кюблер-Росс — прийняття теж згодом прийде)))
А тепер без жартів: досвід цікавий, але впевнений, що натягувати його всі технологічні компанії і ліпити сюди стадії заперечення-прийняття не варто (т.к. ці стадії самі по собі нічого не доводять).

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

У нас путь без QA и он нам дает отличные результаты и за это приходится платить высокую цену. Это как покупка Тоyota вместо Hyosung, сразу дороже, но когда ты понимаешь долгосрочную математику всего этого — то выгода очевидна.

Работает ли это для огромных компаний — да и FAANG в пример!
Работает ли это для средних компаний — да, Indeed в пример
Работает ли это для стартапов — да, People.ai в пример

Мы показываем свою модель и возможно это поможет кому-то при старте очередного проекта рассмотреть больше альтернативных вариантов и принять решение, которое действительно подходит.

Я не спец по трендам, особенно в США, но звучит логично. Т.к. QA — это подход, процесс (если художественно сказать — культура). Это не должность, это процесс, который сторится людьми на разных позициях (разработчики, менеджеры, аналитики, тестировщики и т.д.). Если мы говорим о позициях QC и Test инженеров, то я бы назвал это не отказом от QA, а переквалификацией. Область обеспечения и контроля качества так же развивается как и разработка, появляются новые инструменты и методологии, требующие бОльших технических навыков. Цель остается та же, роли те же, меняется инструмент и название.

Это еще ничего, у меня был один PM который сильно пушил фичу к сроку который он без нас пообещал заказчику. После нашего аргумента что мы может и успеем написать, но вот тестировщикам времени не хватит точно, он сказал что надо тогда просто писать код без багов :-D

писать сразу без багов — намба уан на всех ретроспективах страны.

А шо такое, я пишу код без багов (ну, почти)

Когда ты сам себе спеки пишешь, и сам у себя работу принимаешь, — и не такое может быть.

Через 4 года ждем статью:

Почему в People.ai НАНЯЛИ QA-команду и что это дало

Это в том случае, если стартап протянет 4 года без QA

Бізнесу пофіг на якість коду і на процеси.

Исправьте в комментарии на: «если стартап протянет 4 года с таким руководством»

Я, звичайно, вірю, що менеджмент неабияк пишається своїми нововеденнями, але давайте на чистоту — ви переклали всі обов’язки і відповідальність на плечі інженерів. В інтерв’ю це ніхто і не приховує, підкреслюючи, як це круто. В принципі, якщо є необхідність в pagerduty і нічним дзвінкам це швидше говорить про незрілість процесів і відсутність контролю якості. Якісно відтестований продукт не обсирається по ночам. Принаймні не так часто і сильно, щоб вводити для цього нічні вахти. А ваші Unit тести перевіряють тільки те, що код працює так, як це собі уявляє його автор. А оскільки ви також переклали обов’язки і BA і PO на інженерів, то цінність такого тестування, в принципі, викликає питання — немає документу на який можна посилатись під час тестів — все в головах бідних інженерів.
І ок, якби в цих інженерів був стейк в компанії або 200% оплата праці за всю цю головну біль. Тоді, можливо, дійсно ці люди були б зацікавлені в підтримці всього цього зоопарку. Але єдиний інструмент мотивації, про який згадували — заклик до відповідальності.

Сергей, коротко по сути предположений

1. Ночных PagerDuty нет — часовые зоны Киев + Сан-Францизско
2. Все в головах инженеров, в дизайн-документах, PMs — работать реально проще, каждый хорошо знает не только свою часть, но еще и пограничные зоны.
3. Unit-tests, e2e, также еще и фича-флаги, конфиг флаги, b-юзеры, CI/ID и конечно же ручное тестирование руками разработчиков
4. Стейк в компании, хорошая зарплата, прочие perks
5. Сейчас 200+ человек в компании, продолжаем расти
6. Ответственность — это ценность которой мы руководствуемся когда реализуем наши решения

Самое главное — команда, где каждый доводит начатое до конца.

Вопрос — Андрей, на основании каких фактов из статьи вы сделали вывод что призыв к отвественности это единственный инструмент мотивации?

Вопрос — Андрей, на основании каких фактов из статьи вы сделали вывод что призыв к отвественности это единственный инструмент мотивации?

Віктор, а Ви часом рекрутером на півставки не працюєте?

але ж він... Олександр

Сергей, вопрос еще актуален, помогите нам пожалуйста понять на основании чего делается вывод что призыв к отвественности это единственный инструмент мотивации?

Прощу прощения за не правильное имя в тексте ответа, следовало указать Сергей вместо Андрей.

Александр, ваши инженеры обязательно уйдут из компании рано или поздно, и вместо них придут новые люди. Вместо старых дизайн-документов будут многократно переделанные, обновленные, устаревшие более поздние документы. Тогда подход «все в головах...» перестанет казаться Вам «реально проще». Каждый будет не только не знать свою часть, но и потеряет всякое представление про пограничные зоны.
А «ручное тестирование руками разработчиков», по моему мнению, говорит не про то, что вашему стартапу удалось настроить работу без QA, а про то, что новых инженеров придется искать скорее раньше, чем позже.

Сергей, если инженер не тестирует то, что сделал своими руками, можно ли сказать что он сделал свою работу качественно?

В дополнение к ручному тестированию

3. Unit-tests, e2e, также еще и фича-флаги, конфиг флаги, b-юзеры, CI/ID и конечно же ручное тестирование руками разработчиков

Уйдут инженеры или нет — это вопрос будущего, которое не опредленно. Расчет на то, что если инженер знает больше, то и учить новичков будет ему проще.

Подход «Все в головах» рисковый, тут спору нет, и поэтому мы активно пишем документацию.

Мій минули проєкт був якраз стартапом, що культивував подібний підхід. І це було (особисто для мене) ПЕКЛО. :) Але досвід, звісно, може відрізнятися, тому хотілося би відмітити великим плюсом для компанії People.ai, що вони чітко і прямо вказують цей нюанс процесу розробки відразу на етапі найму і набирають тільки фахівців, котрим так працювати OK.

Отже, як це було. Мою команду взяли на допомогу в розробці одного американського стартапу. Нам круто пощастило, що людина, котра нас рекомендувала, продала нас разом з одним QC інженером (при тому що в команді на стороні клієнта QC реально не було ніколи), і розроблена нами функціональність все ж таки тестувалася QC. Попри це, нас всеодно схиляли до того, що ми маємо тестувати свій код самостійно.

Тепер розкажу, чому це було такою великою проблемою для мене. Я спеціалізуюся в основному на бекенді і пишу на Django/DRF. Ці інструменти «з коробки» мають просто офігєнний інструментарій для юніт-тестів, при чому ці тести є чимось середнім між класичними юніт-тестами і e2e — легко покривається робота цілого ендпоінту.

На «сусідніх» проєктах (той що був перед тим прогресивним стартапом, і той на котрому я є зараз), я цілком собі успішно пишу бекенд, маючи досить смутне уявлення, як взагалі виглядає фронтенд. А штуки типу Postman не використовую взагалі. Бо джангівські юніттести — часто реально найшвидший і найзручніший спосіб нагнути систему в потрібне мені положення щоби подивитися як працює код у кожній бренчі логіки. Після того результат легенько запихається в assert — і функціональність покрита тестами. В результаті на моїх проєктах coverage 90+%, і виходить це цілком органічно, просто тому, що юніттести є найпростішим способом перевірити, як працює код.

Попри хороше покриття, після мої юніттестів QC всерівно час від часу (але, повірте, не дуже часто) знаходять якісь баги. Пишеться юніт-тест котрий це репродьюсить, бага фіксається, тест лишається.

Ну і от. Коли мене поставили перед фактом, що я мушу займатися мануальним тестуванням — це, по-перше, мене досить сильно демотивувало, бо мені якось цікавіше і приємніше займатися тим, на чому я справді знаюся. По-друге, якість мого мануального тестування була така собі. По-третє — знаючи, що мені всеодно треба робити ручне тестування, я почав ловити себе на тому, що десь бракує юніттесту, оскільки я репродьюснув і пофіксав багу під час ручного тестування, а тест потім було писати лінь, та й час на це не вистачало.

Коли клієнт не продовжив контракт (вони скорочували витрати через початок епідемії) — то був один з найкращих днів в моєму житті. :)

P.S. І так, коли ми зайшли на проєкт, покриття тестами там було мінімальне (якщо добре пам’ятаю, щось коло 43% — після 4+ років розробки). Коли ми через рік звідти йшли, покриття складало 85%.

Не можу цього впевнено стверджувати, але припускаю, що такі сумні цифри покриття були не в останню чергу через те, що девелопери тестували свій код вручну. Після того, як ти вже витратив купу часу на те, щоби вручну засетапити дані в базі, заставити себе зробити фактично ту ж саму роботу в юніт-тестах досить складно.

Покриття тестами != якісний продукт

Я і не стверджував цього. Але відсутність тестів майже завжди == неякісний продукт. Котрий вкрай важко розвивати.

В одной из веток форума, я вспоминал как мы делали и продавали свой продукт JxBrouser. На начальном этапе в 2007-2008 годах у нас не было тестировщика, иногда удавалось «выциганить» кого нибудь из аутсурсинговых отделов вокурат перед релизом. И баги попадали в релиз, нас потом рвали на части пользователи обращаясь в супорт. И вот потом, наш новый менеджер, сам бывший QA, какими то правдами или не правдами сумел найти нам тестировщика и баги в релиз перестали попадать (о чудо). Вот один из QA вступивший в дискуссию на эту тему написал замечательное высказывание : «разработчик может сам тестировать с таким же успехом как и тестировщик может сам разрабатывать». В общем все что я вынес из этой статьи — жлобство бизнесменов иногда приводит к очень глупым решениям, которые стоят намного дороже чем те суммы которые они намеревались с экономить. Самый типичный пример — Чернобыльская АС. P.S. По вопросам «проблем» в разработке с которыми столкнулись авторы статьи — тех/тим лидам и менеджерам (впрочем как и тест лидам если они вообще были) большой физкульт привет, и рекомендация читать книги по профессии (одной тут явно дело не обойдется).

Всё правильно! Нужно что бы и у разрабов была возможность «прийти к успеху» :)
ain.ua/...​ody-xbox-kodov-na-10-mln

«После релиза обычно всплывало много багов, клиенты жаловались.»
— Это вообще как? Зачем вы вообще релизились с багами?
Если их не находили на этапе тестировани — надо просто менять тестировщиков.
Если фича была плохо документирована и вылазило то, чего не тестировали — писать доки и, верочтно, все равноменять тестировщиков.

«Обычно на этапе тестирования вылезало большое количество ошибок и мы не успевали их фиксить вовремя.»
— Значит надо менять инженеров. Почему они так плохо проектировали фичи?
На проекте вообще была дока?
Вы понимаете что программист 90%времени думает и проектируе, 9% читает код и только 1% кодит?

«При этом бывало, что у Олега Рогинского, нашего фаундера, через несколько дней после планирования релиза уже был назначен customer call, на котором он должен был презентовать новую фичу.»
— Вот вам лайфхак. Один раз задержите выпуск одной фичи и после этого показываете ее уже готовую чрезе неделю в то время делаете фичи Б, В, Г ...
— Кроме того это опять же проблема или отсутствия документации (зхнания инженерами системы) или отсутствие платирования при выполнении задач.

Ребята — вы просто запретили инженерам косячить! «Типа я вроде сделал, а тестировщики пусть проверяют».

Есть такое понятие в Scrum как Definition of Done. Можно ввечти такое правило что, задача отдается в тестирование только если разработчик видит, что она рабоатет по документации на тестовом окружении.
Можно не давать премию, если любая задача вернулась к разработчику более 3х раз (для начала) в джите это отлично видно. И потом снижать порог.

«Но у нас были инженеры, которые хорошо знакомы с таким подходом и умели это делать. И вот они показывали пример, менторили тех, кто учился.»
— Ну то есь инженеры которые не косячат были.

«Я считаю, что инженеры могут видеть разные edge-кейсы и даже лучше, чем QA»
— Значит это плохой QA, не зря есть анекдот

Заходит однажды тестировщик в бар.
Забегает в бар.
Пролезает в бар.
Танцуя, проникает в бар.
Крадется в бар.
Врывается в бар.
Прыгает в бар
и заказывает:
кружку пива,
2 кружки пива,
0 кружек пива,
999999999 кружек пива,
ящерицу в стакане,
—1 кружку пива,
qwertyuip кружек пива.
’ or 1 == 1 кружек пива.

... А потом, после открытия бара, заходит первый посетитель и спрашивает у бармена, где туалет. Бар взрывается, разрушая весь квартал.

Тут усі такі розумні, то задам питання.
Є декілька команд, взагалі п’ятдесят людей. Одна людина робить в середньому дві задачи за тиждень, але періодично є тижні де майже немає нічого зробленого, лкрім рефакторингу чи внутрішніх програм, а іноді дуже багато зроблено.
Деплой йде хвилин зі двадцять без жодних проблем для користувача.

Питання, де в цьому процесі потрібні QA?

PS. Я не пов’язаний з People ai анітрішки.

Вашою роботою потім користувачі користуються, чи ви працюєте виключно в /dev/null ?

Мабуть так.
А ні почекайте, бо програмісти пишуть тести різного рівня. Разом з doc командою пишуть документацію.
Support допомагає зрозуміти проблеми користувачів, шле баги.

— E2E Autotests?
— ні, не чули

*і це тільки Е2Е, якщо юніт і інтеграційні/контрактні/etc є готові і раняться і пишуться девами (що далеко не завжди)

Тобто або затримуємо реліз на декілька днів, щоб написати тести(плюс час на повернення коду з помилками, плюс реверт, плюс зміна контексту) , або деплоїмо непротестований код.
Або девелопери пишуть E2E тести під час роботи на завданням. Але навіщо тоді QA?

чекайте, що значить «затримуємо реліз»?
тестування — це одна з основних активностей потрібних в девелопмент циклі (якщо навіть абстрагуватись від того, що ви апологет, що QA не потрібні).
як тестування може «затримувати» реліз?
тобто, чим швидше реліз, тим краще, так?
тоді за вашою логікою, не потрібні менеджери, БА і всі інші. давайте залишимо тільки кодерків, які будуть робити все і релізитись хоч щодня.
ото буде клас

Без QA. Середня програмістка пише тести півтора дня і код два дні, ще дві години на контекст. Ще дві години на CI/CD. В сумі чотири дні від задачі до продакшну.

З QA. За півтора дні напрограмована задача, можливо ще години дві на юніт тести.
QA бере задачу через день, пише день тести. Знаходить баг. Повертає задачу розробниці.
Розробниця витрачає годину на контекст, годину на виправлення, потім ще годину, щоб повернутися до іншої задачі.
Знову QA чекаємо півдня. Потім за дві години QA каже, що працює і можна релізити.
В сумі п’ять днів на задачу.

Якщо реліз можна зробити дуже швидко, то це відразу помітно.

Ну та а регрессия?
Хотя бы в связанных модулях.
Рефакторинг как раз требует регрессии.

Внутренние программы тоже можно тестировать.
Как правило всегда есть долг по приведению документации в соответствие проекту.
Если тестировщики толковые они могут писать или оптимизировать автотесты.

Якісь люди мають писати документацію.
Чому це не програмісти чи тех райтери.

Про автотести не зрозумів. Чому їх не можуть писати програмісти? (Окрім того, що тестери трохи дешевші). І знову таки — затримуємо реліз на час написання автотестів чи релізимо без тестів?

Рефакторинг має покриватися тестами проекту, інакше не можна робити легкі рефакторинги постійно, що робить код слкаднішим і підвищує ризик рефакторингів, бо якщо треба чекати на тестера, то витрачати на рефакторинг будуть не підвгодини-годину, а декілька днів.

Так — справа у вартості години роботи ))
Крім того не завжди програмісти можуть взагалі написати зрозуміло документацію.
На проекті було 2 тестувальники — як я бачу у статті, наврядче там є техрайтер.

Чи не забагато відповідальность напрограміста?
— знати всю систему (щоб розуміти впливи при розробці своєї фічі)
— знати свою МП
— знати як працює рушій БД на проекті
— враховувати безпекові ризики при написанні коду
— часто — бути фуллстеком
— красномовно і швидко писати документацію
— знати (часто додаткову) МП для написання автотестів
— при цьому встигати писати якісний код у стиснуті терміни!
— я так розумію реліз менеджмент теж на хлопцях
— може ще скарги їм почати приймати від людей і відповідати, щоб менше часу минало від виявлення бага до його фіксу?

Звичайно замовнику це дуже зручнно — по сіти на тебе працюють 3 фріланери на яких повна відповідальність за все: від деталізації усної постановки задачі двома речення від замовника — до забезпечення якості, релізу і документуваня.

Питання в тому, на якій стадії проект. З якогось масштабу бідь який бізнес дробиться на специалізації, хоча починається з одного засновника який робить все.

Є декілька команд, взагалі п’ятдесят людей. Одна людина робить в середньому дві задачи за тиждень, але періодично є тижні де майже немає нічого зробленого, лкрім рефакторингу чи внутрішніх програм, а іноді дуже багато зроблено.

хачипури торговал, куртками торговал, соней торговал и имел уважение ©

Ну прям король.

рефакторинг сцк опасный настоко, шо после него нада полноразмерную регрессию делать ващето

Можливість безболісного рефакторінгу мусить бути закладена в архітектуру (не плутати з рахітектурами).

зазвичай у реальному житті© Шановний Замовник дозволяє рефакторинг тільки тоді, коли костилінг© вже неможливий, і архутектура безнадійно спотворена

Дешева рибка — погана юшка.

Якби знав, де впадеш, соломки підстелив би

Це цикл з позитивним зворотнім зв’язком.
Рефакторинг будуть тестувати, що займе наприклад п’ ять годин. Тож, я не буду робити десять малих рефакторингів на тиждень, а зроблю один дуже великий. Який щось зламає, що буде важче починити(бо де саме буде помилка буде важко знайти) , що збільшить у майбутньому час на перевірку, і на рефакторинг і зробить його більш небезпечним.

Не, ну если нет столько работы чтобы одному фул тайм тестеру целый день работать, то может и не надо.

А якого розміру має бути проект, щоб там потрібні були QA?

Вопрос не в объеме проекта, а в подходе — для кого-то хорошо работает вариант с QA, а для кого-то без.

Вариант без QA выглядит как полная дичь если ты живешь там, где QA это must have в команде и выглядит как очень рабочий если ты живешь там где задаются тренды и определяется будущее IT

Сегодня подумала: я бы не хотела знать, что к примеру Укрсиб отказался от QA и программисты там сами тестируют свой код. Я все понимаю, но спалось бы неспокойно.

а что толку? пиши статью, или нет — а на итальянском ит уже один фиг засветились

Допустим, ночью возникла проблема. Что сделает нормальный инженер?

Даже не узнает о ней т.к. телефон на беззвучном, если конечно это не отдельная оплачиваемая роль «ночного дежурного».
Или у вас норма сорвать человеку сон а потом еще с утра его потащить на работу?:)

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

Можно/надо заставлять человека быть сутки on call — абсолютно нет
Можно упрекать человека за то, что он не встал ночью — абсолютно нет

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

Сейчас у нас ночью никто не встает, так как хватает инженеров во всех зонах чтобы покрыть сутки. Однако когда проблемы возникает, то локализируется она практически мгновенно, за счет того что нам необходимо знать все досконально о наших продуктах, ведь у нас нет QA

Если же инженеру прошлось по каким-то особым причинам работать ночью и/или на утро он чувствует себя не в форме, то это решается с помощью одного сообщения лиду — «Я себя плохо чувствую, я сегодня возьму выходной». У нас Open PTO и нужно брать отпуск столько, сколько надо чтобы восстановиться на 100%

Итого, что было сделано полезного:
1. Переход на CI / CD парадигму от скрама и фиксированных итераций.
2. Научились писать юнит и интеграционные тесты.
3. Добавили тулзов для мониторинга системы (входит в 1, в общем-то).
Все эти изменения были абсолютно верными и соответствуют переходу компании от early stage startup в middle stage startup, но все эти изменения НИКАК не касались отказа от QA :)
Я бы сказал так: то, что багов стало меньше — частью заслуга юнит-тестов и нормального процесса код ревью, частью — то, что их просто никто не находит теперь. Что не означает их отсутствия.
Почти уверен, что, когда прийдёте к mature stage startup — снова задумаетесь о привлечении QA команды. Причина: связность кода станет слишком высокой, чтобы возможно было оценить импакт пулла на все компоненты системы и потребуются тесты более высокого уровня (system & e2e), чтобы контролировать баги, которые трудно будет найти тестами низкого уровня.
Успехов! :)

все эти изменения НИКАК не касались отказа от QA

100500%. Я теперь поняла почему парочка заказчиков хотели убрать QA. Это делается чтобы стимулировать #@$^# программистов живущих вообще-совсем без тестов — писать тесты и настроить нормальный CI/CD?

Но если разработчики и так уже пишут тесты (покрытие 95%) и внимательность у них огромная, но SLA и критичность сервиса очень высокие, мне кажется хотя бы 1 экспертный QA в команде улучшит качество и надежность сильно лучше чем еще +100 тестов или +5 разработчиков. Просто потому что хороший QA думает о том, о чем все не подумали (хотя этим также занимается хороший аналитик или архитектор)

Не знаю с чем сравнить из реальной жизни... К примеру с тренером в спортзале. Новичкам очевидно он нужен, потому что они вообще не соображают, к чему эти тренажеры и как ими управлять. Середнячки думают «зачем мне тренер, я и так все могу, выгнать тренера!». Но монстры которые хотят экстра достижений (экстра качества и надежности) снова приходят к тренеру. Хотя бы за регулярной консультацией.

Саме так. Віддавати тестування коду людині, котра сама ж його написала — те ж саме, що віддавати вичитку-редагування тексту письменнику, а не професійному редактору.

(Хороші) QC зовсім не даремно їдять свій хліб. Я не перестаю дивуватися, які цікаві штуки вони іноді знаходять після моїх юніт-тестів, котрі показують такі приємні цифри coverage.

Стаття трохи однобока, я б сказав що такий підхід буде працювати лише в певних випадках: коли є дуже досвідчені девелопери, відповідно дорогі і рідкісні, невеликий продукт або стартап, не аутсорс, нема багато інтеграцій, хитрих сценаріїв, легасі коду, команда в цілому сильна а не джуни після академій, кількість середовищ та варіантів перевірок невелика. Але найбільша залежність то мати дорогих і досвідчених девів, не всі дозволять собі це. На багатьох проектах дешевше застафити
девів і тестерів і ще залишиться.

така вумна стаття і коменти такі вумні, — піду ка я мівінки запарю

кто дочитал до конца, разрабов заставили в конце за месяц рожать или нет?
ПС идеальное время бить разрабов по голове палкой

Мне все-таки повезло работать с крутыми QA в своей карьере и могу точно сказать, что практически никакой разработчик, что работает над продуктом (и особенно свой код) не протестирует его так, как хороший QA.
Причина в том, что разработчик изначально ЗНАЕТ как оно должно работать и не придумает кейсов которые случаются у не технических пользователей.
Часто разработчики вообще ограничиваются happy path или им подобным тестированием.
Так что «не стало QA» и «багов стало меньше» возможно связано с тем, что просто нет тех, кто их находит :)
P.S. Я понимаю, какие цели были у people.ia изначально вовлекая разработчиков в тестирование, но описание процессов и проблем периода, когда у них были qa выглядит просто как отсутствие инженерной культуры. О чем многие в комментариях уже сказали.

Все от цели. Пока есть QA на которого хочется свалить и работу и ответственность, то тезис «разработчик никогда не сможет» становится повесткой дня. Однако дорогу осилит идущий и при желании ( ответственности ) оказывается разработчик может

А пока идущие осиливают дорогу (разработчики учатся тестировать сами) то баги на продакшене компания терпеливо терпит?

Причем осилить дорогу — это же не 1 месяц и не два. Наняли новых людей — и они снова начинают дорогу осиливать. И так бесконечно.

есть QA на которого хочется свалить и работу и ответственность

это тоже больше об инженерной культуре, чем о наличии QA отдела. В условно хорошей культуре QA инженеры часть dev команды, чтобы ownership задачи на «расползался» на несколько команд.
Да и не спорю, что отдельный разработчик при желании сможет стать хорошим тестером. Но я все таки считаю, что лучше бы он потратил это время на то, что бы стать еще лучшим разработчиком и усилил свою тех экспертизу.
Сами понимаете, что на любом интервью будут оценивать его навыки как разработчика, а не QA. Что, по моему, более чем обьективно показывает, насколько деву РЕАЛЬНО нужно быть хорошим QA

Богдан очень справедливое замечание. И это действительно так в компаниях в которых разрабочики работают с 9 до 17 и впервые видят задачу на Sprint planning.

Ситуация другая когда ты регулярно on-call, участвуешь во встречах с реальными клиентами, принимаешь непосредственное активное участие в планировании на следующие 3/6/12/18 месяцев. Мы не делаем features, мы добавляем ценность и чтобы это делать хорошо — надо понимать что, зачем, кому и как.

как-то один до*бистый QA моей команды сказал: «я знаю как вы, разработчики, мыслите. и я всегда найду то, о чём вы не подумали.»

Обратное, вероятно, тоже справедливо — разработчик может написать такую дичь, что ни один QA не найдет.

разрабочики работают
с 9 до 17

А у вас как, 24/7?

У нас с N до К, где ты сам определяешь эти значения исходя из текущей ситуации, никто никого не контролирует и не заставляет что-то делать.

По-умолчанию подразумевается что Senior инженер способен делать качественную оценку ситуации, делать правильные выводы и расставлять приоритеты, а иначе какой он Senior

Не знаю, зачем этот максимализм в вашем ответе.
Умение быть крутым разрабом с 9 до 17 и ценить work/life баланс — отличные качества взрослого человека.
Более того, я бы даже скорее сказал, что тот кто может запланировать и выдавать стабильно высокий результат без переработок, более крутой специалист, чем тот у кого постоянные овертаймы (и неизбежное выгорание через пару лет).

Богдан, полностью разделяю вашу точку зрения за исключением временного интервала 9-17. Я не знаю по каким фактам из статьи и/или ответам был сделан вывод что в компании овертайм — это нормально.

Иногда приходится работать с 7-30 чтобы больше провести времени с командой из Киева, иногда я работаю до 19, но при этом могу начать в 11 после развозки детей по местам временного содержания и завтрака с супругой в кафе.

Мой Work/life баланс это одна из ключевых забот моего менеджера, регулярно поднимаем этот вопрос на 1-1.

И в месте с тем, работая в People.ai, у меня получается работать, проводить время с детьми, с друзьями, учиться на MBA, проходить онлайн курсы, писать статьи и отвечать на комментарии.

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

Особенно «прекрасно» разработчик тестирует свой код когда он уже устал и у него пятница. Или когда он недоэстимейтил таску и торопится ее закрыть.

А как поступают QA в таком случае, если он устал тестировать и у него тоже пятница и разработчик присылает недоэстимейтиную таску которую торопиться закрыть?

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

Если посчитать сколько раз я находила баги после того как QA сказал «я потестировал» и после того как программист (в том числе и я) сказал «я потестировал зуб даю» то соотношение вероятностей близится к 1-2% / 30% — 100% где 30 или 100 сильно зависит от степени внимательности программиста. Невнимательные QA просто-напросто вылетают из профессии. Невнимательные программисты — нет.

Но железобетонность QA я помню нервирует всех кто хочет релиз побыстрее (и программисты и заказчики) пусть даже с багами. И еще, часто 80% юзеров используют только основные 20% use cases и поэтому пользователи никогда не наткнутся на те баги, которые есть, если сделать шаг влево или вправо. Из-за этого тщательное тестирование кажется избыточным.

Ответственность должна быть на инженерах, которые пишут код

Хмм, только мне одному непонятно, каким именно образом проявляется вышеуказанная «ответственность»? Автор, конкретизируйте пожалуйста тип ответственности: материальная, моральная, штрафы, бонусы, как в общем эта штука «ответственность» проявляется для конкретного разработчика конкретной фичи, по которому случился алерт наступления «ответственности»?

На партсобрании пожурят)
Особо злостных багоделов — лишат партбилета.

Вышеуказанная «ответственность» проявляется в следующем

1. Высокое качество кода — разработчик учитывает гораздо больше фактов при реализации решения
2. Быстрее разработка — мы находим критические ошибки еще на этапе дизайна, так как «прилетает» много комментариев к данному решению. Плюс гораздо больше альтернатив, которые мы рассматриваем
3. Быстрый поиск проблем — ты либо сам знаешь где поломато, либо знаешь у кого спросить и обычно это не 5-7 звеньев передачи, а 1 максимум 2

За счет чего?
У разработчиков шире горизонт понимания проблемы и опыт с пограничными случаями. Фокус разработчика смещается с «сделать вот эту фишку и забыть» на «какую ценность это принесет клиенту»

А вот штрафы, лишение бонусов и материальное наказание или поиск к/////ла отпущения это удел компаний с посредственным менеджментом

Окей, практический пример. У вас в команде джун/миддл. Вы ему доверили делать фичу. Вы думаете он все edge cases продумает? Половина из них даже не знают какие бывают security уязвимости в коде, и делают их регулярно. Так тогда ответственность на ком? На этом джун[o]миддле или на его лиде? Я думаю на лиде. Вы добавили работу лидам/сеньорам, убрав QA?

Я так понимаю что или:
(а) таску у вас кто-то тщательно проектирует, с учетом секьюрити и важных для бизнеса edge cases, performance, — и прописывает что и как делать (бизнес-аналитики? design document? архитектор?) — и только тогда она попадает среднестатистическому разработчику (middle например)
(б) у вас просто нет среднестатистических разработчиков и все уровня senior и выше
(в) сильно больше работы стало у лидов (вместо того чтобы полагаться что задачу этого джуна/миддла проверит QA, им нужно теперь в 2 раза больше времени тратить на постановку и проверку задачи)

Не сильно страшно если из-за бага какого-то джун/миддла кто-то из пользователей увидит на странице warning типа «Cannot read property ’a’ of undefined» или вследствие деления на 0 увидит Infinity вместо числа, или дату не ту, что нужно. Ну придет мессадж в support на пейджер — почините.

Но если из-за security бага кто-то вытащил у вас из БД все данные пользователей — я бы расстроилась...

Я очень подозреваю, что компания построена по принципам «джуно-миддл-фрее». В принципе, подобная схема работы вполне работоспособна, когда девелопментом занимаются одни синьоры. Которые работают напрямую с бизнесом и плотно вовлечены в бизнес-область. Тогда в случае наличия QA-макак (которые занимаются простым мануальным тестированием без понимания бизнес-области), последних можно безболезненно сократить. Они даже вредны.

Т.е. в случае сплоченной продуктовой команды данный подход взлетает.

Но т.к. большинство наших коллег, выражаясь простым языком, «продукта не нюхали» (работают в аутсорс-компаниях с совсем другим подходом и ценностями), то это вызывает непонимание написанного и жесткий троллинг. Естественно, в аутсорсе описанный подход не взлетит от слова совсем.

Лично мне же подобный подход близок, так как в основном применяется в текущей компании.

Единственное, что меня зацепило, так это фраза «ответственность должна быть». Причем как это реализуется практически — непонятно. И пока что похоже на то, что это просто «манеджерско-мусорная» фраза без практического смысла (по крайней мере, пока что я такового не увидел)...

Написала ниже про ответственность. На аутсорс вы зря бочку катите: то, насколько люди заморочены качеством и надежностью, зависит от этих людей (членов команды) а не от формы их трудоустройства — аутсорс, аутстаф, продукт, etc

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

Со своего опыта техлида могу сказать, что «ответственность» разными людьми понимается совершенно по-разному. И если её не формализовать, она окажется лишь громким словом без практического наполнения. Наверное, исключением будет компания «семейного типа», в которой сотрудники подбираются, исходя из личных ощущений владельца компании, который всем прививает негласные правила «ответственности». Тогда это скорее всего нельзя формализовать, оно так и останется на уровне «интуитивного понимания»...

Ответственность, это когда что то будет, если не сделаешь.

Поэтому и не понятно что имеется в виду под ответственностью. В худшем случае, при самом страшном факапе или даже регулярных факапах — программиста уволят. Но при перегретом (как сейчас) рынке когда «хайрится все что движется» он даже не расстроится.

Единственное что программист может бояться потерять — это самоуважение и репутация.

Единственное что программист может бояться потерять — это самоуважение и репутация.

Самоуважение я потеряю, если буду работать вместо жизни.

Отвественность — Необходимость, обязанность отвечать за свои действия, поступки, быть ответственным за них.

Елена, у нас сейчас работают только разработчики уровня Senior+ и выше. Каждый проходит 5+ раундов интервью и оценка hard skills (технологии) это небольшая часть всего процесса. Серьезный упор делается на soft skills. Поэтому все в компании разделяют общие ценности по поводу ответсвенности и комитментов.

Очень тяжело работать в коллективе где ты один не такой как все, ты либо быстро меняешься либо уходишь

Владимир, в статье речь идет НЕ про «юридическую» ответственность, а про персональную ответственность в широком смысле этого слова.

Необходимость, обязанность отвечать за свои действия, поступки, быть ответственным за них.

Поясняю популярно: я работаю, чтобы заработать денег для себя или своей семьи. Любые рассказы не про деньги сейчас мне не интересно

Ты это говоришь и говоришь, снова и снова. Ты уже заметил что многим такая позиция не близка?

Их дело, конечно. Свои мозги в малолетние головы мне не вставить,да и не нужно

дарю лайфхак — если инженер например ремонтировал сам свои бетонометры, то его еще можно привлечь к ремонту сантехники побелить покрасить поштукатурить, столики собрать как минимум
не благодарите

Вот так каминг аут )
В принципе работа без QA во время релизов = правильно настроенный CI/CD процесс. Но хотелось бы добавить пару важных моментов
1. Такой подход очень сложно приготовить если процесс обновления клиентского приложения занимает больше нескольких часов (Мобильные приложения, прошивка для железяк и т.д.).
2. Если у вас в компании нет мониторинга, АБ тестирования, фичер флагов и возможности быстрого отката изменений — лучше такое не делать
3. Хорошо иметь команду SDT которая работает параллельным стримом для написания e2e тестов или инфраструктуры которая ускоряет процесс их написания.

А так я с этим полностью согласен, желаю ребятам hockey stick growth graph

1. Да так и есть, очень сложно приготовить. Нам легче в том что нет железяк и мобильных приложений
2. Если этого нет, то и компанией это назвать тяжело — так, кружок программирования. У нас все это есть, а также и еще прочие инструменты и практики которые позволяют быстро находить проблемы
3. Возможно

Огромное спасибо за статью.
Всегда интересно узнать как происходят процессы оптимизации и трансформации качества в разных компаниях.

Есть несколько вопросов \ комментариев по содержанию статьи:

1. До момента расформирование тестировщиков — никаких видеов тестов почти не было, кроме ручных? Судя по проблемам внедрения функциональностей в Core систему не хватало интеграционного тестирования.
2. Если возникал вопрос ответственности за ошибку («это QA виноват — нет это DEV виноват») — то почему не внедрили ответственность всей скрам команды? Если пропустили багу, все сидят тестируют, фиксят и тд? В таком случае не будет «перекладываний» ответственности.
3. Правильно ли я понял, что работу QA «размазали» между разработчиком, саппортом и конечными пользователями?
4. Какие метрики позволили сказать, что при устранении отдела тестирования багов стало меньше и качество стало лучше?
5. Проводя параллели с компаниями в Долине и практикой on-call. У вас так же как и в Долине достойная компенсация и +100-200% к зп опционами дается? Или «работай как в Долине, получай как в Украине»?
6. Изменение отношения к юнит тестам не зависят от того, есть ли у Вас тест инженеры или нет. Зависит «культуры разработки» на всех уровнях. Простой блок на мердж при снижении покрытия кода ниже 70% может «привить» эту культуру. При условии того, что менеджмент не давит фичами «на завтра».
7.Полностью согласен с Вашим подходом «быть инженером, а не разработчиком на языке %%%»!
8. Внедрение CICD процессов могло произойти и с наличием тестировщиков. При Continuous Deployment никакого мануального тестирования не подразумевается — сразу в прод автоматически.
9. То есть «убрав» отдел тестирования — у Вас никто не обучал как правильно тестировать, техникам тестирования? Просто — «пишите тесты»? Никто не ведет статистику того, какие фичи покрыты и на каком уровне?
Отдельно взятый инженер не всегда может охватить весь продукт и понять последствая того или иного фикса.(Фокус инженера ограничен).
10. Кто занимается поддержкой end-to-end автотестов и обычных тестов? Как Вы боретесь с flaky тестами?

Я б сказав, навіть не валить, а вже завалив

Боюсь спрашивать, а как же обстоят дела с требованиями? Кто ими занимается, есть ли планы привлечь девелоперов непосредственно к менеджменту требований, чтоб так сказать больше вовлекались в бизнес?

Годнота підвалила. Як же ж не хочеться тролити сьогодні подібне...

«Интересно, что после этих изменений, как рассказали нам в компании, релизы существенно ускорились, количество багов уменьшилось»
— єссєсна))

«...интересно — качество продукта без отдельной QA-команды даже улучшилось...»
— як?) як можна вимірювати якість без спеціаліста по якості?))

«... Когда у вас отдельные команды — QA и инженерная...»
— пхаха) це взагалі як?) тобто Software Test engineer є не інженерною роботою?) я вже мовчу про QA

«Я уважаю твою точку зрения, при этом считаю, что ...»
— Як то кажуть, все, що сказано співрозмовнику до фрази «але», «при цьому вважаю» — абсолютно немає ніякого значення. Тобто ніхто нікого не поважає)

«А QA не в состоянии всё дотестить, он же не сидит у программиста в голове и не понимает, как работает каждый Loop Statement...»
— в наш час працювати з тестувальниками, які в очі код не бачили, найбільша помилка. Тому це питання до кваліфікації тестувальників, які працювали в компанії

«Сейчас мы серьезно отладили Scrum-процесс, поэтому и распределенная работа происходит эффективно, работоспособность не снижается. Сейчас имеем качественное планирование...»
— ще раз. Як ви знаєте, що планування якісне? Це вимірює хто? QA ж у вас немає))

«Ответственные инженеры могли добавить какие-то unit-тесты, но такого требования к ним не было....»
— тоді ясен фіг, що до тестувальників доходила така кількість проблем, яку осилити не встигали) але задумались над цим тоді, коли відділ прибрали))

«... Разработчики по очереди следят за уведомлениями, кто дежурит — тот и отвечает за решение проблемы...»
— щось мені підказує, що на девів просто накинули роботу тестувальників)) ще і оверлоуди скоріше))

«... Но в основном этим Support-команда занимается, когда что-то хочет перепроверить, посмотреть, исследовать..»
— тобто таки тестінг є)) просто розкинули ще на одну команду))

«... Со временем у нас появилось правило: все фичи должны быть обязательно покрыты unit-тестами...»

— нарешті прийшли до основ адекватного підходу. Ще з часом сподіваюсь компанія прийде до того, що типів тестування така кількість, що розробники фізично не встигатимуть цього робити. І до того ж, тестування — це інший спосіб мислення, це бачення продукту під іншим кутом

«Это не обсуждается вообще, всегда подразумевается, что тестирование включено в эстимейт...»
— ван мор пруф))

«... QA Automation инженер перешла в команду разработки, быстро выросла в Senior-инженера...»
— аааа, пам’ятаю ту статтю)) там короткий був рецепт)) щоб стати розробником, просто дочекайся, до того часу, коли будуть розпускати QA відділ і тобі просто запропонують бути розробником))

«... В нашей команде тогда было два инженера, которые пришли из Google...»

— я прям бачу, як чуваки прийшли з Гугла і кажуть «хух, ну нарешті хоч тут не буде цих кюеїв, як у нас, задовбали просто»)

«Освободившийся бюджет уходил на рост команды. Но его и освободилось не так много...»

— все, що варто було знати про оцінювання роботи QA ще на момент їх існування))

«... у нас нет конкретных тест-кейсов, просто весь функционал покрывается тестами сразу...»
— у нас немає тест дизайнів, тест планів, ревю кейсів, немає метрик якості ... ми одразу просто лупашимо «тести»)) до речі, якими тестами весь функціонал покривається- неясно))

«На мой взгляд, всё, что больше 80% — избыточно и не означает, что качество самих тестов повышается. Дима, ты с этим согласен?»

— бляха, так знову ж таки — відділу якості немає, тому як можна судити про якість тестів?)) ...ще і Дмитра дьоргають, щоб він хоч десь сказав «ну, ок, молодці»)) але він тримається)
— ...і з пірамідкою тестів, бачу, проблемки)

«На самом деле, у нас фронтенд построен опытными инженерами, он очень компонентизирован и написан правильно...»
— написаний правильно...

— уявляю картину як на автозаводі вирішують відмовитися від відділу якості і тестування авто. «Та ми посадили наших механіків та інженерів за кермо. Вони ж краще знають авто, яке робили. А ще є відділ камікадзе-техніків. Зранку вони зварюють ходову авто. А ввечері роблять тест-драйв безпеки, лупашать в стіну на швидкості 100 км. Так і дешевше. Нащо нам якісь манекени закупляти...»

«... Мы продолжаем активно нанимать людей...»
— це більш, ніж очевидно

«QA имеет хорошую базу, чтобы вырасти в инженера...»
— апять...

Короче...
Як зменшити кількість багів — звільни того, хто їх знаходить. Апупєнчік. Записав.
А взагалі відділ QA у вас є і досі. Просто розробники не знають, що виконують +чужу роботу за ті самі гроші)
Але це гарно названо «хвілософією».

Пропоную Кулібінам запропонувати подібний підхід для Гугла, наприклад, а то останні занадто багато ресурсів дарма витрачають на тестування. Варто допомогти колегам зекономити великі гроші)
...до речі, тут он АІ підвалює, який буде вже сам код писати, тому теж варто брати на озброєння)

А взагалі бомбічно круто було б звільнити відділ розробки і не вчити їх тестувати, а залишити відділ QA і навчити їх кодити. Вихлоп по такій логіці був би ще моцніший))

Ех...
Але удачі вам. Сподіваюся, все буде добре)

Ответ просто прекрасен!) Пиши еще!

Просто розробники не знають, що виконують +чужу роботу за ті самі гроші)

Там зепехи під 10к. Так що все чесно :)

А взагалі бомбічно круто було б звільнити відділ розробки і не вчити їх тестувати, а залишити відділ QA і навчити їх кодити. Вихлоп по такій логіці був би ще моцніший))

 — в слух)

Дякую за ваш коментар, ви зробили мій день:)))

Ребята, то есть по Вашему мнению, отсутствие перспектив выглядит именно так? piccy.info/...​bacebd6b4fb26624f6c0f75a

Алексей, статья не про отсутсвие перспектив, а про наличие альтернатив и новых возможностей

Microsoft принял решение отказаться от QA в 2014. Посмотрите на их сток за этот период 43$ -> 257$

Аналогично действуют Amazon, Facebook, Google. В интернете полно информации по этому поводу

www.quora.com/...​-it-very-rare-to-see-them

интересная статья. Забавно, заглянув в комментарии, наблюдать сообщения типа «да вы просто не понимаете что делаете, у вас ничего не работало и не начало работать» в ответ людям из продуктовой компании, которые отслеживают метрики и прошли путь не в 2 месяца, а 4 года. Напомню — если бы у продуктовой компании стало «больше багов и всё плохо» то за продукт просто перестали бы платить, а траты на привлечение клиентов стали расти во времени. В статье поделились опытом, который, глядя на результат, имеет право на жизнь и является взглядом на контроль качества под другим углом

Читатели просто делятся своими мыслями на этот счёт. Возможно, если бы в статье были действительно метрики (ретеншен юзеров, динамика по конверсии, поведению, общая картина по восприятию продукта юзерами) ДО и После отказа от стандартной модели, то это убедило бы в эффективности их процесса больше.
И опять же, взять для сравнения аналогичные компании, путь которых тоже ± 4 года, но процесс с куа.
Стоить заметить, что убрали только должность, процесс таки остался, как ни крути.

Растущий продуктовый бизнес совершенно не означает, что все подразделения работают эффективно. Это, кстати, относится и к гуглам с фейсбуками.

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

Что очень интересно — качество продукта без отдельной QA-команды даже улучшилось, хотя можно было бы предположить обратное

Можливо я пропустив в статті, але незрозумілим залишається спосіб вимірювання якості продукту. Через кількість знайдених багів? Якщо так, то знайдені ким — користувачами, що звернулися в сапорт, чи самими девелоперами?

У нас QA тоже нет как должности, я например сам себе мануал тестер 😁

Т.е. QA упразднили как отдел.
А остатки от QA процесса (не то чтоб он был очень налажен) размазали тонким слоем по дев команде...
И дайте угадаю — стали находить меньше багов, и теперь думают что у них качество продукта улучшилось... (Спойлер — нет, они просто стали находить меньше багов)
Конфликт интересов дев и QA процессов? Нет, не слышали.
Посадить делать QA инженеров а на абы кого? Тоже не слышали. А вот и сюрприз — QA это самая натуральная инженерная задача, с соответствующими требованиями по квалификации.

если коротко: сложилось впечатление что ребята не знали что делать тестерам и с тестерами, и решили просто от них избавиться :( нет должности — нет проблем

ну дев тестинг (как и юнит, но есть нюансы) неотъемлимая часть работы прогера, как по мне. Причем тут наличие куа вообще? Дочитал до фразы про проблем с наличием енвов для интеграционного тестирования. Все в принципе ясно.

Да, а ещё глупо делить на front-end и back-end — можно ведь всё одному человеку делать. Намного меньше проблем будет.
Да и языки программирования все похожи — пускай одни и те же люди на всех языках пишут.
И требования у заказчика пускай лучше программисты выясняют изначально — чтобы не было недопониманий потом.
Ещё можно наладить процессы уборки офиса по очереди «дежурными» программистами — намного эффективнее: меньше будут мусорить.
...
...
...
(если нужны будут ещё идеи — обращайтесь)

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

За неї ще позмагатися прийдеться...

и с тех пор каждый разработчик должен сам не только писать, но и тестировать свой код.

замечание с 1-го же абзаца — «тестировать код» != «QA». Также прочитал бегло статью, и мог бы конечно детально ее «разрывать на цитаты» потратив время на детальный анализ, но уже сейчас могу сказать — что выглядит эта трансформация так: — были плохие процессы/качество в разработке и деливери, нормальные «правильные» QA процессы отсутствовали, занялись трансформацией в разработке и деливери и многое улучшилось, QA процессы так и не появились, QA расформировали так зачем они нужны если QA процессов/gates нету, перепутали причину и следствие улучшений, написали статью.
В принципе атмосфера/процессы в стартапе — вполне понимаемы и нормальны... и то что разработчики должны писать различные тесты, тестировать функциональность, быть кросс функциональными — я это все поддерживаю абсолютно..., и рад что у вас произошли улучшения .... но дать такой заголовок и посыл о QA — это некорректно... очень некорректно.
Это точно также как с бизнес-анализом, да вполне нормально можно не иметь БА в команде, но это означает что кто-то другой делает бизнес-анализ как функцию, либо под другим тайтлом либо совмещая с другими обязанностями. Но нельзя говорить что мы вообще работаем без бизнес-анализа. И точно также может быть что бизнес-анализ делается плохо или хорошо, как с выделенным БА в команде так и без него.

Еще можно добавить: для разработчика стоит дважды подумать — а стоит ли идти в стартап работать, твое ли это все? Кого-то будет переть, но точно не всех подряд.

Я там вище лишав коментар про мій досвід роботи для компанії, де QA не було ніколи, від самого початку запуску стартапу. І їхній фаундер казав, що такий підхід є досить популярним серед стартапів. На запитання «чому» — наводилися тези, дуже подібні до тих, що є у статті. «Відповідальність» за код, «розуміння продукту», CI/CD і супер-швидке викочування фіч і отримання фідбеку. Єдине що про автоматичне бажання покривати код юніт-тестами там не йшлося, бо вони їх майже не писали (і я схиляюся до думки, що не писали власне тому, що самі вручну все перетестовували).

Результат (принаймні в плані якості архітектури і коду) був дуже посередній. Мені працювати в таких умовах було вкрай некомфортно, і коли мені доводилося займатися невластивим мені активностями типу manual QA — це просто вбивало мою продуктивність і мотивацію. Інженерів, котрі би були супер-щасливі, що у них нема QA, я не зустрічав. Хоча ніби ніхто (крім мене :) ) і не жалівся/обурювався.

Живий приклад того, як відмова від QA та перехід на юніт-тести не покращують якість коду та архітектуру. Про що я кажу постійно. Хочете якісний продукт? Ви мусите йти геть від тестування. Це капець як важко та складно (здається), але вихлоп набагато суттєвіший. Заміна тестуванню є: хелсчеки, моки, фейл-сейф та фолт-толерант архітектури, зменшення імперативного коду, збільшення рівнів абстракцій, тощо.

Ех, завжди розчулює, коли читаю, як вебщики свій досвід виводять в абсолют, так наче тестувати більше в світі нема чого)

Таке враження, що для вас вебщики — найнижчий клас програмістів.... Не люди навіть, так, біосміття...

Краще б задалися запитанням, які критерії оцінки роботоспроможності ви будете використовувати для fails save та fault tolerant систем. Як ви їх тестувати зібралися?

Головне, щоб інші компанії такий «передовий» досвід не переймали)
Мєлкософт в свій час теж цілий відділ QA розігнали — думаю, не потрібно нагадувати, на скільки «якісні» апдейти приходили на 10ку.
А так, виглядає наче команда тестувальників була безтолкова, і її відсутність ні на що не повпливала, імхо.

Рост акций Microsoft с 43$ до 257$ за период с 2014, как это объяснить для компании которая зарабатывает на софте?

Основний дохід майкрософта не від вінди — тому якість останньої ніяк не впливає на виручку біллі. Цитата з інтернету про структуру доходів майкрософта:
«Самые крупные три сегмента: „Офисные продукты и облачные сервисы“ (25,7%), „Серверные продукты и облачные сервисы“ (23,7%) и Windows (17,7%)»

А они только для Windows отказались от тестировщиков? Было бы очень странно, правда?

Не дивно. Я не знаю, на рахунок інших продуктів. Наявна інфа є тільки про Windows.
І загальновідомим фактом є те, що після звільнення QA, вінду стали тестувати звичайні користувачі (в тому числі і я), регулярно відловлюючи баги.
Може якщо і розігнали команду QA в якомусь Azure, без відчутних втрат в якості — це нічого не пояснює. Все залежить від конкретного продукту, конкретної команди — і не потрібно свій окремий випадок називати світовою тенденцією, тому що ще хтось таку практику застосував.

Краткое резюме статьи:
— мы не смогли настроить процесс QA как положено (автоматизация, CI/CD и так далее) и вместо того, чтобы решить эту проблему просто удалили QA как класс.

Не удалили, а переназвали. Заголовок просто кликбейтный.

Вполне вероятно они с кодом так делают. Не работает? Давайте просто удалим! Отсюда так все стабильно.

Хмм... А что, неплохо. Отличный лайфхак, пойду попробую как работает.

часто звучало про «ответственность инженеров», но увидел только про процессы «протестировать сам», «написать юнит тесты», «on-call дежурства». А какая будет ответственность в случае пропущенного бага — не увидел. Проморгал, мож?

штраф зарплаты или отсечение пальца

отсечение пальца

чтобы по количеству пальцев сразу было видно — кто сколько косячит

такие вещи решаются через квартальные OKR и бонусную систему, никто не привязывает количество багов «2 или 5» к «штраф в этом месяце»

бонусы за отсутствуие багов? спрашиваю всерьез, не сталкивался с похожим, любопытно.

бонусы за достигнутые OKR) которые ты не выполнишь если у тебя критическое к-во багов

при этом нанимая человека называют ЗП с учетом бонусов?
Или ЗП без учетов бонуса, а бонусы сверху потом?

не, зп это зп, а бонусы это бонусы. Бонусы чаще всего это процент «от и до», либо ежемесячные либо квартальные(чаще)

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

Тостеры не нужны!

Нужны люди, которые умеют готовиться к тому, чтобы делать продукт, планировать, продумывать, анализировать. А если не умеют, их можно к этому принудить.

Есть много профита в переходе от «Пишем код» к «Делаем продукт». Не все могут, единицам это нужно.

Есть много профита от перехода «Хренакай код ровно до момента, когда он заработал, потом пофиксишь» к «Сперва подумай, чтобы потом не приходилось фиксить». Не все хотят, могут единицы.

При всем этом qa могут быть, а могут не быть в компании — не в них дело.

QA понимают продукт в лучшем случае на уровне ~30% от разработчиков. Реальный ассептанс должен проводиться стейкхолдерами — продакт менеджерами, дизайнерами и пр. Задача QA заказать −1 кружку пива и очень далеко не каждую росто-ориентированную компанию интересует что при этом произойдет.

QA больше всех нужны галерам чтобы дуть штат играя на неуверенностях заказчиков.

Всю статью прослеживается нотка, что отдел QA — причина бед не частых и обьемных релизов, отсутствия приемлемого coverage, культуры написания unit тестов dev специалистами.

Очень забавная история, каким образом команда QA виновата в отсутствии CI/CD, а главное каким образом отказ от QA команды решил проблему его внедрения))
Опять же если узким местом для позадачного деплоя было регрессионное тестирование(чек того что старый рабочий функционал не ломаем), то кто останавливал автоматизировать этот процесс и избавится от ручного регресса? От отказа QA команды регресс то моментально не пропал))
Кто мешал развивать культуру написания unit тестов dev специалистами? Представляю как QA бубнит «ребята, не пишите тесты, есть же мы, мы и без тестов все сами проверим».

Странно, что недостаточно оптимизированные/автоматизированные процессы в команде слили на QA.
Даже если после отказа от QA «хуже не стало» (не холиварю за то нужна QA команда или нет) , обьяснять достижения о появлении абсолютно нормальных процессов в команде тем что, мы отказались от QA — какие-то странные параллели.

Не смог дочитать статью, очень разволновался.
Если совсем коротко:
1. куа и так не особо много работали
2. тестировщиками как были енд-юзеры, так и остались.
3. багов стало в 2.5 раза больше.

количество багов в статье — количество обращений от клиентов, которое прямо связано с трафиком и количеством пользователей. Чем больше юзеров — тем больше обращений. Но из этих обращений регулярных багов (а не вопросов по бизнес логике) по воронке стало меньше

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

p.s. у меня у самого команда успешно работает без QA. я просто не уловил логику действий СТО

Полагаю, логика была вот в этом:

нанимали новых инженеров, многих из Кремниевой долины

Если нанимать в команду только высококлассных спецов (и очень толковых джунов, которые с младых ногтей будут учиться у таких «монстров рок-н-ролла»), то, в целом, да, подход без QA может быть жизнеспособен.

Проблема в том, что «не только лишь все» могут позволить себе такую роскошь.

p.s. у меня у самого команда успешно работает без QA. я просто не уловил логику действий СТО

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

спасибо за статью. Правильно ли я понял, что хотя у вас и нет QA как должности, тем не менее Engineering Efficiency команда — по факту являются SDETами которые решают специфические для тестирования задачи? Поесть вы внедрили практики SDET вместо стандартных процессов QA, AQA и т.д?

Підписатись на коментарі