Все верно, в стандарте есть такое определение качества. Мое определение из книги “Total quality cintrol”, которое мне запомнилось и как мне кажется отражает суть качества. Как я писал, стандарт отличается от реальной жизни. В стандартах нет тестировщиков, а в жизни есть, так же и тут. Продукта без пользователей не существует. И фактически качество продукта определяют они, а не ТЗ. Другой вопрос кто за это отвечает и что с этим делать.
Можешь раскрыть немного почему ты считаешь что «QA-инженеры участвуют на самых ранних этапах создания продукта/фичи…»
это валидация и верификация?
Да, все что вы написали входит в задачу QA. У меня нет опыта работы в разных компаниях и если в компаниях есть люди, которые занимаются исключительно процессами обеспечения качества, то это круто (наверное). Но мне кажется это далеко не во всех компаниях, поэтому я и призываю самим становиться QA и улучшать процессы и влиять на качество.
Сопровождаемость это хорошо, но кривая стоимости изменений справедлива и для самого сопровождаемого продукта. Давайте представим продукт с хорошей сопровождаемостью и 2 ситуации:
1. мы нашли “багу” на PBR или в ТЗ.
Чтобы ее пофиксить владелец продукта или кто-либо вносит правку в приемочные критерии или доку. Баг пофикшен.
2. Нашли багу на проде.
Прилетел тикет на первую линию. Первая линия не разобралась в чем подвох, отдала на вторую. Вторая линия выяснила что это бага и сделала задачу на фикс. Владелец продукта увидел эту задачу, поставил ей приоритет. Разработчик затянул задачу, пошел читать код и править её. Сделал, отдал на тестирование. Тестировщик так же погрузился в контекст, затем протестировал задачу. Дальше отправляем задачу релиз-инженеру, который катит это на прод.
Вторая ситуация куда более затратная чем первая. Именно эти затраты и отражает эта кривая.
Спасибо, в целом у тебя получился неплохой краткий пересказ моей статьи)
Действительно, если убрать мои рассуждения и примеры подкрепляющие их то в сухом остатке будут эти тезисы, я бы еще к ним добавил тезис
6) если видишь в вакансии смесь QA и QC — возможно в компании не различают эти понятия, будь осторожен.
Инициаторами введения метрик во всех продуктах и публичное их отображение были руководители it-направления в компании. Я был полностью за, так как мы некоторые показатели в монолите уже замеряли и следующим шагом логично было бы собирать их не только в монолите, но и в других сервисах тоже.
А начали собирать метрики в монолите тестировщики и разработчики, без чьих-либо указаний, больше года назад.
Да, вы правы, это важное замечание. Необходимо понимать кто и зачем создает метрики.
Мы создавали метрики не для того, чтобы кого-то наказывать или кому-то показывать что у нас все хорошо. Мы действительно хотим создавать качественный продукт и поэтому решили это качество измерять.
вот несмотря на то, что в тексте подчёркивается многократно, что это «право» разработчика — всё же не очень верится, что это именно инициатива самих разработчиков, а не добровольно-принудительная указка сверху.
Я не знаю как вас убедить в том, что это не обязательно, у нас есть разработчики, которые не работали в пиццерии никогда и это нормально.
окей, я может некорректно выразился, скажу по-другому: получается, ваш разработчик как бы сразу же и тестировщик?
Я бы не сказал так. Пользоваться продуктом и тестировать его — это разные вещи. Разработчик просто выступает в роли пользователя. Он разрабатывает продукт для кого-то, в частности для сотрудников пиццерии и пользуются они ей в определенном окружении, условиях. Вот на это окружение и условия, в том числе, ходят смотреть разработчики.
это право сотрудника, ровно и пойти в пиццерию, тоже его право.
Обычно вообще отдельные люди транслируют потребности бизнесов в айти команду. То, что у вас этим занимаются разработчики, означает, что вы сэкономили на подобных людях.
сошлюсь на текст из абзаца «Кто должен ходить в гембу»
Для продактов это один из основных видов деятельностей, в пиццерии они черпают идеи, получают инсайты, видят картинку в целостности. Продакт-менеджеры используют гембу для тестирования гипотез, глубинных интервью, customer-development, составления customer journey map и так далее.
Разработчики не транслируют потребности бизнеса, они пользуются продуктом в реальных, полевых условиях.
Всегда полезно смотреть на процесс с разных сторон. Сфера интересов и знаний каждого человека сильно различается и то, что разработчику будет понятно как оптимизировать тот или иной процесс с помощью технологий, далеко не факт, что будет понятно менеджеру или любому другому человеку, далёкому от IT.
Что касается продуктов и аллергии на эти продукты, то это не значит, что куски рыбы прям с планшета свисают и попадают в другую пиццу. Плашеты мы обрабатываем регулярно как пищевые поверхности. Никто не оставит планшет грязным, для этого есть чек листы и обходы пиццерии.
С процессами в то время было не очень, вы правы. Но мы исправляем их потихоньку.
Да, бизнес позволяет это делать и даже больше скажу введение матрицы приоритетов это инициатива бизнеса.
Финальная валидация интеграции кода всех команд у нас выполняется автотестами.
Прежде чем разойтись по командам мы провели эксперимент. Двух тестировщиков оставили заниматься финальной валидацией продукта, после прохождения автотестов. Команды знали об этом экспермиенте. Баги найденные тестировщиками на этом этапе приравнивались к багам которые мы выпустили в прод. Команды стали внимательнее относится к коду, который сливали в дев. Мы смотрели сколько багов найдут тестировщики руками после прохождения автотестов и сравнивали с количеством багов найденных во время регресса до начала эксперимента. Количество багов не изменилось и критичность пропущенных багов осталась на том же уровне. Увидев что нет разницы мы решили вообще не проводить ручную финальну валидацию. Тут вопрос в потенциальных убытках, которые компания может понести от пропущенных багов и затратах на поиск этих багов. Мы приняли риски и сократили время выпуска продукта, в других ситуациях такой подход не допустим и это нормально.
Про ротацию. “Нужно согласие отпускающей команды” я имел ввиду что нельзя просто так взять и уйти ничего не сказав команде, не обсудив с ней это. И мы ни в коем случае не мешаем переходу.
По сути изменилось время начала взаимодействия. Раньше взаимодействие тестирощика и разработчика начиналось когда код разработчика попадал в релизную ветку и сводилось к тому, что тестировщик приносил баг, найденный на стейдже и потом перепроверял его, теперь тестировщик участвует в командных активностях, в командном планировании или груминге, выполняет приемочное тестирование до того, как код сольется в дев ветку. Может показать сценарии по которым он будет тестировать фичу, чтобы разработчик сразу учел различные моменты и стало меньше возвратов задачи на доработку.
У нас теперь нет вообще команды тестировщиков, в команде разработки сидит тестировщик и помогает команде выпускать качественный продукт.
Ротация между командами возможна, но при согласии 3х сторон (самого тестировщика, отпускающей команды и принимающей команды). Такое происходит не часто.
Баги, которые найдены и будут поправлены через неделю складываем в Кайтен. У нас есть общая доска для всех команд, там и держим их. А команды когда затягивают эту багу уже хранят как им удобно, у моей команды физическая доска.
Можешь раскрыть немного почему ты считаешь что «QA-инженеры участвуют на самых ранних этапах создания продукта/фичи…»
это валидация и верификация?
Да, все что вы написали входит в задачу QA. У меня нет опыта работы в разных компаниях и если в компаниях есть люди, которые занимаются исключительно процессами обеспечения качества, то это круто (наверное). Но мне кажется это далеко не во всех компаниях, поэтому я и призываю самим становиться QA и улучшать процессы и влиять на качество.
Сопровождаемость это хорошо, но кривая стоимости изменений справедлива и для самого сопровождаемого продукта. Давайте представим продукт с хорошей сопровождаемостью и 2 ситуации:
1. мы нашли “багу” на PBR или в ТЗ.
Чтобы ее пофиксить владелец продукта или кто-либо вносит правку в приемочные критерии или доку. Баг пофикшен.
2. Нашли багу на проде.
Прилетел тикет на первую линию. Первая линия не разобралась в чем подвох, отдала на вторую. Вторая линия выяснила что это бага и сделала задачу на фикс. Владелец продукта увидел эту задачу, поставил ей приоритет. Разработчик затянул задачу, пошел читать код и править её. Сделал, отдал на тестирование. Тестировщик так же погрузился в контекст, затем протестировал задачу. Дальше отправляем задачу релиз-инженеру, который катит это на прод.
Вторая ситуация куда более затратная чем первая. Именно эти затраты и отражает эта кривая.
Действительно, если убрать мои рассуждения и примеры подкрепляющие их то в сухом остатке будут эти тезисы, я бы еще к ним добавил тезис
6) если видишь в вакансии смесь QA и QC — возможно в компании не различают эти понятия, будь осторожен.
А начали собирать метрики в монолите тестировщики и разработчики, без чьих-либо указаний, больше года назад.
Мы создавали метрики не для того, чтобы кого-то наказывать или кому-то показывать что у нас все хорошо. Мы действительно хотим создавать качественный продукт и поэтому решили это качество измерять.
Я бы не сказал так. Пользоваться продуктом и тестировать его — это разные вещи. Разработчик просто выступает в роли пользователя. Он разрабатывает продукт для кого-то, в частности для сотрудников пиццерии и пользуются они ей в определенном окружении, условиях. Вот на это окружение и условия, в том числе, ходят смотреть разработчики.
сошлюсь на текст из абзаца «Кто должен ходить в гембу»
Разработчики не транслируют потребности бизнеса, они пользуются продуктом в реальных, полевых условиях.
Всегда полезно смотреть на процесс с разных сторон. Сфера интересов и знаний каждого человека сильно различается и то, что разработчику будет понятно как оптимизировать тот или иной процесс с помощью технологий, далеко не факт, что будет понятно менеджеру или любому другому человеку, далёкому от IT.
Что касается продуктов и аллергии на эти продукты, то это не значит, что куски рыбы прям с планшета свисают и попадают в другую пиццу. Плашеты мы обрабатываем регулярно как пищевые поверхности. Никто не оставит планшет грязным, для этого есть чек листы и обходы пиццерии.
Да, бизнес позволяет это делать и даже больше скажу введение матрицы приоритетов это инициатива бизнеса.
Прежде чем разойтись по командам мы провели эксперимент. Двух тестировщиков оставили заниматься финальной валидацией продукта, после прохождения автотестов. Команды знали об этом экспермиенте. Баги найденные тестировщиками на этом этапе приравнивались к багам которые мы выпустили в прод. Команды стали внимательнее относится к коду, который сливали в дев. Мы смотрели сколько багов найдут тестировщики руками после прохождения автотестов и сравнивали с количеством багов найденных во время регресса до начала эксперимента. Количество багов не изменилось и критичность пропущенных багов осталась на том же уровне. Увидев что нет разницы мы решили вообще не проводить ручную финальну валидацию. Тут вопрос в потенциальных убытках, которые компания может понести от пропущенных багов и затратах на поиск этих багов. Мы приняли риски и сократили время выпуска продукта, в других ситуациях такой подход не допустим и это нормально.
Про ротацию. “Нужно согласие отпускающей команды” я имел ввиду что нельзя просто так взять и уйти ничего не сказав команде, не обсудив с ней это. И мы ни в коем случае не мешаем переходу.
У нас теперь нет вообще команды тестировщиков, в команде разработки сидит тестировщик и помогает команде выпускать качественный продукт.
Ротация между командами возможна, но при согласии 3х сторон (самого тестировщика, отпускающей команды и принимающей команды). Такое происходит не часто.