Тестирование программных продуктов тесно связано с написанием подробных тест-планов. Особенно это актуально на больших проектах, которые разрабатываются продолжительное время. Такие тест-планы, зачастую, становятся неповоротливыми мастодонтами в тысячи страниц текста. В итоге получаем сам продукт, который нужно тестировать с бесплатным приложением в трех томах соразмерных с произведением «Война и Мир». Огромные тест-планы сложно писать, а еще сложнее поддерживать. Представьте ситуацию: ваш тестировщик в течение года пишет, покрывает тестами, поддерживает документацию в актуальном состоянии, а затем ему приходит в голову уволиться из компании. Он увольняется, на его место приходит другой тестировщик. Тут начинается веселье — ему необходимо въехать в проект и разработанную ранее документацию прежним QA специалистом. Задачка не из легких. Даже можно сказать неподъемная (знаю по себе). После прочтения тест-плана (уходит часов 8-16) в голове одна мысль — что я сейчас прочитал? 90% прочитанного вообще не воспринимается адекватно. В итоге получаем пустую трату времени, запутываемся в проекте, шлем все к черту, забиваем, запиваем, увольняемся.

Никто не будет разбираться в ваших тест-планах. Это нудно, не интересно и бесполезно. Я, изначально, был против такой системы. То есть, как сейчас принято ставить работу (привожу самый минимум): планирование проекта, написание тест-плана, тестирование по тест-плану. Везде фигурирует тест-план. И это на подсознательном уровне раздражает. При разработке этого увесистого документа обязательно что-то будет упущено. В итоге вернемся к началу — будем писать тест-план на тест-план и так далее до бесконечности. Никогда не любил писать бессмысленные вещи и терять время впустую. Тест-планы разрабатываются и поддерживаются олдфагами потому, что так принято мировыми стандартами и никто не хочет отступать от очевидного. Сказали что ручка синего цвета — значит ручка синего цвета. Никто не пытается поменять в ручке стержень на красный. А зачем?

А правда зачем? Мы пишем тонны планов, получаем за это деньги, начальство устраивает. А приносит ли это пользу и повышается ли качество продукта — да всем плевать. Зачастую банально отсутствует вменяемое техническое задание. Тогда QA начинает выдумывать свой функционал и покрывать тестами то, чего в принципе даже не существует.

Олдфаг (от англ. oldfag, что при буквальном прочтении old fag может означать «cтарый пед%к», но фактически фаг/fag в интернет сленге используется как синоним слова «фанат») — характеристика человека, давно и много участвующего в жизни интернет-сообщества.
Подразумевается, что олдфаги являются своеобразной элитой того ресурса, на котором они находятся, и обладают широкими знаниями об их истории, традициях, правилах поведения. Статус олдфага является неформальным и присваивается человеку метапедически активным ядром проекта.

Мне было не плевать. Я начал искать более адекватные пути тестирования, обкатал несколько разных вариантов, но остановился лишь на одном. Тест-кейсы — наше все. Да, ребята, банальные тест-кейсы.

КАК ЭТО РАБОТАЕТ (HOW IT WORKS)

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

Возьмем абстрактную задачу — Корзина (интернет магазин, реализовать функционал корзины).

Данную задачу разбиваем на маленькие подзадачи:

• Добавление в корзину
• Удаление из корзины
• Очистка корзины
• Обновление количества товара
• Пустая корзина
• Итоговая стоимость всех товаров

Получается, что одна большая задача превратилась в несколько маленьких и уже не так страшно выглядит. Виден план работ. Программисту на психологическом уровне становится намного проще. Не просто браться за задачу «Реализовать функционал корзины» , а брать отдельные подзадачи и потихоньку реализовывать их в жизнь. Далее, после разбивки большой задачи в подзадачи, QA кооперируется с программистом (не по скайпу, не на духовном уровне) а прям лично, ставят два стула, берут один компьютер и начинают обговаривать функционал подзадач. Для каждой подзадачи реализуется список тест-кейсов. В итоге получается отличное взаимодействие программиста и QA специалиста. Идет мозговой штурм, тестировщик задает контрольные вопросы и предлагает варианты ответов (либо сам программист уже знает ответ на вопрос) по подзадачам. Вопросы вида — Что произойдет если находясь в корзине с товарами, нажать на кнопку «Очистить корзину» ? Появится окно с сообщением «Вы действительно хотите очистить корзину?» Сработает какой-то редирект? Или товары удаляются из корзины, выводится заранее подготовленный текст, происходит обновление счетчиков? Задачи разбираются более подробно, появляется осмысление, а иногда всплывают нелогичные моменты, которые требуют уточнение у менеджеров. Тут сплошные плюсы. Естественно, если подойти к этому ответственно, а не махать рукой — а, и так сойдет.

