Home

Автор:Michael Bolton

В своей предыдущей статье я писал о важности критического мышления. Навыки критического мышления занимают центральное место в философии, положенной Джеймсом Бахом в основу Rapid Software Testing. На наших тренингах, презентациях, в кулуарах конференций люди часто спрашивают, можно ли научиться навыкам критического мышления. Я вполне уверен, что этому можно научить, но мне кажется, что правильнее эти навыки вдохновлять, тренировать и культивировать. Имейте в виду, отсутствию любопытства тоже можно легко научить, это происходит, когда учитель или руководитель даёт "правильный" ответ, считает вопрос закрытым, и не допускает дальнейшего обсуждения или, хуже того, дальнейшего обдумывания. Я думаю, чтобы начать развивать навыки критического мышления, нужно поощрять людей задавать вопросы. Для тестирования это тоже важно: когда мы перестаем задавать вопросы, мы приобретаем «туннельное видение», мы начинаем игнорировать контекст, начинаем верить в «лучшие практики», как будто они существуют.

Джеймс Бах предложил эвристическую модель стратегии тестирования (Heuristic Test Strategy Model) как основу для формулирования вопросов, которые помогут тестировщикам быстро и эффективно выработать подход к тестированию своего продукта. В этой статье мы рассмотрим первый из четырёх компонентов этой модели – рабочее окружение, или среду проекта (projectenvironment). Модель определяет восемь категорий, о которых стоит спросить для получения полезной информации.

Заказчики, заинтересованные лица (Customers). Кто является заказчиками продукта? Как я уже писал в прошлый раз, этот вопрос следует рассматривать максимально широко. Думайте не только о тех, кто использует продукт, но и о тех людях, которые являются их клиентами. Помните о том, что покупает продукт не всегда тот же самый человек, который им пользуется. Другой важный вопрос, относящийся к этой категории – кто является заказчиком работ по тестированию? Перед кем мы отчитываемся? Кто ещё может быть заинтересован в нашей работе? Есть ли у нас доступ ко всем этим людям?

Информация (Information). Какие существуют источники информации о продукте и о том, где он будет использоваться? Есть ли у тестировщиков какая-нибудь предварительная информация – знания, предположения, неявные спецификации, из которых можно извлечь идеи тестирования? Есть ли доступ к проектной документации, и если есть, то в какой форме она представлена? Кто в данном проекте мог бы предоставить нам необходимую информацию?

Связи с разработчиками (DeveloperRelations). Кто они – наши разработчики? Где они находятся – в одном месте или в разных местах? Как они ладят между собой и с остальными участниками проекта?

Команда тестировщиков (Test Team). С кем мы работаем? Что мы знаем о нашей команде? Насколько разнообразны навыки участников команды? Нужно ли кому-нибудь из нас дополнительное обучение, и есть ли необходимость в подборе новых сотрудников?

Оборудование и инструменты (Equipment and Tools). Имеется ли тестовый стенд или нам придется обходиться собственными компьютерами? Разделены ли среды разработки, тестирования и эксплуатации продукта? Требуется ли для тестирования какое-либо специальное оборудование? Подходят ли те инструменты тестирования, которыми мы уже пользуемся, или нам придется найти и установить какие-то другие инструменты?

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

Состав тестируемого продукта (TestItems). Что представляет из себя продукт, который мы тестируем? Есть ли у нас доступ к нему? Достаточно ли он стабилен или постоянно изменяется? Будут ли необходимы новые тесты в результате изменений, или мы будем проводить только регрессионное тестирование? Какие особенности продукта могут повысить удобство тестирования? И каково будущее направление развития продукта?

Результаты (Deliverables). Что наши заказчики хотят получить в результате процесса тестирования? Как мы будем записывать и сообщать о текущем положении дел? Насколько формализован процесс отчетности? Кому мы отчитываемся? Существуют ли стандарты, которым мы можем или должны следовать? Про каждый документ полезно спросить себя: это инструмент, который нужен, чтобы поддержать нашу собственную работу, или продукт, который мы должны передать кому-то другому? Не переусердствуйте с подготовкой документов, которые никто не собирается читать или использовать, сосредоточьтесь на важных вещах.

Более подробный и детализированный список, с дополнительными вопросами и подкатегориями, доступен на сайте Джеймса Баха www.satisfice.com. Если у вас есть категории или вопросы, которые вы хотели бы добавить в список, сделайте это обязательно, особенно если эти вопросы вы задаёте регулярно в разных проектах. Но в любом случае, практикуясь в использовании эвристической модели стратегии тестирования, вы сможете собрать значительное количество необходимой информации о любом проекте за очень короткое время.

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

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

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

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

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

Я считаю, что хорошее тестирование требует от нас делать это постоянно. Как тестировщики, мы не хотим быть одураченными приложением, которое, на первый взгляд, работает корректно, и мы не хотим заблуждаться, думая, что мы делаем работу хорошо. Чтобы быть интеллектуально честными, мы должны приветствовать в нашей работе критику и мышление, мы должны быть самокритичными. Мы должны быть готовы к сильным испытаниям наших убеждений, таким образом мы сможем постоянно совершенствовать свои инструменты, практики и подходы. Задавая вопросы о своём проекте, своей миссии, своих моделях, и своей стратегии, мы уменьшим вероятность появления сюрпризов в виде необнаруженных ужасных дефектов.

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