company_banner

Как мы «разогнали» команду QA, и что из этого получилось

Или как получить неочевидные последствия, если отказаться от команды тестирования.

Полтора года назад мы разрушили команду тестирования: отказались от регресса, передали E2E автотесты на Selenium в поддержку разработчикам и разошлись по командам, которые пилят фичи, чтобы предотвращать ошибки «в зародыше». В розовых мечтах нам казалось, что так будет больше пользы: QA работают над качеством, тестирование начинается рано, а разработчики пишут автотесты сами и никто им не мешает.

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



Что такое последствия первого и второго порядка


У Рэя Далио в книге «Принципы» есть понятие «последствия второго порядка». Это неочевидные следствия наших решений, которые мы часто не можем предугадать. Например, в 60-х годах 20-го века в Китае развернули войну с воробьями. Воробьи съедали зерно, и чтобы они перестали его есть, Китай открыл охоту на птиц. За время охоты китайцы массово убили почти два миллиарда птиц.



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

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

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

У нас была команда QA и мы её «разогнали»


Теперь расскажу, как мы ощутили на себе последствия и первого и второго порядка. У нас была уютная выделенная команда тестировщиков из 7 человек: 4 из них писали автотесты, а 3 — тестировали вручную. Мы в какой-то момент решили разделиться и разойтись по командам. Почему? 

Потому что разработчики получали обратную связь слишком поздно.

Баги находились на этапе, когда уже вся разработка «закончена», всё «интегрировано» и нужно проверить, что продукт готов к релизу. Приёмочного тестирования не было, его выполняли аналитики-продакты у которых не было навыков тестирования. Кроме этого тестировщики и разработчики находились в разных мирах и мало взаимодействовали.

Очевидное (тогда) решение — разойтись по командам, которые работают над определенными фичами (частями) системы, чтобы предотвращать баги «на корню». Бросать свой участок работы мы не хотели, поэтому решили передать разработчикам наши функции. Мы подумали про автотесты — передадим их разработчикам и они будут сами тестировать без проблем.

Гипотезу сначала решили проверить на себе «экспериментом»: покроем критические сценарии регресса автоматическими тестами и откажемся от ручного регресса. Если в результате опыта количество хотфиксов и откатов релиза не вырастет драматически, то можно считать эксперимент удачным. Так и случилось — хотфиксов больше не стало. Решено — расходимся.

Примечание. В компании есть продукт «Ресторан». В него входят все сервисы и наш монолит. Цель продукта — максимально автоматизировать и оптимизировать работу всех сотрудников ресторана. Сейчас наша работа направлена больше на предотвращение ошибок. Теперь мы QA в продукте «Ресторан»: развиваем качества в продукте, участвуем на всех этапах проработки задач.

Последствия первого и второго порядка


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

А теперь то, что мы не планировали — это последствия второго порядка.

Никто не драйвит качество продукта. В этой проблеме есть 2 стороны:

  • качество с точки зрения процессов;
  • качество автотестов и пайплайна. 

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

После того как мы разошлись по командам, это всё куда-то исчезло. В команде разработки мы часть команды, часть корабля: полностью погрузились в её работу, глаз «замылился» и вот это вот всё общее качество продукта стало чем-то далеким.

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

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

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

Лишняя работа для разработчиков. Тяжело быть разработчиком. Если раньше они привыкли писать продуктовый код, который «магическим» образом проверяется и уходит на продакшн, то теперь им нужно самим писать тесты, править и стабилизировать. Мы на PBR определяем, какие сценарии должны быть покрыты тестами, а уровень автотестов разработчики выбирают сами.

Разработчики прошли несколько стадий принятия смерти пайплайна. 

Отрицание. Все релизы Dodo IS катят разработчики. Они организуют процесс, комуницируют с командой нагрузочного тестирования, смотрят логи и мониторинг во время релиза. Разработчики, которые катили релиз, сталкиваясь с красным тестом, не пытались разобраться в его причине, а просто перезапускали пайплайн, пока он не становился зеленым 5–7–10 раз. Всё потому, что не было доверия к автотестам. 

Максимальное количество перезапусков, которые я нашел, — 44 раза!!! Мне кажется, от полного отказа от тестов нас спасло правило которое мы приняли на одном из ретро «Не релизим с красными тестами. Если тест красный — разберись в чём проблема. Если проблема в тестах — почини или заигнорь и сделай карточку на разблокировку теста, и добавь ее в бэклог». 

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

Торга и депрессии не было, наступило сразу принятие: разработчики теперь могут сами писать E2E-тесты UI и API, стабилизируют и улучшают их.

Количество багов на проде стало увеличиваться. На продакшн стали просачиваться не критичные баги. На это есть несколько причин:

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

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

Как мы решаем эти проблемы


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

Создали гильдию QA Ресторана или Community of practice, в которую вошли все QA Ресторана. Цель сообщества — драйвить качество всего продукта, распространять хорошие практики тестирования на все команды продукта. Это образование, которое совмещает в себе преимущества выделенной QA-команды и также мы получаем преимущества от нахождения QA в команде разработки.



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

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



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

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

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

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

Что бы мы сделали сейчас?


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

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

Проблему с лишней работой для разработчиков никак не компенсируешь, но можно было бы снизить боль от написания тестов тем, что не ставить перед фактом, а:

  • показать ценность тестов в явном виде;
  • научить разработчиков эти тесты писать, улучшать и поддерживать;
  • сделать переход не таким быстрым (за неделю), а растянуть дольше.

Как научиться предугадывать последствия второго порядка


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

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

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

Тот, кто научится предугадывать последствия второго (и даже третьего) порядка любых решений сможет спасти или уничтожить человечество. Или заработать денег больше, чем у Скруджа МакДака — хотя бы на колебаниях цены акций. 

