Тестирование методом свободного поиска: Отказ от плана не значит отказ от цели

    image

    В статьях Джеймса Баха можно встретить несколько различных определений того, что такое тестирование методом свободного поиска (exploratory testing), и одно из них звучит так: «тестирование без заранее подготовленных сценариев, выполняемых в точным соответствием с планом» (Exploratory tests, unlike scripted tests, are not defined in advance and carried out precisely according to plan).

    За это тестирование методом свободного поиска часто подвергается критике — как можно отказаться от планов, а как же управляемость, контроль и учёт? И вообще, если не будет планов, тогда каждый будет делать кто во что горазд, что-то будет протестировано несколько раз, что-то вообще не будет протестировано, люди не будут знать, что им делать.

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

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

    Тестировщик, имея перед собой ясную цель, может, конечно, наметить себе некоторый план, который должен его привести к этой цели. Но если на его пути встретятся какие-то препятствия, или он заметит, что выбранный план уводит в сторону, или следуя этому плану он не достигнет цели к поставленному сроку — это повод для того, чтобы изменить план, а не пытаться «подправить цель».

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

    Не теряйте из виду своих целей!
    Поделиться публикацией

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

      +3
      Напомнило метафору из Extreme Programming про езду на машине к цели, при этом меняя траекторию движения по ходу возникновения препятствий
        0
        «Вы должны планировать так, как это делает пожарное отделение: там не могут предугадать, где будет следующий пожар, поэтому они формируют энергичную и эффективную команду, которая сможет реагировать как в обычных, так и непредвиденных ситуациях» Эндрю Гроув, «Выживают только параноики»
          +2
          Согласен. Но у многих тестировщиков почему-то имеется священный трепет перед словом «тест-ПЛАН» :)
            0
            Был у нас такой «тест-ПЛАН» на одну АИС… еженедельное тестирование всей системы, которая находилась в разработке, по плану. Тесты могли меняться каждую неделю, в зависимости от разработки. Но ведь главное, чтобы тест-план выполнял свою главную задачу: соответствие функционала системы требованиям ТЗ и корректность его работы, не так ли? :)
              +2
              Трепет перед тест-планом у тестировщиков бывает в двух случаях:

              * если этот план пришел «сверху»;
              * если этот план они писали сами.

              Не вызывают трепета только тест-планы, которые должны проходить другие тестировщики.

              :)
            +2
            Отказ от планов может сэкономить время на планирование, но не позволит оценить степень выполнения работы. Компромиссным решением может быть установка контрольных точек (промежуточных целей), как в авторалли (используя вашу аллегорию).
              +1
              Совершенно верно, поэтому я и написал, что сторонники exploratory testing ратуют за отказ от тактического планирования, и при этом очень уважительно относятся к стратегическому планированию.
              +2
              exploratory testing должно отвечать на вопрос «а что если...»
              я б назвала это интуитивным тестированием, когда основные сценарии уже пройдены… и нужен просто взгляд на систему сбоку и иногда сверху. поэтому иногда наверное и цель может быть в тумане но узнаваема)
                +1
                Любое тестирование должно отвечать на вопрос «а что, если...»

                Что касается «интуитивного тестирования» — не надо этим термином называть что-то другое. Вы дали Ваше объяснение того, что представляет собой «интуитивное тестирование» в Вашем понимании.

                Я придерживаюсь следующего определения «тестирования методом свободного поиска» (exploratory testing), которое можно найти в трудах людей, развивающих это направление тестирования: «одновременное осознание, проектирование и выполнение тестов». Это же определение приведено в Википедии, так что можно считать его достаточно общепринятым.

                Взгляд сбоку или сверху тут ни при чём, этот подход прекрасно работает и при взгляде спереди. А также когда ещё не пройдены основные сценарии. А также если цель не в тумане. Это неважно. Принципиально другое — разделены ли во времени действия по осознанию, проектированию и выполнению тестов, или же все эти три деятельности выполняются одновременно.
                  +1
                  мне кажется мы с вами говорим щас о разных направлениях exploratory testing. верней о разных ветвях.
                  очень интересно об этом говорит James Bach: его можно применять для исследования как отдельного дефекта, так и для нахождения наиболее важного из огромной кучи; для того чтоб быстро понять как работает система (имхо тут главное не спутать с smoke testing) и чтобы понять текущий статус продукта. а все к чему… цель туманна, потому что ее не ставят в лоб… например целью может быть: проверить UI на то, что оно отвечает стандартам, скажем, Android приложения.
                  я не хочу с вами спорить) просто это тот вид тестинга, который как правило не включается в тест планы, который не оценивают вначале проекта, но на него тратят время (что правомерно). он нужен тестерам, но его не понимают менеджеры. потому что для них exploratory testing = freestyle testing в прямом понимании этих слов.
                    +1
                    Давайте Вы приведёте ссылки на статьи упомянутого Джеймса Баха про то, что «это тот вид тестинга, который как правило не включается в тест планы, который не оценивают вначале проекта, но на него тратят время», приведёте ссылки на описание того направления, о котором говорите Вы.

                    А я со своей стороны дам ссылку на статью тоже же автора «Heuristic Test Planning»: www.satisfice.com/tools/satisfice-cm.pdf
                    Это статья как раз про стратегическое планирование, про планирование и управление «по целям», а не «по планам».

                    На самом деле это интересно — почему тестировщикам цель «не ставится в лоб»? Может быть стоит ставить цели чётко, а? А тестировщикам, со своей стороны, прояснять цели? Иначе получается диалог типа «потестируйте тут что-нибудь» — «мы тут кое-что потестировали, вот нашли кое-какие дефеты» :)
                  0
                  Мне кажется Вы говорите об регрессионном тестировании.
                • НЛО прилетело и опубликовало эту надпись здесь
                    +1
                    статью про невключаемый в тест план вид тестинга, я вам не дам… это было не от Джеймса, а от личных переживаний при планировании тестирования. от Джеймса было сказанно выше.
                    и одно дело как Вы ставите цели себе со стороны тестирования (четко все разжевывая и раскладывая по полочкам, добиваясь ясности от менеджеров) и как «Он» — менеджер эту цель приподносит вам же.
                      +2
                      Ладно, оставим терминологические споры, в конце концов заметка была не про это, а про то, что цель важнее плана. Про что, что составив план и действуя в соответствии с ним, если вдруг вы понимаете, что он уводит вас от цели — менять надо план, а не цель. Про то, что план лишь средство для достижения цели. Про что, что плана вообще может не быть, но если нет цели… Тогда, как говорил Чеширский Кот, всё равно куда идти.

                      Что касается непонимания менеджерами чаяний тестировщиков, мне помнится, мы в Вами уже спорили по этому поводу где-то в другой теме :) И я приводил ровно тот же аргумент — если менеджер чего-то не понимает, это не потому, что он тупой, может быть просто ему про это никто никогда не говорил. Если менеджер не знает, как правильно ставить цели тестировщикам, не умеет этого делать — надо не обижаться на него за это, а взять и объяснить!

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

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