Случалось ли вам сталкиваться с такой ситуацией: проект существует уже десятки лет и все процессы на нем хорошо отлажены. Однако в определенный момент приходит новый заказчик и требует начать все с чистого листа. Если вам это не только знакомо, но и, вспоминая о таких историях, вы покрываетесь потом, а пальцы начинают от дрожи промахиваться по клавиатуре – вы пришли по адресу. Александр Полещук, QA Lead с большим опытом работы на крупных международных проектах, знает, как избежать подобных мучительных воспоминаний и построить процессы на существующем проекте с максимальной эффективностью. Все тонкости и хитрости будут также полезны при построении процессов на абсолютно новом проекте, когда зачастую многие не знают с чего начать.
Для того чтобы не наступать на грабли, на которые наступали уже другие, Александр советует следовать пяти основным правилам:
- Простота. Простота – это залог успеха. Начните работу с самых простых задач. Не пытайтесь все выполнить от «А» до «Я» и постоянно повторять «подождите-подождите, еще пару месяцев и все заработает». Начните с того, что даст результат уже сегодня. Возможно, этот результат будет не самый эффективный, но зато ваш процесс начнет работать.
- Документация workflow. Рабочие процессы нужно документировать как разработчикам, так и тестировщикам. Очень важно, чтобы на проекте велась документация и к ней всегда можно было бы обратиться. О том, как правильно составлять документацию, вы узнаете далее в статье.
- “How—To” статьи. Не менее важно также создавать и “how-to” статьи, содержащие информацию об особенностях работы проекта, настройках тестовых окружений и всего того, что может понадобиться не только конкретно вам, но и человеку, у которого возникнет подобный же вопрос. Бонус таких статей в том, что вам не придется лишний раз устно объяснять одно и то же или ждать пока Петя-Вася вернется с больничного. При необходимости можно просто дать человеку ссылку на соответствующую “how-to” статью.
- Создавайте тренинг-сессии. И записывайте все, что говорится в рамках этих сессий. Такая запись помогает избежать пересказывания одной и той же информации, а также снижает риск отсутствия ключевого сотрудника на проекте. Записи тренингов должны храниться в общедоступной для проекта папке.
- Открытые “To Do” списки. Создание открытых списков с перечислением существующих задач – очень полезная практика. Представьте себе такую ситуацию: типичный разговор на scrum-митинге о необходимости завести баг («вот, Миша заведет минут через 15»). А Мишу отвлекли на что-то более серьезное («scrum-митинг все-таки»). В итоге, про баг этот так и забыли («вроде и заводили, а вроде и нет»). Однако, если бы был открытый “to do” список, такой ситуации попросту не возникло бы. Даже если у кого-то не получилось сделать свое задание, его выполнит другой участник команды, увидев статус “incomplete” в списке.
Теперь поговорим про документацию рабочих процессов — особую главу из истории построения процессов на любом проекте. Для того чтобы документация действительно способствовала эффективности, необходимо также учесть различные тонкие нюансы. В частности, нужно соблюдать баланс между двумя радикальными случаями: излишняя бюрократизация и отсутствие документации как таковой. Среди основных моментов, которые нужно документировать, Александр перечисляет:
- How—To Page. «How-To Page» можно воспринимать как мини-википедию проекта. Здесь можно документировать различные специфические вещи, относящиеся сугубо к вашему проекту, будь то настройка почты, установка сертификатов или контактные данные участников команды. В результате, вам опять-таки не придется лишний раз устно пересказывать информацию.
- QA Testing Process. Очень важно задокументировать хотя бы базовые аспекты процесса. Например, формирование циклов тестирования, процесс приемочного тестирования и списки регрессии.
- Workflow Definitions. Очень полезно будет описать процесс для разработчиков и тестировщиков, а также при каких условиях конкретный элемент процесса должен переходить из одного состояния в другое.
- Issue Creation Process и Test Case Writing Standards. Тестировщики могут совершенно по-разному описывать и баги, и тесткейсы, поэтому для удобства работы лучше всем предоставить единые стандарты и правила.
- Production Testing Information. Тестовая и «продакшн» информация вам будет нужна всегда, поэтому она должна быть общедоступна.
- Regression Testing List. Задокументированная регрессия будет очень полезна новичкам. Ведь, обычно, новые на проекте тестировщики и начинают с регрессии – так называемого, «безболезненного тестирования».
Построение процесса в формате вышеописанного подхода позволит создать легковесный и, в то же время, приемлемо документированный процесс. Такой процесс будет обладать хорошим уровнем гибкости, а это очень важно для Agile методологии, являющейся трендом в наше время. Также, такой процесс позволяет легко вливаться в команду даже Junior-специалистам.
В аудио-видео формате доклад можно посмотреть по соответствующим ссылкам:
- в формате блиц-доклада на SQA-Days 18:https://vimeo.com/151221033
- в расширенной версии на конференции COMAQA:http://www.youtube.com/watch?v=vpXaZbSs4QQ&t=2h29m12s
