Опытный тестировщик, особенно если он со своим проектом знаком давно, накидывает список тест кейсов довольно ловко. Но если вы еще только формируете свой профессиональный стиль или пришли в новый продукт, или просто открыты обмену опытом то, вероятно, вы найдете что-то значимое для себя в списке моих профессиональных приемов работы.
Вступление
Есть теория, что интуиция - это результат вашего опыта и знаний. Все, что вы когда-то видели, слышали и чувствовали, отложилось где-то там в мозгу, даже если вы этого не помните. В копилке интуиции могут быть как знания, полученные многодневным чтением книг, так и фраза, мельком услышанная при прощелкивании каналов на телевизоре.
И когда вы принимаете решения, не опираясь на аргументы, вы опираетесь на интуицию, которую приобрели просто проживая жизнь.
Получается, чем шире ваш кругозор, тем лучше интуиция. Это, очевидно, сработает и в случае, когда нужно писать тесты. Документация - это прекрасно. Но для хорошего Quality Control процесса - это точно не все, тем более при сильной срочности нужно выбрать ограниченный набор тестов. Интуитивно.
Изучаем use cases пользователей
Use case - это сценарий, по которому реальный клиент будет использовать функционал. Самое сложное их достать. Где вы можете их взять? Если есть возможность общаться с клиентами, спрашивайте у них: как, зачем и почему. Если возможности нет - просите Product Manager добывать реальные примеры. Чем больше, тем лучше.
Дружим с командой техподдержки
Кладезь информации - команда support. У них можно узнавать вопросы, проблемы и сценарии, которые присылают клиенты.
Берем в тщательную работу баги клиентов
Баги, открытые клиентами, - это ценный источник вдохновения. Обязательно фиксируем сценарии этих багов в виде регулярных тестов (авто или ручные) и сохраняем себе клиентские артефакты, приложенные к багам. Это могут быть входные файлы, особенные метаданные, настройки, конфиги и т.д. На этих реальных данных мы будем гонять другие тесты тоже.
Изучаем белый ящик
Понимать архитектуру проекта, внутреннее устройство - задача сложная, но достижимая. Зная на что изменения в одном модуле влияют изнутри, как по цепочке происходит работа “под капотом”, можно писать очень грамотные тесты.
Подмечаем слабые части продукта
Разработка не бывает одинаково ровной. Иногда что-то делается в режиме прессинга, быстрей-быстрей. Такие части продукта могут давать о себе знать багами довольно долго. Здесь хорошо не терять из виду этот функционал.
Наблюдаем за разработчиками
Знать, кто какой кусок кода сделал, а главной какой он разработчик, на самом деле, очень удобно. Встречаются те, которые откровенно не любят тесты, мало их пишут, ничего не перепроверяют (это не значит, что он "плохой", у него могут быть другие таланты). Если вы узнали, что этот кусок функционала работа такого человека, нужно быть дотошнее. А есть те, кто очень скрупулезно все сверяет и выверяет. Проверять такой функционал спокойнее. Можно создать внутренний рейтинг для себя (с кем нужно быть внимательнее, а кто делает работу чисто).
Погружаемся в тему продукта
Каждый продукт существует для какой-то сферы жизни. А там целый мир: свои термины, свои понятия “хорошо” и “плохо”, свой рынок. Бывает полезно понимать эту лексику, что-то знать/читать об индустрии, наблюдать за продуктами конкурентов. Когда ты “в теме”, мозг быстро прикидывает на что нужно обратить внимание. А продукты конкурентов иногда могут научить, как сделать лучше, например, если тестируемые изменения касаются интерфейса.
Изучаем теорию тестирования
И для черноящичного и для белоящичного уже есть разработанные приемы написания тестов, они всегда могут стать отправной точкой, когда не знаешь с чего начать. (Equivalence Partitioning, Boundary Value Analysis, Decision Table, State Transition, Use Cases VS Statements testing)
Как дополнение этому пункту напишу, что вдохновение для написания тест кейсов можно черпать еще из следующих областей:
Непосредственный функционал:
каждый acceptance criteria;
валидные тесты;
невалидные тесты;
граничные значения;
Cмежные(интеграционные) области:
области, которые будут отправлять свои данные в новый функционал;
области, которые будут отправлять свои данные в новый функционал;
коллизии - типы отправляемых и принимаемых данных соответствуют;
вариации коммуникации функционала с остальными модулями: через ftp, через aws, конфиги и прочее;
Роли, пермишны, доступы - ничего не нарушено, все сохранено;
Каноны, стандарты, общепринятые удобства;
UI/UX:
информативность сообщений об ошибках; представьте, что вы впервые видите продукт и столкнулись с ошибкой; сообщение вам помогло предпринять следующий шаг для ее решения?
информативность успеха; пользователь понял, что достиг желаемой цели?
единый стиль с остальными частями продукта: списки, фильтры, таблицы;
и т.п.
Заключение
Конечно, простой ежедневный опыт тоже откладывается в интуицию. Чем больше времени ты на проекте, тем острее его чувствуешь. А еще бывает как с вождением автомобиля, чем дольше за рулем, тем больше притупляется осторожность. В такие времена меня спасает пробежаться по чеклисту выше и проверить саму себя на тему, а не упустила ли что-то важное в новом функционале.
Эти заметки не претендуют на какую-то научность, этакий обмен опытом с моей стороны, поэтому я буду рада вашим дополнениям на заявленную тему, делитесь, пожалуйста.
