×Закрыть

Как выжить, если ты один 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. Постепенно он рос, отбрасывал «заглушки» и начал самостоятельно выполнять функции. Это почти как воспитывать ребёнка: чувствуешь причастность и гордишься проделанной работой.

Все свои проекты ты будешь помнить, поэтому просто получай удовольствие от работы!

LinkedIn

33 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Коли один на проекті і сам себе не застрахуєш — то легко можна залишитись винним і це дійсно буде правдою, відповідальність космічна і ніхто не прикриває. Хоча з таких проектів в мене лише самі теплі спогади — найбільше навчилась саме там, а не в команді.
Навики комунікації, організованості, самостійність і характер добре розвиваються, потім впринципі вже нічого страшно не буде, слабких місць просто не залишається)
1,2, 3, 5, 9 — прямо в точку. Цей чеклист можна видавати впринципі усім. Дуже погоджуюсь, що потрібно абсолютно усе документувати публічно, жодних фіксів на колінці, бо в 1 з 2 випадків завжди щось піде не так і вилізе QA боком + запитувати чи радитись толком немає з ким. І це все зовсім не про прикриття 5.

www.youtube.com/watch?v=FvFz3rDJDSA

У нас вообще QA нет, сами разработчики пишут тесты и нормас.

Это не ок, поймёте это позже)
А чем позже баг обнаружен, тем он дороже)

Ой да ладно у нас баги иногда через три года обнаруживаются. Уже почти 10 лет как я там работаю такая практика нормас.

Это не ок

не ок одразу оцінювати. ви не знаєте контексту та який проект, не знаєте цілей
Якщо розробники норм тестують, тех дебт та рівень дефектів їх не тормозить — не бачу потреби їх навантажувати ще і додатковим тестувальником

Это не девелоперы нагружаются дополнительным тестировщиком))

Существуют выработанные годами методологии обеспечения контроля качества. Кстати, не только в IT. На любом предприятии есть отдел контроля качества. И пока эти ребята не дадут добро, отгрузки партии не будет.

Дешевле оплачивать труд этих специалистов, чем пытаться сэкономить на них, а потом платить за последствия.

ви не знаєте як працює конкретна команда, якщо вони можуть самі забезпечити собі тестування, без окремої людини, то це дуже правильний напрямок руху.

Не могут, даже если им кажется, что могут. И это не считая оплаты труда дева, которая, обычно, выше, чем у куа. Так что заставлять девов тестить — еще и не выгодно экономически.

Не могут

чому ?

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

unit testing\TDD — це не mindset девелоперів ?

Mindset — это в принципе не уровень тестирования и не методология разработки.

та ок. але хороший девелопмент опирається на тестування. І будь який хороший девелопер займається тестування, на тому чи іншому рівні. Хтось пише юніт тести, а хтось e2e тести. Це все тестування. Багато девів також перевіряють свої зміни ручками.
Тому, не завжди потрібна окрема людина для тестування

Это не ок, поймёте это позже)

багато команд можуть працювати без окремих тестувальників без проблем
Та і взагалі за цим майбутнє — continues testing, shift-left testing і тд це тенденції які не хочуть бачити окрему людину, яка тестує, а пропонують тестувати всі команді, на всіх рівнях

Естественно, что занимается. Но заменить QA инженера девелопер не может. Как и представляя в целом менеджмент, не может заменить ПМ, хорошо рисуя, не может заменить дизайнера. Это специалисты разного профиля.

Тенденции комментировать не буду, это всё представления очень личного характера. Я читал и о ровно противоположных по смыслу. Потому предпочитаю оперировать тем, что есть в реальности.

Это специалисты разного профиля

ось в цьому і проблема. Ми починаємо розділяти обов’язки між людьми, створюємо ролі і тд і тп. І у нас виходять учасники проекту які не знають як працюють їхні колеги. І у нас виходить команда, де кожен знає лише свою маленьку пісочницю і нічого не знає про проект в цілому. І це проблема

читал и о ровно противоположных по смыслу

Ви бачите процес з чітко розподіленими ролями і відповідальностями. Десь як у 90-тих, там воно працювало бо середовище таке було.У сучасному швидкому світі все йде до спільних відповідальностях та розмитих ролях — DevOps, FullStack development і тд і тп. І все тому, що потрібно швидше і швидше роботи delivery. Практики 90-тих вже не працюють
Якщо дев не розуміє як тестувати — результат його роботи буде важко тестувати, або і взагалі неможливо. Йому пофіг як хтось буде виконувати тестування, він свою роботу зробив. Якщо дев повинен ще і тестувати свою роботу — йому доведеться зробити її так, щоб можна було тестувати.

Олег, разделение труда — это один из признаков развития общества и одна из главных причин успехов любой экономической системы)) Это не проблема, а громадное достижение))

И тестировщиков достаточно и у Гугла, и у Майкрософта, не вводите в заблуждение неведающих))

это один из признаков развития общества

розділення праці != розділення обов’язків. Ви ніяк не можете мене зрозуміти.
У певних сценаріях, задля ефективного процесу, роботу можна розділяти. Але у певних сценаріях можна і не розділяти. Наприклад, коли проект маленький. Або той рівень якості який забезпечує команда без тестувальника, задовольняє замовника чи клієнтів. І це ок.

І для того, щоб трошки подумати www.youtube.com/watch?v=qd9N9eU1Qn0

тестировщиков достаточно и у Гугла, и у Майкрософта

вони то там є, але у великій меншості і також займаються девелопментом. За якісь та тестування там відповідають розробники
testing.googleblog.com/...​ts-software-part-two.html
Test Engineer is the exact reverse of the SET. It is a a role that puts testing first and development second. Тобто, тест інженери також є девелоперами

