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