Как обеспечить качество на скорости
Изменение гарантии качества на качественную помощь
Трудно адаптировать традиционные методы тестирования к agile культуре. Команды иногда чувствуют себя вынужденными обменять качество своего продукта на скорость предоставления (поставки).
Для борьбы с этими проблемами команды Atlassian предложили другой подход к agile тестированию, известный как Quality Assistance (качественная помощь). Вместо того чтобы создавать отдельную команду тестирования, отвечающую за качество, небольшая группа инженеров по оказанию помощи в области качества занимается евангелизацией и обучением методам устойчивого тестирования в группе разработчиков. Узнайте больше об этой трансформации и как:
- Создать культуру качества.
- Возложить ответственность за тестирование на разработчиков.
- Предотвращать баги, а не выявляйть их.
Вопросы и ответы
Прочтите раздел «Вопросы и ответы» из этой презентации, чтобы узнать больше о том, как команда из 65 инженеров создает и быстро поставляет высококачественный продукт, используя только шесть инженеров обеспечения качества (QA).
Вопрос 1: Сколько времени нужно, чтобы разработчик освоил этот тип мышления?
Ответ 1: Труднее изменить культуру всей команды, чем трансформировать людей. Нам потребовалось пять лет, чтобы вывести команду Jira Software на качественный уровень мышления, который у нее есть сегодня, но каждому новому разработчику не требуется много времени, чтобы освоиться. Они быстро улавливают мышление у своих коллег-разработчиков, и вскоре они приобретают навыки тестирования с помощью сопряжения и семинаров. Самое сложное - собрать все знания о рисках и продукте. Это может занять годы, но мы смягчаем это путем обмена знаниями в рамках презентаций обеспечения качества (QA) и демонстраций обеспечения качества (QA).
Вопрос 2: По-прежнему ли нужны тестовые случаи, только для регрессионного / автоматического тестирования?
Ответ 2: Сценарии с ручным тестированием вообще не входят в нашу стратегию. Если тест является просто «проверкой», то есть набором заранее определенных шагов и определенного утверждения, мы считаем, что он более эффективен и менее подвержен ошибкам, если он выполняется компьютером, а не человеком. Если тест действительно является тестом, требующим критического мышления, свободы расследования и оценки риска, мы считаем, что лучше выполнить его как часть предварительного тестирования, чтобы включить эту свободу и интеллект в тестирование.
Вопрос 3: Разработчики, как правило, стоят дороже, чем тестеровщики. Если мы используем разработчиков в качестве тестеровщиков, не является ли это неэффективным использованием бюджета / рабочей силы?
Ответ 3: Безусловно, использование разработчиков в качестве тестеровщиков для выполнения отдельного этапа тестирования является дорогостоящим и растратой времени разработчика. Но проведение отдельного этапа тестирования - даже одного, выполняемого тестировщиками - стоит дорого и тратит время разработчика. Каждый раз, когда история или баг передаются от тестировщиков разработчикам, это не просто затраты на тестирование, это затраты разработчика. Снизив коэффициент отклонения со 100% до 4%, мы сэкономили много времени на разработку, которое было потрачено на переработку историй и исправление глупых багов перед выпуском релиза. Мы сэкономили время, затрачиваемое на расследование, составление отчетов, сортировку, оценку, воспроизведение и исправление внутренних багов. А код разработан с нуля в более тестируемом виде, потому что разработчики знают, что именно им придется проводить тестирование. Наша стадия DoTing (разработчик на тестировании) была промежуточным этапом на пути повышения качества, так что мы могли полностью исключить отдельный этап тестирования. Это была временная инвестиция, которая более чем окупилась.
Вопрос 4: У нас есть разработчики и тестировщики обеспечения качества в разных часовых поясах. Будет ли эта модель работать только в одном часовом поясе? Как вы работаете с удаленными командами?
Ответ 4: Мы оказали удаленную помощь по качеству с командами в Польше и Вьетнаме, с инженером обеспечения качества (QA), базирующимся в Австралии. Это не так эффективно, при наличии квалифицированного обеспечения качества на месте, так как большая часть хорошего инженера по оказанию помощи в качестве выстраивает личные отношения с вашими разработчиками. Удаленного инженера по обеспечению качества легко вырубить из цикла, и гораздо сложнее оценить общую культуру команды. Тем не менее, мы смогли успешно запустить удаленные демонстрации обеспечения качества (QA), запуск QA и сеансы сопряжения с помощью видеозвонков - просто позвонив напрямую с компьютера разработчика на QA и предоставив общий доступ к экрану.
Вопрос 5: Являются ли заметки QA индивидуальными для каждой истории или вы строите базу знаний о заметках QA? Как вы справляетесь с повторяющимися рисками?
Ответ 5: Заметки о контроле качества основаны на истории на историю, поэтому обычно инженеры по обеспечению качества выявляют закономерности повторяющихся рисков. Это стало сложнее с годами, так как наша команда Jira Software QA (по обеспечению качества) выросла, так как каждый инженер по обеспечению качества QA не обязательно знает то, что знают другие. До сих пор мы смягчали это с помощью еженедельных встреч по обмену знаниями и вики-страниц, на которых мы отслеживаем общие или неожиданные риски. Мы приближаемся к точке, когда это больше не масштабируется. Прямо сейчас мы работаем над более структурированной базой знаний с базой данных правил, которые выполняются для каждого коммита (фиксации кода). Так, например, если он обнаружит, что вы используете объект User в своем коде Jira Software, он добавит комментарий к задаче: «Объект User может быть нулевым, если текущий пользователь является анонимным, пожалуйста, убедитесь, что вы обработали (справились с этим) это правильно ». Это поможет нам получить знания о руководящих принципах обеспечения качества QA и, в лучшем случае, может даже заменить необходимость в демонстрационных тестах и стартовых примерах. Это было бы так полезно!
По материалам Agile Coach "Qa at speed"