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

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

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

Продолжаем читать «древнюю» статью Баха 😉

Предыдущая часть вот ТУТ.

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

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

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

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

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

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

Исследовательское тестирование в действии

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

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

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

Базовая стратегия исследовательского тестирования – иметь базовый план действий, но позволять себе отступать от него на короткие периоды времени. Кэм Канер называет это принципом «туристического автобуса». Людям в туристическом автобусе позволено периодически выходить из него и бродить вокруг. Ключ в том, чтобы не отстать от автобуса и не заснуть в нем. Мое первое желания отклониться от плана возникло, когда мне на глаза попалось диалоговое окно, управляющее количеством оперативной памяти, которое использует программа. В тот же момент меня посетила идея (случайные идеи поощряются в исследовательском тестировании). Так как одни из требований к совместимость – это стабильность, я подумал будет интересным установить использование минимального количества памяти и выполнить действие, которое достаточно серьезно нагружает память. Итак, я установил использовать не более 5% системной памяти, затем увеличил размер картины до максимального, заполнил ее фиолетовыми точками и пошел в меню с эффектами.

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

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

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

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

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

 

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

 

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

By | 2018-01-17T01:07:55+00:00 Январь 17th, 2018|Переводы, Профессия|0 Comments

About the Author:

Leave A Comment