Сегодня утром пересматривал ссылки с интересными заголовками на http://mmm.software-testing.ru/library/testing и наткнулся на статью.
Статья напомнила мне мои недавние размышления на эту же тему - нужны ли нам подробные тест кейсы и как вести тестовую документацию так, чтобы она приносила пользу команде, проекту и компании.
На многих проектах (по опыту моих проектов и судя по рассказам QA инженеров и менеджеров из разных компаний и команд) тестовая документация либо не ведётся совсем, либо ведётся совершенно формально, "чтобы было", и даже чек листы не отражают реального положения дел и не включают в себя все тесты, которые на самом деле проверяют инженеры перед запуском в продакшн.
Другой пример - на проектах, где из тестовой документации есть только чек листы, каждый инженер трактует тест кейсы "по-своему" (потому что нет описания того что именно надо проверить, есть только название фичи), в результате чего нет полной уверенности, что тест кейс будет выполнен так, как себе представлял тест аналитик, который его написал (даже если тест аналитиком был один из инженеров этой же команды). И от версии к версии у нас нет повторяемости проводимых тестовых испытаний, как нет и видения что на самом деле было проверено.
Так какая тестовая документация нужна и почему?
Конечно, если тестовая документация ведется только для отвода глаз, она, как правило, не обновляется, и поэтому она не только не помогает тестировать, но иногда и мешает - проверяем одно, в тестовые репорты пишем другое, некоторые тест кейсы уже либо совсем не применимы (например, фичи такой больше нет) либо выполняются не так, как описаны и проверяется совсем другой результат.
Если тестовой документации нет, то у команды тестирования в большинстве случаев нет и целостной картины как и зачем проводится тестирование и что является результатом проделанной работы. Возникает впечатление, что "баги всегда останутся в продукте", "оно не работает" и нет ощущения, что это когда нибудь будет исправлено и мы сможем гордиться нашим продуктом.
Тестирование превращается в отчаянные попытки "проверить всё" без понимания что именно проверить для нас критично и почему и сколько нам необходимо времени для проведения полного тестирования (даже на проектах, где есть отличная автоматизация, всё равно есть ручное тестирование).
Непонимание того, что и зачем мы тестируем, приводит к ошибкам. Мы пропускаем баги, а получаемые отчёты не отражают настоящего положения вещей и баги уходят в продакшн.
Так при чём здесь тестовая документация?
Недавно на моём проекте произошёл показательный случай, который меня кое-чему научил. На проект выделили пять новых инженеров (пользуясь моментом, передаю привет тем. кто узнал в них себя), на две недели, чтобы усиленно потестировать новый функционал перед деплоем на продакшн. У нас было пять новых инженеров, которые не знакомы с проектом и две недели до релиза. Проект сложный, разбираться самостоятельно только на основе предыдущего опыта можно долго. Но у меня уже была написанная тестовая документация по проекту - чек листы и детальный тест план по функциональному тестированию, с описанием основных тестовых сценариев. За один день, используя уже существующие тестовые сценарии, я написал недостающие тест кейсы для нового функционала, который мы хотели протестировать, обновил чек лист и уже на следущий день пятеро инженеров тестировали проект!
Конечно, я провел показательную демонстрацию на одном из тестовых сценариев - организовал конференцию для удалённой команды и показал на своём экране что значит каждый из описанных шагов в тестовом сценарии и где находится основной функционал приложения. Эта демонстрация заняла пол часа, после чего они попробовали сами и мы еще раз прошли по сценарию, чтобы убедиться что они могут выполнить его самостоятельно. Это заняло еще пол часа, учитывая уточняющие вопросы и общие вопросы по проекту.
Все остальные две недели пятеро инженеров работали, без проблем проходя тестовые сценарии и отмечая результаты в чек листах (перед выполнением теста они отмечали что начали его выполнять), и мне оставалось поддерживать тестовую инфраструктуру в актуальном состоянии (чтобы тестировалась всегда последняя версия продукта) и отвечать на вопросы в скайп, которых было не много.
Если бы у меня не было детального тест плана, я мог бы потратить эти две недели на обучение новых инженеров и по прошествии этого времени проект так и остался бы не проверенным достаточно хорошо - ведь у меня не было бы никой уверенности, что я достаточно хорошо объяснил то, как надо проверять, что меня поняли именно так, как нужно, и никто бы не смог сказать наверняка, когда мы можем заканчивать тестирование и готовы ли мы к релизу - потому что без тестовой документации не понятно что мы проверили, а что нет.
Никогда не знаешь, когда подобная ситуация произойдёт. Ведь тест план может пригодиться и для обучения новых инженеров, и для того, чтобы продемонстрировать кому-нибудь что именно мы проверяем, и для того, чтобы мы в любой момент могли устроить ревью наших тестов, например, по результатам ретроспективы.
Тестовая документация должна быть и она должна быть актуальной. Если она не требуется сейчас, это не значит, что она не пригодится вам завтра. Если не хотите в один день обнаружить, что нужная вам документация неактуальна или совсем отсутствует, то нужно уделять время на её поддержку, ведь поддержка документации не потребует много времени, а у вас появится отличный шанс раз в неделю или месяц пройтись по всем тестовым сценариям и оценить на сколько хорошо мы проверяем продукт и стоит ли добавить новые проверки. А ведь в таком случае тестовая документация будет полезна даже если вы единственный инженер по обеспечению качества на проекте.
И вот теперь уже не сомневаюсь - тестовая документация мне нужна и я буду её писать и обновлять, и точно знаю, что смогу использовать её, когда она будет нужна. Вы, конечно, можете не соглашаться - проекты бывают разные и разные требования к качеству и срокам. Если документация только отнимает время и не приносит никакой пользы, попробуйте уменьшить её объём и менять форму - меняйте до тех пор, пока не почувствуете, что ваш труд приносит результаты.
Статья напомнила мне мои недавние размышления на эту же тему - нужны ли нам подробные тест кейсы и как вести тестовую документацию так, чтобы она приносила пользу команде, проекту и компании.
На многих проектах (по опыту моих проектов и судя по рассказам QA инженеров и менеджеров из разных компаний и команд) тестовая документация либо не ведётся совсем, либо ведётся совершенно формально, "чтобы было", и даже чек листы не отражают реального положения дел и не включают в себя все тесты, которые на самом деле проверяют инженеры перед запуском в продакшн.
Другой пример - на проектах, где из тестовой документации есть только чек листы, каждый инженер трактует тест кейсы "по-своему" (потому что нет описания того что именно надо проверить, есть только название фичи), в результате чего нет полной уверенности, что тест кейс будет выполнен так, как себе представлял тест аналитик, который его написал (даже если тест аналитиком был один из инженеров этой же команды). И от версии к версии у нас нет повторяемости проводимых тестовых испытаний, как нет и видения что на самом деле было проверено.
Так какая тестовая документация нужна и почему?
Конечно, если тестовая документация ведется только для отвода глаз, она, как правило, не обновляется, и поэтому она не только не помогает тестировать, но иногда и мешает - проверяем одно, в тестовые репорты пишем другое, некоторые тест кейсы уже либо совсем не применимы (например, фичи такой больше нет) либо выполняются не так, как описаны и проверяется совсем другой результат.
Если тестовой документации нет, то у команды тестирования в большинстве случаев нет и целостной картины как и зачем проводится тестирование и что является результатом проделанной работы. Возникает впечатление, что "баги всегда останутся в продукте", "оно не работает" и нет ощущения, что это когда нибудь будет исправлено и мы сможем гордиться нашим продуктом.
Тестирование превращается в отчаянные попытки "проверить всё" без понимания что именно проверить для нас критично и почему и сколько нам необходимо времени для проведения полного тестирования (даже на проектах, где есть отличная автоматизация, всё равно есть ручное тестирование).
Непонимание того, что и зачем мы тестируем, приводит к ошибкам. Мы пропускаем баги, а получаемые отчёты не отражают настоящего положения вещей и баги уходят в продакшн.
Так при чём здесь тестовая документация?
Недавно на моём проекте произошёл показательный случай, который меня кое-чему научил. На проект выделили пять новых инженеров (пользуясь моментом, передаю привет тем. кто узнал в них себя), на две недели, чтобы усиленно потестировать новый функционал перед деплоем на продакшн. У нас было пять новых инженеров, которые не знакомы с проектом и две недели до релиза. Проект сложный, разбираться самостоятельно только на основе предыдущего опыта можно долго. Но у меня уже была написанная тестовая документация по проекту - чек листы и детальный тест план по функциональному тестированию, с описанием основных тестовых сценариев. За один день, используя уже существующие тестовые сценарии, я написал недостающие тест кейсы для нового функционала, который мы хотели протестировать, обновил чек лист и уже на следущий день пятеро инженеров тестировали проект!
Конечно, я провел показательную демонстрацию на одном из тестовых сценариев - организовал конференцию для удалённой команды и показал на своём экране что значит каждый из описанных шагов в тестовом сценарии и где находится основной функционал приложения. Эта демонстрация заняла пол часа, после чего они попробовали сами и мы еще раз прошли по сценарию, чтобы убедиться что они могут выполнить его самостоятельно. Это заняло еще пол часа, учитывая уточняющие вопросы и общие вопросы по проекту.
Все остальные две недели пятеро инженеров работали, без проблем проходя тестовые сценарии и отмечая результаты в чек листах (перед выполнением теста они отмечали что начали его выполнять), и мне оставалось поддерживать тестовую инфраструктуру в актуальном состоянии (чтобы тестировалась всегда последняя версия продукта) и отвечать на вопросы в скайп, которых было не много.
Если бы у меня не было детального тест плана, я мог бы потратить эти две недели на обучение новых инженеров и по прошествии этого времени проект так и остался бы не проверенным достаточно хорошо - ведь у меня не было бы никой уверенности, что я достаточно хорошо объяснил то, как надо проверять, что меня поняли именно так, как нужно, и никто бы не смог сказать наверняка, когда мы можем заканчивать тестирование и готовы ли мы к релизу - потому что без тестовой документации не понятно что мы проверили, а что нет.
Никогда не знаешь, когда подобная ситуация произойдёт. Ведь тест план может пригодиться и для обучения новых инженеров, и для того, чтобы продемонстрировать кому-нибудь что именно мы проверяем, и для того, чтобы мы в любой момент могли устроить ревью наших тестов, например, по результатам ретроспективы.
Тестовая документация должна быть и она должна быть актуальной. Если она не требуется сейчас, это не значит, что она не пригодится вам завтра. Если не хотите в один день обнаружить, что нужная вам документация неактуальна или совсем отсутствует, то нужно уделять время на её поддержку, ведь поддержка документации не потребует много времени, а у вас появится отличный шанс раз в неделю или месяц пройтись по всем тестовым сценариям и оценить на сколько хорошо мы проверяем продукт и стоит ли добавить новые проверки. А ведь в таком случае тестовая документация будет полезна даже если вы единственный инженер по обеспечению качества на проекте.
И вот теперь уже не сомневаюсь - тестовая документация мне нужна и я буду её писать и обновлять, и точно знаю, что смогу использовать её, когда она будет нужна. Вы, конечно, можете не соглашаться - проекты бывают разные и разные требования к качеству и срокам. Если документация только отнимает время и не приносит никакой пользы, попробуйте уменьшить её объём и менять форму - меняйте до тех пор, пока не почувствуете, что ваш труд приносит результаты.
Комментариев нет:
Отправить комментарий
Я признателен Вам за то, что делитесь своим мнением