Перевод статьи «Context Driven Testing: 7 Basic Principles with an Example».
Направляясь в аэропорт, я обычно выбираю самый быстрый и короткий маршрут, желательно, бесплатный. Но однажды я поехал по длинной, платной дороге. Я просто хотел провести еще немного времени с моим другом, который очень долго добирался, чтобы провести выходные с нашей семьей. Худший выбор маршрута, в данном случае, оказался лучшим.
Но подумайте вот о чем.
Что, если бы у меня было мало бензина?
А если бы у меня не было денег?
Я бы выбрал другой вариант.
БЕСПЛАТНО СКАЧАТЬ QA КНИГИ можно в телеграм канале "Библиотека тестировщика"
Если вы принимаете решения, отталкиваясь от следующих моментов, это решение обусловлено контекстом:
- Вовлеченные люди
- Обстоятельства
- Цели
- Имеющиеся варианты
- Эмоции и т.д.
Итак, что же такое контекстное тестирование?
Контекстное тестирование – это целая философия тестирования, разработанная Джемом Канером, Джеймсом Бахом и Бретом Петтихордом. Подробности о ней можно найти в их знаменитой книге: Lessons Learned in Software Testing.
В ней заложено 7 основных принципов.
1. Ценность любой практики зависит от ее контекста.
2. В контексте есть много хороших практик, но среди нет наилучших.
3. Люди, работающие в одной команде, являются наиболее важной частью контекста любого проекта.
4. Проекты развиваются во времени непредсказуемым образом.
5. Продукт – это решение. Если проблема не решена, продукт не работает.
6. Качественное тестирование программного обеспечения – это сложный интеллектуальный процесс.
7. Только благодаря суждениям и навыкам, применяемым на протяжении всего проекта, мы можем делать правильные вещи в нужное время для эффективного тестирования наших продуктов.
Я не буду объяснять каждый из этих пунктов, потому что за нас это уже сделали сами эксперты.
Я просто расскажу о своем взгляде на контекстное тестирование.
Пример контекстного тестирования:
Допустим, я начинаю проект А, который включает сквозное тестирование веб-приложения.
Какова будет моя стратегия?
Согласно стандартным процессам, последовательность событий будет такой:
- Собрать требования и ознакомиться с приложением.
- Утвердить план тестирования.
- Разработать документацию по тестированию – сценарии тестирования, тест-кейсы, матрицу трассируемости и т.д.
- Проверить и утвердить всю документацию.
- Создать тестовую среду и тестовые данные.
- Провести тестирование.
- Завести баг-репорты.
- Создать итоговый отчет о состоянии выполнения тестов и т.д.
Если я задам себе вопрос: “Как я решил, что это именно то, что я должен делать?”. Мой ответ будет следующим: “Я выбрал лучшие практики и стандарты обеспечения качества, изучил отраслевые рекомендации и базовые показатели прошлого опыта и т.д., верно?”
Я просто делаю то, чему меня научили, или то, что делали на моих глазах другие тестировщики.
Есть ли в этом что-то плохое? Вовсе нет. Это даже может сработать, потому что в такой подход отточен временем и многократными проверками. Однако приведет ли он к оптимальным результатам?
Сомнительно. Почему?
Потому что на каждом проекте у вас будут разные обстоятельства:
- документированные и недокументированные требования;
- команды, работающие бок о бок в офисе, и команды на удаленке;
- разработчики и тестировщики из одной компании и конкуренты;
- достаточное количество времени или жесткий график;
- состав команды – новички или опытные;
- ручное тестирование или автоматизация;
- тип проекта – требует строгого соблюдения правил (FDA или банковская деятельность) или экспериментальный (например, социальные сети);
- технология проекта – например: вы не будете тестировать веб-приложение и приложение для windows одним и тем же способом.
- требования клиентов (одним важны ежедневные подробные отчеты, другие интересуются только основными моментами).
- методики проекта (Agile против традиционного тестирования, сценарное тестирование против исследовательского).
Этот список – лишь пример, ведь в каждом проекте существует множество разных своих переменных.
Контекстное тестирование – это позволить обстоятельствам определять ваши методы и технику тестирования, а не действовать строго в соответствии с установленными стандартами.
Допустим, на проекте А есть следующие детали:
- Я работаю с командой из 4-5 новичков и 1 опытного тестировщика.
- У меня нет строгих документированных требований.
- Моя команда находится в Индии, а команда разработчиков – в США, поэтому мы работаем в разных часовых поясах.
- Клиент хочет видеть ежедневный подробный отчет о состоянии продукта.
- Мы используем баг-трекинговые системы, такие как Mantis или Bugzilla, и это все, что у нас есть.
- Я должен провести 2 этапа тестирования за 10 дней, и 3 дня заложено на тестовую документацию.
Вот примерный план действий:
1. Поскольку в команде много новичков, нам понадобится много экспертных оценок.
2. Необходимо назначить как минимум 2 встречи по обсуждению требований с командами Dev и бизнес-аналитиков. Эти встречи должны состояться формально, потому что команды находятся в разных местах, и нет возможности часто задавать им вопросы.
3. Агрессивный график тестирования документации. Чем больше документации будет написано, тем больше рецензий в итоге потребуется, а значит, будет затрачено больше времени. Поэтому нужно сокращать ее количество. Можно документировать только тест-кейсы по сквозному тестированию, а остальное проверить экспериментально.
4. Отчеты о состоянии выполнения тестов будут создаваться и отправляться в конце каждого дня.
5. Большинство тестов являются исследовательскими, поэтому нужно составить краткое описание каждого из них. Так будет проще понимать, что тестируется, а что нет.
6. Информация о дефектах будет указываться в режиме реального времени в баг-трекинговой системе Mantis. Поскольку команды работают в разных часовых поясах, возможно, им придется ждать целый день, прежде чем они получат сообщение от QA инженеров, если им понадобится что-нибудь уточнить. Поэтому рекомендуется назначить ежедневный созвон в удобное для всех время, во время которого команда тестировщиков будет иметь возможность продемонстрировать воспроизведение багов.
И так далее.
Когда у вас будет разработана общая стратегия, напишите базовый план тестирования. Теперь вы готовы приступить к тестированию продукта после его тщательного рассмотрения и составления индивидуальной стратегии.
Заключение
Это тестирование, ориентированное на контекст; оно делает ваши обстоятельства (а не стандарты) основными исходными данными и факторами влияния на вашу стратегию тестирования. Это призывает нас оглянуться вокруг и принять во внимание все, что вас окружает.
Лично мне очень близка эта концепция, потому что слишком часто практику тестирования считают достаточно жесткой, ограниченной рамками и основанной на повторении прошлого опыта. Кто-то так сделал, у него все получилось, значит, и я должен взять с него пример. Именно этот момент отпугивает людей от попыток примерить на себя роль тестировщика и остаться в этой профессии.
В контекстном тестировании есть много возможностей для творческого мышления, аналитических навыков и принятия решений. Если вам интересно узнать о нем больше, изучите подробнее тему по приведенным выше ссылкам.
Удачного контекстного тестирования!