Разделение труда — это не разделение обязанностей?))

Нет, то есть у них есть тестироващики, которые прежде всего занимаются тестированием))

заменить QA инженера девелопер не может

а чому тоді у лідерів ринку (Google, Microsoft) практично немає тестувальників ?

Круть! Маю декілька доповненнь та свого ІМХО)
1. Найкращі друзі тест інженера — це автоматизація та аналітика. Бюрократія тільки прикриває «сраку» коли інженер не повноцінно проаналізував та не автоматизував — тобто як батьки, в разі чого прикриють сраку сина)
Але все ж я більше схиляюсь до гнучкого балансу між аналітикою, автоматизацією та бюрократією, який залежить від культури в команді/компанії
Деякі баги та не доробки прикриваю фічами та тасками, все повноцінно автоматизувати важко але позитивні та базові негативні речі можливо, а аналітика як мати того всього
2. Гарно підмічено, що дуже важливо розібрати як все на проєкті влаштовано. Я б додав тільки що покращення можливі не тільки в QA та менеджмент частині, а ще й продуктовій частині та технічній. Продукт формується на захцянках замовників — якщо вони погано обробляються, то є проблеми (порою дуже дорогі). Продукт розробляється мовою розробки — тут потрібні і Code convensions, і статичні аналізатори коду, і баланс покриття тестами всіх рівнів коду, і як виконються доставки коду до проду, які в принципі існують qulity gates. Також як виконується observability та збір аналітики з реальної системи — як користувачі користуються нею.
3. Підтримую повністю, що розробники теж є найкращі друзі тест інженера. Але іноді щоб не задавати глупих запитань, треба розумітися в програмуванні та порою фіксити баги коли їх помічаєш замість розведення бюрократії 😉
4. Аналізуй, потім плануй та порівняй в кніці чи співпли плани із релаьними справами.
Я користуюсь Onenote щоб планувати дні, тижні та місяці, а потім переглядаю чи все було виконано
5. Так :)
6. Автоматизовуй тест кейси та автоматизуй їх створення в тест менеджемент системі 😉
7. Ооо так) Мало хто вміє гуглити
8. +
9. Ну замість сторі, маю фільтри в жирі на баги та на те що створено мною
10. Ооо так!

всегда можно съехать на начальство (QA Lead, PM, PO), которое требует именно этого. И не переживай, ведь ни один девелопер не пойдёт выяснять, какого лешего QA выполняет свою работу.

Він піде виясняти, чи справді начальство вимагає саме цього, і якщо ти ’з’їхав’ без їхнього відома, то проблеми будуть в тебе. В такому випадку їх треба підключати одразу

Еще про это одиночество тестировщика на проекте testitquickly.com/2010/11/21/37

Даже если разработчик пишет: «Мы решили изменить этот момент», отвечаешь: «Внесите изменения в описание стори, тогда и прокомментируем».
Не бойся выглядеть занудным: всегда можно съехать на начальство (QA Lead, PM, PO),

вот после этого, вопрос:

Потому с добродушной улыбкой начинай доставать коллег-разработчиков вопросами: «А как это работает? Как это можно протестировать?.

Скорее всего вызовет так же «добродушную» улыбку и вопрос о Вашей квалификации, причем не к Вам, а к вашему Лиду и Вы намного раньше начнете искать новую работу чем

QA, которые хотели построить максимально ламповое и неформальное общение с командой разработки.

Статья зашла на одном дыхании, только ожидала увидеть тут несколько другие моменты, больше про процессы, хотя и таких статей хватает. У меня так же был опыт работы одним QA на 2-х проектах и да, это кайф и для меня — сам себе тим лид, хотя некоторые минусы в этом всё же есть, но плюсов точно больше. Сейчас, на проекте нас 2е и в целом, это тоже ок, особенно, если вы оба профессионалы своего дела и есть чему друг и друга научиться.

Свои плюсы есть в обоих подходах, конечно)

Настолько крутая статья была недавно «Як за допомогою тестів пришвидшити реліз» (линк bit.ly/3fMJQ88), где автор круто раскрыл тему как QA может приносить большой business value продукту и бизнесу.
Здесь же, мне совсем не близки эти подходы про добавление начальников в копию, репорты и прочее, что позволяет прикрыть свою 5ую точку. Но с другой стороны, в мире кровавого аутсорса это очевидно часто работает и может быть полезно.

Здесь же, мне совсем не близки эти подходы про добавление начальников в копию, репорты и прочее, что позволяет прикрыть свою 5ую точку. Но с другой стороны, в мире кровавого аутсорса это очевидно часто работает и может быть полезно.

Це не дуже добре може вплинути на відносини між dev-qa, чи атмосферу в команді, але працювати з неприкритою 5 точкою, для QA тим більше, це самогубство.
В продукті, особливо великому, ентерпрайзному такий підхід працює тільки так, якщо не хочеш потім бути винен за любу фігню

Полезные заметки, спасибо что делитесь таким опытом.

От себя добавлю:

Воевать за них до последнего патрона — это портить отношения с коллегами и срывать сроки релиза.

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

9. Заведи свою личную историю в бэклоге

И это хорошо иметь в общем беклоге, чтобы все об этом были вкурсе, а не только вы. Задача на прикрыть ж**у, а выпустить продукт. И опасно если вы припрятали в «своем» беклоге , на ваш взгляд, минорный баг, который на самом деле для бизнеса является очень критичным.

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

Для меня — в кайф. Как показывает практика, для большинства специалистов — нет.

может быть, это дело вкуса, когда у меня был такой проект то это было прекрасно :)

Как показывает практика, для большинства специалистов — нет

А это то Вы откуда взяли ? )))

Подписаться на комментарии