Логика создания эффективных проверок от Куликова

Если вы еще не читали книгу Святослава Куликова «Тестирование программного обеспечения. Базовый курс» — рекомендую прочитать. В ней есть много интересного и полезного!

Для затравки хочу привести небольшой особо понравившийся кусочек.

... существует достаточно простой алгоритм, позволяющий нам создавать эффективные проверки... Приступая к продумыванию чек-листа, тест-кейса или набора тест-кейсов, задайте себе следующие вопросы и получите чёткие ответы:

1. Что перед вами? Если вы не понимаете, что вам предстоит тестировать, вы не уйдёте дальше бездумных формальных проверок.
2. Кому и зачем оно нужно (и насколько это важно)? Ответ на этот вопрос позволит вам быстро придумать несколько характерных сценариев использования того, что вы собираетесь тестировать.
3. Как оно обычно используется? Это уже детализация сценариев и источник идей для позитивного тестирования (их удобно оформить в виде чек-листа).
4.  Как оно может сломаться, т.е. начать работать неверно? Это также детализация сценариев использования, но уже в контексте негативного тестирования (их тоже удобно оформить в виде чек-листа).

И пара советов

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

Абсолютно согласна с этими советами. Нет бага → нет исправления. Вы могли обсудить с разработчиком, что «Да-да, надо бы поправить»... И забить. Не оформить. А через месяц наткнуться на баг снова и возмущаться «Почему не исправили??!»

Аналогично и в чек-листах. Вроде идея есть, но, если ее не записать — забудешь. Помню, недавно все проверила, кроме миграции. В голове вертелось "Вот это закончу и миграцию проверю». Но потом что-то отвлекло, уже и не знаю что — коллега, клиент, чашка чая? В общем, я забыла проверить миграцию. Угадайте, где потом нашелся баг? 

А еще очень важно не просто бегать к начальнику/аналитику/разработчику каждые 5 минут, когда возникает новый вопрос, но записывать все, что хотелось спросить и потом идти со списком вопросов — так вы экономите время коллег и показываете свое к ним уважение!