Любовь и тестирование

Тестирование шредингера

Бывают такие случаи, когда тестирование в компании нужно организовать с нуля. Что и как делать тестировщику, если он пришёл на это поле непаханое?
Ответ : Погрузиться в продукт и существующие процессы разработки.

Погружение в продукт

По поводу продукта, вариантов может быть два, плохой и хороший. Хороший вариант, это когда есть документация. В виде технических заданий, или пользовательских историй, или на худой конец есть аналитик, у которого это все можно выспросить, и написать кратенько основные моменты самому.
Но может выйти и так, что ничего нет. Продукт есть, разработка есть, а что там внутри творится, никто не знает.

В таком случае сначала нужно исследовать сам продукт. Максимально расспрашиваем тех, кто может нам предоставить информацию (разработчиков, продуктологов и тд) - что это у нас такое, для чего, какие функции выполняет и все такое. Потом подходим с точки зрения пользователя, исследуем систему, проверяем, выполняются ли пользовательские сценарии и тд.

В процессе этого исследования у вас сама собой получится куча заметок, какие-то чек-листы, может сразу список самых важных кейсов. Тут главная заповедь - все записывать. Для начала хоть у себя в блокноте, потом обязательно это все пригодится, а на основании своих записей уже можно будет вести документацию (начиная от кейсов и чек-листов и заканчивая статьями в confluence и пользовательскими сценариями)

Погружение в процессы

Точно так же, как и продукт, исследуем процесс разработки.
Как она вообще происходит? Кто, когда и как ставит задачи? Как они проверялись до вас (если проверялись). Как новый код попадает на прод? Есть ли тестовая среда?
На первых порах задача тестировщика понять этот процесс и встроиться в него.
Тут тоже возможно несколько вариантов.

Встроиться до непосредственно разработки - то есть активно общаться с аналитиком и product owner, читать сценарии, обсуждать, заранее прикидывать список проверок, находить ошибки в постановке или непредусмотренные сценарии. (это чаще всего бывает, когда в компании есть документация и все более менее ок)
Непосредственно тестировать будем уже после выкатки на тест.

Но может быть и так, что поначалу процесс будет выглядеть как - вот тебе список пришедших на тестирование штук, проверяй.

Тут нужно выстраивать отношения с разработчиками, аккуратно и дотошно всех выспрашивать, о чем фича, какие могут быть особенности проверки и тд (если описание в задаче так себе). Тоже самое можно делать с теми, кто поставил задачу - если к ним напрямую есть доступ. Если доступов нет - пытаемся выбить.

Задача тестировщика в таких процессах, повторюсь, аккуратно и нежно встроиться, ничего не ломая (поначалу), максимально вовлечься во все что творится, а дальше уже действовать по обстоятельствам и в зависимости от полномочий.
Задача мах - чтобы получилось в итоге как описано в первом варианте.

Может получиться и так, что процессы модернизировать не дадут, так и будете сидеть и тестить то, что приходит от разработчиков. Такое тоже бывает. Тут сложно советовать что-то конкретное, многое зависит от специфики продукта, размера компании и тд.
Нужно помнить, что задача тестировщика - сделать хорошо бизнесу, чтобы пользователи были довольны, все работало, фичи выкладывались рабочие и вовремя, продукт приносил пользу и прибыль.

В конце-концов, если будет совсем всё грустно и плохо, всегда можно найти другой проект)
Тестировочный полезняк Процессы
Made on
Tilda