Комментарии 10
Покончите с зависимостью от контроля качества. Устраните потребность в массовых проверках, прежде всего встраивая качество в продукцию. Качество создается не в результате проверки, а благодаря улучшению производственного процесса.
Не бывает управления без изменения. Тестировщики как раз и выполняют такую функцию. Это основа и она ни куда не денется.
Согласно принципу Эшби, управляющая система должна иметь такое же или большее разнообразие как управляемая. Это значит, что на каждый вариант нежелательного отклонения, со стороны управления должно быть заготовлено соответствующее компенсирующее воздействие.
В самом деле, чем выше надёжность системы, тем меньше разных вариантов нештатных ситуаций и тем проще ей управлять. Но сложность, обусловленная разнообразием возможных проблем, ни куда не девается - она просто переходит в процессы управления качеством.
Как следствие, если QC достаточно уметь измерять результат, то QA должен детально разбираться в процессе, причинах возникновения отклонений и способах их компенсации. По сути такой персонаж должен обладать экспертизой уровня всей команды: разработчиков, менеджеров, архитекторов и всех остальных вместе взятых - чьи действия в своей области могут приводить к дефектам. А иначе, не обладая достаточными компетенциями, он сам станет причиной неверных решений и ошибок. Как вариант, он может решить абстрагироваться от сложных деталей, но тогда его функция становится чисто бюрократической, в роде коучинга.
А вывод такой, что управление качестом разумнее встраивать в существующую иерархию управления (начиная с самых низов - разработчиков, их менеджеров, менеджеров менеджеров и т.п.), а не городить параллельную ей структуру из отдельных QA. Функция контроля QC остаётся в любом случае востребованой на любом уровне.
Верно
Вероятно, я все таки плохо передал основную идею, а заключается она именно в том, что выстраивая любой производственный процесс, в том числе и процесс разработки, вложение в обеспечения качества выгоднее, чем вложение только в контроль качества.
Городить структуру и не нужно, просто нам мой взгляд "тестеры" должны чаще задумываться о добавлении в свою работу практик направленных на работу с качеством, а не только на его контроль, иначе они останутся за бортом.
Вы подняли интересную тем, но пока это выглядит как субъективое мнение и не понятно как оно привязано к практике. Тут здорово бы смотрелись примеры реальных ситуаций - какие тактики из области QA использовали тестировщики и как это сказалось на проекте и их личной карьере.
Да, совершенно верно, мнение субъективное. Подача выбрана в таком формате специально, для привлечения внимания тестировщиков :)
В стать речь идет именно о понимание отличия этих двух направлений, касательно практик, там есть пару предложений, они имеет весьма "гигиенический" характер, но могут дать не плохой результат.
Если перейти к реальным кейсам, то могу предоставить примеры из личного опыта.
Работал с командами в которых были исключительно практики контроля качества, как это выглядит. QC не участвует, либо формально участвует в pbr, не погружается в контекст задачи, не понимает и подсвечивает команде возможные риски, сценарии тестирования и критерии успешности фичи. Спринт для такой команды выглядит обычно как waterfall модель. Разработка пишет большую половину спринта код, в конце спринта тестировщики берутся за тестирование. И тут происходит самое интересное, а именно:
находятся критичные дефекты (так не была проведена работа по определению критичных сценариев и приемочных критериев)
начинается расхождение того как поняли задача разработчики, тестировщики и что хотел заказчик
выстреливают критичные риски (ну например сервис не держит нагрузку)
Это разумеется обобщенный и неполный список, но суть заключается в том, что в самом конце цикла разработки мы фиксируем проблемы, которые могли предотвратить. Это как правило ведет к большим потерям времени, так как чем дальше мы ушли в плане разработки, тем дороже выходит исправление найденных проблем.
И я повторюсь, что если работа построена именно в таком русле, то какое бы ни было количество людей, которое в конце спринта нам скажет, что все плохо, не изменит качество и не сделает наш продукт лучше.
Именно с этим связана основная мысль, что "тестировщик" должен расширять свою зону компетенций и начинать влиять на качество на всех возможных этапах.
С точки зрения развития себя как QA, я бы посоветовал проанализировать типичные проблемы команды и попробовать внедрить небольшую практику которая помогла бы эти проблемы решить.
Касательно примера выше это было бы:
придти на PBR с чек-листом обеспечения качества и задать вопросы актуальные для продукта (будут ли проблемы с нагрузкой, нужно ли что-то специфическое по безопасности, нужно ли заранее продумать выход в продуктив и миграции и так далее, зависит от специфики команды)
вытащить из заказчика четкие формулировки, что для него будет являться "выполненной задачей" и проговорить со всеми членами команды какие кейсы точно должны реализованы
сразу же подготовить чек-лист основных проверок, придти к разработке и передать этот список, явно проговорил каждый пункт
Вероятнее всего, что мы не решим все наши проблемы, дефекты так же будут появляться, форс мажоры случаться, но заложить качество и помочь команде сразу реализовать именно тот функционал который нам нужен у нас повысится.
Это достаточная большая тема, кажется, что мне вновь не удается передать суть и практики. Но есть литература в которой уже описано :)
Для знакомства мог бы рекомендовать:
Agile-тестирование. Обучающий курс для всей команды Джанет Грегори, Лайза Криспин
Ну а так же все, что есть в интернете на тему shift-left testing, там можно так же подглядеть практики.
придти на PBR с чек-листом обеспечения качества... нужно ли что-то специфическое по безопасности
Чек-лист качества это мечта уровня философского камня, который будет превращать в золото все что угодно. Но если верить Гёделю, то будучи формальной системой, он окажется либо не полным, либо противоречивым. Со всеми вытекающими последствиями.
Давайте про безопасность. Как на практике. Желание приблизиться к полноте в таком важном вопросе, как безопасность, привела к появлению целого семейства стандартов - на разработку ISO/IEC 27000, и 15408 - на проверку. Крайне популярное и увлекательное чтиво в последнее время, покрывающее вопросы уровня огранизации, людей, физической безопасности и технологий - суммарно около 100 тем из разных областей. Вот пример классического чек-листа, затрагивающего лишь несколько из них https://github.com/RedHatInsights/secure-coding-checklist. Т е. если подходить к делу ответственно, то получить начальные сертификаты займет несколько месяцев, а внедрить и научиться осмысленно применять - миллионыгоды.
SAST, DAST, MPT, SCA, RE, PTasS, BAS, MAST - просто перечислить акронимы разного вида тестирования, необходимых, чтобы претендовать на соответствие стандартным требованиям - уже целое предложение.
Вы все ещё уверены, что тестировщики в скором времени останутся без работы? Мне кажется у для них с каждым годом работы только прибавляется.
Не совсем понял про философский камень и мечту. На основании своего опыта могу точно сказать, что озаботившись даже самым простым чек-листом который соответствует специфики команды, вы можете получить значительное увеличение качества того артефакта который будет в итоге реализован. В любом случае мероприятия связанные с качеством будут выполнены, тесты будут написаны, баги буду найдены. Вопрос заключается лишь в том, что вкладываясь в качество, вы получаете тот же самый результат, какой вероятно получите и не вкладываясь в него, но в первом случае это будет дешевле. Именно этот посыл, имеет главное значение. Компаниям не нужны будут тестеровщики, так как это будет просто не выгодно и их место должны будут занять инженеры по обеспечению качества. Я полагаю, что вы согласны, с тем, что цена предотвращенного дефекта , дефекта найденного на этапе обсуждений или на ранних этапах разработки на порядок ниже, чем цена дефекта найденного в готов артефакте?
В рамках этой статьи я не касался вопроса специалистов по тестированию безопасности, это отдельная специфическая тема в которой у меня нет релевантного опыта. Но косвенный опыт все же есть. Опыт это связан, как раз с чек-листами от ИБ специалистов, которые нужны были для предотвращения типовых ошибок в разработке и цель этого была именно увеличить качество поставляемого к ним на тестирование артефакта. Нет требования полного покрытия всего. Работа с качеством не означает, что ты полностью предотвращаешь все проблемы, это не так. И важно понимать, что qa, так же занимается и контролем качества, но предварительно выполняет работу по его обеспечению. Процесс контроля останется , от него уйти или сложно или не возможно, а вот роль, которая занимается только контролем должна будет исчезнуть.
Касательно моего примера, если qa инженер на этапе разбора задачи, хотя бы просто поднимет этот вопрос, то это может привести к положительным результату. Например команда продумает вопрос авторизации заранее, например использовать клиентскую или межсервисную, сразу явно проговорит правила сброса и времени жизни сессий и так далее.
Разумеется мы можем этого не делать и в ходе тестирования готового артефакта найти эти дефекты. Завести баги, потратить время на их исправление, ревью, мерж, сборку. Это и есть работа «тестера» сказать на сколько итоговый артефакт соответствуют явным или не явным требования, а задаче qa, провести ряд мероприятий, может быть даже и самых простых, таких как, просто сказать, «а что с ИБ?» и по возможности предотвратить дефект и помочь всей команде реализовать ожидаемую бизнесом фичу в оговоренный сроки.
и такая профессия как “тестер” полностью исчезнет из крупных и средних кокомпаний
Бред, конечно, полный. Даже не обсуждается.
"Скоуп работ" - риали? "Объем работ" не катит?
Да, и с запятыми у автора просто беда...)
А так, все верно.
Как-то всё переусложнено...
В двух словах:
профессия ручного тестировщика вымирает, потому что ручное тестирование плохо встраивается в рамки CI/CD;
если вы — ручной тестировщик, но не лишены сообразительности, осваивайте автоматизацию (например, Selenium или pytest);
если вы освоили автоматизированное тестирование, но не лишены сообразительности, осваивайте программирование (например, Python).
Tester. Или почему важно, изменить свою роль в команде