Записи с метками QA

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

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

Заблуждение 1. «Исследовательское тестирование – это выполнение проверок посредством прохождения по турам.»

Что не так с этой трактовкой? Давайте представим как происходит процесс тестирования по так называемому “туру”. Любимый пример Джеймса Виттакера (автора книги Exploratory Software Testing):

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

Давайте спроецируем это пример на тестирование. Что получается? У нас есть набор чекпоинтов, быть может чеклист end-2-end набор тестов, который указывает нам на порядок выполнения действий. Не нужно долго думать, чтобы ответить на вопрос “На что похоже такое тестирование?”. Конечно же – это скриптовый подход к тестированию.

Каким должен выглядеть процесс, чтобы он был похож на исследование? В первую очередь нам нужна цель. Говоря о Лондоне, целью может быть – купить красивое пальто или зонт. А где, в каком магазине и в какое время – не важно! Главное – результат. Что использовать для этого – дело сугубо индивидуальное. Кто-то может составить план, кто-то может доехать до центральной улицы и спрашивать у прохожих дорогу к ближайшему магазину одежды, а кто – банально зайти в первый попавшийся магазин и купить первое попавшееся на глаза. У каждого тестировщика свой стиль тестирования. И это правильно! Главное – это достижение цели, конечного результата. В этом разрезе, тестировщик более похож не на туриста, а на исследователя, который ищет пути решения поставленной проблемы.

Заблуждение 2. «Мы проводим исследовательское тестирование целый день, после того как все новые задачи проверены.»

Бред, вранье и полная чушь! Одно из самых частых заблуждений относительно исследовательского тестирования. Чаще все встречается у неграмотных Agile тестировщиков. Как вы можете заниматься исследованием лишь один раз в неделю? А чем же вы тогда занимались остальное время – тестировали? Нет, тогда вы не тестировали – вы проверяли на соответствие (checking). Исследовательское тестирование – всеохватывающий процесс, это подход к тестированию, а не одна из доступных техник. В пример этого заблуждения можно принести всем известные Agile квадраты.

Очень глупо было размещать Exploratory Testing в квадрате Q3. Почему? Давайте подумаем, можем ли мы делать исследования на этапе написания unit-тестов? Можем. Разработчики тоже могут исследовать код приложения, чтобы написать больше тестов. Проведение code review тоже можно отнести к исследованиям. Тоже самое касается остальных типов тестов. Например, вы можете записать в режиме исследования скрипт для нагрузочного тестирования, используя BadBoy. И запускать его при помощи JMeter с разными типами нагрузок. Кому интересно детальное опровержение этой матрицы – посмотрите выступление Элизабет Хендриксон на последней конференции CAST.

Заблуждение 3. «Exploratory Testing – это ручное тестирование.»

Если вы когда-то услышите эту фразу – смело ругайте этого человека. Какие инструменты можно применять для проведения исследовательского тестирования? Да любые! Это и скриншоттеры, и рекордеры, и логгеры. Используя автоматизированные скрипты можно подставлять разные массивы данных и тем самым заниматься исследованием системы автоматически, конфигурируя текстовые или xml-файлы. Тот же Selenium IDE и прочие record-and-play инструменты могут облегчить работу тестировщику во время проведения тестовой сессии.

Заблуждение 4. «Быстрые проверки – это и есть исследовательское тестирование.»

Еще одно из часто упоминаемых заблуждений. Быстрые проверки или, как их еще принято называть, quick tests могут проводиться как в исследовательском, так и скриптовом режимах. Для примера скриптового подхода, вы можете описать набор smoke или sanity тест кейсов для вашего приложения и тестировать по ним. В исследовательском тестировании же можно использовать мнемоники и туры для проведения быстрого тестирования. Но обратите внимание, что не все туры бывают быстрыми, и не все быстрые проверки – это туры. Полный список – на сайте Майкла Болтона.

Заблуждение 5. «Exploratory testing – это недокументированный процесс.»

Напоследок – самое сладкое заблуждение, которое полно необоснованных убеждений. Все тестировщики, по долгу службы, привыкли к стандартному течению обстоятельств. Читаем требования, пишем тест кейсы, ждем пока разработчики что-то напишут и уже по этим тест кейсам приступаем к тестированию. Я не говорю, что тестирование по тест-кейсам это плохо. Напротив, в некоторых контекстах без них никуда: медицинское, авиа, банковское ПО. Но везде должен быть разумный предел того, что документировать, а что – нет. Самый ценный совет, который можно здесь дать – «Документируйте только то, что нужно». Узнайте у членов вашей команды, менеджеров – какие документы им нужны, чтобы контролировать выполнение ваших обязанностей без постороннего вмешательства? Подумайте сами, какие документы вам необходимы для проведения тестирования. Но всегда держите в голове – «Keep it simple». Кстати, то же самое имелось ввиду в Agile манифесте «Working software over comprehensive documentation». Тестировщику нужно заниматься тестированием, а не администрированием процесса, точно так же как программисту – написанием кода, а не спецификаций. Но везде должен быть баланс. Если для поддержания рабочего процесса необходим документ – лучше его написать. В исследовательском подходе к тестированию документировать можно что угодно и сколько угодно. Главное договориться о том, что должно попасть в отчет тестовой сессии и какие сценарий следует формализовать.

Будьте готовы принять вызов и отстоять точку зрения о правильном исследовательском тестировании. Приводите примеры из своих контекстов. Задавайте вопросы и критикуйте, ведь этих пяти примеров может быть недостаточно, чтобы полностью ответить на вопрос «Что не есть Exploratory Testing?»

Хотите научится применять этот подход на практике? 26-27 октября в Киеве будет проходить тренинг «Exploratory Testing». На множестве практических заданий под руководством опытного тренера вы освоите исследовательское тестирование и сможете применять его в своей работе.

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!

Вторая статья из цикла «Один день в жизни тестировщика». В предыдущей статье мы говорили о планировании. В этом примере мы рассмотрим, чем занимается тестировщик в самый разгар итерации.

Контекст:

• проект разработки портала спортивных новостей;
• методология – Scrum;
• 5 программистов и 2 тестировщика;
• итерации продолжительностью 2 недели;
• все работают в одной локации;

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

После согласования, оба приступают к тестированию своих User Story.

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

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

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

«А что если теперь изменить настройки module2 с указанием аналогичных значений и проверить операцию суммирования еще раз с новым созданным товаром?» – предложил второй тестировщик.

Решили осуществить проверку, но опять-таки получили успешный результат. Проверка платежной системы заняла 10 минут, но им все таки удалось найти ошибку и stacktrace в файле логов, где должны собираться все совершенные платежи. Первый тестировщик просто не посмотрел в этот файл, когда тестировал в одиночку, соответственно не смог выявить, на каком шаге возникла ошибка.

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

Тестировщики спросили: «Сколько времени займет, чтобы исправить это?»
«По оптимистическим оценкам – 30-50 минут» – ответил программист.

Недолго думая, единогласно приняли решение, что нужно завести баг и добавить это задачей в колонку TODO этого спринта и связать с тестируемой задачей.

В чем мораль этой истории?

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

Какие ошибки допустил первый тестировщик в своей работе?

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

Как он смог быть решить эту проблему самостоятельно за 5 минут?

Использовать заметки в момент выполнения тестовой сессии в виде чеклистов, интеллект-карт или инструментов для записи экрана. Это поможет пересмотреть результаты и понять, какие шаги спровоцировали проблему.

Дайте свое виденье разрешения проблемы. Как в будущем избежать потерю времени?

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!