company_banner

В поисках самого лучшего способа тестирования системы

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



    В основе статьи – выступление Яна на июньской конференции Heisenbug 2017 в Питере. Ян занимается тестированием более двадцати лет. В настоящее время он работает тест-менеджером для приемочных тестов в голландской компании по стандартизации Squerist. Этот доклад о самых разных подходах к тестированию: от детальной проработки сценариев и до исследовательских туров, от сессионного тестирования и до поиска ошибок совместно с пользователями. Его цель – помочь вам повысить профессионализм, обратив внимание на те методы, которые вы до сих пор не использовали.

    Почему существуют разные подходы к тестированию?


    Я хотел бы начать с Линды Фишер. Вы ее не знаете, но более 19 лет назад я у нее проходил курсы по тестированию. Она говорила о том, что тестирование нужно делать вот так: сначала это, потом то (интерфейсы, проектирование и т.д.).

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

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

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

    • Гибкость в разработке преобладает над четким планированием.
    • Мы больше ориентируемся на мастерство, чем на методы.
    • Цели важнее, чем процесс. Если раньше мы следовали двухсотстраничному руководству, в котором был пошагово описан весь процесс тестирования, сегодня в этом нет необходимости. Важно смотреть, какого результата мы хотим достичь, и делать все для этого.
    • Быстрое тестирование преобладает над основательным. Большинство организаций хотят выйти на рынок как можно быстрее.
    • Прагматичные методы преобладают над стандартами. Следование стандартам может увеличить время тестирования, количество необходимой документации и требуемого персонала более чем в три раза. Поэтому даже в организациях, которые занимаются стандартизацией, часто отказываются от тестирования по стандартам.

    Основные подходы к тестированию


    Существует два основных вида тестирования – сценарное (scripted) и исследовательское (exploratory).



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

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

    Некоторые люди полностью полагаются на сценарное тестирование и считают исследовательское тестирование опасным. Другие, наоборот, используют исследовательское тестирование и считают сценарное чем-то из прошлого. Я думаю, правы и неправы и те, и другие. Оба подхода могут иметь ценность, но это зависит от ситуации.

    Промежуточные подходы к тестированию


    Однако эти два подхода к тестированию – не единственные. Кроме них существуют другие подходы, которые находятся где-то между ними.



    Почему я расположил их в таком порядке? Исследовательское тестирование практически не требует подготовки, а к сценарному тестированию нужно серьезно готовиться. А, например, сессионное находится где-то посередине – оно требует подготовки, но не столь большой.

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

    Подробное сценарное и общее сценарное тестирование (Detailed Scripting & Global scripting)


    В чем отличия между подробным сценарным и общим сценарным тестированием? Объясню на примере.

    Если мы тестируем, скажем, почту, то подробное сценарное тестирование может выглядеть так:

    • Перейдите на стартовую страницу
    • Нажмите на кнопку «Новый»
    • В поле «Кому» напишите j.cannegieter@squerist.nl
    • Нажмите на кнопку «Файл»
    • Выберите документ «Тест1»
    • В поле «Тема» напишите «Тестовое вложение <дата>»
    • Откройте почтовый ящик jcannegieter
    • Проверьте, доставлено ли сообщение и вложение.

    Для этого же примера сценарий общего тестирования может выглядеть так:

    • Создайте и отправьте письмо с вложением одному получателю
    • Проверьте, доставлено ли сообщение и вложение

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

    Сессионное тестирование и поиск багов (Session Based Testing & Bug Hunts)


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



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

    Сессионное тестирование предусматривает наличие:

    1. Сессий тестирования.
    2. Миссии и точки тестирования / идей для тестирования.
    3. Заметок во время сессии.
    4. Отчета после сессии (что мы обнаружили, каково качество системы и пр.).

    Поиск багов имеет много общего с сессионным тестированием, но есть и важные отличия. В поиске багов принимают участие не только тестировщики, но и разработчики, а также пользователи.

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

    Исследовательское тестирование и туры (Exploratory Testing & Test Tours)


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

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

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

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

    В этой связи я хотел бы привести цитату Джеймса Уиттакера: «Исследовательское тестирование без хорошего руководства подобно блужданию по городу в поисках интересных достопримечательностей. Руководство дает возможность понять, куда вам нужно следовать».

    В книге «Исследовательское тестирование ПО» Джеймс Уиттакер пишет о самых разных исследовательских турах. Вот некоторые из них:

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

    Основные различия методов тестирования и сравнение их эффективности


    Итак, основные отличия исследовательского тестирования от сценарного представлены в таблице ниже:
    Сценарное тестирование
    Исследовательское тестирование
    Сфокусировано на подготовке
    Сфокусировано на действии
    Сфокусировано на планировании
    Гибкое
    Опирается на методы
    Прагматичное
    Подчиняется процессу
    Ставит в центр внимания тестировщика
    Сфокусировано на документации
    Сфокусировано на выполнении тестов

    Каждый раз, когда я провожу эту презентацию, я делаю одну и ту же ошибку – у всех возникает чувство, что исследовательское тестирование лучше сценарного. Это не так. Сценарное тестирование так же ценно, как и исследовательское, но тут все зависит от ситуации.

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

    Как решить, какой метод тестирования подходит лучше


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



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

    Категория
    Ситуация
    Сценарное
    Исследовательское
    Система
    Много вычислений
    +


    Ориентирована на интерфейс

    +

    Ориентирована на бэкенд
    +


    Мобильное приложение

    +
    Цели тестирования
    Проверка на соответствие требованиям
    +


    Проверка ценности системы

    +

    Юзабилити

    +

    Тестирование бизнес-правил
    +


    Производительность
    +


    Проверка автоматизации
    +


    Безопасность
    +
    +
    Организация
    Ориентирована на планирование и подготовку
    +


    Энергичный современный стартап

    +

    Иерархическая, традиционная
    +


    Приветствует самоуправление
    +
    +
    Документация
    Много подробной документации
    +
    +

    Немного документации

    +

    Требования / документация постоянно меняются

    +
    Разработка
    Каскадная модель
    +
    +

    Agile

    +
    Бюджет
    Большой
    +
    +

    Небольшой


    Время
    Включение в работу на ранних сроках
    +
    +

    Включение в работу на поздних сроках

    +

    Много времени
    +
    +

    Мало времени

    +
    Навыки тестировщиков
    Аналитические, скрупулезные
    +


    Критическое мышление (сомневаются во всем)

    +

    Гибкость

    +

    Профессиональные тестировщики
    +
    +

    Непрофессиональные тестировщики
    +
    +


    Вместо заключения


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



    Если ваша профессиональная деятельность связана с тестированием, наверняка вас заинтересуют вот эти доклады на нашей двухдневной декабрьской конференции Heisenbug 2017 Moscow:

    JUG Ru Group
    Конференции для программистов и сочувствующих. 18+

    Комментарии 9

      +1

      Вопрос по таблице. При "Небольшом бюджете" тестирование, предполагается, вообще не проводить?

        0
        Может быть, при «небольшом бюджете» тестирование становится искусством (очень сложное ограничение — и протестировать надо, и денег нет), и думать об этом в смысле этой таблицы уже не применимо? Есть какая-то хитрая комбинация минимально необходимых мер, сильно зависящая от очень конкретных обстоятельств и микро-проблем. Ландшафт будет в основном формироваться этими микро-проблемами, а не аналитикой
        0
        По сути, имхо, градация между сценарным и исследовательским подходами, очень напоминает градацию между каскадной и гибкими методологиями. На мой взгляд, автор занимается адаптацией этих методологий к процессу тестирования, хотя прямых аналогий не проводит.

        А ещё сравнительная таблица очень напоминает приведённую у Макконнелла в «совершенном коде»: насколько детальным должно быть проектирование по ситуации.
          0
          Почему автор считает, что при подробном сценарном тестировании, тестировщик не занимается и отчасти исследовательским? Мне кажется, автор считает, что цель тестировщика при сценарном тестировании — пройти сценарий, но это не так, так же как и в исследовательском тестировании целью является проверка, что система работает так, как ожидалось и поиск ошибок. Да, у тестировщика есть сценарий, который как правило описывают возможные сценарии работы пользователя с системой, и тестировщик обязан проверить, что такой сценарий выполняется, но при этом тестировщик так же может производить проверки и не описанные в сценарии.
            0

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

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

                Я понимаю вашу логику, и думаю что действительно это имеет место быть — для больших систем, типа банковских и т д, но в тоже время такой выбор тестирования, заставляет очень много времени тратить на поддержку, актуализацию, написание сценариев… Насколько это выгодно для вас — решать только вам конечно же.
                Возможно, этот вариант — это хорошая подушка безопасности)
                Но думаю мы все равно не придём никогда к 1 мнению, так как все равно для каждой организации подойдёт исключительно свой процесс, и то что кажется верным мне — может быть совершенно противоположным для вас)

                  0
                  Ну изначально мне не понятно было, почему сценарное тестирования исключает исследовательское. Прохождение сценария — это не цель, а средство проверки качества системы. И да, я считаю, что если для маленьких систем можно обойтись только исследовательским тестированием, то для больших систем, сценарий в том или ином виде, с каким-либо уровнем детализации, необходим.
            0
            Я до сих пор не понимаю этих терок между скриптовым и исследовательским тестированием. Неужели до сих пор жесткое следование детально прописанным сценариям широко распространено? Настолько, что это проблема, с которой надо бороться, продвигая исследовательское? Что вот тестировщики составили тест-кейсы и ни на шаг, не отступают от них.
            Или это частный случай тренда «придумай проблему, а потом борись с ней», чтобы создавать движение в отрасли.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое