OpenQuality.ru
Качество программного обеспечения
Добрый день.
В купе поезда по Шотландии едут физик, математик, тестировщик и корреспондент. Поезд проезжает мимо лужайки, на которой пасется черная овца. Корреспондент передает в редакцию: “Невероятно, но факт: в Шотландии все овцы черные”. Физик отмечает: “Каков коленкор! В Шотландии встречаются черные овцы”. Математик констатирует: “В Шотландии есть по крайней мере одна овца, у которой хотя бы один бок черный”. А тестировщик, высунувшись в окно, вопрошает: “А овца ли это?”
“Не верь глазам своим”, копай глубже – одна из основных заповедей QC-инженера. А куда копать? От забора и до обеда? Можно и так. В роли забора и лопаты выступает тест-план. Все расписано по пунктам, согласовано с разработчиками и аналитиками. Все учтено, формализовано, в добрый путь. Можно отследить процесс выполнения задачи и даже спрогнозировать ее завершение. Сколько у нас процентов выполнено на сегодня? 72? Отлично, еще пару деньков, и мы закончим. Все довольны. Мы молодцы – такой большой, подробный тест-план, и мы прошли его “от и до”. “Не надо думать, с нами тот, кто все за нас решит” (Высоцкий). За нас решил тест-план, и с виду все выглядит замечательно. До тех пор пока пользователь нашего продукта не натыкается на лазутчика, который: a) обитает вне ареала, описанного нашим тест-планом, и б) вызывает сильное недовольство у пользователя.
Подобные ситуации встречаются не только в тестировании. Как адвокату строить линию защиты? Строго по правилам? Это проще всего. Любой добросовестный выпускник юридического факультета знает назубок учебник по уголовному праву. Есть набор процедур, которые нужно неукоснительно выполнять. Но чем отличается обычный адвокат от хорошего адвоката? Тем, что последний не довольствуется устоявшимися практиками, а ищет новые пути. В данном деле, для данного подзащитного. И находит факты, способные убедить суд присяжных. Другой пример – зубной врач. Пять лет обучения – это базис. А надстройка – “колдовство” стоматолога над вашим зубом, ювелирные манипуляции исходя из его особенностей. Порой вопреки тому, что пишут в медицинских журналах. Можно все сделать “по инструкции” и потерять зуб, а можно копнуть чуть глубже и сохранить.
Какого адвоката преподчтет подзащитный? Какого стоматолога выберите вы? О каком тестировщике мечтает ваш программный продукт? :)
Впервые об исследовательском подходе к тестированию (exploratory testing) заговорили родоначальники контекст-ориентированной школы (в первую очередь, Сem Kaner и James Bach). Это неудивительно, поскольку выпускники этой школы ставят во главу угла контекст, знание о продукте. Они строят свою стратегию на изучении особенностей, характерных черт отдельно взятого приложения. Вот как James Bach определяет исследовательское тестирование:
Exploratory testing is simultaneous learning, test design, and test execution.
Что это значит? Перед началом тестирования у вас есть мысли, ожидания о продукте. Вы знаете, что заказчик хочет получить. Вы представляете базовые проверки, которые надо выполнить. Вы расставляете приоритеты. И у вас есть много вопросов: “А что если …? А какова реакция на …? А почему …?”. Вы не знаете ответов на эти вопросы, вы получаете их в процессе тестирования. Вы изучаете продукт, и на основе полученных знаний планируете новые тестовые сценарии. Их выполнение рождает новое знание и новые вопросы. Ваша тактика гибко варьируется в зависимости от тех результатов, которые у вас есть на текущий момент.
Процесс исследовательского тестирования можно сравнить с поиском клада. В ваши руки попал полуистлевший черновик “Острова сокровищ” Стивенсона с настоящей, неопубликованной картой острова. На ней почти ничего невозможно разобрать, но примечания свидетельствуют, что клад поделен на части и укромно спрятан в разных местах. Вы прибываете на остров и начинаете поиск. “Ага, вот пещера. А что если пошарить у дальней стены? Череп носорога? Куда направлен клык?”. Вы останавливаетесь, что-то привлекает ваше внимание и кажется важным. Вы исследуете весь остров, пока не проверите все свои догадки. И чем более вы внимательны, тем больше частей клада вы найдете. То же самое в тестировании: предположение, проверка, результат, новая сессия поиска.
Кстати, о сессиях. Проповедники исследовательского тестирования ввели понятие Session-Based Test Management, посчитав необходимым формализовать процедуру исследовательского поиска. Безусловно, в этом есть свой резон, поскольку “свободный полет” – это не свобода от обязательств. На каждом этапе исследовательского тестирования должен быть результат, который приумножает наши знания о продукте, позволяет извлечь необходимые уроки и запланировать следующий шаг. Помочь в этом деле могут утилиты, специально созданные для таких целей. Вот, к примеру, инструмент Session Tester, который представил Jonathan Kohl. Хочется лишь отметить следующее: важно не выплеснуть с водой ребенка. Излишняя формализация исследовательского поиска сведет на нет все его преимущества.
Исследовательский и сценарный (scripted testing) подходы отлично дополняют друг друга. Первый привносит творческие, нестандартные шаги, второй – базовые, обязательные проверки. Какое влияние мы оказываем на окружающую среду? Нужно творчески прозондировать поведение системы. Какие ресурсы потребляют наши процессы? Нужно выполнить один из обязательных тестовых сценариев. И тогда ни один золотой жук не проскочит, и все сокровища острова будут наши.
Анонс следующей статьи: “Взлетная полоса, или введение в mock-объекты”. До встречи.
Что такое качество программного обеспечения и как его улучшить: теория и практика, задачи и решения, подводные камни и обходные пути.
Автор комментария : Интересующийся | May 2, 2009
Интересно, как этот тестировщик собрался тестировать овцу?
[Ответить]
Автор комментария : Капитан Аляска | May 4, 2009
Интересующийся, a он не собирался ее тестировать. Он просто засомневался, овца ли это. Мало ли что там под шкурой :)
[Ответить]
Автор комментария : clauster | May 9, 2009
Хорошая заметка, но не для новичков - смысл слегка ускользает между овцами и стоматологами :)
[Ответить]
Автор комментария : Капитан Аляска | May 11, 2009
Clauster, спасибо за комментарий! Ну что ж, прочтут по готовности :)
[Ответить]
Pingback : OpenQuality.ru | Качество программного обеспечения | December 13, 2010
[…] будет действовать пользователь системы). И наконец, исследовательское тестирование – вершина пирамиды и полновластная епархия […]
Pingback : OpenQuality.ru | Качество программного обеспечения | April 2, 2012
[…] о чем мы говорили не раз и не два (три, четыре, пять). Ведущие эксперты отрасли подчеркивают важность […]