Всем привет, это моя первая статья по тестированию. До этого я писал от лица Scrum-мастера, а теперь уже и от лица QA. В тестировании я уже более 2-х лет. Работал на двух проектах одновременно, и было супер весело менять проект на протяжении дня: утром ты тестируешь веб-сервис, а вечером со студентами делаешь тест-план по мобильному приложению. Не жизнь, а сказка!

Из названия мы с вами понимаем, что тема статьи интересна и, как воздух, необходима.

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

Не будем петь серенады, как это сложно, и приступим к делу.

Вас посвящают в суть проекта, и главный шаг - уточнить у аналитика или того героя, кто выполняет эту роль, "Есть какая-нить дока?" (далее - спецификация).

Какая может быть спецификация на проекте? Будьте внимательны, я не использую термин документация, потому-что дока - это текстовый формат, а в виде спецификации может выступать:

1. документация; обновленная в последний раз в 90-х

2. макеты; вообще не похожи на прод

3. тикеты в Jira; обычно там один заголовок, но верим в чудо

4. user-story;

5. тест-кейсы, чек-листы; если был тестировщик до

6. звонок с владельцем продукта; Product owner

7. блокнот разраба, утопленный в слезах;

8. презентация для заказчика; тут самый сок, все красиво, и глаз радуется

9. корректировки заказчика, пользователя;

10. вышеуказанные косвенные требования;

11. статьи на Хабре по удобству использования сервисов;

12. статьи с правилами UI UX дизайна. (ого, а так можно было?)

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

Теперь у нас есть список, откуда мы будем доставать спецификации. Вот же веселуха, нам бы протестить наш продукт, а тут еще и искать надо. Ну, а как иначе бесценный опыт получать? Важный момент, который определит ваш успех - документировать, складывать все то, что вы нашли, в один формат. Далее это нужно преобразовать в интеллект-карту, требования, обновленные ТК и ЧЛ.

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

Первое правило тестировщика - дружи с разрабом, ибо он будет воспринимать задачки на исправление функционала как "твой код никому не нравится, кроме тебя". Сглаживаем углы.

В книге Gula Artur - Bug reporting. Submit issues like a pro - 2022.
"What do you feel when someone points out that you are wrong? It may be anger, offense, irritation. It's a similar mechanism when you report an issue in someone else's code. Your bug reports say: 'you made a mistake, men.' Of course, you can't change that. But the form of the issue may affect that feeling in both directions."

"Что вы чувствуете, когда кто-то указывает вам на ваши ошибки? Это может быть гнев, обида, раздражение. То же самое происходит, когда вы сообщаете о проблеме в чужом коде. В ваших сообщениях об ошибках говорится: 'Вы допустили ошибку, ребята'. Конечно, вы не можете этого изменить. Но форма проблемы может повлиять на это ощущение в обоих направлениях."

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

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

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

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

Матрица трассировки - предоставит информацию по покрытию тестами и покажет пустые зоны без тестирования. По диагонали в нашем случае это старые ТК и ЧЛ, по вертикали используем один из форматов: интеллект-карта, старые требования, макеты.

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

Еще один навык, который приобретается с опытом - это техника тест-дизайна Предугадывание ошибок. Я бы сказал, навык нарабатывается, когда ошибка попала в пром и положила всё, такие моменты остаются в памяти навсегда.

Выше указанная Интеллект-карта прояснит структуру продукта, это не тест-дизайн, но оставлю это здесь.

Таким образом, я четко и структурированно описал шаги и действия к шагам. В следующем материале я на реальных примерах покажу результат своего плана. Хорошего настроения :)

Мой тг для связи @evanovnew