Единственный тестировщик на проекте
Мой опыт выживания в ситуации, когда на десяток разработчиков в команде приходится один тестировщик.
Знакомство с продуктом
Проект, про который идет речь — ламповый видеосервис, в который мы вкладываем душу, код и старания. Другими словами, есть виртуальные комнаты и набор фич в виде аналитики, реакций, скриншаринга и т. д. На момент моего прихода в команду продукт был MVP, соответственно, тестирование практически отсутствовало, а то, что было, осуществлялось хаотично.
Итак, с чего же начать, когда у тебя не хватает релевантного опыта, отсутствует документация и полная свобода действий?
Первый этап — исследование. Что за продукт передо мной, что он делает, а всё ли мне понятно. Завела док и выписала все (сто раз все) вопросы, которые возникали, и, как следствие, был выведен целый скоуп багов и задач на обсуждение. Так как не было никакой документации, я начала писать тест-кейсы, чтобы было на что опираться. Этот этап занял около месяца.
Следующий этап — внедрение в команду. Привет soft-skills, потому что нужно получить море информации от разработчиков за короткие сроки. Знакомилась с каждым, собирала информацию, уточняла нюансы и… продолжала писать тест-кейсы. День, другой, третий… В скором времени проект был полностью описан. И на этом моменте в качестве бонуса — мобильная версия. Нет, не приложение, а мобильный браузер. Конечно же, функционал отличался, но это уже другая история. Этап внедрения занял около двух месяцев и шел параллельно с исследованием.
Как бы ни казалась сладка жизнь тестера, описывающего функционал, начался спринт и понеслись задачи. Очень много задач. В двух словах про тестирование по задачам из спринта: много сырого/сделанного на коленке, споров и радости от принимаемых решений. В таком режиме прошёл мой испытательный срок и следующие три месяца: тест кейсы, новый функционал, тестирование фич, поиск багов и прочее.
Правила выживания
Итак, как же не попасть в воронку под названием «у меня не получается и я не успеваю»? Для себя я выработала несколько правил, которые использую не только в работе, но и в повседневной жизни:
- Приоритизация
Без нее никуда. Привет джедайские техники и все остальное. Не получится сделать всё хорошо и вовремя. Сначала мы делаем очень важное, потом важное и далее по списку. Нередко случается, что приоритет у всех задач примерно одинаковый. В таких случаях в начало очереди ставлю те задачи, где за меньшее время можно получить больший выхлоп, и так по убыванию соотношения “время-результат”. - Планирование
С учетом первого правила. Чем больше задач, тем тщательнее должно быть планирование. Можно расписать свой день буквально по часам: в это время я работаю над одной задачей, в это — над другой и так далее. Понятно, что бывают выбивающие кейсы, но стоит постараться следовать плану. - Документация
Нет готовой — напиши сам. Пусть небольшой документ, пусть некрасивый, пусть тезисно, главное — пиши. Потом ты точно скажешь себе спасибо, когда она пригодится. Именно «когда», а не «если». - Качество продукта — не только твоя ответственность
Самый сложный пункт для меня, но очень важный. Нужно принять, что единственный QA — это не мессия, благодаря которому любой проект сразу станет классным и любимым пользователями. Так не будет, ответственность всегда коллективная. Но свою работу нужно делать хорошо. - Баланс
Важно понимать: работать сверхурочно в определенные моменты — нормально, постоянно — нет. Это прямой путь к выгоранию, невозможно концентрироваться на задачах/быть продуктивным. Увы, придется принять тот факт, что соблюдение баланса отдыха и работы грозит вам развитием и кайфом от жизни в целом. - Дружба с разработчиками
Никогда не понимала борьбу между разработчиками и тестерами. Мы же вместе коммитим в одну цель, соответственно — нам лучше быть на одной стороне. И да, подсказать, рассказать и поддержать они могут, как никто другой.
Для достижения комфортного уровня работы и получения информации и нюансов по работе платформы мне потребовалось около двух-трех месяцев. Это только мой опыт. Каждый индивидуален, и подход к работе у каждого свой. Главное — не теряться и быть смелее, проявлять активность и сохранять дипломатичность.
Влепил плюсик, статья хоть и банальная, но если писала реально тестер начинающая, то молодец
Нет это писал копирайтер.
Дело было так, начальник отдела маркетинга утвердил контент план.
Согласно плана, девочка копирайтер пришла к CTO, он отправил ее в отдел тестирования.
Там выбрали джиниора, того кому нечего делать), и попросили рассказать её историю про работу.
Девочка копирайтер выслушала, сделала заметки и родила вот это.
Да, у автора все в порядке с головой и ее применением.
Хороший русский язык, отличная стилистика изложения.
Банальности вовсе не банальны :) Это как в математике - иногда возвращаешься к основам и понимаешь, что не все просто с этими основами :)
1. Писать тест-кейсы, не зная правильно ли продукт работает. А смысл писать, тест-кейсы, если это mvp? Что сидеть и тратить время на поддержку? Почему нельзя было обойтись чек листами? Или вообще просто описание функционала, что бы были понятны токности.
2. Качество продукта в первую очередь твоя отвественость. Типа надо продавливать многое, а не просто сообщать, что у нас полное Г.
прочитал по диагнонали
у нас по сути такая же ситуация есть раздираемый QA
команды первичное тестирование делают сами, подготавливают все для QA, типа базовые кейсы мы прокликали, а тебе делать уже интеграционное тестирование.
как там в канбане, T shape и почие базворды.
Есть набор задач которые надо распределить между людьми
Как раз только раздерут единственного QA - из погреба приносят нового, необглоданного? :))
Самое главное забыли - автоматизация