http://software-testing.ru/library/testing/general-testing/2562-testing-problems-are-test-results
И референс к предыдущей впечатлившей меня статье:
вам не нужно больше тестировщиков.
Оригинал статьи:
http://www.developsense.com/blog/2011/09/testing-problems-are-test-results/
Автор: Майкл Болтон (Michael Bolton)
Перевод: Ольга Алифанова
В курсе Rapid Software Testing я даю студентам такое упражнение: я прошу их перечислить все, что, с их точки зрения, усложняет или замедляет тестирование. Их ответы, как правило, однотипны – я регулярно слышу одни и те же вариации (пример таких ответов можно посмотреть, к примеру, в обсуждении на Stack Exchange). Обычно это примерно следующий перечень:
- Я единственный тестировщик, и работаю с несколькими
разработчиками (или один из тестировщиков, и в нашей команде много
разработчиков).
- Я очень сильно ограничен по времени. Постоянно приходят новые билды, и мы релизимся каждую неделю-две.
- Продукт(ы), который я тестирую, очень сложен сам по себе.
- Между модулями продукта (или между разными продуктами) множество взаимозависимостей.
- Я вижу, что ряд проблем возникает именно из-за этих
взаимозависимостей – небольшое изменение в одном модуле может
повлечь за собой катастрофу в другом.
- Я считаю, что для отлова подобных багов нужно прогонять полный регресс для каждого нового билда.
- Я стараюсь справиться с задачей, используя автотесты, но
сложность продукта затрудняет автоматизацию тестирования – "якоря"
для автотестов минимальны или отсутствуют, а частые изменения
продукта усложняют поддержку автоматизации.
- На поддержку автотестов уходит приличное время, и я не успеваю заняться тестами, которые хотел бы прогнать.
- Все это сильно выматывает, но я пытаюсь справляться.
И, в плюс к вышеперечисленному,
- Компания, в которой я работаю, утверждает, что работает по Agile
- Помимо двухнедельных итераций, на самом деле мы применяем максимум
пару практик, относящихся к Agile-подходу – как правило, ежедневные
scrum-встречи или канбан-доски.
И вишенка на торте:
- Приходящие на тестирование билды очень нестабильны. Система падает
при самых базовых smoke-тестах, и мне приходится ждать и/или
пересобирать билд вместо того, чтобы заниматься своим прямым делом.
Как можно проанализировать эти наблюдения?
Мы можем расценивать их, как проблемы тестирования, но мы также можем взглянуть на них иначе – как на
результаты тестирования.
Результаты тестирования не говорят нам, что что-то пошло хорошо или
плохо. Они поставляют информацию для принятия решений, оценки, и тому
подобных вещей. Люди, получающие результаты тестирования, решают, есть
ли в продукте проблемы и в чем они заключаются, что еще надо выяснить, и
какие решения принять. Это требует участия живых людей, оценки
множества факторов, и нескольких возможных интерпретаций.
Так же, как и в случае с автотестами и другими результатами
тестирования, очень важно принимать во внимание весь спектр возможных
причин и интерпретаций
мета-результатов тестирования –
наблюдений, касающихся тестирования. Если мы этого не делаем, то рискуем
упустить важные проблемы, угрожающие качеству как тестирования, так и
продукта как такового.
Джерри Вайнберг в своей книге "Perfect Software and other illusions
about testing" отмечает, что то, что мы получаем в качестве результата –
это прежде всего информация. Если тестирование, по словам Джерри – это
сбор информации с целью ее передачи лицам, принимающим решения, то
нельзя оставлять за бортом потенциально значимые наблюдения.
Тестируя, мы часто сталкиваемся с теми или иными проблемами. Однако вместо того, чтобы относиться к ним как к проблемам
для тестирования, мы можем также думать о них, как о
симптомах проблем продукта или проекта – проблем, которые тестирование может решить.
К примеру, если тестировщик страдает из-за большого количества
разработчиков, или если тестировщику не хватает времени на тестирование –
это результат теста. Зачастую это ощущение вызывается тем, что
программисты генерируют столько сложных задач, что тестировщик просто
не может справиться с ними в одиночку. Сложность, как и качество – это
взаимоотношение между человеком и чем-либо еще. Сама по себе сложность
необязательно будет проблемой, в отличие от реакции людей на нее.
Наблюдая за тем, как люди реагируют на субъективную сложность и риски,
мы можем узнать много полезного.
- Помогаем ли мы, как тестировщики, коллегам иметь представление о рисках – особенно о "Черных лебедях" – которые обычно ассоциируются со сложностью?
- Если люди представляют себе риски, обращают ли они на них
внимание? Паникуют ли они, или просто игнорируют в надежде, что все
образуется? Или что-то другое?
- Реагируют ли люди спокойно и прагматично? Признают ли они сложность продукта, пытаются ли с ней справляться?
- Если сложность продукта или процесса нельзя снизить,
предпринимается ли что-то для того, чтобы сделать продукт/процесс
проще для понимания?
- Случается ли, что программисты пишут или изменяют код так
быстро, что у них просто нет времени разобраться, что же там на
самом деле происходит?
- Если кто-то полагает, что команде нужно больше тестировщиков, почему он так думает? (Я обсуждал этот вопрос несколько лет назад)
Как же найти ответы на эти вопросы? Один из способов – внимательно посмотреть на результаты и мета-результаты тестирования:
- Считает ли кто-то в команде, что тестирование затруднено или занимает много времени? Кто?
- Почему он так думает, какие предположения привели его к этой мысли?
- Не ухудшается ли тестовое покрытие от того, что тестировщики тратят
много времени на исследование, локализацию и оформление багов? (Я писал
об этой проблеме ранее).
- Выявляет ли тестирование единообразные паттерны отказов?
- Систематически ли эти отказы и их паттерны удивляют программистов?
- Вызывают ли небольшие изменения кода большие или трудноуловимые проблемы?
- Хорошо ли программисты понимают внутренние взаимосвязи продукта? Необходимы ли продукту эти взаимосвязи, или их можно избежать?
- Предпринимают ли разработчики какие-то шаги для предотвращения или
предупреждения проблем, связанных с интерфейсами и взаимодействиями?
- Если автоматические проверки трудно разработать и поддерживать,
говорит ли эта ситуация об уровне профессиональных навыков
тестировщиков, качестве интерфейсов автоматизации, или масштабе
проверок? Или она сигнализирует о чем-то еще?
- Мешают ли нестабильные билды глубокому тестированию?
- Можно ли интерпретировать нестабильные билды как знак того, что в
продукте настолько много серьезных проблем, что их можно найти даже при
поверхностном тестировании?
- Если после череды нестабильных билдов наконец-то появился стабильный – насколько он на самом деле стабилен?
Возможно, получив ответы на эти вопросы, мы можем задать еще больше вопросов.
- Как эти проблемы угрожают успеху продукта в краткосрочном и долгосрочном периодах?
- Если тестирование систематически выявляет паттерны отказов и
сопутствующих рисков, что делает команда с этой информацией?
- Обязаны ли программисты только и исключительно предоставить
код, или они обязаны предоставить код с гарантией, что этот код
делает то, что должен (и не делает того, что не должен), насколько
им известно? Насколько искренне программистам предпочтителен второй
вариант?
- Заставляет ли кто-то программистов выдерживать сроки/объемы работ, в которые они на самом деле не могут уложиться?
- Могут ли программисты и тестировщики противостоять навязанным
им срокам и объемам работы, если эти сроки повышают продуктовые или
проектные риски?
- Прислушивается ли бизнес к опасениям команды? Знают ли они о
рисках, найденных тестировщиками и разработчиками? Когда команда
разработки указывает на существующие риски, предпринимает ли
менеджмент/бизнес адекватные шаги в ответ на это?
- Работает ли команда в комфортном режиме, или продукт/проект
серьезно задавлен сложностью, внутренними взаимосвязями, хрупкостью
и трудностями, находящимися за пределами возможностей
разработки/тестирования справиться с ними?
- Действительно ли команда работает по Agile, соблюдая
манифест Agile? Может, "гибкость" используется как карго-культ –
практики и артефакты только маскируют бестолковость проекта?
Тестировщики зачастую считают, что их задача – искать, исследовать и
сообщать о багах в тестируемом ПО. Обычно это так и есть, но такой
взгляд на тестирование крайне ограничен. Продукт – это все, что кем-то
произведено: программа, требования, диаграмма, спецификация, график,
прототип, процесс, идея… Тестирование может искать информацию о любых
продуктах, если им уделяется достаточное внимание.
С одной стороны, проблемы, перечисленные в начале этой статьи, выглядят
серьезными проблемами тестирования. Возможно, это так, но это не все,
что за ними стоит. Если вспомнить определение Джерри Вайнберга –
"тестирование – это сбор информации для передачи ее людям, принимающим
решения", окажется, что абсолютно все, что мы обнаруживаем и замечаем в
процессе тестирования – это результат тестирования.
