Как ускорить процесс контроля качества

Обеспечение качества: содействие вместо контроля

Laura Daly Laura Daly
Просмотр тем

Приспособить традиционные методы тестирования к agile-культуре нелегко. Командам кажется, что они должны пожертвовать качеством их продукта ради быстрой поставки.

Чтобы справиться с этой проблемой, команды компании Atlassian изобрели новый подход к agile-тестированию под названием «Содействие в обеспечении качества» (Quality Assistance). Чтобы не использовать отдельную команду тестировщиков, которая была бы ответственна за качество, небольшая команда специалистов по содействию в обеспечении качества агитирует за применение методов сбалансированного тестирования в команде разработчиков и обучает их этим методам. Просмотрите запись вебинара, чтобы узнать больше об этом преобразовании и о том, как:

  • сформировать культуру качества;
  • снова возложить на разработчиков ответственность за тестирование;
  • предотвращать баги, а не выявлять их.

Вопросы и ответы

Прочитайте вопросы, заданные в заключительной части этой презентации, и ответы на них, чтобы узнать больше о том, как команда из 65 специалистов создает и быстро поставляет высококачественный продукт, хотя тестированием занимаются всего лишь шесть человек.

Вопрос 1. Сколько разработчику нужно времени, чтобы освоить этот образ мышления?

Ответ 1. Преобразовать культуру всей команды сложнее чем привычки и подходы отдельных людей. Нам понадобилось пять лет, чтобы привить в менталитет команды, занимающейся Jira Software, установку на качество, которая у нее есть сейчас. Однако выработать такой образ мышления у каждого нового разработчика удается за более короткий промежуток времени. Новички быстро перенимают мысленный настрой у давно освоившихся коллег, а навыки тестирования приходят к ним через работу в паре и семинары. Сложнее всего усвоить все знания о рисках и продукте. На это могут уйти годы, но, чтобы ускорить процесс, мы поощряем обмен знаниями на собраниях по запуску тестирования и демонстрации проверенного кода.

Вопрос 2. Сохраняется ли при этом потребность в сценариях тестирования, или они нужны только для регрессионного/автоматического тестирования?

Ответ 2. Наша стратегия не предполагает какое-либо ручное тестирование по сценарию. Если тест — не более чем простая проверка, т. е. он представляет собой ряд заранее прописанных шагов и определенное утверждение, которое нужно проверить, то мы предпочитаем поручить его выполнение компьютеру, а не человеку. Компьютер более эффективен и менее склонен к ошибкам. Если тест действительно является тестом, т. е. тестировщик должен применять критическое мышление, самостоятельно выбирать направление своего анализа и оценивать риски, то мы предпочитаем проводить его в рамках глубокого тестирования. Оно дает необходимую свободу и предполагает осуществление определенной умственной деятельности.

Вопрос 3. Как правило, разработчики обходятся дороже тестировщиков. Если мы используем разработчиков в качестве тестировщиков, не будет ли это нерациональным расходованием бюджетных средств и (или) людских ресурсов?

Ответ 3. Действительно, использовать разработчиков в качестве тестировщиков для выполнения отдельного этапа тестирования накладно. Так использовать время разработчиков невыгодно. Но отводить под тестирование целый этап, даже если в нем участвуют тестировщики, в целом нерационально и дорого с точки зрения времени разработчиков. При каждой передаче пользовательской истории или бага от тестировщиков обратно разработчикам увеличиваются расходы как на тестирование, так и на разработку. Снизив долю отклонений со 100 % до 4 %, мы добились значительной экономии времени разработчиков, которое уходило на переработку историй и исправление необязательных багов перед релизом. Мы сэкономили время, которое тратилось на анализ причин, отправку сообщений, приоритизацию, оценку, воспроизведение и исправление багов, найденных тестировщиками. И написание кода с самого начала ведется так, чтобы упростить его тестирование, потому что разработчики знают, что им же и придется проводить тестирование. Мы встроили в нашу цепочку создания качественного продукта промежуточный этап DoTing («тестирование, выполняемое разработчиками»), чтобы не выделять под тестирование отдельный этап. Эта временная инвестиция окупилась сторицей.

Вопрос 4. У нас разработчики и тестировщики находятся в разных часовых поясах. Предложенная вами модель подходит только командам из одного часового пояса? Что вы предлагаете удаленным командам?

Ответ 4. Мы практиковали содействие в обеспечении качества удаленно: команды находились в Польше и Вьетнаме, а специалист по тестированию — в Австралии. Это не так эффективно, как когда опытный специалист по качеству присутствует в том же месте, что и остальная команда, физически, поскольку успех содействия в обеспечении качества в большой степени зависит от прочности личных связей между специалистом по тестированию и разработчиками. Удаленному специалисту по тестированию сложно постоянно держать руку на пульсе событий в проекте и еще сложнее перенять общую культуру команды. Тем не менее, нам удавалось успешно проводить удаленные демонстрации проверенного кода, собрания по запуску контроля качества и сеансы парной работы посредством видеосвязи. Разработчик просто звонил со своего устройства специалисту по тестированию и демонстрировал ему свой экран.

Вопрос 5. Составляют ли специалисты по качеству примечания к каждой отдельной пользовательской истории или вы выстраиваете базу знаний на основе этих примечаний? Что вы делаете с регулярно возникающими рисками?

Ответ 5. Специалисты по тестированию составляют примечания к каждой отдельной истории, поэтому именно они выявляют связь между повторяющимися рисками. С годами возникли сложности, поскольку наша команда по обеспечению качества Jira Software разрослась и знания ее участников не во всем сходятся. До сих пор мы устраняли несоответствие в знаниях при помощи еженедельных собраний по обмену знаниями и вики-страниц, в которые мы заносим типичные или необычные риски. Скоро мы окажемся в ситуации, когда это решение нельзя будет приспособить к размеру команды. Прямо сейчас мы работаем над более структурированной базой знаний, которая включала бы в себя базу правил, применяемых к каждому коммиту. Вот как мы хотим, чтобы эта система работала: если, например, она замечает, что разработчик использует объект User в коде Jira Software, она добавляет комментарий к задаче с таким содержанием: «Объект User может быть пустым, если текущий пользователь анонимен. Убедитесь, что вы правильно используете этот объект». Так мы сможем заставить специалистов по тестированию поделиться своими уникальными знаниями с другими; в идеале эта система избавит нас от необходимости проводить демонстрации проверенного кода и собраний по запуску контроля качества. Это бы нам очень пригодилось!

продолжение темы
Technical debt