Джеймс Бах: Исследовательское тестирование. Часть 3

/Джеймс Бах: Исследовательское тестирование. Часть 3

Джеймс Бах: Исследовательское тестирование. Часть 3

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

Оригинал статьи можно найти вот ТУТ.

Начало перевода вот ТУТ.

Часть 2 вот ТУТ. Продолжим 😉

Практикуя исследовательское тестирование

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

Мы должны быть готовы отчитаться о нашем статусе и результатах в любое время. Обычно сессия исследовательского тестирования начинается с устава, который определяет миссию и возможно некоторые тактики, которые следует использовать. Устав может быть определен лично тестировщиком, или же задан лидом тестировщиком или тест менеджером. Иногда устав записывают. В некоторых организациях, тестовые сценарии и процедуры задокументированы настолько нечётко, что по существу являются уставами для исследовательского тестирования. Вот некоторые примеры уставов тестирования для продукта DecideRight:

  • Исследуйте и анализируйте элементы продукта. Делайте эскиз тестового покрытия.
  • Определите и тестируйте все требования из руководства пользователя (или помечайте в распечатанном руководстве пользователя, или записывайте каждое протестированное требование).
  • Определить потоки бизнес-процессов и пробуйте каждый. Потоки должны представлять реальные пользовательские сценарии, они должны выполнять каждую важную функцию продукта.
  • Мы должны понимать производительность и надежность продукта. Начинайте с простых сценариев, усложняйте их в плане количества, параметров, пока приложение не начнет зависать, падать или же предостерегать пользователя.
  • Проверяйте все поля, которые позволяют ввод данных (на функционал, на неверный ввод и на граничные значения).
  • Анализируйте формат файлов и определяйте поведение, когда программой начинают манипулировать. Тестируйте как обрабатываются ошибки при копировании таких файлов.
  • Проверьте интерфейс согласно стандартам Windows.
  • Можно ли как-то повредить файлы, как мы поймем, что файл поврежден. Расследуйте, можно ли написать автоматическую проверку файла. И возможно разработчики это уже сделали.
  • Протестируйте интеграцию с внешними приложениями, особенно с Microsoft Word.
  • Определите алгоритм принятия решения, поэкспериментируйте повторите в Excel. Используйте это для тестирования продукта.
  • Проверьте продукт с помощью Microsoft AppVerifier.

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

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

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

  • Тест дизайн: тестировщик исследователь прежде всего тест дизайнер. Любой может создать тест случайно, отличный тестировщик исследователь способен создавать тесты, которые систематично изучают продукт. Это требует определенные навыки: анализировать продукт, оценивать риск, использовать инструменты, мыслить критически, и т.д.
  • Тщательное наблюдение: отличный тестировщик исследователь более тщательно наблюдает, чем новичок, или же чем опытный тестировщик по сценариям. Тестировщики по сценариям наблюдают только то, что сценарий говорит ему наблюдать. Тестировщик исследователь должен зорко следить за всем необычным и загадочным. А также должен аккуратно отличать наблюдение от вывода, даже под давлением, дабы предвзятые предположения не затмевали важные проверки и поведение продукта.
  • Критическое мышление: отличный тестировщик исследователь может объяснить свою логику, может искать ошибки в своих выводах. Это особенно важно, когда готовится отчет о сессии исследовательского тестирования или локализуется ошибка.
  • Иные идеи: отличный тестировщик исследователь вырабатывает больше и лучшие идеи, чем новичок. Они даже могут использовать эвристики. Эвристики – это, например, руководства, общие чеклисты, мнемоники или эмпирические правила. *А тут идет битая ссылка))), поэтому вставляю более полезную: http://www.satisfice.com/tools.shtml — вот тут можно найти разные полезности. Джеймс Виттакер и Алан Йоргенсен предлагают использовать как эвристики 17 атак, которые описываются в книге «Как сломать ПО» (но об этом всем я напишу потом 😉). Разнообразие темпераментов и прошлого опыта тестировщиков в команде должно быть использовано исследователем в процессе мозгового штурма для выработки лучших идей тестирования.
  • Разнообразные ресурсы: отличный тестировщик исследователь создает обширный инструментарий, источники информации, тестовый данные, друзья, на которых можно положиться. И когда такие профессионалы тестируют, они готовы к появляющимся возможностям использовать данные ресурсы.

Управляя исследовательским тестированием

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

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

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

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

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

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

 

Продолжение следует…

Давайте делать мир лучше 😉

By | 2017-12-08T23:27:16+00:00 Декабрь 8th, 2017|Переводы|0 Comments

About the Author:

Leave A Comment