Автор: Рикард Эдгрен (Rikard Edgren)
Оригинал
Перевод: Ольга Алифанова

Часть 1

Часто (и по праву) говорят, что нужно учитывать куда больше, нежели явные требования, чтобы быть в состоянии хорошо тестировать^[1].

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

Мы также должны спросить себя, какую проблему пытается решить тестирование. Я думаю, в основном это ситуации вроде такой:

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

А не такой:

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

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

В разделе идей для тестирования есть подробный список^[2], который можно рассматривать как "чеклист для создания собственного чеклиста". В нем не все всегда будет релевантным, и я рекомендую потратить минутку на каждую категорию. Подумайте о том, что важно, и решите для себя, какие источники информации надо рассматривать подробнее. Полученная вами информация может сразу дать вам хорошие идеи для тестов, указать на важные вещи, и со временем помочь с детализацией вашего тест-дизайна. Комплексное слияние помогает понять, что важно, во множестве ситуаций.

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

Использование множества моделей

Требования – это важная модель того, чего должно добиться ПО, однако это куда более сложный вопрос, выходящий далеко за рамки документированных требований. Вы должны относиться к требованиям критически, и, используя другие источники, попытаться найти неявные ^[3]значимые требования.

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

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

Справка моделирует функциональность – если она написана с точки зрения пользователя.

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

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

Будьте открыты для моделей других людей – тестировщики не идеальны, и как и все, делают ошибки.

Продукт и проект

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

• Составили ли вы каталог ошибок для распространенного типа багов?
• Можете ли вы проставить теги багам и тикетам поддержки, чтобы использовать их для вдохновения?
• Каким образом вам удалось найти важные баги так рано, и как мимо вас проскользнули пропатченные баги?
• Как пользователи пытались решить свою проблему без вашего ПО?
• Используете ли вы ваши маркетинговые материалы как руководство по самым важным областям?
• Ищете ли вы в сети информацию о реальном использовании и проблемах, вызванных им?

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

У вас есть контекст выполнения тестов, который должен направлять ваш тест-дизайн.

• Когда вы можете к этому приступить, и сколько у вас времени?
• Каков опыт и специализация тестировщиков?
• Что будет тестироваться другими людьми?
• Какие новые типы тестирования нужно применить в этот раз?
• Готовы ли вы ко всегда происходящим неожиданностям?
• Возможно, стоит составить свободный, открытый план, который легко изменить.

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

Люди и навыки

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

Чтобы выяснить, что должно быть протестировано, надо использовать и свои навыки, и навыки команды:

• Знания, опыт, интуиция, субъективные ощущения.
• Исследования: изучайте и учитесь.
• Аналитическое мышление: моделируйте детали и общую картину, следуйте путям.
• Критическое мышление: ищите проблемы, риски и возможности.
• Креативность^[4]: расширяйте спектр тестирования, генерируйте новые идеи, используйте латеральное мышление.
• Глаз Тестировщика: хочет видеть ошибки, видит много типов, смотрит во множестве мест, смотрит часто, концентрируется на важном, смотрит чужими глазами^[5].

Больше вдохновения

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

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

Вы можете посмотреть на конкурентов – другие программные продукты, внутренний инструментарий, но также и аналоговые системы: как выполнялись похожие функции, пока не были компьютеризированы?

Чтобы понять нужды бизнеса, логику, информацию, знания, стандарты и законы, можно попробовать тестировать в паре с бизнес-экспертом.

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

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

Вдохновляйтесь общими тест-идеями вроде быстрых тестов, туров, мнемоник, эвристик, характеристик качества, хитростей^[6], атак^[7], чеклистов, и другим знанием из книг, курсов^[8], блогов^[9], форумов, сайтов, статей^[10], конференций и разговоров.

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

Двойная работа?

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

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

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

К тому же, проделывая это упражнение, тестировщики получат ряд источников для использования в качестве оракулов ^[12]в ходе оценки интересного поведения под тестами.

[1] Один из лучших примеров: "Тестировщик, который рассматривает проектную документацию (явную спецификацию продукта) как единственный источник требований, вредит процессу тестирования". Уроки 32 и 33 в книге Кема Кейнера, Джеймса Баха и Брета Петтикорда, Lessons Learned in Software Testing, John Wiley & Sons, Inc., New York 2002. Другой пример – "Тестировщики должны базировать свои тесты на информации, которую они могут получить – и они могут получить много информации из источников, не включающих спецификацию". Кейм Кейнер, The Ongoing Revolution in Software Testing, Software Test & Performance conference, 2004, http://www.kaner.com/pdfs/TheOngoingRevolution.pdf

[2] Рикард Эдгрен, Мартин Янссон и Хенрик Эмильссон, 37 Sources of Test Ideas, http://thetesteye.com/blog/2012/02/announcing-37-sources-for-test-ideas/

[3] Хороший старт для неявных требоавний – на слайдах 8-9 в курсе Кема Кейнера и Джеймса Баха, Black Box Software Testing, Specification-Based Testing http://www.testingeducation.org/BBST/specbased/BBSTspecBased.pdf

[4] Рикард Эдгрен, Where Testing Creativity Grows, EuroSTAR conference 2007, http://thetesteye.com/papers/where_testing_creativity_grows.pdf

[5] Рикард Эдгрен, The Eye of a Skilled Software Tester, The Testing Planet, March 2011 – Issue 4, http://wiki.softwaretestingclub.com/w/file/fetch/39449474/TheTestingPlanet-Issue4-March2011.pdf

[6] Много советов доступно на http://www.quicktestingtips.com

[7] Джеймс Уиттакер, How to break Software: A Practical Guide to Testing, Addison-Wesley, Boston 2002

[8] Отличный бесплатный курсовой материал доступен на http://www.testingeducation.org (в основном от Кема Кейнера)

[9] Блог-портал для старта: http://www.testingreferences.com

[10] Колонки Майкла Болтона в Better Software вдумчивы и вдохновляют: http://www.developsense.com/publications.html

[11] Отличная книга про требования: Дональд Гауз, Джеральд Вайнберг, Exploring Requirements: Quality Before Design, Dorset House Publishing Co. 1989

[12] Для более внятного списка эвристик оракулов см. Бах/Болтон, HICCUPPS (F) - http://www.satisfice.com/rst.pdf

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