Да, экспертизу в продукте с улицы не купишь. Но в нашем случае экспертиза в продукте не делась никуда, мы остались в компании и остались в своем продукте, просто стали ближе к разработке
А как вы хотели, если у вас на одного тестировщика приходится аж 17 разработчиков?!
С того момента у нас вышло 2 QA инженера, поэтому отношение изменилось)
Плюс открыты 3 вакансии и когда мы всех наймем опять ситуация будет другая.
Нет. Как любил повторять Генри Форд, «каждый должен заниматься своим делом, и достигать в нем высокого мастерства».
Может быть. Но Генри Форд жил давно, когда не было компьютеров и индустрии разработки ПО. Приведу абзац текста из книги Continuous Integration: Improving Software Quality and Reducing Risk
In many organizations where automated functional testing is done at all, a
common practice is to have a separate team dedicated to the production and
maintenance of the test suite. As described at length in Chapter 4, “Implementing
a Testing Strategy,” this is a bad idea. The most problematic outcome is that the
developers don’t feel as if they own the acceptance tests. As a result, they tend
not to pay attention to the failure of this stage of the deployment pipeline, which
leads to it being broken for long periods of time. Acceptance tests written without
developer involvement also tend to be tightly coupled to the UI and thus brittle
and badly factored, because the testers don’t have any insight into the UI’s underlying
design and lack the skills to create abstraction layers or run acceptance tests
against a public API.
The reality is that the whole team owns the acceptance tests, in the same way
as the whole team owns every stage of the pipeline. If the acceptance tests fail,
the whole team should stop and fix them immediately.
Авторы считают, что нужно привлекать разработчиков к написанию тестов.
Да, все правильно, поэтому и приняли такое решение пойти в команды и покрыть регресс автотестами, чтобы была возможность начинать раньше обеспечивать качество продукта.
Вы не успевали его полноценно делать, оно тормозило или очень хотелось релизить фичу, но релиз пребывал в состоянии «аль денте»
Мы успевали его делать, но делали это дольше, чем хотелось бизнесу. Точнее так, весь процесс доставки фичи занимал много времени, а бизнес всегда хочет доставить фичу как можно быстрее (при прочих равных)
бизнес достаточно сильно давит на разработку
Давление есть, но это здоровое давление, от которого никуда не деться. Оно больше исходит от необходимости бизнеса развиваться, расти, успевать или обгонять конкурентов.
разработчики, которых не интересует качество продукта...
Если из моей статьи вы сделали вывод, что наших разработчиков не интересует качество продукта, значит я что-то упустил или криво сформулировал (shame on me), потому что наши разработчики заинтересованы в качестве продукта.
Любое дежурство по природе является повинностью.
Награждение не сделает работу менее скучной и не интересной. Но вы правы, эта работа важная и нужная и делать ее кто-то должен. И обеспечить ее выполнение мы можем это несколькими способами. Или вводить отдельную команду или вводить дежурство. Может есть еще какие-то способы.
кстати, кто именно?
Наш технический директор задал вопрос, оставляем дежурного или отменяем, команды решили что можно отменить, т.к. метрики стабилизировались и по внутренним ощущениям разработчиков все стало лучше.
Зачем было отменять дежурного, если вы знали, что что-то ухудшится обратно?
Пока дежурный дежурит, он не пишет фичи, за которые нам платят клиенты и фактически выпадает из команды. Ну и как я уже говорил нет людей, которые готовы все свое рабочее время посвятить этой работе.
Есть великая разница в осознании факта проблемы...
Может мы действительно не осознали самой проблемы, а осознали пока только факт наличия проблемы. Но осознание этого — первый шаг на пути к решению проблемы.
На PBR-е в задаче уже написано что должно быть покрыто автотестами и разработчики знают что нужно покрывать они учитывают это в объеме задачи когда затягивают к себе в бэклог
Для этого нужен QA в команде, который будет увеличивать разносторонность тестирования и смотреть свежим взглядом на фичу, используя свои знания из области тестирования и знание продукта
Вот с этим пока беда. По сути никто. Поэтому сейчас есть дублирование функций, разные подходы в разных местах. Но мы идем к тому, чтобы QA комьюнити забрало себе владение этим фреймворком и его развитие.
Мне прям понравилась аналогия с бургерами. Аналогия с пиццей была бы еще лучше)
QA инженеры пошли в команды разработки, чтобы в рамках конкретной команды смотреть как жарятся котлетки, помогать командам жарить эти котлетки и проверять качество этих котлеток до упаковки.
Разработчики пишут автотесты, но на какие сценарии писать подсказывает QA инженер. И зачастую тестирует тоже QA инженер, но иногда могут потестировать разработчики. Но от QA инженера есть сценарии как это нужно тестировать.
Что касается игнора тестов, я тут тоже согласен с вами, нельзя игнорить тест, если он не проходит по какой-то причине, нужно разобраться и починить эту проблему.
Да, про образование прям в точку. У меня в универе даже намека на тестирование и обеспечение качества не было. Зато я умею с 3-мя cms-ками разным работать. Как тебе такое Илон Маск?)
А можете подробнее раскрыть какие подходы SDLC мы нарушили?
QA инженеры составляют приемочные критерии к каждой задаче вместе с Владельцем продукта и с разработчиками. Затем QA инженеры в командах берут конкретные задачи смотрят на эти приемочные критерии и составляют тест-кейсы для фичи и отмечают какие кейсы должны быть автоматизированы.
Я неправильно выразился. Регрессионное тестирование не тормозит релизы само по себе. Я имел в виду, что регрессионное тестирование было бутылочным горлышком нашего релизного цикла.
Про релизный менеджмент почитаю, если кинете в меня толковой книгой буду благодарен.
И вы не очень поняли зачем делается код фриз
Можете рассказать зачем?
Блог Сергея недавно открыл для себя, потихоньку изучаю.
Да, мы отменяли дежурного с осознанием, что придется его вернуть снова. То что мы решаем проблему каким-то способом есть показатель что мы ее осознали.
Что вы имеете в виду под «награждать»?
Да, изначально были люди с этой компетенцией и они написали существующий набор автотестов. Потом один человек уволился, остальные пошли заниматься кто продуктовым менеджментом, кто разработкой, а кто скрам мастерством.
Да, спасибо за советы, они на самом деле полезные. Цель прочитал не так давно и сейчас осознаю, что когда регрессионное тестирование тормозило релизы, мы пользовались этими знаниями, чтобы ускорить наши релизы. Например, освободили тестировщиков от любой работы не связанной с тестированием релизов, ввели правило Stop The Line когда разработчики не могли создавать новые задачи, чтобы не копить очередь. У нас об этом есть статья.
А что касается грамотного QA, если поделитесь контактами, будет очень здорово. Мы бы с удовольствием его наняли. А пока приходится через боль и страдания проходить по всем граблям.
Вы правы, если отвечают все — не отвечает никто. Мы с первого раза это осознали. Проблема в том, что починка пайплайна, его стабилизация и ускорение, не очень интересная работа, мы не нашли добровольцев, которые готовы были на 100% своего времени погрузиться в эту работу. Поэтому решили пока закрывать проблему дежурствами по необходимости. В крупных компаниях есть релизные команды, куда входят и QA инженеры. Цель этих команд катить релизы и улучшать эти процессы. Но мы пока либо не доросли до этого, либо у нас особый путь)
Все верно, в стандарте есть такое определение качества. Мое определение из книги “Total quality cintrol”, которое мне запомнилось и как мне кажется отражает суть качества. Как я писал, стандарт отличается от реальной жизни. В стандартах нет тестировщиков, а в жизни есть, так же и тут. Продукта без пользователей не существует. И фактически качество продукта определяют они, а не ТЗ. Другой вопрос кто за это отвечает и что с этим делать.
Можешь раскрыть немного почему ты считаешь что «QA-инженеры участвуют на самых ранних этапах создания продукта/фичи…»
это валидация и верификация?
Да, все что вы написали входит в задачу QA. У меня нет опыта работы в разных компаниях и если в компаниях есть люди, которые занимаются исключительно процессами обеспечения качества, то это круто (наверное). Но мне кажется это далеко не во всех компаниях, поэтому я и призываю самим становиться QA и улучшать процессы и влиять на качество.
Сопровождаемость это хорошо, но кривая стоимости изменений справедлива и для самого сопровождаемого продукта. Давайте представим продукт с хорошей сопровождаемостью и 2 ситуации:
1. мы нашли “багу” на PBR или в ТЗ.
Чтобы ее пофиксить владелец продукта или кто-либо вносит правку в приемочные критерии или доку. Баг пофикшен.
2. Нашли багу на проде.
Прилетел тикет на первую линию. Первая линия не разобралась в чем подвох, отдала на вторую. Вторая линия выяснила что это бага и сделала задачу на фикс. Владелец продукта увидел эту задачу, поставил ей приоритет. Разработчик затянул задачу, пошел читать код и править её. Сделал, отдал на тестирование. Тестировщик так же погрузился в контекст, затем протестировал задачу. Дальше отправляем задачу релиз-инженеру, который катит это на прод.
Вторая ситуация куда более затратная чем первая. Именно эти затраты и отражает эта кривая.
Спасибо, в целом у тебя получился неплохой краткий пересказ моей статьи)
Действительно, если убрать мои рассуждения и примеры подкрепляющие их то в сухом остатке будут эти тезисы, я бы еще к ним добавил тезис
6) если видишь в вакансии смесь QA и QC — возможно в компании не различают эти понятия, будь осторожен.
С того момента у нас вышло 2 QA инженера, поэтому отношение изменилось)
Плюс открыты 3 вакансии и когда мы всех наймем опять ситуация будет другая.
Может быть. Но Генри Форд жил давно, когда не было компьютеров и индустрии разработки ПО. Приведу абзац текста из книги Continuous Integration: Improving Software Quality and Reducing Risk
Авторы считают, что нужно привлекать разработчиков к написанию тестов.
Мы успевали его делать, но делали это дольше, чем хотелось бизнесу. Точнее так, весь процесс доставки фичи занимал много времени, а бизнес всегда хочет доставить фичу как можно быстрее (при прочих равных)
Давление есть, но это здоровое давление, от которого никуда не деться. Оно больше исходит от необходимости бизнеса развиваться, расти, успевать или обгонять конкурентов.
Если из моей статьи вы сделали вывод, что наших разработчиков не интересует качество продукта, значит я что-то упустил или криво сформулировал (shame on me), потому что наши разработчики заинтересованы в качестве продукта.
Любое дежурство по природе является повинностью.
Награждение не сделает работу менее скучной и не интересной. Но вы правы, эта работа важная и нужная и делать ее кто-то должен. И обеспечить ее выполнение мы можем это несколькими способами. Или вводить отдельную команду или вводить дежурство. Может есть еще какие-то способы.
Наш технический директор задал вопрос, оставляем дежурного или отменяем, команды решили что можно отменить, т.к. метрики стабилизировались и по внутренним ощущениям разработчиков все стало лучше.
Пока дежурный дежурит, он не пишет фичи, за которые нам платят клиенты и фактически выпадает из команды. Ну и как я уже говорил нет людей, которые готовы все свое рабочее время посвятить этой работе.
Может мы действительно не осознали самой проблемы, а осознали пока только факт наличия проблемы. Но осознание этого — первый шаг на пути к решению проблемы.
QA инженеры пошли в команды разработки, чтобы в рамках конкретной команды смотреть как жарятся котлетки, помогать командам жарить эти котлетки и проверять качество этих котлеток до упаковки.
Разработчики пишут автотесты, но на какие сценарии писать подсказывает QA инженер. И зачастую тестирует тоже QA инженер, но иногда могут потестировать разработчики. Но от QA инженера есть сценарии как это нужно тестировать.
Что касается игнора тестов, я тут тоже согласен с вами, нельзя игнорить тест, если он не проходит по какой-то причине, нужно разобраться и починить эту проблему.
А можете подробнее раскрыть какие подходы SDLC мы нарушили?
Про релизный менеджмент почитаю, если кинете в меня толковой книгой буду благодарен.
Можете рассказать зачем?
Блог Сергея недавно открыл для себя, потихоньку изучаю.
Что вы имеете в виду под «награждать»?
А что касается грамотного QA, если поделитесь контактами, будет очень здорово. Мы бы с удовольствием его наняли. А пока приходится через боль и страдания проходить по всем граблям.
Можешь раскрыть немного почему ты считаешь что «QA-инженеры участвуют на самых ранних этапах создания продукта/фичи…»
это валидация и верификация?
Да, все что вы написали входит в задачу QA. У меня нет опыта работы в разных компаниях и если в компаниях есть люди, которые занимаются исключительно процессами обеспечения качества, то это круто (наверное). Но мне кажется это далеко не во всех компаниях, поэтому я и призываю самим становиться QA и улучшать процессы и влиять на качество.
Сопровождаемость это хорошо, но кривая стоимости изменений справедлива и для самого сопровождаемого продукта. Давайте представим продукт с хорошей сопровождаемостью и 2 ситуации:
1. мы нашли “багу” на PBR или в ТЗ.
Чтобы ее пофиксить владелец продукта или кто-либо вносит правку в приемочные критерии или доку. Баг пофикшен.
2. Нашли багу на проде.
Прилетел тикет на первую линию. Первая линия не разобралась в чем подвох, отдала на вторую. Вторая линия выяснила что это бага и сделала задачу на фикс. Владелец продукта увидел эту задачу, поставил ей приоритет. Разработчик затянул задачу, пошел читать код и править её. Сделал, отдал на тестирование. Тестировщик так же погрузился в контекст, затем протестировал задачу. Дальше отправляем задачу релиз-инженеру, который катит это на прод.
Вторая ситуация куда более затратная чем первая. Именно эти затраты и отражает эта кривая.
Действительно, если убрать мои рассуждения и примеры подкрепляющие их то в сухом остатке будут эти тезисы, я бы еще к ним добавил тезис
6) если видишь в вакансии смесь QA и QC — возможно в компании не различают эти понятия, будь осторожен.