Как говорить о тестировании

У менеджеров, разработчиков и даже тестировщиков часто появляются нуждающиеся в ответе вопросы о тестировании:

• Почему мы не нашли этот баг до релиза?
• Почему мы не предотвращаем проблемы вместо того, чтобы тестировать?
• Тестирование улучшилось бы при использовании практики Х – прямо как у компании Y!
• Почему нельзя автоматизировать все тестирование?
• Почему тестирование занимает так много времени? Сколько тестирования достаточно?
• Зачем нам специализированные тестировщики? Почему нельзя просто получить обратную связь от пользователей? Почему тестированием не могут заниматься разработчики? Почему им не могут заниматься вообще все?

Такие вопросы часто возникают, когда у организации есть проблемы, предположительно возникающие из-за тестирования или где-то рядом с ним. Однако для разрешения этих вопросов нужно вначале понять, чем является тестирование – и чем не является. Затем нужно понять, из чего оно состоит, как эти части связаны друг с другом, и какими словами их описывать. Только тогда можно начать продуктивно говорить о тестировании – без бесполезных концепций, которые в противном случае будут присутствовать в разговоре.

В этой статье два раздела:

• Основы тестирования (то, что вам нужно знать о тестировании, чтобы внятно о нем разговаривать)
• Разговорные паттерны тестирования (виды бесед, которые вы можете вести о тестировании)

Основы тестирования

Мощное определение тестирования – это "процесс оценки продукта путем его изучения через исследование и эксперименты". Это значит, что тестирование – это не то же, что ревью, инспекция или "обеспечение качества", хотя там оно тоже играет свою роль.

Под "оценкой" я в первую очередь имею в виду выявление всего того в продукте, что потенциально может ему угрожать. Потенциальные проблемы еще называются риском. Следовательно, тестирование – это процесс анализа ассоциированного с продуктом бизнес-риска (теперь давайте просто называть это "продуктовым риском").

1. Суть тестирования – в вере в существование проблем и в их активном поиске.

Тестирование – имманентно скептичный процесс. Сущность тестирования в основном в том, как вы думаете обо всем, что видите. Тестировщик должен быть отрицательно предубежден (потому что лучше думать, что вы видите проблему, и ошибиться, чем ошибиться в том, что проблема отсутствует). Когда компетентный тестировщик видит продукт, который с первого взгляда вроде бы работает, он не реагирует "Ура, работает!" – он говорит "Возможно, что продукт достаточно хорош для релиза, но также возможно, что в нем есть пока не выявленные серьезные проблемы". Только после проведения достаточного тестирования (с достаточным покрытием, с достаточно чувствительными к бизнес-риску оракулами) тестировщик может сформировать хорошо обоснованное мнение о статусе продукта.

Тестирование никогда не "доказывает", что продукт соответствует требованиям. Это истинно и для науки в целом – можно опровергнуть теорию о мире на основании одного-единственного факта, но никогда нельзя доказать истинность этой теории, потому что это потребует сбора абсолютно всех возможных фактов. Представьте бочку с яблоками. Можно взять одно, увидеть, что оно гнилое, и сделать из этого вывод, что бочка не удовлетворяет требованию "должна содержать только свежие яблоки". Однако если это яблоко свежее, невозможно сделать вывод, что все прочие яблоки в ней так же хороши.

Процесс тестирования не определяет, "готов" ли продукт и пригоден ли он для релиза. Иными словами, нет способа установить непротиворечивый, алгоритмический или математический критерий, способный влиять на хорошее, ответственное бизнес-решение о релизе. Вместо этого тестирование добывает необходимые менеджменту (тем, кто отвечает за принятие релизных решений) данные, чтобы решение о релизе было достаточно информированным. Выпуск ПО – это сложное бизнес-решение, а не простая техническая задача.

Процесс тестирования – это обучение. Тот, кто не учится, тестируя – не тестирует. Конечно, мы хотим выяснить статус продукта, но мы также хотим узнать, как нас можно обмануть, протащив мимо нас важные проблемы. Хорошее тестирование требует постоянного обновления способов обнаружения проблем – частично на основе багов, найденных только после релиза.

