Бывают такие случаи, когда тестирование в компании нужно организовать с нуля. Что и как делать тестировщику, если он пришёл на это поле непаханое?
Ответ : Погрузиться в продукт и существующие процессы разработки.
Погружение в продукт
По поводу продукта, вариантов может быть два, плохой и хороший. Хороший вариант, это когда есть документация. В виде технических заданий, или пользовательских историй, или на худой конец есть аналитик, у которого это все можно выспросить, и написать кратенько основные моменты самому.
Но может выйти и так, что ничего нет. Продукт есть, разработка есть, а что там внутри творится, никто не знает.
В таком случае сначала нужно исследовать сам продукт. Максимально расспрашиваем тех, кто может нам предоставить информацию (разработчиков, продуктологов и тд) - что это у нас такое, для чего, какие функции выполняет и все такое. Потом подходим с точки зрения пользователя, исследуем систему, проверяем, выполняются ли пользовательские сценарии и тд.
В процессе этого исследования у вас сама собой получится куча заметок, какие-то чек-листы, может сразу список самых важных кейсов.
Тут главная заповедь - все записывать. Для начала хоть у себя в блокноте, потом обязательно это все пригодится, а на основании своих записей уже можно будет вести документацию (начиная от кейсов и чек-листов и заканчивая статьями в confluence и пользовательскими сценариями)
Погружение в процессы
Точно так же, как и продукт, исследуем процесс разработки.
Как она вообще происходит? Кто, когда и как ставит задачи? Как они проверялись до вас (если проверялись). Как новый код попадает на прод? Есть ли тестовая среда?
На первых порах задача тестировщика понять этот процесс и встроиться в него.
Тут тоже возможно несколько вариантов.
Встроиться до непосредственно разработки - то есть активно общаться с аналитиком и product owner, читать сценарии, обсуждать, заранее прикидывать список проверок, находить ошибки в постановке или непредусмотренные сценарии. (это чаще всего бывает, когда в компании есть документация и все более менее ок)
Непосредственно тестировать будем уже после выкатки на тест.
Но может быть и так, что поначалу процесс будет выглядеть как - вот тебе список пришедших на тестирование штук, проверяй.
Тут нужно выстраивать отношения с разработчиками, аккуратно и дотошно всех выспрашивать, о чем фича, какие могут быть особенности проверки и тд (если описание в задаче так себе). Тоже самое можно делать с теми, кто поставил задачу - если к ним напрямую есть доступ.
Если доступов нет - пытаемся выбить.
Задача тестировщика в таких процессах, повторюсь, аккуратно и нежно встроиться, ничего не ломая (поначалу), максимально вовлечься во все что творится, а дальше уже действовать по обстоятельствам и в зависимости от полномочий.
Задача мах - чтобы получилось в итоге как описано в первом варианте.
Может получиться и так, что процессы модернизировать не дадут, так и будете сидеть и тестить то, что приходит от разработчиков. Такое тоже бывает. Тут сложно советовать что-то конкретное, многое зависит от специфики продукта, размера компании и тд.
Нужно помнить, что задача тестировщика - сделать мах хорошо бизнесу - чтобы пользователи были довольны, все работало, фичи выкладывались рабочие и вовремя, продукт приносил пользу и прибыль.
В конце-концов, если будет совсем всё грустно и плохо, всегда можно найти другой проект)
Всем спасибо, с вами была Вселенная тестирования.
P.S. Если вам понравилась статья, ставьте лайк и подписывайтесь на канал.
А ещё есть канал в телеграме