Как тестировать без требований? Или как убедить разраба и себя, что это баг
Сгенерированно с помощью Кандинского
Всем привет, это моя первая статья по тестированию. До этого я писал от лица 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
Сгенерированно с помощью Кандинского