Миссия тестирования – информировать заинтересованных лиц. Если конкретнее, тестирование существует для того, чтобы предоставлять заинтересованным лицам правильную информацию, нужную им для принятия достаточно хорошо информированных решений о продукте. Сам по себе процесс тестирования не может и не должен определить, "достаточно ли хорош" продукт для релиза – это решение принадлежит заинтересованным лицам.

Почему это важно: если мы не можем понимать и уважать суть тестирования, у менеджмента и других сторонних лиц будут раздутые ожидания от того .что тестирование может им дать – и они могут использовать тестирование в качестве козла отпущения в случае проблем, возникших где-то еще

2. Тест – это эксперимент, который человек проводит над продуктом

Представьте "пьесу" в театре. Сценарий пьесы часто тоже называется пьесой, но настоящая пьеса – это само представление, с актерами на сцене. Люди могут даже говорить о "пьесе", как о наборе представлений (к примеру, "пьеса шла на Бродвее четыре недели").

Думайте о тесте в том же ключе. Неформально мы можем называть тест-спецификацию "тестом", но постарайтесь никогда не забывать, что тест-спецификация никогда не описывает реальный проведенный тест полностью, потому что к тесту прилагаются человеческое внимание и суждение. Мы также можем говорить о "таком же тесте" спустя какое-то время – даже несмотря на то, что тест развивается и, возможно, никогда не проводится в точности одинаковым образом дважды.

Просто помните, что на самом деле "тест" не будет действительно тестом – кроме момента, когда он выполняется. Тогда он становится реальным, к лучшему (когда этим занят квалифицированный и мотивированный тестировщик) или худшему (когда у руля некомпетентный, невнимательный тестировщик). Многие тесты начинают свой путь как открытые вопросы и наброски, и со временем становятся детальнее и систематизированнее. Тестирование по своей сути деятельность исследовательская, как и сам процесс разработки продукта. Это верно даже для тестов с автоматизированными элементами, так как автоматизацию нужно прототипировать, дебажить, поддерживать.

Почему это важно: это определение преподносит тестирование как имманентно человеческую деятельность, которой можно помочь инструментами, но нельзя целиком автоматизировать. Такое определение помогает защищать процесс тестирования от попыток чересчур его упростить или отмахнуться от него.

3. Мотивация для тестирования – это риск

Нет продуктового риска – нет нужды тестировать. Тестирование начинается с некоей веры, что продуктовый риск существует; обычно эта вера проистекает из различных индикаторов риска, вроде существования сложных связей и потенциального вреда, если код поведет себя плохо. В ходе тестирования и обнаружения проблем (или неспособности их обнаружить) вера в риск заменяется основанными на фактах суждениями о риске, пока эти самые суждения не приведут тестировщиков к выводу, что известно уже достаточно, и менеджмент может принимать достаточно информированные решения о продукте.

Следовательно, способность систематически думать о риске – это ключевой фактор для профессионального тестирования.

Почему это важно: несмотря на то, что риск – основа тестирования, мало кто обучен думать о нем. Это приводит к бессистемной тест-стратегии и трате сил. Между тем, каждый раз при проектировании теста вы должны быть способны ответить на вопрос, почему этот тест вообще должен существовать. Ответ "потому что продукт может не работать" недостаточно хорош. Что именно может не сработать? Каким образом оно может не сработать? Насколько это вероятное событие? Единственный ли это тест, покрывающий продукт? Какую конкретную ценность дает этот конкретный тест?

4. Любой, занимающийся тестированием, в этот момент - тестировщик

Хорошее тестирование требует определенных интеллектуальных, социальных и технических навыков, но, как и в случае с кулинарией, практически кто угодно может до определенной степени заниматься тестированием, и практически кто угодно может внести свой вклад в отличный процесс тестирования.

Некоторые специализируются в тестировании – это тестировщики полного рабочего дня. Но для целей этого документа понятие "тестировщик" применимо к кому угодно – разработчику, менеджеру и т. д., - кто на данный момент вовлечен в попытки протестировать продукт.