Как я теперь буду пытаться предугадывать последствия


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

  • Прежде чем принять решение — задавать себе вопрос «А что будет дальше?» и добавить к вопросу временные отрезки. Что будет через 10 минут, 10 месяцев или 10 лет?
  • Тренировать свое мышление в сторону таких последствий, размышляя над разными ситуациями. Например, какие могут быть последствия первого второго или даже третьего порядка, если весь мир пересядет на электромобили, или, например, введут базовый безусловный доход. В этом упражнении нет правильных ответов, но оно позволит мыслить шире.
  • Помнить о том, что первая мысль в голове — это первый порядок. Всегда.

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

P.S. Нам сейчас требуются 2 мобильных QA-инженера в продукт «Открытие стран» и в Дринкит. Мы ищем человека которому не все равно на качество тестируемого продукта и который развивается в автоматизацию. Задач и возможностей полно: можно расти и углубляться в автоматизацию, можно менять процессы и подходы в командах, а можно двигаться в сторону SRE-практик и стать mobile SRE инженером. Все зависит от ваших целей и предпочтений. Если вы хотите у нас работать, пишите в Телеграм: мне (@EvgenSkt) или нашему HR Саше (@alexpanev).

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

Наш Телеграм-чат, если захотите обсудить статью и задать вопросы.
Dodo Engineering
О том, как разработчики строят IT в Dodo

