Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разговорные паттерны тестирования

Почему мы не нашли этот баг до релиза?

Это можно интерпретировать, как:

1. Это интересный баг, такой баг хотелось бы найти до релиза.
2. Мы пытались найти все интересные баги до релиза.
3. Однако этот баг мы не нашли, что огорчает.
4. Возможно, что-то не так с нашим процессом, и вот он результат.
5. Что пошло не так?

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

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

Предполагаемый ответ: "Давай разберемся и выясним".

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

1. Тестируемость. Было ли что-то в дизайне продукта или организации проекта, что позволило багу скрыться от нас? Можно ли улучшить в них что-то конкретное, чтобы будущим багам стало сложнее прятаться?
2. Альтернативные издержки. Если бы мы сделали все возможное для нахождения этого сбежавшего бага, не сбежали бы от нас вместо него другие баги?
3. Эффект знания задним числом. Анализируя, как избежать будущих багов, очень соблазнительно сконцентрироваться на точных обстоятельствах, при которых баг сбежал – потому что о его существовании вы уже знаете. Но это слишком узкий взгляд. Следующий баг не будет его братом-близнецом, но может быть похожим – думайте о наборе схожих, но не идентичных багов, и том, что вы можете сделать, чтобы найти все баги из этого набора.
4. Автоматизация. Есть ли автоматический способ ловли таких багов? Важны ли они и сильно ли распространены, чтобы обосновать такую автоматизацию?
5. Деятельность тестировщика. Предполагают ли причины побега бага что-то о концентрации, ответственности или навыках тестировщика? Возможно, с тест-стратегией и инструментарием все в порядке, а у тестировщика просто был неудачный день. Или, возможно, никто не берет на себя достаточную ответственность за процесс тестирования.

Почему мы не предотвращаем проблемы вместо того, чтобы тестировать?

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

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

Тестирование улучшилось бы при использовании практики Х – прямо как у компании Y!

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

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

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

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

1. Навыки. Требует ли новая практика специальных навыков для правильного применения? Необходимо ли некое внешнее обучение?
2. Альтернативные издержки. Что будет отложено в долгий ящик при внедрении этой практики? На что не останется времени?
3. Оценка. Как мы узнаем, что все получилось? Как мы обнаружим порожденные новинкой проблемы?
4. Горизонт прогресса. Сколько понадобится времени на эксперимент, чтобы объявить его успешным или провалившимся? Когда разумно будет ожидать результатов?
5. Необходимая поддержка. Чье содействие и какая инфраструктура необходимы для пробы пера? Можно ли это удешевить?

Почему нельзя автоматизировать все тестирование?

Это разумный вопрос, если вы уверены, что тестирование и проверка фактов – это одно и то же. Проверку фактов можно автоматизировать, хоть это, вероятно, дорого, медленно и сложно в поддержке. Неважно – сделать это можно.

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

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

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

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

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

Почему тестирование занимает так много времени? Сколько тестирования достаточно?

На эти вопросы можно ответить, лишь зная контекст. Иногда тестирование занимает больше времени, а иногда его можно провести довольно быстро. Это зависит от множества факторов, которые можно назвать аспектами тестируемости. См. "Эвристики тестируемости", чтобы узнать больше.

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

Зачем нам специализированные тестировщики? Почему нельзя просто получить обратную связь от пользователей? Почему тестированием не могут заниматься разработчики? Почему им не могут заниматься вообще все?

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

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

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

Обсудить в форуме