Как выжить, если ты один QA на проекте. 10 советов
Буквально на днях случилась вторая годовщина моей работы в ELEKS и четвёртая в отрасли в целом, и я задумался, что на большинстве проектов я был единственным QA-инженером. Более того, в одном стартапе я подключился к проекту для крупного заказчика через два месяца после его начала, что сделало мою работу ещё более экстремальной.
И, глядя на рынок вакансий, думаю, что мой опыт окажется полезным суровым инженерам, которые не побоялись в одиночку броситься в этот шторм. Особенно, если они только начинают не лёгкий, но интересный путь QA.
Итак, выводы, к которым я пришёл.
Иллюстрация Алины Самолюк
1. Бюрократия — твой лучший друг
И сразу начну с не самого популярного утверждения: мало есть таких полезных категорий для QA, как бюрократия и процедуры. И дело не только в том, что их действительно придумывали не просто так, а устареть они не успели. Когда ты один QA, тебе надо не просто хорошо выполнить свою работу, но и не зашиться с ней.
И вот тут пригодятся те самые процедуры: ты берёшься за историю, только когда она на тебе и в нужном статусе, строго фиксируешь репортами любые отклонения от требований/дизайна. Даже если разработчик пишет: «Мы решили изменить этот момент», отвечаешь: «Внесите изменения в описание стори, тогда и прокомментируем».
Не бойся выглядеть занудным: всегда можно съехать на начальство (QA Lead, PM, PO), которое требует именно этого. И не переживай, ведь ни один девелопер не пойдёт выяснять, какого лешего QA выполняет свою работу. Фиксируй все блокеры, истории, которые ставишь на on hold.
Я лично знаю несколько QA, которые хотели построить максимально ламповое и неформальное общение с командой разработки. И когда начались проблемы, то виноватыми оказались именно они. Сложно объяснить руководству, что баги были обнаружены, пофикшены, но не вносились в систему. Хотя бы потому, что это не имеет смысла.
В предыдущей компании была другая ситуация: на параллельном проекте команда разрабатывала небольшую фичу и единственный QA вместе с девелопером решили не вносить большинство багов в документацию, а фиксить их с колёс. В результате продукт вышел более-менее качественным (благо, был не очень сложным и совсем небольшим). Но у руководства возникли сомнения насчёт необходимости QA на второй фазе, раз в первой разработчик сделал всё настолько классно.
И да, это совсем нелогично и неправильно, но было ли моему коллеге проще от осознания этих фактов, когда он искал себе другую работу? А хорошо ли жилось разработчику без QA на втором этапе? Не думаю.
Следование процедурам даст ещё кое-что: твоя пятая точка всегда будет прикрыта. На любой вопрос «почему это не сделано/не работает/работает не так?» у тебя будет ответ.
И ещё, полюби электронные письма. Ведь ничто так не мотивирует работать, как сообщение с описанием проблемы и списком адресов в копиях. Пусть даже эти адресаты ничего не понимают в описанной ситуации.
2. Постарайся понять, как это всё работает
Вот проект: три разработчика пару месяцев пишут код, нет никакой документации, а ты десантируешься прямо в эту горячую точку. Ситуацию приходится выруливать овертаймами и постоянным общением со стейкхолдерами. При этом особое внимание уделяешь тому, кто и за что отвечает и какие процедуры приняты.
Нужно получить любой доступный документооборот: от официальных requirements и approaches до электронных писем, где есть какие-то решения.
Главное — разобраться в том, что разработчики делали и каким образом. Как-то ведь они работали до того, как ты присоединился к проекту? Хорошо или плохо — не имеет значения, ведь решение работало по крайней мере для них: кто-то отвечал за постановку задач, кто-то за их реализацию, кто-то решал проблемы и принимал меры.
Понимание того, как организована работа, позволит быстрее вникнуть в ситуацию, понять границы ответственности на проекте.
А отсюда сделать выводы, что можно улучшить. И не только в разделе QA, но и в менеджерской части. Апгрейд положительно скажется на качестве работы команды, а отсюда и на продукте. А полученные навыки тебе когда-то пригодятся, особенно если решишь двигаться в сторону QA Lead. Но при решении вопросов не прыгай через голову. Вышестоящий в копиях появляется тогда, когда на своём уровне ситуация тормозится.
3. Разработчики — это твои лучшие друзья номер два
В отличие от проекта, где сформирована QA-команда, когда ты один, обратиться за помощью бывает не к кому. Потому с добродушной улыбкой начинай доставать коллег-разработчиков вопросами: «А как это работает? Как это можно протестировать? У тебя есть dummy data? А где ещё используется код, который в этой форме?».
Например, на моем первом проекте разработчики написали короткий функционал по заполнению текста ошибки, когда что-то идёт не так со стороны сервера, но подробного описания не было или оно было малоинформативным для пользователя. И прежде всего я стал задавать вопросы по тому, как это вообще протестировать. Девелопер стал показывать — и сразу вскрылся критический баг.
Мог ли я поступить иначе? Конечно. Протестировать сам, погуглить возможные варианты. Но так команда обнаружила серьёзный недочёт, а после исправила его.
Таким образом ты начнёшь погоню сразу за целым стадом зайцев и вопреки пословице домой вернёшься с трофеями.
4. Планируй, планируй и ещё раз планируй
Работу на день, на спринт, на определённые этапы проекта. Расставляй приоритеты! Чёткие цели позволят не только понимать, что делаешь и зачем, но и выкинуть из головы ненужную тревогу о том, что, например, надо бы не забыть retest бага № 160989 и подготовить test summary report к концу спринта.
Пользу приоритизации особенно оцениваешь, когда возникает подобная ситуация: последний девелоперский спринт, впереди стабилизация, у разработчика есть больше дюжины приоритетных багов, две незаконченных истории и несколько CR’ов от другого разработчика. Что делать в первую очередь? Если не уверен, посоветуйся с BA или PM и донеси решение до своего разработчика.
Что касается построения планов, то речь не только о традиционных методологиях планирования, где ты определяешь требования, оцениваешь риски, необходимые и доступные ресурсы и так далее. В первую очередь дело в самоорганизации и привычке писать планы на день. Отдельно отмечу тот приятный момент, когда вычёркиваешь из списка законченное дело.
А если при этом ещё следовать своим планам, то продуктивность взлетит до небес, что обязательно скажется на зарплате и снисходительном взгляде на отстающих бэкендщиков.
5. Ты — не единственный, от кого зависит качество продукта
Да, на тебе основная ноша, но ответственность за релиз продукта без багов лежит на всех, кто имел с ним дело. Старайся понемногу доносить эту мысль до остальных стейкхолдеров, постоянно напоминать и переспрашивать: «Что с unit-тестами?», «Макеты готовы?», «BA, новые требования описаны?», «Функционал проверен во время Acceptance testing?».
6. Пиши тест-кейсы
В TestLink или где-то ещё, это помогает заранее продумать, как тестировать фичу, дисциплинирует (а это важно, смотри пункт 4) и даёт возможность показать выполняемую работу.
И даже если никто и никогда в них не заглянет, когда покрываешь функционал тестами, ты облегчаешь себе работу во время регрессии.
7. Гугли!
Очевидный совет, который к месту при любом раскладе, независимо от того, один ты охотишься за «жуками» или с двумя отделениями тестировщиков. Ищи на «Хабре», software-testing.ru, в QA-дайджесте на DOU или просто в форме гугл-поиска — это всё пойдёт на пользу.
Даже если точно знаешь, как протестировать, например, форму ввода логина и пароля, погугли этот элементарный вопрос на досуге. И, может, обнаружишь сценарии, которые попросту в голову не приходили. А уж твоим разработчикам и подавно.
Помимо увеличения покрытия тестами функционала, будешь прокачивать тот самый experience based testing — неуловимый навык, который превращает человека из неопытного рекрута в сурового ветерана войн с инсектоидами.
8. Не будь перфекционистом
А когда ты один контролируешь качество, то задержка дедлайна — это последнее, что хочется видеть на своём проекте. Важно осознавать, что не все баги будут исправлены, а функции — доведены до совершенства. Воевать за них до последнего патрона — это портить отношения с коллегами и срывать сроки релиза.
Идеального продукта не существует. Хотя бы потому, что представления (а значит, требования) к этому идеалу у всех разные. Разработать же продукт под каждого отдельного пользователя — невозможная роскошь. То есть дело всегда в поиске компромисса.
Так же и с багами. Твоя задача — понять, что необходимо исправить в любом случае, а на что можно закрыть глаза. Отчасти в этом помогает правильная приоритизация ошибок и тест-план. С другой стороны, более тесное общение с BA и PO, а также твой личный опыт, пригодятся не меньше.
9. Заведи свою личную историю в бэклоге
Назови её, к примеру, BUGS и вноси туда все issues, которые находишь, но не можешь прицепить к текущим задачам. Это даст сразу целый букет бонусов. Во-первых, всегда сможешь объяснить любому стейкхолдеру, почему всё так сложно (если что-то пошло не так и стало сложно). Во-вторых, дать задачу разработчику, если он заскучал.
В-третьих, список обнаруженных, но неисправленных/нереализованных issues может стать хорошим прологом для продолжения проекта в следующей фазе. А за это будет благодарно уже руководство, что всегда положительно сказывается на платёжном балансе специалиста.
10. Получай удовольствие
В конце концов, далеко не каждый может похвастаться тем, что единолично выполняет роль всего отдела по контролю качества на целом проекте (!).
Когда-то ты видел свой проект ещё младенцем — в approach или requirements. Постепенно он рос, отбрасывал «заглушки» и начал самостоятельно выполнять функции. Это почти как воспитывать ребёнка: чувствуешь причастность и гордишься проделанной работой.
Все свои проекты ты будешь помнить, поэтому просто получай удовольствие от работы!