Нужно различать два вида тестировщиков – ответственных и поддерживающих. Ответственный тестировщик – это любой тестировщик, отвечающий за качество своей собственной работы. Иными словами, ответственные тестировщики в норме работают без надзора. Ответственные тестировщики также самостоятельно выбирают тактики и техники, и сами решают, когда остановить тестирование. От поддерживающих тестировщиков не ожидается, что они будут контролировать свою собственную тест-стратегию. Это все те, кто заглядывает помочь с тестированием, или другие тестировщики, работающие только под присмотром тест-лида. Зачастую задача создания формальных баг-репортов зарезервирована за ответственными тестировщиками.

Почему это важно: многие годы тестированием в основном занимались специалисты, располагающие временем и концентрирующиеся на выявлении глубинных истин о продукте. С приходом Agile в тестирование стали вовлекаться те, кто не делает его своей специальностью и не располагает временем на его планирование или повышение собственных тест-навыков. Это значит, что необходимо явно обсуждать и оценивать важнейшие элементы тестирования, а не предполагать по умолчанию, что те, кто погружен в тестирование, проведут его согласно профессиональным стандартам.

5. Тестирование – это не верификация, верификация – часть тестирования

Верифицировать можно только то, у чего есть истинное значение – правда или ложь. Однако у качества продукта такого значения нет – отчасти потому, что "качество" – многомерная концепция, включающая субъективные компромиссы. Можно верифицировать, что на "томатометре" фильм заработал 46,7, но нельзя верифицировать, действительно ли он хуже фильма, получившего там же 53,2. Люди могут обоснованно спорить о качестве фильмов – и точно так же они могут спорить о качестве ПО. В этом смысле качество можно оценить – можно прийти к основанному на фактах суждению о нем, - но нельзя верифицировать. Качество нельзя осмысленно свести к одному-единственному измерению. Скажем, я могу верифицировать, что если на входе 2+2, то сразу после запуска конкретный калькулятор в конкретное время отобразит на экране "4". Но это не верификация того, что "сложение работает". Другими словами, верификация устанавливает факты, но ни один набор фактов с конечным покрытием не будет логически эквивалентен широкому обобщению.

В методологии Rapid Software Testing мы называем верификацию "проверками" – сокращение от "проверки фактов". Но тестирование – это больше, чем проверки. Тестирование использует верификацию как тактику, но также включает критическое мышление, неявное знание и социальную компетенцию. Тестирование – это еще и озарения. Тестирование – это процесс поиска смысла и построения теорий на основании наблюдаемых фактов. Это куда больше простой верификации.

В отличие от верификации, тестирование пытается прибегать к обоснованным обобщениям – скачкам суждения – на основании фактов, и менеджмент может использовать эти обобщения для принятия решений. В результате тестирования формируется оценка качества продукта.

Почему это важно: верификация зачастую проста. Тестировать сложно. Очень соблазнительно выполнять проверки фактов вместо тестов, потому что проверки не требуют рассуждений, и, следовательно, никто вас не опровергнет. Проверки безопасны и объективны. Но именно эти качества систематически делают их поверхностными и обманчивыми. Стратегия, сконцентрированная исключительно на верификации, пройдет мимо больших продуктовых рисков, которые любой разумный тестировщик должен выявить и исследовать.

6. Выполнение тестов – всего лишь часть тестирования

Каждый раз, когда вы экспериментируете над продуктом и исследуете его с целью поиска багов (включая автоматизацию, помогающую этим заниматься), вы выполняете тесты.

Но тестирование – это еще и переговоры с командой, проектирование тестов, проработка наборов данных, разработка инструментов, использование инструментов для создания и проведения проверок, изучение спецификаций, написание баг-репортов, отслеживание багов, исследование использованной в создании продукта технологии, изучение пользователей, планирование, и т. д. Любой из этих видов деятельности – это тестирование, если посвящен миссии тестирования.

