Еще раз о тест кейсах

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

О своем подходе к составлению тест кейсов я писал несколько лет назад, он с тех пор не изменился существенно, я встретился с другим способом разработки тестовой документации, но об этом в другой раз. А сейчас я хочу рассказать откуда я беру информацию для составления тест кейсов.

Порядок в списке, не означает приоритет.

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

2. По готовому коду – получили продукт и по тому как он работает пишем тест кейсы, убирая явно бракованные варианты поведения и ошибки. Попутно записываются баги. Есть риск того, что при тестировании будет проверена всего лишь техническая реализация, а не соответствие тому, для чего проект был сделан. Но это наиболее простой способ и основной в условиях бардака.

3. Из общения с разработчиками. По сути этот пункт должен быть первым в процессе работы, но на практике оказывается, что далеко не каждый разработчик способен рассказать о своей работе так, как нужно тестировщику. То есть рассказывает то он всё правильно, но только на другом языке. Поэтому часто это неэффективный вариант, но без него не обходится. Если же при написании тест кейсов с разработчиками общения про продукту не происходит, то стоит задуматься о смене стиля работы. К тест кейсам это отношения особо не имеет, но показывает расслоение команды на “тех” и “этих”.

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

5. Гайдлайны. Те, которые предоставляют Microsoft, Apple, Google и прочие производители средств разработки и исполнения приложений. Перекликается с четвёртым пунктом, но легче, – не требует глубокого знания области (понимания требует, но знание не существенно), тесткейсы на их основе легче аргументируются и лояльно воспринимаются разработчиками, дизайнерами и прочими любителями сделать фишечку в интерфейсе графическом или программном от которой пользователи впадают в ступор. Минус в том, что покрытие приличное ими не гарантируешь и проверяется соответствие каким то внешним условиям, а не соответствие продукта его основному предназначению. Так же гайдлайны часто очень детальные и трудно адаптируемые к ручному тестированию из-за своей точности, а вот для автоматизированного в самый раз.

6. Best practices. Адаптация чужого знания и опыта к какой-либо части разрабатываемого продукта. Заменяет гайдлайны, когда их нет. Плюсы – минусы теже.

7. С потолка. Иногда и так. Особенно в стартапах, когда не всегда и не все известно как должно работать. Например, как оценить новый геймплей? Функционально да, можно, а вот саму идеереализацию геймплея? Юзабилити тут ни при чем.  В итоге появляется договорённость о том, что мы считаем правильным. Это по сути источник для регрессионных тестов и тестов, которые позволяют оценить вектор изменения будущих версий относительно предыдущих (а это уже в юзабилити в том числе).

А еще тест кейсы тоже надо тестировать :] Я делаю это в процессе ревью с теми, кто заинтересован в проекте. Потом, по полученному фидбеку меняю или не меняю написанное. Заодно сразу становится понятно, в каких местах придется преодолевать сопротивление разработчиков, дизайнеров и бизнеса и нужно ли это будет делать.

 

Leave a Reply

Your email address will not be published. Required fields are marked *