Тоже использую аналогичный подход, построить нормальную пирамиду - это бесценно. А касательно затрат времени, до момента применения подобных практик приходилось автоматизировать все проверки на уровне API (я в основном по микросервисам). Мой опыт говорит, что протестировать многообразие входных данных, а так же сделать это при необходимости с использованием моков и других инструментов, значительно быстрее на уровне юнитов/интеграционных тестов, чем пытаться повторить это на вершине пирамиды. И это мы еще не коснулись тех косвенных бонусов которые получает команда за счет такого плотного взаимодействия ее членов.
Но надо признать, что построить в одной команде это не так сложно, а масштабировать такой подход, действительно очень трудозатратно. У нас ушло около года на все трения.
Не совсем понял про философский камень и мечту. На основании своего опыта могу точно сказать, что озаботившись даже самым простым чек-листом который соответствует специфики команды, вы можете получить значительное увеличение качества того артефакта который будет в итоге реализован. В любом случае мероприятия связанные с качеством будут выполнены, тесты будут написаны, баги буду найдены. Вопрос заключается лишь в том, что вкладываясь в качество, вы получаете тот же самый результат, какой вероятно получите и не вкладываясь в него, но в первом случае это будет дешевле. Именно этот посыл, имеет главное значение. Компаниям не нужны будут тестеровщики, так как это будет просто не выгодно и их место должны будут занять инженеры по обеспечению качества. Я полагаю, что вы согласны, с тем, что цена предотвращенного дефекта , дефекта найденного на этапе обсуждений или на ранних этапах разработки на порядок ниже, чем цена дефекта найденного в готов артефакте?
В рамках этой статьи я не касался вопроса специалистов по тестированию безопасности, это отдельная специфическая тема в которой у меня нет релевантного опыта. Но косвенный опыт все же есть. Опыт это связан, как раз с чек-листами от ИБ специалистов, которые нужны были для предотвращения типовых ошибок в разработке и цель этого была именно увеличить качество поставляемого к ним на тестирование артефакта. Нет требования полного покрытия всего. Работа с качеством не означает, что ты полностью предотвращаешь все проблемы, это не так. И важно понимать, что qa, так же занимается и контролем качества, но предварительно выполняет работу по его обеспечению. Процесс контроля останется , от него уйти или сложно или не возможно, а вот роль, которая занимается только контролем должна будет исчезнуть.
Касательно моего примера, если qa инженер на этапе разбора задачи, хотя бы просто поднимет этот вопрос, то это может привести к положительным результату. Например команда продумает вопрос авторизации заранее, например использовать клиентскую или межсервисную, сразу явно проговорит правила сброса и времени жизни сессий и так далее.
Разумеется мы можем этого не делать и в ходе тестирования готового артефакта найти эти дефекты. Завести баги, потратить время на их исправление, ревью, мерж, сборку. Это и есть работа «тестера» сказать на сколько итоговый артефакт соответствуют явным или не явным требования, а задаче qa, провести ряд мероприятий, может быть даже и самых простых, таких как, просто сказать, «а что с ИБ?» и по возможности предотвратить дефект и помочь всей команде реализовать ожидаемую бизнесом фичу в оговоренный сроки.
Да, совершенно верно, мнение субъективное. Подача выбрана в таком формате специально, для привлечения внимания тестировщиков :)
В стать речь идет именно о понимание отличия этих двух направлений, касательно практик, там есть пару предложений, они имеет весьма "гигиенический" характер, но могут дать не плохой результат.
Если перейти к реальным кейсам, то могу предоставить примеры из личного опыта.
Работал с командами в которых были исключительно практики контроля качества, как это выглядит. QC не участвует, либо формально участвует в pbr, не погружается в контекст задачи, не понимает и подсвечивает команде возможные риски, сценарии тестирования и критерии успешности фичи. Спринт для такой команды выглядит обычно как waterfall модель. Разработка пишет большую половину спринта код, в конце спринта тестировщики берутся за тестирование. И тут происходит самое интересное, а именно:
находятся критичные дефекты (так не была проведена работа по определению критичных сценариев и приемочных критериев)
начинается расхождение того как поняли задача разработчики, тестировщики и что хотел заказчик
выстреливают критичные риски (ну например сервис не держит нагрузку)
Это разумеется обобщенный и неполный список, но суть заключается в том, что в самом конце цикла разработки мы фиксируем проблемы, которые могли предотвратить. Это как правило ведет к большим потерям времени, так как чем дальше мы ушли в плане разработки, тем дороже выходит исправление найденных проблем.
И я повторюсь, что если работа построена именно в таком русле, то какое бы ни было количество людей, которое в конце спринта нам скажет, что все плохо, не изменит качество и не сделает наш продукт лучше.
Именно с этим связана основная мысль, что "тестировщик" должен расширять свою зону компетенций и начинать влиять на качество на всех возможных этапах.
С точки зрения развития себя как QA, я бы посоветовал проанализировать типичные проблемы команды и попробовать внедрить небольшую практику которая помогла бы эти проблемы решить.
Касательно примера выше это было бы:
придти на PBR с чек-листом обеспечения качества и задать вопросы актуальные для продукта (будут ли проблемы с нагрузкой, нужно ли что-то специфическое по безопасности, нужно ли заранее продумать выход в продуктив и миграции и так далее, зависит от специфики команды)
вытащить из заказчика четкие формулировки, что для него будет являться "выполненной задачей" и проговорить со всеми членами команды какие кейсы точно должны реализованы
сразу же подготовить чек-лист основных проверок, придти к разработке и передать этот список, явно проговорил каждый пункт
Вероятнее всего, что мы не решим все наши проблемы, дефекты так же будут появляться, форс мажоры случаться, но заложить качество и помочь команде сразу реализовать именно тот функционал который нам нужен у нас повысится.
Это достаточная большая тема, кажется, что мне вновь не удается передать суть и практики. Но есть литература в которой уже описано :)
Для знакомства мог бы рекомендовать:
Agile-тестирование. Обучающий курс для всей команды Джанет Грегори, Лайза Криспин
Ну а так же все, что есть в интернете на тему shift-left testing, там можно так же подглядеть практики.
Речь идет не о ручном тестировании или автоматизации, а двух разных видах деятельности, а именно контроле и обеспечении качества. Оба эти направления могут, как содержать, так и не содержать автоматизацию.
Вероятно, я все таки плохо передал основную идею, а заключается она именно в том, что выстраивая любой производственный процесс, в том числе и процесс разработки, вложение в обеспечения качества выгоднее, чем вложение только в контроль качества.
Городить структуру и не нужно, просто нам мой взгляд "тестеры" должны чаще задумываться о добавлении в свою работу практик направленных на работу с качеством, а не только на его контроль, иначе они останутся за бортом.
Тоже использую аналогичный подход, построить нормальную пирамиду - это бесценно. А касательно затрат времени, до момента применения подобных практик приходилось автоматизировать все проверки на уровне API (я в основном по микросервисам). Мой опыт говорит, что протестировать многообразие входных данных, а так же сделать это при необходимости с использованием моков и других инструментов, значительно быстрее на уровне юнитов/интеграционных тестов, чем пытаться повторить это на вершине пирамиды. И это мы еще не коснулись тех косвенных бонусов которые получает команда за счет такого плотного взаимодействия ее членов.
Но надо признать, что построить в одной команде это не так сложно, а масштабировать такой подход, действительно очень трудозатратно. У нас ушло около года на все трения.
Не совсем понял про философский камень и мечту. На основании своего опыта могу точно сказать, что озаботившись даже самым простым чек-листом который соответствует специфики команды, вы можете получить значительное увеличение качества того артефакта который будет в итоге реализован. В любом случае мероприятия связанные с качеством будут выполнены, тесты будут написаны, баги буду найдены. Вопрос заключается лишь в том, что вкладываясь в качество, вы получаете тот же самый результат, какой вероятно получите и не вкладываясь в него, но в первом случае это будет дешевле. Именно этот посыл, имеет главное значение. Компаниям не нужны будут тестеровщики, так как это будет просто не выгодно и их место должны будут занять инженеры по обеспечению качества. Я полагаю, что вы согласны, с тем, что цена предотвращенного дефекта , дефекта найденного на этапе обсуждений или на ранних этапах разработки на порядок ниже, чем цена дефекта найденного в готов артефакте?
В рамках этой статьи я не касался вопроса специалистов по тестированию безопасности, это отдельная специфическая тема в которой у меня нет релевантного опыта. Но косвенный опыт все же есть. Опыт это связан, как раз с чек-листами от ИБ специалистов, которые нужны были для предотвращения типовых ошибок в разработке и цель этого была именно увеличить качество поставляемого к ним на тестирование артефакта. Нет требования полного покрытия всего. Работа с качеством не означает, что ты полностью предотвращаешь все проблемы, это не так. И важно понимать, что qa, так же занимается и контролем качества, но предварительно выполняет работу по его обеспечению. Процесс контроля останется , от него уйти или сложно или не возможно, а вот роль, которая занимается только контролем должна будет исчезнуть.
Касательно моего примера, если qa инженер на этапе разбора задачи, хотя бы просто поднимет этот вопрос, то это может привести к положительным результату. Например команда продумает вопрос авторизации заранее, например использовать клиентскую или межсервисную, сразу явно проговорит правила сброса и времени жизни сессий и так далее.
Разумеется мы можем этого не делать и в ходе тестирования готового артефакта найти эти дефекты. Завести баги, потратить время на их исправление, ревью, мерж, сборку. Это и есть работа «тестера» сказать на сколько итоговый артефакт соответствуют явным или не явным требования, а задаче qa, провести ряд мероприятий, может быть даже и самых простых, таких как, просто сказать, «а что с ИБ?» и по возможности предотвратить дефект и помочь всей команде реализовать ожидаемую бизнесом фичу в оговоренный сроки.
Да, совершенно верно, мнение субъективное. Подача выбрана в таком формате специально, для привлечения внимания тестировщиков :)
В стать речь идет именно о понимание отличия этих двух направлений, касательно практик, там есть пару предложений, они имеет весьма "гигиенический" характер, но могут дать не плохой результат.
Если перейти к реальным кейсам, то могу предоставить примеры из личного опыта.
Работал с командами в которых были исключительно практики контроля качества, как это выглядит. QC не участвует, либо формально участвует в pbr, не погружается в контекст задачи, не понимает и подсвечивает команде возможные риски, сценарии тестирования и критерии успешности фичи. Спринт для такой команды выглядит обычно как waterfall модель. Разработка пишет большую половину спринта код, в конце спринта тестировщики берутся за тестирование. И тут происходит самое интересное, а именно:
находятся критичные дефекты (так не была проведена работа по определению критичных сценариев и приемочных критериев)
начинается расхождение того как поняли задача разработчики, тестировщики и что хотел заказчик
выстреливают критичные риски (ну например сервис не держит нагрузку)
Это разумеется обобщенный и неполный список, но суть заключается в том, что в самом конце цикла разработки мы фиксируем проблемы, которые могли предотвратить. Это как правило ведет к большим потерям времени, так как чем дальше мы ушли в плане разработки, тем дороже выходит исправление найденных проблем.
И я повторюсь, что если работа построена именно в таком русле, то какое бы ни было количество людей, которое в конце спринта нам скажет, что все плохо, не изменит качество и не сделает наш продукт лучше.
Именно с этим связана основная мысль, что "тестировщик" должен расширять свою зону компетенций и начинать влиять на качество на всех возможных этапах.
С точки зрения развития себя как QA, я бы посоветовал проанализировать типичные проблемы команды и попробовать внедрить небольшую практику которая помогла бы эти проблемы решить.
Касательно примера выше это было бы:
придти на PBR с чек-листом обеспечения качества и задать вопросы актуальные для продукта (будут ли проблемы с нагрузкой, нужно ли что-то специфическое по безопасности, нужно ли заранее продумать выход в продуктив и миграции и так далее, зависит от специфики команды)
вытащить из заказчика четкие формулировки, что для него будет являться "выполненной задачей" и проговорить со всеми членами команды какие кейсы точно должны реализованы
сразу же подготовить чек-лист основных проверок, придти к разработке и передать этот список, явно проговорил каждый пункт
Вероятнее всего, что мы не решим все наши проблемы, дефекты так же будут появляться, форс мажоры случаться, но заложить качество и помочь команде сразу реализовать именно тот функционал который нам нужен у нас повысится.
Это достаточная большая тема, кажется, что мне вновь не удается передать суть и практики. Но есть литература в которой уже описано :)
Для знакомства мог бы рекомендовать:
Agile-тестирование. Обучающий курс для всей команды Джанет Грегори, Лайза Криспин
Ну а так же все, что есть в интернете на тему shift-left testing, там можно так же подглядеть практики.
Речь идет не о ручном тестировании или автоматизации, а двух разных видах деятельности, а именно контроле и обеспечении качества. Оба эти направления могут, как содержать, так и не содержать автоматизацию.
Вероятно, я все таки плохо передал основную идею, а заключается она именно в том, что выстраивая любой производственный процесс, в том числе и процесс разработки, вложение в обеспечения качества выгоднее, чем вложение только в контроль качества.
Городить структуру и не нужно, просто нам мой взгляд "тестеры" должны чаще задумываться о добавлении в свою работу практик направленных на работу с качеством, а не только на его контроль, иначе они останутся за бортом.
Очень хорошо, буквально мои мысли и практики оформленные человеческим языком. Спасибо за структурную подачу