Иными словами, тестирование – это больше, нежели простое проведение тестов, и нельзя просто указать на набор тест-кейсов, говоря "вот оно тестирование, прямо тут". Нет, это не оно. Тестирование – это весь процесс, посвященный миссии тестирования, целиком.

Почему это важно: хорошее тестирование требует, чтобы у тестировщиков было время и ресурсы на обучение, моделирование, проектирование, запись, сбор, обсуждение, и т. п. Допущение, что процесс состоит исключительно из написания тест-кейсов и их прогона, не просто ложно – оно несет огромный вред. Оно заставляет тестировщиков работать торопливо и плохо, что выливается в поверхностное тестирование, упускающее важные баги.

7. Ответственный тестировщик должен мыслить иначе, чем разработчик

Разработчику нужно придумать один хороший способ заставить все работать; тестировщик пытается вообразить 999 вариантов того, как оно откажется работать. Это нельзя описывать как "конструктивно-деструктивную" дихотомию – тестировщик ничего не разрушает (кроме, возможно, нашей иллюзорной уверенности). Дихотомия тут скорее "оптимист – пессимист" или "императивное (делай это!) – гипотетическое (а что, если?)".

Тестировщики живут в мире множества гипотетических отказов, абсолютное большинство которых никогда не произойдет, но многие из которых мы обязаны исследовать – потому что некоторые все же случатся. На взгляд разработчика, тестирование выглядит, как бесконечный, бессмысленный цикл. Где же оно наконец закончится? На самом деле важный аспект компетентного тестирования – это знание, как обосновать, что пришло время заканчивать тестирование; это, как правило, непростая задача.

Можно сказать, что разработка ощущается сходящейся задачей, движущейся к завершению, а тестирование, по ощущениям, движется в противоположном направлении: открывает новые возможности, изучает каждую, ведущую к еще большему количеству возможностей, и так далее. Для одного и того же человека довольно трудно размышлять и как разработчик, и как тестировщик, в одно и то же время – это даже болезненно и требует экстраординарной дисциплины. Это не значит, что разработчики не должны проверять свой код. Это важно. Но юнит-"тесты" – на самом деле не тесты, это низкоуровневые проверки фактов, мало похожие на скептический, креативный процесс тестирования.

Тестировщики и разработчики вынужденно движимы разными стимулами: восторг от создания чего-то очевидно хорошего против восторга от обнаружения скрытых недостатков. Когда они работают вместе, они могут построить что-то действительно хорошее, а не просто кажущееся таковым на первый взгляд.

Программирование –полезный навык для тестировщиков, но не все тестировщики должны быть программистами. Тестировщики-программисты часто концентрируются на создании инструментов, помогающих тестировать, а не на прямом интерактивном тестировании продукта. Тестирование выигрывает от любых форм разнообразия, но особенно – от когнитивного разнообразия, которое дают люди, по большей части мыслящие как разработчики и глубоко понимающие технологию, и люди, концентрирующиеся на поведениях и виде продукта, хорошо понимающие пользователей. Хорошо, когда есть те, кто хочет "решить все задачи" (даже если результат не идеален) – и те, кто хочет "сделать все правильно" (даже если решение задач занимает больше времени).

Почему это важно: люди специализируются как тестировщики, чтобы сконцентрироваться на обнаружении проблем, не отягощая себя предвзятостью, проистекающей из надежд, что продукт будет работать, или веры, что он безотказен, или излишней усталости от попыток заставить его работать, не оставляющей энергии для обнаружения отказов. Все любители, иногда занимающиеся тестированием, должны учитывать эти предубеждения и уметь ими управлять.

8. Тест состоит из тестировщика, процедуры, покрытия, оракулов и мотивирующего риска

