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