Коллеги из software-testing.ru прислали цитату из статьи Майкла Болтона
Тестировщики, хватит заниматься обеспечением качества. Как человек, много проработавший в тестировании, не могу не опубликовать, потому что Майкл, конечно, пишет дело:
Рекомендации относительно того, как тестировщики могут оказывать позитивное влияние на менеджеров.
- Оказывайте проекту сервис, а не будьте помехой. Вы поставляете информацию, а не насаждаете процессы.
- Предоставьте менеджерам информацию, которая им требуется для принятия решений, а затем позвольте им принять эти решения.
- Полностью осознавайте, что они принимают не технические, а бизнес-решения.
- Помните, что продукт не обязательно должен соответствовать вашему стандарту качества.
- Ни менеджер разработки, ни кто-либо другой не обременен должностной обязанностью делать вас счастливым. Возможно, часть их работы — помочь вам работать более эффективно. Помогите им разобраться, как это сделать. В частности, обратите внимание на тот факт, что…
- Проблемы, которые замедляют тестирование, крайне важны, поскольку из-за них долго не обнаруживаются ошибки, и найти их становится все труднее. Поэтому сообщайте не только об ошибках в продукте, но и о проблемах, которые замедляют тестирование.
- Обратите внимание (поскольку это обычное дело), почему тестирование занимает столько времени – как мало времени вы тратите на собственно тестирование продукта, и как много времени вы тратите на исследование ошибок и отчетность, работы по настройке, совещания, решение организационных вопросов и другие работы, чтобы обеспечить тестовое покрытие.
- Концентрируйтесь на том, чтобы сделать отчеты точными (скажем, добиваясь точности 5-10%), а не сверхточными, поскольку значительную часть проблем в разработке программного обеспечения можно обнаружить и решить с помощью измерений первого порядка, а не при помощи анализа шести знаков после запятой, значения которых получены с помощью моделей, которые сами оказываются неверными.
- Покажите менеджерам, что большая часть проблем, которые вы находите, обнаруживается не при помощи бездумного повторения тестовых сценариев, а при помощи действий и наблюдений, которые не покроешь тестовыми сценариями, т.е. благодаря интеллектуальному изучению продукта.
- Помогите менеджерам, а также программистам осознать, что автоматизация тестирования — это больше, гораздо больше, чем создание программы, которая заставляет компьютер нажимать на клавиши.
- Помогите всем понять, что автоматизация расширяет возможности некоторых видов тестирования и значительно ограничивает другие.
- Покажите, что ваша работа – это исследование продукта, требующее знаний, и разъясните менеджерам, как мы на самом деле обнаруживаем проблемы.
- Помогите менеджерам и программистам избежать неверного понимания «фазы тестирования». На самом деле это: фаза обнаруженияи исправления ошибок.
Майкл Болтон является одним из наиболее активных евангелистов школы контекстно-ориентированного тестирования. Он имеет более чем 20-летний опыт работы в области тестирования. Майкл регулярно выступает на конференциях, проводит тренинги и семинары, с 2005 года является постоянным колумнистом одного из самых популярных журналов в области тестирования Better Software и ведёт замечательный блог о тестировании www.developsense.com/blog.shtml
17-18 ноября Майкл Болтон приезжает в Санкт-Петербург, где проведет один из лучших тренингов по тестированию ПО «Rapid Software Testing», разработанный им совместно с Джеймсом Бахом.
Pavel Agurov November 2nd, 2010 at 17:46
Дополнение: продумайте и предложите чтобы вы хотели видеть из нутра системы, что облегчит тестирование.
Например, система делает расчет данных и выводит результат. Тестировать это сложно, т.к. виден только результат. Хорошо бы видеть еще (список переменных).
Система загружает данные из внешнего источника – хорошо бы видеть лог загрузки.
Продумайте варианты облегчения тестирования. Система загружает данные из внешнего источника? Хорошо бы иметь возможность “подсунуть” свои, тестовые данные, на которых легче проводить тестирование.
И т.д. Задумайтесь как упростить себе жизнь и улучшить этим продукт.
@Pavel Agurov:
Полная версия статьи, ссылка на которую находится в начале, содержит рекомендации не только про то, как повлиять на менеджеров, но и про то, как повлиять на программистов, там есть советы, достаточно близкие к тому, что Вы написали.
Но конечно такое разделение (так надо влиять на менеджеров, а так на программистов) весьма условно. Всегда в частном случае надо искать решения в конкретном контексте
Последние коментарии