Комментарии 88

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

    Вот именно в этом месте у Вас есть третья возможность с ужасом осознать, что групповая ответственность не работает. Первой было «это всё куда-то исчезло» с самороспуском QA. Второй — когда помогло назначение конкретного ответственного за пайплайн. После осознания, глядишь, и ванговать на два порядка не придётся.

      +2
      Вы правы, если отвечают все — не отвечает никто. Мы с первого раза это осознали. Проблема в том, что починка пайплайна, его стабилизация и ускорение, не очень интересная работа, мы не нашли добровольцев, которые готовы были на 100% своего времени погрузиться в эту работу. Поэтому решили пока закрывать проблему дежурствами по необходимости. В крупных компаниях есть релизные команды, куда входят и QA инженеры. Цель этих команд катить релизы и улучшать эти процессы. Но мы пока либо не доросли до этого, либо у нас особый путь)
        +11
        Мы с первого раза это осознали

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


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

          0
          Да, мы отменяли дежурного с осознанием, что придется его вернуть снова. То что мы решаем проблему каким-то способом есть показатель что мы ее осознали.
          Что вы имеете в виду под «награждать»?
            +9

            Награда — что-либо, выдаваемое (даваемое, присваиваемое) в качестве поощрения за заслуги, отличия, в знак благодарности кем-либо за что-либо (w).


            Повинность — законодательно закреплённая обязанность по выполнению общественно полезного труда (w).


            Ваше дежурство по пайплайну является повинностью. Ещё раз, вы ввели дежурного чтобы что-то стало лучше. Что-то в итоге стало лучше, потом вы (кстати, кто именно?) дежурного отменили, осознавая, что его придётся возвращать. Стало обратно ухудшаться — вводим дежурного снова. Зачем было отменять дежурного, если вы знали, что что-то ухудшится обратно?


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

              –1
              Ваше дежурство по пайплайну является повинностью.

              Любое дежурство по природе является повинностью.
              Награждение не сделает работу менее скучной и не интересной. Но вы правы, эта работа важная и нужная и делать ее кто-то должен. И обеспечить ее выполнение мы можем это несколькими способами. Или вводить отдельную команду или вводить дежурство. Может есть еще какие-то способы.
              кстати, кто именно?

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

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

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

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

                  0
                  У нас есть канал в слаке, куда падают уведомления о том, что пайплайн красный, в комментах автоматически тегаются люди, чьи коммиты были в этой версии кода и они идут чинить пайплайн.
                    0
                    А зачем у вас сначала рушится общий пайплайн у всех, а потом чинится группой подозреваемых? Почему нельзя в общую ветку MR принимать только после зеленого пайплайна по этому MR?
                      0
                      Были обсуждения о том, чтобы так сделать, но почему-то не сделали. Не знаю почему. Нужно будет еще раз закинуть на обсуждение.
                  0

                  Думаю, если делать доплату 50% за дежурство, то очередь будет из желающих. И дежурство станет наградой. Например, дежурит тот, кто меньше всего ломал пайплайн. А значит умеет с ним обращаться)

        +10
        Коллеги, очень советую использовать метод пяти почему и прочитать книгу: Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию.

        Они вам помогут организовать процессы в вашей компании.

        А еще найдите грамотного QA, я думаю вы уже стали большими и вам уже нужен отдельный специалист по качеству.
          +3
          Да, спасибо за советы, они на самом деле полезные. Цель прочитал не так давно и сейчас осознаю, что когда регрессионное тестирование тормозило релизы, мы пользовались этими знаниями, чтобы ускорить наши релизы. Например, освободили тестировщиков от любой работы не связанной с тестированием релизов, ввели правило Stop The Line когда разработчики не могли создавать новые задачи, чтобы не копить очередь. У нас об этом есть статья.
          А что касается грамотного QA, если поделитесь контактами, будет очень здорово. Мы бы с удовольствием его наняли. А пока приходится через боль и страдания проходить по всем граблям.
            +4
            Да, спасибо за советы, они на самом деле полезные. Цель прочитал не так давно и сейчас осознаю, что когда регрессионное тестирование тормозило релизы, мы пользовались этими знаниями, чтобы ускорить наши релизы.


            Регрессионное тестирование не может тормозить релиз. Оно не для этого сделано.

            Например, освободили тестировщиков от любой работы не связанной с тестированием релизов, ввели правило Stop The Line когда разработчики не могли создавать новые задачи, чтобы не копить очередь. У нас об этом есть статья.


            Я ее прочел. Применяйте пять почему и почитайте про релизный менеджмент. Есть общепринятый набор терминов, лучше следовать им. И вы не очень поняли зачем делается код фриз…

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


            Напишите Сергею Мартыненко
            Его сайт: blog.shumoos.com
            Настоятельно рекомендую к ознакомлению
              +2
              Регрессионное тестирование не может тормозить релиз. Оно не для этого сделано.

              Вот только не весь менеджмент это понимает :-)
                +1
                Я неправильно выразился. Регрессионное тестирование не тормозит релизы само по себе. Я имел в виду, что регрессионное тестирование было бутылочным горлышком нашего релизного цикла.
                Про релизный менеджмент почитаю, если кинете в меня толковой книгой буду благодарен.
                И вы не очень поняли зачем делается код фриз

                Можете рассказать зачем?
                Блог Сергея недавно открыл для себя, потихоньку изучаю.
                  +3
                  Я имел в виду, что регрессионное тестирование было бутылочным горлышком нашего релизного цикла.

                  Вы не успевали его полноценно делать, оно тормозило или очень хотелось релизить фичу, но релиз пребывал в состоянии "аль денте"?
                  На самом деле в процессе чтения статьи я не мог отделаться от мысли, что бизнес достаточно сильно давит на разработку и процесс весьма сильно разбалансирован. По крайней мере разработчики, которых не интересует качество продукта — это такой весьма заметный и большой красный флаг, обычно такое бывает на разного рода галерах, где главное фичу отгрузить в минимально работоспособном состоянии, а дальше или менеджеры утрясут вопросы и будет заказа на доработку, или клиент отвалится и черт бы с ним, все равно деньги уже получены.
                    0
                    Вы не успевали его полноценно делать, оно тормозило или очень хотелось релизить фичу, но релиз пребывал в состоянии «аль денте»

                    Мы успевали его делать, но делали это дольше, чем хотелось бизнесу. Точнее так, весь процесс доставки фичи занимал много времени, а бизнес всегда хочет доставить фичу как можно быстрее (при прочих равных)
                    бизнес достаточно сильно давит на разработку

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

                    Если из моей статьи вы сделали вывод, что наших разработчиков не интересует качество продукта, значит я что-то упустил или криво сформулировал (shame on me), потому что наши разработчики заинтересованы в качестве продукта.
                      0

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

                        0
                        Мы отказались от ручного регресса, автоматические тесты с покрытыми критичными сценариями из регресса ходят после каждого коммита в общую ветку. Т.е. от самого регресса мы не отказывались, а свели его к прохождению автотестов.
                          +1

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

                            0
                            Не совсем. Критичные сценарии, которые мы проверяли, покрыли, остальное перестали регрессить. Если всплывают какие-то сценарии которые тогда были не критичными, а сейчас становятся критичными или мы о них не подумали, тоже автоматизируем.
            +4
            > Пропала компетенция написания автотестов

            Можете пояснить, почему пропала компетенция написания автотестов? Я так понимаю, что в QA отделе были люди с этой компетенцией. Они уволились?
              0
              Да, изначально были люди с этой компетенцией и они написали существующий набор автотестов. Потом один человек уволился, остальные пошли заниматься кто продуктовым менеджментом, кто разработкой, а кто скрам мастерством.
                +7
                А написали бы нормально, «Мы разучились писать автотесты», а не «пропала компетенция» — может и корень проблемы был бы виден сразу. Люди уволились, писать стало некому и незачем — им за это теперь не платят. Откуда этот новомодный канцелярит?
                +2
                Мы подумали про автотесты — передадим их разработчикам и они будут сами тестировать без проблем.

                А тест-планы тоже разработчики прорабатывают и составляют, на основе которых пишутся автотесты?
                  +1
                  Тест-план — это очень уж высокоуровневый документ для использования его для написания автотестов. Возможно, имелись в виду тестовые спецификации и тестовые процедуры?
                    +2
                    Давайте я попробую сформулировать свой вопрос с более практической точки зрения. Разработчик в рамках задачи реализовал какую-то новую фичу в проекте, например в рамках требования от бизнеса. После этого ему нужно написать автотест (согласно повествованию в статье). Для того чтобы написать автотест, как мне кажется, должен существовать какой-то план тестирования этой фичи. Конечная же задача чтобы выполнялось требование от бизнеса. Далее на основе плана пишется код автотеста. Если это так, то кто составляет план и кто верифицирует что план верный? И есть ли какое-то ревью теста?
                      +1
                      Для того чтобы написать автотест, как мне кажется, должен существовать какой-то план тестирования этой фичи.

                      Тестовый план — это документ, определяющий более глобальные моменты, что будет тестироваться, какие виды тестов, критерии начала, критерии окончания и т. п. Тестовая спецификация — это уже набор конкретных тестовых случаев, но обычно всеобъемлющий по продукту, для удобства можно уже составлять тестовые сьюты, которые тоже содержат в себе тест-кейсы, но могу формироваться более произвольно. И наконец — собственно тестовые случаи, которые и автоматизируют. Вот тест-кейсы обычно ревьювят другие тестировщики, но могут и продакт овнеры, и бизнес-аналитики, и разработчики (в целом — чем больше ревьюверов — тем лучше).
                        +3
                        Вы придираетесь к формулировкам и не отвечаете по существу. Суть вопроса верная: делается ли анализ и составляются ли тест-кейсы перед автоматизацией?
                          +2
                          Вы придираетесь к формулировкам

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

                          Суть вопроса верная: делается ли анализ и составляются ли тест-кейсы перед автоматизацией?

                          Должны делаться. А так — от проекта зависит, конечно.

                          Чем вас от этот вот ответ не устроил?
                          Вот тест-кейсы обычно ревьювят другие тестировщики, но могут и продакт овнеры, и бизнес-аналитики, и разработчики (в целом — чем больше ревьюверов — тем лучше).
                        +2
                        QA инженеры составляют приемочные критерии к каждой задаче вместе с Владельцем продукта и с разработчиками. Затем QA инженеры в командах берут конкретные задачи смотрят на эти приемочные критерии и составляют тест-кейсы для фичи и отмечают какие кейсы должны быть автоматизированы.
                        0

                        Тест план и тест стратегия – это всё-таки не тождественные вещи, план можно (а иногда и нужно) составлять хоть на каждый спринт (итерацию).

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

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

                              0

                              В классическом скраме в конце каждого спринта создаётся что-то новое, что готово к релизу. По каким-то соображениям оно может не релизиться, но должно быть готово. Включая включение в общие тестовые планы продукта.

                        +1
                        Есть несколько вариантов структур управления, один из них — «матричная структура управления». Скорее всего у вас «QA Engineer» в команде должен иметь «двойное подчинение» — команде/тимлиду и «QA Tech Lead». Так вы сможете получить и максимальную интеграцию QA в разработку и единого ответственного за организацию QA в компании.
                          +1
                          Вы правы. Недавно на нашем гитхабе выложили структуру IT и там как раз матричная структура, к которой мы будем идти.
                          +6
                          Как мы «разогнали» команду QA

                          Всё, что надо знать
                          О том, как разработчики строят IT в Dodo
                            0
                            Там и в целом вся история смешная: «Как Федя решил построить IT-компанию, но получилась почему-то смесь инфобизнеса и пиццерии»
                              0
                              Нужны подробности!
                            +6

                            Спасибо что написали. Статьи и выступления про неудачный опыт иногда полезнее рассказов про удачные решения.

                              +1
                              Спасибо за комментарий. Полностью согласен, мне всегда нравятся статьи и доклады про неудачи и факапы.
                              +7
                              Прекрасная статья, которую также можно было бы назвать «недостатки ИТ образования в РФ и как мы изобретаем велосипед с опозданием на 20 лет». Предлагаю погуглить силабус курса по QA какого-нибудь адекватного университета(MIT например), взять от туда список литературы и дать почитать своему менеджменту. У меня всегда горело с профессионального уровня российского тестирования, судя по всему вы решили зайти на очередной круг, который уже проходили в году так 2010 многие отечественные «ИТ гиганты» :) Хотя чему удивляться, все адекватные специалисты спешно покидают родину все последние годы, а потом тилиды с опытом 3 года и менеджеры проектов по верстке лендингов, встают к рулю.
                              Фактически вы нарушили все подходы по SDLC и оно внезапно не взлетело, «вот это поворот, вот это поворот...»
                                +2
                                Да, про образование прям в точку. У меня в универе даже намека на тестирование и обеспечение качества не было. Зато я умею с 3-мя cms-ками разным работать. Как тебе такое Илон Маск?)
                                А можете подробнее раскрыть какие подходы SDLC мы нарушили?
                                +11
                                Потому что разработчики получали обратную связь слишком поздно.
                                Баги находились на этапе, когда уже вся разработка «закончена», всё «интегрировано» и нужно проверить, что продукт готов к релизу.
                                ..
                                Сказывается и наш поход в сторону отпила микросервисов от монолита. В монолите становится меньше тестов, и все больше в отдельных репозиториях, пайплайн становится стабильнее.

                                Понятно, что тестировать «котлетку» проще когда она вот свеженькая с огня, чем когда она уже запихана в гамбургер и упакована в коробочку.
                                Т.е. у вас был водопад. Понятно, что вам хотелось сделать т.н. «shift-left».

                                Но решение, на мой взгляд, не соответствует задаче. Вы заставили тех, кто жарит котлетки еще и проверять их, а если они не проходят тесты — то откладываем их в сторону (мутим тест) и делаем новую котлетку. Еще и придумываем новые тесты для котлетки. А отгружать котлетки надо с той же скоростью что и раньше. Ну ведь понятно, что в таких условиях серьезного подхода к обеспечению качества не будет. Где тот человек который будет смотреть на процесс создания котлеток и скажет, так, плиту надо передвинуть, купим фаршефасовочную установку чтобы котлетки были все одинакового веса. Будем проверять фарш на консистенцию до поступления на кухню. И т.д., и т.п. В качестве упражнения спросите себя, что, кто и как влияет на качество продукта.

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

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

                                Почему разработчики «плохие» тестировщики? Поверьте, у разработчиков очень хорошо с логикой они отлично могут погрузить себя в роль «хакера». Но им не до этого. Потому что надо пилить. Не одному здравомыслящему человеку не придет в голову работать себе во вред.
                                А выделеный тестировщик — лицо заинтересованое. Ему платят, в конце концов, за то, чтобы он был таким «противовесом» и ничему не верил на слово. Получается здоровое противоборство умов.
                                А когда тестированием занимаются разработчики у нас возникает банальный конфликт интересов. Тесты им реально мешают. И получается, когда они сами этими тестами управляют, они сделают в конце концов так, чтобы они им не мешали. Приспособятся. У вас будут зеленые тесты и баги на проде.

                                Я знаю команды, которые за красные тесты дрючат. Так там такое в тестовом коде найдешь, что стыдно вслух сказать. Заглушенные тесты до фикса бага в продукте ещё самое безобидное.
                                Поясню еще раз для всех: глушить тесты нельзя, по простой причине — они перестают указывать на проблему. А это их, собственно, первоочередное назначение. В любое время дня и ночи. Узелок на память, если хотите.

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

                                  +2
                                  Спасибо за коммент, с многим согласен. Особенно с «плохими» программистами и «заинтересованными» тестировщиками. Всем своим работодателям это говорил пока сам тестил.

                                  > Можно делить команду и воркшоп делают двое а трое «на службе», потом меняются чтобы было противоборство.

                                  Мы пробывали такое сделать, правда без скор-борда (мне бы точно не помогло, т.к. я не воспринимаю информацию «вне», когда я работаю, мне джира удобнее). Некоторые во время «дежурства» просто читали новости 5 часов в день. Но я должен сказать что ни кнута ни пряника за фикс багов не было.
                                    +2
                                    Все правильно написано. Поддерживаю.
                                      +1
                                      Мне прям понравилась аналогия с бургерами. Аналогия с пиццей была бы еще лучше)
                                      QA инженеры пошли в команды разработки, чтобы в рамках конкретной команды смотреть как жарятся котлетки, помогать командам жарить эти котлетки и проверять качество этих котлеток до упаковки.
                                      Разработчики пишут автотесты, но на какие сценарии писать подсказывает QA инженер. И зачастую тестирует тоже QA инженер, но иногда могут потестировать разработчики. Но от QA инженера есть сценарии как это нужно тестировать.
                                      Что касается игнора тестов, я тут тоже согласен с вами, нельзя игнорить тест, если он не проходит по какой-то причине, нужно разобраться и починить эту проблему.
                                      +6
                                      До боли все знакомо с этой ситуацией и с идеями «короткой обратной связи» (как будто критический баг с полным набором логов не достаточно сильная обратная связь). Мне вот только интересно в новом подходе, когда разрабы сами пишут автотесты:
                                      — где они для этого находят время (а времени на это прилично уходит)?
                                      — не лукавят ли они, тестируя свой продукт? могут ли «незамыленно» и разносторонне проверять?
                                      — кто следит за развитием фреймворка? или каждый пилит свой?

                                      Как-то часто не осознают, что проект автотестов может быть сложнее, чем продукт, который он тестирует. И подходы к его разработке и поддержке на практике являются такими же, как к разработке отдельного продукта. Со своим инструментарием и внутренним контролем качества.
                                      Статья полезная и показательная. Жаль руководители, которые иногда принимают кардинальные решения, такие статьи не читают.
                                        +1
                                        • На PBR-е в задаче уже написано что должно быть покрыто автотестами и разработчики знают что нужно покрывать они учитывают это в объеме задачи когда затягивают к себе в бэклог
                                        • Для этого нужен QA в команде, который будет увеличивать разносторонность тестирования и смотреть свежим взглядом на фичу, используя свои знания из области тестирования и знание продукта
                                        • Вот с этим пока беда. По сути никто. Поэтому сейчас есть дублирование функций, разные подходы в разных местах. Но мы идем к тому, чтобы QA комьюнити забрало себе владение этим фреймворком и его развитие.

                                          +1
                                          На PBR-е в задаче уже написано что должно быть покрыто автотестами и разработчики знают что нужно покрывать они учитывают это в объеме задачи когда затягивают к себе в бэклог

                                          Разработчики пишут юниты, интеграционные или e2e-тесты?
                                            0
                                            Разработчики пишут все виды тестов, которые необходимы для тестирования фичи.
                                              0
                                              После такого ответа стало интересно, какой процент от задачи занимает написание тестов.
                                                0
                                                Задал вопрос своей команде ответил пока один человек, поэтому процитирую его ответ
                                                Тесты от unit- и до интеграционных, не покидающих кода сервиса (in-memory репозиторий — да, sqlite вместо mysql — нет) у нас часто пишутся по TDD, поэтому оценить временные затраты сложно — нет отдельной таски. Бывает, что для теста нужно написать 100500 строк тупого кода вроде DSL, бывает, что нужно выносить дублирующийся код из самих тестов в какие-то отдельные конструкции. Я бы сказал, что отношение времени чистой разработки к написанию unit-тестов — 50/50 с легким уклоном в тесты.
                                                Тесты, работающие с SUT как с black-box (хоть по HTTP API или шине, хоть через UI), тоже бывают разные. Где-то нужно переиспользовать готовые шаги и чуть-чуть поменять when'ы, а где-то нужно писать целые PageObject'ы (и иногда вносить изменения в сервис, потому что тот не готов тестироваться автоматически). Относительное время я точно не скажу, а по абсолютному — от полудня до двух-трех дней плюс-минус трамвайная остановка (большой разброс)
                                                  +1
                                                  Спасибо. В целом ожидаемо. Хотя немного неожиданно, что разработчики не против тратить столько времени не на продукт непосредственно.
                                        +5
                                        Все не очевидные последствия в данной ситуации изумительно лечатся депримированием и снятием опционов с менеджмента (предложивших / согласовавших) разогнать QA, года на 1.5-2 точно хватит с запасом
                                          +4
                                          Классика непонимания что такое QA, и чем этот отдел занимается вообще. В двух словах этот отдел — это фильтр между разработчиками и клиентами. Все эти тесты это просто инструменты для этого отдела. Если от QA приходит вердикт, релиз нельзя отправлять в прод из-за ошибок, то это решение никто не может оспорить, ни PM, ни Big Boss, вообще никто. И нарушение ведет как правило не только к денежным, но и репутационным потерям.

                                          Ну и как обычно проблемы с пониманием времени которое нужно для проверки новой функциональности. Например есть фича на разработку которой ушло 100 часов, так вот для проверки этой фичи нужно не меньше 100 часов. И для того чтобы фича появилась не через 200 часов — после разработки и тестирования делают просто — QA начинает разработку тестов для фичи одновременно(или чутка раньше) с разработкой фичи.
                                            0
                                            Да, все правильно, поэтому и приняли такое решение пойти в команды и покрыть регресс автотестами, чтобы была возможность начинать раньше обеспечивать качество продукта.
                                              0
                                              Например есть фича на разработку которой ушло 100 часов, так вот для проверки этой фичи нужно не меньше 100 часов.

                                              Кстати вообще не факт, наблюдал как фичи длинной в 80 часов можно было протестировать за 2 часа(включая документирование тест-кейсов и результатов), и как фичи длинной в 4 часа приходилось тестировать 40 часов(даже после применения всем методик, которые уменьшают количество требуемых тестов), так то во многом зависит от самой фичи и от того, какую часть продукта она затрагивает.
                                                0
                                                Вот чтобы это все не вычислять и не угадывать, берут такое же значение или больше для просчета сколько надо времени на тестирование фичи. А коэффициент этот как правило высчитываться из размера отдела QA. Не забываем что есть если ошибки которые сложно воспроизвести или обнаружить причину возникновения ошибки или же просто ошибка проявляет себя в 1% случаев
                                              0
                                              На все команды не хватило QA-инженеров.
                                              А как вы хотели, если у вас на одного тестировщика приходится аж 17 разработчиков?! (proof)

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

                                              Вообще говоря, странно, что компания с почти 10-летней историей никак не может нащупать свой правильный путь.
                                                0
                                                А как вы хотели, если у вас на одного тестировщика приходится аж 17 разработчиков?!

                                                С того момента у нас вышло 2 QA инженера, поэтому отношение изменилось)
                                                Плюс открыты 3 вакансии и когда мы всех наймем опять ситуация будет другая.
                                                Нет. Как любил повторять Генри Форд, «каждый должен заниматься своим делом, и достигать в нем высокого мастерства».

                                                Может быть. Но Генри Форд жил давно, когда не было компьютеров и индустрии разработки ПО. Приведу абзац текста из книги Continuous Integration: Improving Software Quality and Reducing Risk
                                                In many organizations where automated functional testing is done at all, a
                                                common practice is to have a separate team dedicated to the production and
                                                maintenance of the test suite. As described at length in Chapter 4, “Implementing
                                                a Testing Strategy,” this is a bad idea. The most problematic outcome is that the
                                                developers don’t feel as if they own the acceptance tests. As a result, they tend
                                                not to pay attention to the failure of this stage of the deployment pipeline, which
                                                leads to it being broken for long periods of time. Acceptance tests written without
                                                developer involvement also tend to be tightly coupled to the UI and thus brittle
                                                and badly factored, because the testers don’t have any insight into the UI’s underlying
                                                design and lack the skills to create abstraction layers or run acceptance tests
                                                against a public API.
                                                The reality is that the whole team owns the acceptance tests, in the same way
                                                as the whole team owns every stage of the pipeline. If the acceptance tests fail,
                                                the whole team should stop and fix them immediately.

                                                Авторы считают, что нужно привлекать разработчиков к написанию тестов.
                                                  0
                                                  А разработчики у вас случайно не админят сервера? Если сказать коротко, то для QA, разработки, админства надо чтобы мозги работали по разному. Вот поэтому тут и не работает принцип «швец, жнец и на дуде дудец».
                                                    0
                                                    Нет, сервера они не админят. Хотя опыт перехода целой команды разработки в инфраструктуру у нас был и разработчики стали инженерами инфраструктуры.
                                                    А можете подробнее рассказать почему должны работать по-разному мозги QA, разработчика и инженера инфраструктуры, в чем разность?
                                                      0
                                                      Ну это очень просто. Задача разработчика создать что-то. Задача QA проверить то что создал разработчик на соответствие каким-то критериям. По сути же задача QA сводиться к тому, чтобы проверить «на прочность», найти способ как сломать. Если разработчик по сути зажат рамками системы в которой он что-то разрабатывает, то QA наоборот действует на эту систему из вне. И проверяет не только новую функциональность, но и саму систему.

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

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

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

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

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

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

                                                      Да я балансирую на грани сроков и объема тестирования, да у меня замылен глаз. Но я лучше знаю свой код. Я пишу тесты, которые покрывают основные моменты. Они сокращают мне время на проверку моей же работы. Я становлюсь более уверенным в своем коде. Я сокращаю шансы что-то случайно поломать в другом месте. В конце-концов — тесты помогают мне ставить на место токсичных членов команды, которые во всех проблемах винят других, но только не себя. Со временем вся команда понимает, что мой код стабилен и, в основном, свободен от багов. И начинают смотреть сначала у себя. Это вот прям реально такое было.

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

                                                      Поэтому вот это все «программист не должен писать тесты» — означает, что программисту посрать на проект и на команду. Он скидывает с себя ответственность за свою же работу. Чаще всего есть оправдание — менеджмент закидывает задачами, как золотая антилопа того чувака на лестнице.
                                                        0
                                                        Тестирование — это убедиться что что-то соответствует каким-то требованиям. Как правило эти требования размазаны по куче документов. И как правило в ТЗ к какой-то фиче или в баг репорте никто не вписывает параметры которые используют при Load Testing или Stress Testing, даже если и впишут то разработчик не будет их проверять или не сможет создать такую нагрузку. И таких требований которые не знают разработчики на самом деле очень много.
                                                        Ваши требования к вашей работе тут не причем.

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

                                                        Со временем вся команда понимает, что мой код стабилен и, в основном, свободен от багов. И начинают смотреть сначала у себя. Это вот прям реально такое было.

                                                        А потом бах случается какой-то баг и никто не смотрит в ваш код, он же покрыт тестами. Хоть и плохо и поверхностно
                                                        Я пишу тесты, которые покрывают основные моменты.
                                                        А потом оказывается что баг был в этом самом коде, и на его поиски ушло в сто раз больше времени. QA это всегда недоверие ко всем тестам и ко всему коду, поэтому всегда тесты прогоняют с начала и все. А еще есть баги в архитектуре/спецификации например, которые тестами никак не вылавливаются. Есть еще и баги в тестах :)
                                                          +1
                                                          Тестирование — это убедиться что что-то соответствует каким-то требованиям. Ваши требования к вашей работе тут не причем.

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

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

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

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

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

                                                          Так стоп «начинают смотреть сначала у себя» != «смотреть ТОЛЬКО у себя». Начинают другие, чисто по теории вероятности, если не нашли — идут ко мне. Если бага в итоге у меня — я дописываю тест.

                                                          Такое ощущение, что у вас теоретическое представление о программистах и процессах разработки.
                                                            0
                                                            С требованиями там все просто, разработчику требования приходят переработанные PM-ом, Tech или Team Lead-ом. QA же работает с требованиями от бизнеса или клиентов, которые технически не всегда грамотные. И то что вы идеально сделали фичу по ТЗ — это хорошо, но это ТЗ может содержать ошибки или не точности.

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

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

                                                            Это только ощущение.
                                                            Тема разработчик и QA сложная и холиварная, и с той и с той стороны есть куча косяков. Я побывал и на той и на той стороне «баррикад», и админил еще в придачу.
                                                              +1
                                                              С требованиями там все просто, разработчику требования приходят переработанные PM-ом, Tech или Team Lead-ом. QA же работает с требованиями от бизнеса или клиентов, которые технически не всегда грамотные.

                                                              Большинство компаний/сотрудников только мечтают об этом. Обычно есть босс + программист, в лучшем случае босс + аналитик/тестировщик + программист.
                                                              Полный набор редко у кого встретишь и лично я в таких компаниях не работал.

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

                                                              Покрытие кода тестами на 10%

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

                                                                Хорошо, Ваш код покрыт тестами. Вы контролируете качество своей работы.

                                                          +1
                                                          Полностью согласен. С другой стороны мы (программисты) не специалисты по тестированию и не всегда можем или хотим придираться к каждой мелочи.
                                                          Я считаю правильным решением было бы если бы после того как продакт пишет описание фитчи, перед тем как она попадает к разработчику тестировщик должен описать все Acceptance Tests которые явсляются неотъемлемой частью фитчи. Это конечно же не отменяет всех остальных видов тестов, которые разработчики должны писать для проверки своего кода.
                                                            0
                                                            У меня супруга тестировщик — говорит: максимальный фейс-палм у тестировщика вызывает, когда на тестирование отдают фичу, которая не делает то, для чего она создавалась. Возникает вопрос — ты задеплоил и не можешь ткнуть три кнопки, что оно просто работает? Не в силах проверить — прошел ли вообще деплой и вообще тот ли комит ты задеплоил? А тестировщику надо все это верифицировать, проверить стабильно ли воспроизводится, описать и вернуть таску обратно.
                                                            Я вот просто внедрял коробочное ПО в контору и регулярно наблюдал, как в бетотестее, куда самых активных пользователей пригласили, продукт работал на альфу. Ну то есть банально, открываешь список исправлений и нововведений и начинаешь расставлять плюсики в каком месте на основе предыдущего опыта будут косяки. Потом сравниваешь итоги с предсказанием и попадаешь так в 3/4 случаях) Особенно смешно было, когда они внедряли в третий раз схожий функционал и ты в третий раз нашёл ту же самую ошибку, которую они допустили до этого уже дважды.
                                                            Но самый фейспалм именно в случае, когда ты нажимаешь кнопочку, а ничего не работает как объявлено. И ты такой: чта? как так-то?
                                                            И после внутренний голос предлагает тебе выпить… чаю, потому что предлагать побиться головой о стену ты ему запретил.
                                                      +8

                                                      Ликвидировать централизованный ручной QA в компании — это терять самую трудно нарабатываемую экспертизу.


                                                      Гуру Спринта или Реакта вы наймёте за соответствующие деньги. А где вы наймёте гуру ВашегоПродукта? А ведь QA — это архетип power user'а. Опытного пользователя, который всё знает и всё умеет. Который точно знает как оно должно быть и как оно не должно быть (и почему). Опытный QA — это эксперт в вашем продукте. Самый главный эксперт. Может быть, даже единственный, кто понимает, как все эти куски друг с другом стыкуются и почему именно так.


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

                                                        +1
                                                        Да, экспертизу в продукте с улицы не купишь. Но в нашем случае экспертиза в продукте не делась никуда, мы остались в компании и остались в своем продукте, просто стали ближе к разработке
                                                          +3

                                                          if you say so.


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

                                                            0
                                                            В этом смысле да, вы правы. Это еще одно последствие с которым нам предстоит разобраться. Управление знаниями наше всё)
                                                          +3
                                                          Согласен, еще QA хорошо бы работать в поддержке или хотя бы читать тикеты. У меня супруга работала на стыке аккаунт менеджера и QA. Он видела все боли клиента и чуть ли не единственная знала — как работает вся эта программа с точки зрения бизнеса и конечного заказчика, знала о багах, которые клиенту еще только предстоит найти и знала как их косвенно обойти при возможности.
                                                            0

                                                            Если бы мог поставил бы плюс к каждому вашему комментарию к этой статье.

                                                          +5
                                                          Вообще это неправильно — заставлять разработчиков писать е2е тесты. Во-первых, как упоминали выше — каждый должен заниматься своим делом. Ну, казалось бы — пилят разрабы автотесты — это не так сложно для них, время идет, зп идет — все проверяется. Но при этом они не видят картины в целом по фреймворку, и насколько точно в нем тестируется весь продукт.
                                                          Отсюда вторая проблема — очень не зря говорят, что хорошо, когда автоматизацией занимаются бывшие ручные тестеры — люди с опытом составления кейсов и документации. Разработчик так не сможет покрыть автотестами функционал, как сделает это тестировщик. У него будет минимум сценариев е2е тестов на фичу, которые будут напоминать расширенные юнит тесты с кучей моков и заглушек — лишь бы в отчете загорелся зеленый свет.
                                                          И третья проблема — она тоже на мой взгляд важна — разработчики знают код и уверенно усложняют фреймворк дополнительными самописными библиотеками, кучей оверрайда и т.д… Потом, если захотите возобновить набор автотестеров — то им будет очень сложно интегрироваться, так как там может ждать TestNG+Junit+Cucumber+Rest+ что-то еще монстр собранный из разных частей фреймворков.
                                                          И по поводу «утерянной экспертизы» — надо все документировать — в конфлюенс в битбакете в гитлабе в проекте — где угодно, но комменты нужны такие, чтобы и дураку понятно было.
                                                          Короче — наймите нормального QA лида — он разберется)
                                                          Читать было интересно))
                                                            +1
                                                            Я очень рад, что вам было интересно почитать)
                                                            По поводу того, кто должен писать тесты ответил в комменте выше
                                                            Отсюда вторая проблема

                                                            Проблему неумения разработчиков составлять исчерпывающие сценарии мы решаем наличием QA инженеров в команде, которые составляют эти сценарии. Разработчикам только нужно их автоматизировать.
                                                            И третья проблема

                                                            Тут не могу прокомментировать, пока не сталкивались, возможно столкнемся
                                                            надо все документировать

                                                            Да, документировать нужно и в каком-то виде тест-кейсы мы храним + автотесты сами по себе документация.
                                                            0

                                                            Смотрю я на это все и просто ржу или плачу. Вот прям 1 в 1 такая вот хрень сейчас происходит в моей компании, только у нас еще хуже, у нас тестировщики теперь приемкой заниматься должны, а мы теперь разработчики и верификаторы (недотестировщики)… И как раз сегодня моей команде грозили лишением премий из-за того, что в прод. версию месячной давности ушел критический баг… И автотесты под Selenium тоже говорят начинайте писать… да еще и на java, а у нас вся команда фронта, кроме меня, не знает ничего кроме js/ts… Видимо это заразно среди руководителей

                                                              0
                                                              Странное у вас руководство, зачем тесты под селениумом обязательно на джаве? Я конечно в целом скорее тоже за джаву и не сторонник js в автотестах, но если вся команда хорошо владеет js, то почему нет? Тем более что JS-инфраструктура для автотестов сейчас семимильными шагами развивается. Вон Playwright тот же к примеру.
                                                                0

                                                                Потому что ожидается, что тестировщики потом будут поддерживать и развивать эти тесты, а там народ нулевый, их только 1 месяц обучали писать тесты на java с JUnit. Тут банально нехватка умений. И наоборот, мои сопартийцы не хотят учить Java, чтобы писать тесты с NgWebDriver

                                                              0
                                                              Я вообще не понимаю уже, кто эти ребята из QA.
                                                              Это какие-то «недопрограммисты»?
                                                              Ну серьезно, ребята, у нормального программиста просто кровь из глаз, когда он смотрит на код тестировщиков.
                                                              Раньше это были какие-то девочки, которые быстро-быстро стучали по клавишам и дергали мышкой, нажимая на все что можно в интерфейсе и мне хотя бы была понятна идея.
                                                              Потом решили (и весьма правильно) что все можно автоматизировать. И этим же девочкам сказали писать код! Код, блин! Это то, к чему программист идет годами, через учебу, практику, чтение правильных книг и т.д.
                                                              И, к ужасу, это стало возможно, потому что появился язык питон (я в курсе что он пайтон, но так привычнее), который ввиду своей специфики позволят писать как угодно и кому угодно. Это, конечно, хорошо для обучения. Но для профессионального программирования… Обычно языки худо-бедно подталкивали к тому чтобы писать правильно, здесь эта поддержка отсутствует. И понеслась… Кстати, тот же питон сильно полюбили админы. Если раньше они жили в своей специфической нише из bash и awk (туда программистам было заглядывать жутковато, как в космический корабль «чужих»), то тут их пагубные привычки разлились широким морем по всему энтерпрайзу (еще одна боль — это смотреть на код админов на пайтоне).
                                                              Теперь, могут сказать, мол, вот, все дело в деньгах, программисты получают больше. Да нифига подобного! Уже давно все не так. Тестер, кое как умеющий в питон или JS, получает не меньше (а часто и больше) чем профессиональный программист с опытом на тех же языках. У меня несколько знакомых программеров ушли в QA по этой причине. Довольны: нагрузки меньше, ответственности меньше, денег больше — их обычные для программеров скилы по кодированию выглядят в мире QA как супер-пупер эксклюзи.
                                                              Вообщем, я думаю, что если надо написать какой либо код (не важно, для автотестов или для бизнес логики, и, таки да, и для развертывания образа БД) лучше чем профессиональные программисты этого не сделает никто. И т.о. если уже релиши полностью автоматизировать тестирование, то самое логичное — это дать писать автоматизацию профессиональным программистам, а не каким-то непонятным «QA — специалистам».
                                                                0
                                                                В странах где QA это инженеры контроля качества, где есть факультеты для обучения этой профессии — все хорошо. У нас же до сих пор тестера, а не инженеры. С админством такая же беда.

                                                                Я могу рассказать обратные истории, когда из QA уходили в разработку — потому что «нагрузки меньше, ответственности меньше, денег больше». И нету постоянной бумажной работы. Наформошлепил, залил и пусть себе QA разбираться что ок, что не ок.
                                                                Сам из разработки уходил в QA — да баги просто пачками вылавливаешь, потому как знаешь где разрабы ошибаются. Хороший опыт посмотреть на себя со стороны :)

                                                                По моему ощущению все админы которые могли в bash, awk и sed — ушли в разработчики. 20 лет назад только телеком был кузницей кадров и только на такой работе можно было получить какой-то инет для доступа к информации. Знаю потому что сам так начинал, с FreeBSD, работы на провайдере.

                                                                В деньгах я бы не измерял ничего, потому что есть например DevOps, у которых почти вся разработка на yaml :)
                                                                0
                                                                del

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

                                                                Самое читаемое