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

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

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

Если мы предложим протестировать продакту, то с какой-то вероятностью, он даже пройдёт не только основной сценарий, но ещё и какие-то корнер-кейсы, которые были обсуждены с командой, отрисованы и реализацию которых он предполагает увидеть. Но, опять же, будет ли он придумывать какие-то ещё другие корнер-кейсы кроме тех, о которых он и так знает? Достаточно ли у него инженерных знаний, чтобы предположить (или посмотреть в коде) на каких входных данных та или иная функциональность может сломаться? А самое главное, если даже в этот раз он всё тщательно проверит, будет ли он это делать в следующий раз? Знает ли он как правильно зафиксировать тест-кейсы, по которым надо проходиться в разных ситуациях?

В обоих случаях, если ручное тестирование проводит продакт или разработчик, у меня складывается ощущение, что они заняты не своей работой. Что значит не своей? Я в это вкладываю две вещи. Первая - ту работу, экспертиза в которой не является для них профильной. Вторая - ту работу, которая подразумевает другой склад характера, чтобы делать её хорошо. Да-да, QA-инженеры, разработчики и продакты это люди, которые могут сильно по-разному смотреть на одни и те же вещи. И то, что каждый из них прикоснулся к фиче, прежде чем она была зарелижена - это благо. Есть более-менее общепризнанное мнение, что diversity это хорошо, так как мы получаем больше различных взглядов на одни и те же проблемы. Так вот наличие у вас в команде QA-инженера в добавок к продакту и разработчику - это тоже в каком-то смысле diversity, которое повышает качество вашего продукта.


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