Собственно в заголовке озвучен весь вопрос. Вводные данные: есть, на данный момент, отдел обеспечения качества, в котором работает три человека. Каждый сотрудник отдела закреплен за обеспечением качества отдельного продукта, разрабатываемого отдельной командой. При этом - все продукты, по сути, связаны между собой.
Из опроса опытных коллег-разработчиков выяснилось, что более распространенная практика - это “тестировщик в команде”. Руководитель компании считает иначе и у него есть свои доводы, с которыми можно согласиться. Вроде “замыливания взгляда”, “конфликт интересов” (это когда руководитель команды начинает сильно влиять на тестировщика внутри команды), и “такой тестировщик рано или поздно превратится в разработчика”.
А как вы считаете - какой подход эффективнее?[poll type=regular]
Ребята, простите, что не указал этого сразу - но будет просто круто, если вы будете аргументировать свои ответы)
Я считаю, что должен быть “тестировщик в команде” - так будет эффективнее. Будет больше погруженности в проект. С замылеванием взгляда можно бороться, к примеру, проведением тестирования методом свободного поиска на других проектах.
Многое зависит от жизненного цикла разработки и подходов к разработке. Если используется Agile + Scrum - то однозначно “тестировщик в команде”, если какие-то другие варианты - как-то Waterfall , RUP и другое - то тут может быть эффективнее отдельная команда тестировщиков с центральным управлением от тест лида или QA Manager
Отдельный QA отдел с динамически распределяемой нагрузкой.
ИМХО 2-й вариант оптимальнее.
а). Если Вася уйдёт в отпуск / заболеет, его заменит Петя, который также знаком с данной функциональностью. В случае выделенного ресурса такой замены не произойдёт, потому что Петя не знаком с функцональностью продукта Васи.
б). В случае временной низкой загрузки на проекте Пети, ему вполне могут скинуть задачи Васи, у которого сейчас как раз запара. В случае выделенного ресурса, Петя для Васи будет бесполезен: его обучение отнимет время, а пока Петя вкурит функциональность продукта, запара успеет закончиться.
в). Если Вася увольняется, остальной отдел сможет взять эту нагрузку до тех пор, пока не найдут ему замену. Эффективность будет снижена, но ничего фатального не произойдёт. В случае выделенного ресурса, эффективность тестирования будет снижена значительно. Более того, не исключён вариант, что Коля, которого возьмут вместо Васи, посчитает решение Васи полным бредом и начнёт писать всё с нуля, что повлечёт дополнительные трудозатраты.
г). Если продукты связны между собой, возникает потребность тестирования интеграции. Абсолютно не проблема в случае отдела. Есть тикет, есть исполнитель. В случае выделенного ресурса, возникнет вопрос, кому это тестировать: никто не захочет брать на себя лишнюю работу, которая с его продуктом напрямую никак не связана.
е). В случае введения автоматизации, отдел сделает это сравнительно легко: 2 человека берут задачи 3-х, 3-й, наиболее компетентный, разворачивает окружение и пишет автотесты. В случае выделенного ресурса, всё не так просто. Каждый из тестировщиков вынужден будет тратить значительный % времени на описанные выше задачи, что неминуемо приведёт к падению качества тестирования в целом. Как минимум до тех пор, пока автотесты не начнут приносить пользу.
ж). Если продукты связаны, они вполне могут быть похожи. Напрашивается создание общего тестового фреймворка. В случае отдела - не проблема. QA Lead берёт на себя / делегирует роль Test Architect. В случае выделенного ресурса, TA столкнётся с лишними проблемами типа “зачем делать так, если оно написано эдак и работает”.
Плюсы 1-го подхода: сниженные затраты времени / денег на роль QA Lead. Но эта разница легко перекроется с лихвой, когда прилетит любой из 6-ти перечисленных выше раскладов.
А если ведётся хорошая документация? Краткая и понятная, по всему - по продукту, по окружению, по действиям, необходимым для развёртывания окружения и пр. Плюс проводятся периодические митапы раз в неделю, с обсуждением сделанного и встреченных проблем?
Чем она поможет Пете за 2 часа сделать задачи Васи, который внезапно заболел, если разбираться в этой хорошей документации Пете придётся неделю?
А делать это превентивно у Пети мотивации нет и не будет: у него есть свой проект, нафига ему чужой курить?
Не буду говорить что это сказка на проектах, но есть такая мягко говоря проблема - актуальная документация. Безусловно считаю что должна быть отдельная команда, ибо можно:
Не заботится о тех кто уходит в отпуск / болеет
Проводить тестирование заменяя руки. Теоретически можно найти новые баги 3. Да и вообще, как контролить работу QA когда он сидит в своем проекте и больше никто туда не суется?
Мой любимый на данный момент вариант - все в команде тестируют свой код и тестировщик в этом первый среди равных - инженер заточеный на тестирование (как инженер заточеный на backend или frontend) . Все покрывают свой код тестами, учавствуют в их ревью, в том числе и тестировщик (его тесты тоже ревьювятся командой).
Знание раскатывается по команде и нет проблем с кратковременной болезнью или отпуском.
Работал в таком сетапе.
Оба подхода имеют право на жизнь. Всё зависит от объёма проекта и количества людей. В основном, где я работал, всё-таки тестировщик выделяется на проект. Это удобней с точки зрения того, что человек глубоко вникает в тему и лучше выполняет работу. Чем постоянная ротация, где каждый раз нужно человека вводить в текущее состояние дел.
Проблемы часто возникающие когда команда тестировщиков отдельная.
Конечно всё зависит от культуры разработки, но киньте в меня камень кто с таким не встречался!
Поехали:
За качество отвечает кто то со стороны. Возникают ситуации “Это не мы напрограмировали, а они не дотестировали!”. “Давай заделиверим, а там пусть QA смотрит! Это же их работа”
В итоге риски провиса по качеству.
Команда тестировщиков приходит в проект и смотрит на всё большими глазами,
" - ой ребята а что вы это тут накодили?
А это вот на таком митинге у нас было обсуждено! Иди к Бизнес аналитику/Системному Аналитику/Главному разрабу/Менеджеру и читай там всю нашу Вики - всё записано!
"
В итоге двойной анализ требований и выхлоп неэфективности
Автотесты забота тестировщиков.
“Мы свою работу сделали - теперь вы ребята автоматизируйте! У нас нет capacity чинить вам локаторы. На продакшене локаторы плохо деплоить - это тестовый код!
В базу доступ? Не - вы же тестеры! Black box!”
В итоге риски на продуктивности тестировщиков и риск получить плохие, неэфективные автотесты
Maintenance забота тестировщиков.
“Да они чё то там напокрывали и ни хрена не работает! Вот прийдут пускай разбираются! Им быстрее. Мы пока покодим”
В итоге не работающие автотесты, риск потратить впустую время на автоматы, провис по качеству.
Не встречался с таким лично, но полагаю что такое может быть. Наверное в том случае, когда QA-лид закомплексованный, не способный разговаривать с другими лидами “человек”. На мое счастье, всегда попадались адекватные ребята, которые могли нормально построить взаимодействие с разработчиками. И всё же мне кажется, на второй подход нужны QA посильнее в знаниях, чем на первый. А это сложно, потому первый вариант и более распространен.
Кстати очень часто видел QA команды и всякие QA resource pools с не сильно хорошим уровнем экспертизы у Йндийских вендоров. Один из любимых вариантов в огромных фирмах.
В целом конечно предупрежден - вооружен!
Надо понимать сильные и слабые стороны каждого варианта и работать с ними.
Абсолютно согласен, более того, люди порой не понимают смысл QA как такого.
QA - это не тестирование и не контроль качества, хотя QA и состоит из этого тоже.
Чтобы вы понимали, для тестировщика обычно чем больше багов он нашел тем лучше.
Для QA чем больше багов он нашел тем хуже, это значит мы имеем недоработки в обеспечении качества. Может у нас не достаточное покрытие тестами или мы не делаем ревью или ещё что-то…
QA - это исправить проблему ДО её появления, а тестирование - просто сообщить, что проблема уже существует.
Ок, а если сейчас мы имеет мало багов, а завтра выкатывается новая фича, достаточно багованная. Мало нашли тоже будет хорошо?
Мне кажется, вы не работали в высоконагруженных и сложных проектах, раз у вас такое мнение. В тех проектах, где вы будете копаться в логах только полдня после упавшего теста.
У вас проблема в том, что вы выкатываете достаточно багованные фичи
Это значит у вас проблемы с QA, вы опираетесь только на тестирование, которое просто вам говорит, что вы уже сделали свою работу плохо.
Не снимайте с себя ответственность, оправдывая это сложностью проекта.
Все эти ваши фразы говорят о том, что на проекте у вас создана супер инновационная, кластеризованная система распределения джоб на воркеры в 50 потоков, где овер 1000 UI тестов гоняются параллельно в докер контейнерах и всё это великолепие тестирует TODO-менеджер
“руководителей” в команде, по хорошему бы, не иметь вообще, лучше когда команда самоорганизована и понимает что и для чего делает, а с “руководителем” далеко не уедешь(
Говорят чем выше уровень независимости тестирования, тем оно как минимум обьективней и в идеале иметь несколько уровней.
Как пример, у нас на проекте (типа срам ) в каждой команде разработки есть отдельный тестер, который отвечает за функционал только его команды. И отдельно команда тестирования, которая тестирует интергацию/регрессию/приемку, занимается сбором метрик и QA по всему приложению.
Поработав в обеих, могу сказать, что быть одним тестером среди команды разработчиков как минимум скучно, как максимум сложнее… В первом случае, голос одного тестера != голосу пяти разработчиков, но голос команды тестирования по весу равен голосу разработки, поэтому лобировать свои интересы проще… Ну и главный для меня плюс - это возможность разделять задачи по желанию и способностям между членами команды, и как следствие повышение эффективности.
Выбрал вариант “Тестировщик в команде” т.к. качество продукта это зона ответственности всей команды, включая, помимо тестировщиков и разработчиков, всех людей участвующих в создании и доставке продукта.
А иметь отдельную команду тестирования удобно только в случае если высшим приоритетом есть поиск виновных когда что то пошло не так, вместо разработки и доставки качественного продукта
Да ну? Предложите еще симфоническому оркестру без дирижера сыграть Или в футбол без капитана.
По теме - работал и так и эдак. Быть тестировщиком в команде хорошо, когда идет работа одной команды над одним приложением. Если несколько приложений или энтерпрайз, то без отдельной команды не обойтись.
testomat.io управление авто тестами