С этим разобрались. Резюмируем — программиста спланировали, отгрузили ему задачи, разбили на подзадачи, засели с QA, начали обговаривать каждую подзадачу. Во время разбора подзадач формируем тест-кейсы на каждую из них. Возьмем тот же пример с очисткой корзины. Как строится диалог:

QA: При нажатии на кнопку «Очистить корзину», что произойдет?
DEV: Корзина очищается.
QA: Это понятно, но правильнее будет вывести окно с вопросом «Вы действительно хотите удалить все товары?» и два варианта ответа ДА/НЕТ.
DEV: Точно, мы же на планировании про это обсуждали.

Начинаем писать чек-лист для подзадачи:

1. После нажатия кнопки «Очистить корзину», отображается окно с кнопками ДА/НЕТ.

QA: Так, если пользователь нажал ДА, корзина соответственно очистится, что произойдет дальше?
DEV: Если корзина пустая, должен отображаться текст «В корзине пока ничего нет».
QA: То есть, при очистке корзины не будет никаких редиректов? Просто будет выводиться текст?
DEV: Да, просто выводится текст.

2. При нажатии на кнопку ДА все товары из корзины удаляются, в корзине выводится текст «В корзине пока ничего нет».

QA: Соответственно, если основная корзина очищена, надо проверить, что счетчик количества товара в шапке обнулился. Итоговые суммы так-же обнулились. Так-же не забыть проверить мини корзину.

3. После очищения корзины счетчик количества в шапке обнулился.
4. После очищения корзины итоговые суммы обнулились.
5. После очищения корзины открыть мини корзину, убедиться, что добавленные товары так же очистились.
6. Добавить в корзину 3 товара, удалить первый товар, удалить третий товар, удалить второй товар. Убедиться, что вывелся текст «В корзине пока ничего нет».

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

Весь процесс написание чек-листов занимает от силы один-два часа. А вот если задачи покрыть тест-планом, может уйти и неделя. Плюс, опять-же, 90% всего написанного будет водой. Вся соль в том, что-бы взаимодействовать с программистом и никак по другому.

После того как на все задачи и подзадачи написаны тест-кейсы, разработчик приступает к работе. Выполняет все поставленные задачи и сообщает — готово, я заснял, я заснял. Свободно выдыхает, идет пить кофе, пиво. Но на этом работа разработчика не окончена. Теперь ему нужно пройтись по всем тест-кейсам и проверить за собой. Во время проверки «за собой» в большинстве случаев всплывают неожиданные баги: писал одно — сломал другое. От этого никто не застрахован. По ходу проверки исправляются найденные баги. Это очень важная часть всего процесса. Чем ответственнее разработчик подойдет к самой проверке — тем качественнее продукт он отгрузит в QA отдел. Соответственно, качество повысится в разы.

Разработчик закончил проверять за собой, прошел все тест-кейсы, поправил найденные баги, отгрузил в QA отдел. И теперь точно уже свободно выдыхает и идет пить кофе, пиво. Его работа на этом окончена. Отгруженный продукт тестируется QA специалистами по той-же схеме. Каждая задача проходится по чек-листам. Документируются недочеты и найденые баги. Далее проводится Smoke тест, то есть от лица обычного пользователя. Специалист по тестированию эмулирует действия рядового пользователя, который, в конечном итоге, будет пользоваться разработанным продуктом.

Не стоит пренебрегать человеческим фактором. Тестируя проект восемь часов подряд тестировщик погружается в пелену, в глазах начинает плыть, а это самые благоприятные условия для того, чтобы пропустить очевидные баги. Поэтому, после основного тестирования, проект отдается на тестирование человеку, который как-бы не в теме вообще (человек может быть грузчиком, ПМом, дизайнером). В этом вся суть: у тестировщика один кругозор, у человека не «в теме» — совсем другой. Плюс ко всему свежий, не замыленный взгляд. С таким подходом обнаружится еще масса всего интересного.

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

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

Я работаю по этой системе третий год. Теперь абсолютно безвозмездно делюсь ею с вами. Думаю все подробно разжевал и суть вы поймете. Всегда старайтесь упрощать процессы. Если все делают по сложившимся стандартам, это не значит, что вы должны делать так-же. Удачи в работе, господа.

С Уважением, Фёдорыч.