• Тестировщик. Тест без тестировщика невозможен. Тестировщик – живой человек, на котором лежит ответственность за разработку, осуществление и поддержку теста. Тестировщик – не просто слуга теста, он часть теста. Суждения и внимательность тестировщика – жизненно важная часть хорошего теста. Из этого следует, что передача теста другому тестировщику меняет тест. Два компетентных тестировщика могут следовать одной и той же формальной процедуре теста, но не будут выполнять в точности одинаковые тесты, потому что работа любого теста зависит от разнообразных человеческих факторов. Еще одно следствие из этого принципа: передача хорошей тест-процедуры некомпетентному тестировщику снизит или даже уничтожит ценность этого теста; передача плохой тест-процедуры отличному тестировщику может привести к хорошему тестированию, потому что опытный тестировщик автоматически исправит дизайн теста или компенсирует его недостатки каким-либо иным образом.
• Процедура. Процедура – способ выполнения теста. Процедура может быть или не быть зафиксирована письменно, но должна существовать, иначе теста не будет. Даже если процедура зафиксирована, то, что выполняется тестировщиком (а не инструментами), будет всегда включать неявные элементы, автоматически вытекающие из опыта тестировщика. Если для выполнения теста используются инструменты, то они часть тест-процедуры.
• Покрытие. Покрытие – это то, что было протестировано. Типов покрытия множество, но среди них есть широкие категории: структура, функция, данные, интерфейсы, платформа, операции, время. Вам нужно хотя бы в общем виде знать, что ваши тесты покрывают, а что нет. Один из видов структурного покрытия – это покрытие кода, и для его измерения есть специальные инструменты. В отличие от него, покрытие данных не так легко измерить, потому что типов данных множество, как и способов их комбинирования. Измерение такого покрытия потребует отслеживание всех используемых в тестах данных и их сравнения с теми данными, которые могли бы быть использованы.

Любое покрытие основано на модели, под которой я понимаю определенный способ описания, отображения, постижения продукта; модель – это представление того, что она моделирует. К примеру, покрытие кода основано на модели кода – обычно это читабельный для человека исходный код. При обсуждении тест-покрытия модели обычно имеют форму списка или схемы. Модель браузеров для браузерного покрытия – это список браузеров и их значимых возможностей. Можно сказать, что модель – это перспектива продукта, и для обнаружения всех важных багов нужно тестировать из различных перспектив.

Тест-условие определяется как что-то в продукте, что можно исследовать в ходе теста, или что-то, что может повлиять на результат теста. По сути тест-условие – это нечто, что можно протестировать. Если вы каким-то образом моделируете продукт – скажем, перечислив все его сообщения об ошибках, - то каждое сообщение – это тест-условие. Если у вас есть список активных кнопок, каждая кнопка – это тест-условие. Каждая функция продукта – это тест-условие, как и каждая строчка кода. Мы не можем проверить все возможные условия, но должны знать, как их идентифицировать и как о них говорить.

• Оракулы. Оракулы – это способ обнаружения проблем. Неважно, каково ваше покрытие, без оракула невозможно найти баг. Оракул определяется, как способ обнаружения бага после того, как вы с ним встретились. Видов оракулов множество, каждый из них чувствителен к определенному типу бага, но каждый оракул подразумевает некое соответствие. Мы можем обнаружить баг, если продукт ведет себя несоответствующим чему-то важному образом – например, спецификации, пользовательским ожиданиям, состоянию мира, которое продукт отображает, и т. д. Тестирование можно охарактеризовать, как поиск важных несоответствий между состоянием продукта "как есть" и "как должно быть".
• Мотивирующий риск. Мотивирующий риск для теста – это вероятность и влиятельность проблемы в продукте, оправдывающие проектирование и выполнение этого конкретного теста. Тестирование и мотивируется нашими представлениями о риске, и ведет к более полному пониманию реального риска в продукте (если это хорошее тестирование). В конечном счете цель тестирования – это определение и поддержание хорошего понимания риска, чтобы вся команда, включая разработку и менеджмент, могла принимать правильные решения по разработке продукта в нужное время.

Почему это важно: обсуждение, оценка и защита ваших тестов начинается с понимания этих пяти элементов, необходимых любому тесту. Объясняя ваши тесты и демонстрируя, как они укладываются в глобальную тест-стратегию, нужно затронуть каждый из этих значимых элементов.