Представьте, что вы из большой компании впервые пришли на проект единственным тестировщиком и ещё с трудом представляете, что именно вас ждёт. В этой статье хочу затронуть некоторые нюансы организации тестирования в небольшой команде.
Дисклеймер
Статья нацелена, в основном, на не очень опытных тестировщиков, которые решили перейти из большой продуктовой компании с устоявшимися регламентами, в дружную компанию-семью на небольшой проект.
Я сам не считаю себя профессионалом невероятного уровня, мой опыт в QA - 4 года. Но за это время я успел заняться организацией процессов тестирования в двух небольших компаниях и очень хотел бы поделиться своими размышлениями на этот счет.
Перестройка мышления
В большом количестве статей можно прочитать, что первым этапом организации тестирования является "Планирование", но я бы выделил перед ним ещё один, специально для людей, которые попали в такую ситуацию впервые. Прежде всего нужно изменить свой mindset.
Да, вы были достаточно успешным тестировщиком на большом проекте, находили много багов, возможно даже руководили небольшой командой. Всё это отлично! Но... все эти достижения стоят на прочной основе работы других людей, которые занимались глобальной организацией процесса: продумали флоу разработки, при котором вам комфортно тестировать, организовали доставку фич на тестовый стенд, обучили разработчиков взаимодействовать с тестированием. Эти люди продумали и прописали в регламентах ваши действия почти на любой случай.
Больше всего этого у вас нет. Вы сами себе тест-менеджер, тест-аналитик, администратор разработки и руководитель отдела тестирования. Теперь пул ваших обязанностей никак не определён, вы занимаетесь примерно всем, что на ваш взгляд может повлиять на качество конечного продукта.
Вы лезете во все процессы компании, разбираетесь от и до, чем живёт бизнес, а чем разработка. Администрирование джиры? Да это ваша задача, если хотите добиться прозрачности разработки. Организация работы с тестовыми стендами? Тоже ваше, наслаждайтесь, потому что разработчики готовы хоть сейчас лить фичи на прод. Помощь разработчикам в организации работы с ветками? Помощь бизнесу в подборе оптимальных сторонних сервисов? Разбор покрытия юнит-тестами? Всё для вас!
Для всего этого вам придется определить приоритеты и начать с этим работать.
А вот теперь планирование
Как и отмечается в любой статье на эту тему - критический этап. Много где процесс описан подробно, но тут тоже есть нюансы, которые в большинстве источников упоминают вскользь.
Вы ознакомились с проектом, вникли в процессы и даже накидали примерный план того, что и как вы будете тестировать. Вы начинаете это реализовывать и... не работает. Фичи путаются, никто не понимает, что и в какой момент находится на тестовом стенде, задачи проскакивают на продакшен без тестирования и возникают ошибки. Что же ускользнуло от нашего взгляда?
Сначала организация разработки
По факту, это один из самых важных шагов. Насколько бы не был ваш процесс тестирования крутым и идеально выверенным - в этом нет никакого смысла, если процесс разработки не готов для работы с тестированием. Иными словами, как вы собираетесь строить дом на просевшем и непрочном фундаменте?
Самое главное, что нужно понять: чаще всего перекраивать процесс разработки не нужно никому кроме вас.
Разработчики сосредоточены на написании кода, они не испытывают никаких тёплых чувств от мысли, что нужно будет что-то менять в рабочем процессе.
Бизнес, в лучшем случае, заинтересован в уменьшении количества багов, НО не готов тратить на разработку больше времени. Поэтому внедрение новшеств в разработку часто расценивается просто как внесение лишнего хаоса в процесс и затягивание доставки фичи клиенту.
Из этого следует, что главная задача "продать" нашу схему бизнесу и как-то убедить разработчиков не саботировать её внедрение. Конкретные способы решения этой проблемы и подходы к этому процессу заслуживают отдельного обсуждения.
Отключение перфекционизма
В процессе планирования вы скорее всего где-то ошибетесь и плоды своей ошибки придется пожинать сильно позже, когда ваш грандиозный план начнёт претворяться в жизнь. Этого не нужно бояться, вообще, изначально, не стоит строить слишком амбициозных планов на организацию работы проекта. Для этого вы не обладаете самой необходимой вещью - контекстом. Полноценное осознание того, чем живёт проект может прийти сильно позже в процессе работы.
Основная мысль здесь в том, что нужно постараться построить "скелет" процесса, на который позже мы сможем наслаивать новые улучшения.
Тестовая документация
Тут в целом всё однозначно, вам нужно составлять такую документацию, которая будет давать максимум пользы с минимальными затратами на поддержку (обязанностей много, а вы один, помните?). Так что, в данном случае, для меня выбор однозначный - чек-листы. И опять же некоторые нюансы:
Пишите документацию с возможностью расширения.
Сейчас у вас немного времени, а позже могут появиться другие тестировщики, проект разрастётся и/или вы задумаетесь об автоматизации тестирования, ваша документация должна быть готова это пережить.Приучайте разработчиков обращаться к тестовой документации за уточнениями.
Это сэкономит время всем и поднимет общее понимание работы системы в команде, что уже ощутимо снижает риск ошибок в логике.Рисуйте схемы, крепите ссылки к тест-комплектам.
Картинка со схемой авторизации на сайте будет гораздо эффективней в перспективе, чем описание 40 тестов текстом. Я не говорю, что надо рисовать схемы вместо тестов, но разработчику гораздо проще будет посмотреть на схему, чем читать полотно проверок написанных на "QAшном языке".
Борьба с собой
Итак, мы разобрались с самыми важными, на мой взгляд, нюансами, на которых может споткнуться QA даже прочитав десяток статей по организации процесса тестирования. А теперь затронем мысли, которые появляются у самих QA, и которые нужно гнать прочь из своей головы.
Сделаю всё как на прошлом проекте
Очень соблазнительная идея прийти на новый проект и устроить всё так же как было у вас на предыдущем проекте. Это ловушка! Неосознанная попытка сменить место работы и остаться в своей зоне комфорта. С очень большой долей вероятности схема, которая работала в старой компании будет очень плохо работать в новой. Каждый проект индивидуален и требует такого же индивидуального подхода в организации процессов.
Люди работают тут давно, они знают как лучше
Скорее как раз наоборот! Вы как тестировщик хорошо должны быть знакомы с эффектом "замыленного глаза". Чем дольше люди работают по конкретному процессу, тем сложнее им увидеть его недостатки. Понимая этот момент можно довольно успешно отстоять свои нововведения, указав на слабые места текущего процесса.
Что нового я могу рассказать людям с таким опытом
Очень и очень многое! Даже разработчик с 15 летним стажем может почти не задумываться об организации непосредственно процесса разработки, а уж тем более тестирования. Бизнес, который нанял вас единственным QA на проект, так же, вероятно, очень смутно представляет в чём заключаются эти процессы. Да, у вас может быть не так много опыта в своей сфере, но в QA вы должны разбираться определённо лучше чем разработчик и менеджер!
Я знаю как лучше, а они меня не слушают
Проблема противоположная предыдущим. Я - Д'Артаньян! Одно слово - терпение. Нельзя прийти на проект и сразу стать для коллег признанным экспертом в сфере обеспечения качества. Слово "признанный" как раз и подразумевает путь который ты проходишь от какого-то случайно зашедшего на огонек новичка, до серьезного специалиста с определённым уровнем экспертности.
Ни одна хоть сколько-то адекватная компания не будет, по желанию только что нанятого сотрудника, перекраивать свои рабочие процессы. И будет права! Любое ваше слово должно быть подкреплено не только абстрактными аргументами, но и реальными кейсами из работы этой самой компании. Что-то вроде: "Произошла вот такая ситуация, а ещё я нашёл в чате несколько похожих случаев в прошлом, что бы избежать такого в дальнейшем предлагаю сделать вот так".
Ваша роль в этом вопросе на первых парах, да и вообще, больше консультативная. Вы в любом случае не сможете навязать бизнесу подход, которого он не хочет. Здесь основная задача - обозначить проблему и предоставить вариант, а лучше несколько вариантов, её решения.
Я один против всех, "всё тлен"
Не отчаивайтесь! Если разобраться, то всё не так плохо:
Цель разработчика быстро разрабатывать фичи, как можно реже переключаться из одного контекста в другой, чтобы править ошибки. И вообще работать в комфорте и спокойствии.
Бизнес хочет уменьшить количество ошибок в выпускаемых фичах и получить максимально хороший фидбек деньгами и отзывами от своих клиентов. А главное достичь этих целей с наименьшим вложением собственных денег!
QA нацелен на то, чтобы максимально уменьшить количество ошибок попадающих к клиенту и, для соблюдения первой цели, обеспечить понятность и прозрачность процессов разработки.
Из этого следует очень простой вывод: разработка и бизнес - ваши союзники, даже если они сами этого ещё не понимают. И одна из ваших целей как раз и состоит в том, чтобы донести до них эту информацию и научить их понимать друг друга.
Итог
Организация тестирования в небольших проектах - очень увлекательный и интересный вызов. Вот некоторые вещи, которые я хотел донести этой статьей:
Ваши задачи и место в процессах большого и маленького бизнеса сильно отличаются.
Понимание этого самого места играет определяющую роль в качестве организации процессов.
Время - это ваш самый ценный ресурс, в маленькой команде вам часто придётся концентрироваться на более общих вещах.
Организация тестирования - сложный процесс, на старте нужно, на время, отключить перфекционизм и нацелиться на получение первого результата.
Все участники процесса заинтересованы в выпуске качественного продукта, но по разным причинам, ваша задача - стать связующим звеном в этом процессе.
Понимаю, что тема довольно абстрактная и мнений тут может быть бесконечное множество. Я выделил здесь именно те моменты, на которых сам набивал шишки, либо был непосредственно знаком с людьми, которые их набивали. Буду очень рад пообщаться на этот счет в комментариях!
