Как успешно и эффективно строить новые процессы тестирования?

Как успешно и эффективно строить новые процессы тестирования?

Случалось ли вам сталкиваться с такой ситуацией: проект существует уже десятки лет и все процессы на нем хорошо отлажены. Однако в определенный момент приходит новый заказчик и требует начать все с чистого листа. Если вам это не только знакомо, но и, вспоминая о таких историях, вы покрываетесь потом, а пальцы начинают от дрожи промахиваться по клавиатуре – вы пришли по адресу. Александр Полещук, QA Lead с большим опытом работы на крупных международных проектах, знает, как избежать подобных мучительных воспоминаний и построить процессы на существующем проекте с максимальной эффективностью. Все тонкости и хитрости будут также полезны при построении процессов на абсолютно новом проекте, когда зачастую многие не знают с чего начать.

Для того чтобы не наступать на грабли, на которые наступали уже другие, Александр советует следовать пяти основным правилам:

  • Простота. Простота – это залог успеха. Начните работу с самых простых задач. Не пытайтесь все выполнить от «А» до «Я» и постоянно повторять «подождите-подождите, еще пару месяцев и все заработает». Начните с того, что даст результат уже сегодня. Возможно, этот результат будет не самый эффективный, но зато ваш процесс начнет работать.
  • Документация workflow. Рабочие процессы нужно документировать как разработчикам, так и тестировщикам. Очень важно, чтобы на проекте велась документация и к ней всегда можно было бы обратиться. О том, как правильно составлять документацию, вы узнаете далее в статье.
  • HowTo” статьи. Не менее важно также создавать и “how-to” статьи, содержащие информацию об особенностях работы проекта, настройках тестовых окружений и всего того, что может понадобиться не только конкретно вам, но и человеку, у которого возникнет подобный же вопрос. Бонус таких статей в том, что вам не придется лишний раз устно объяснять одно и то же или ждать пока Петя-Вася вернется с больничного. При необходимости можно просто дать человеку ссылку на соответствующую “how-to” статью.
  • Создавайте тренинг-сессии. И записывайте все, что говорится в рамках этих сессий. Такая запись помогает избежать пересказывания одной и той же информации, а также снижает риск отсутствия ключевого сотрудника на проекте. Записи тренингов должны храниться в общедоступной для проекта папке.
  • Открытые “To Do” списки. Создание открытых списков с перечислением существующих задач – очень полезная практика. Представьте себе такую ситуацию: типичный разговор на scrum-митинге о необходимости завести баг («вот, Миша заведет минут через 15»). А Мишу отвлекли на что-то более серьезное («scrum-митинг все-таки»). В итоге, про баг этот так и забыли («вроде и заводили, а вроде и нет»). Однако, если бы был открытый “to do” список, такой ситуации попросту не возникло бы. Даже если у кого-то не получилось сделать свое задание, его выполнит другой участник команды, увидев статус “incomplete” в списке.

Теперь поговорим про документацию рабочих процессов — особую главу из истории построения процессов на любом проекте. Для того чтобы документация действительно способствовала эффективности, необходимо также учесть различные тонкие нюансы. В частности, нужно соблюдать баланс между двумя радикальными случаями: излишняя бюрократизация и отсутствие документации как таковой. Среди основных моментов, которые нужно документировать, Александр перечисляет:

  • HowTo Page. «How-To Page» можно воспринимать как мини-википедию проекта. Здесь можно документировать различные специфические вещи, относящиеся сугубо к вашему проекту, будь то настройка почты, установка сертификатов или контактные данные участников команды. В результате, вам опять-таки не придется лишний раз устно пересказывать информацию.
  • QA Testing Process. Очень важно задокументировать хотя бы базовые аспекты процесса. Например, формирование циклов тестирования, процесс приемочного тестирования и списки регрессии.
  • Workflow Definitions. Очень полезно будет описать процесс для разработчиков и тестировщиков, а также при каких условиях конкретный элемент процесса должен переходить из одного состояния в другое.
  • Issue Creation Process и Test Case Writing Standards. Тестировщики могут совершенно по-разному описывать и баги, и тесткейсы, поэтому для удобства работы лучше всем предоставить единые стандарты и правила.
  • Production Testing Information. Тестовая и «продакшн» информация вам будет нужна всегда, поэтому она должна быть общедоступна.
  • Regression Testing List. Задокументированная регрессия будет очень полезна новичкам. Ведь, обычно, новые на проекте тестировщики и начинают с регрессии – так называемого, «безболезненного тестирования».

Построение процесса в формате вышеописанного подхода позволит создать легковесный и, в то же время, приемлемо документированный процесс. Такой процесс будет обладать хорошим уровнем гибкости, а это очень важно для Agile методологии, являющейся трендом в наше время. Также, такой процесс позволяет легко вливаться в команду даже Junior-специалистам.

В аудио-видео формате доклад можно посмотреть по соответствующим ссылкам:

 

 
 
система комментирования CACKLE
Go to Top