Проблема с тест-кейсами в том, что они могут быть представлены множеством способов, и все способы правильные. А мы, как каторжники, всё ищем «наилучший способ написания тест-кейсов» и настаиваем на важности единообразия.
Я уже много лет не испытываю сложностей с написанием тест-кейсов, мне сложно быстро понимать новый объёмный продукт. Очень мешают иллюзии вроде «а, это мне знакомо…», а потом «ну кажетаг-то, мне же казалось, что оно вот так, а оно вон оно как…»
Тест-кейсы выглядят по-разному не по чьей-то злой воле.
Когда тесты условно-краткие — их удобно быстро считывать и выполнять, но их невозможно выполнять, если не понимаешь ни контекст, ни «как это сделать».
Когда они условно-подробные — их тупо неудобно быстро выполнять, и большинство опытных тестировщиков просто перестают их читать (а там что-то может быть изменено, ойёпт), но их можно предсказуемо выполнять средне-медленно, потому что есть подробная инструкция, которую придётся переписывать во множестве мест, если что-то где-то ВНЕЗАПНО поменяется… Ой.
Логично предположить, что если мы будем придерживаться одного ХОРОШЕГО стандарта, то все сложности исчезнут. Однако логично и то, что «стандарты» всегда тяготеют к «пусть будет много нужной и полезной информации», а это всегда в итоге формат «условно-подробнейших тест-кейсов», которые постоянно хочется «переписать попроще», но времени нет.
Нет нужды упарываться по исчерпывающе хорошим тест-кейсам, важнее заморачиваться продумыванием ситуаций, которые должны происходить (первый уровень осознания требований) и которые могут происходить (второй уровень), когда ПО будет работать. Если я понимаю тему, то тестов я вам накатаю бесконечно много. Если я не понимаю тему, то смысл их катать?
Тест-кейс — инструкция по созданию тестовой ситуации.
Иногда ситуацию можно объяснить одним предложением, и результат её очевиден. Иногда надо предварительно объяснить предусловия и не факт, что всё будет понятно. Иногда достаточно просто упомянуть, что «а ещё в базе надо проверить, что наценка на товар правильно применилась и повсюду посчиталась». Иногда надо прямо указать, куда зайти и какой запрос использовать.
Не нужно искать один-единый формат тест-кейсов. На одном и том же проекте надо использовать разные форматы тестов в зависимости от условий и контекста возникающих задач.
Общий подход — пишем тесты в виде идей. Коротко.
Идею можно уточнять — добавить несколько нужных строк. Если выглядит достаточно понятным самому себе — всё норм.
Идею можно снабжать отсылкой к подробной инструкции для выполнению отдельных шагов. Инструкции можно записывать в общие места (Confluence, Notion, тыды).
Какие-то тесты навсегда останутся однострочниками. Какие-то будут монстрами. Думать надо о том, чтобы они были понятными, а не стараться заранее определять, что и как из них получится.
Знать такое заранее было бы так же смело и странно, как точно знать завтрашний курс криптовалюты в Молдове и смело призывать всех вкладывать в передовую технологию будущего из прошлого ценную международную валюту с изображением Штефана чел Маре.
