что такое парное тестирование
Что такое парное тестирование
Что пишут в блогах
Продолжу хвастаться статусом книги.
I’m sticking with “bug” rather than adopt another word such as “fault,” which is the current fad in publications because:
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Каждый тестировщик пишет тесты по определенному принципу. Даже тот, кто слыхом не слыхал ни о каких методиках, так или иначе руководствуется рядом принципов, которые, как правило, держит в голове, или в редких случаях на бумаге. Но скажите, какой бывалый тестировщик не представлял себе фантастическую ситуацию, когда эти принципы реализованы в коде: софт создает тест-кейсы. Конечно до такой радужной перспективы еще очень далеко, но первые шаги на этом поприще уже сделаны…
Описание метода
Представьте себе, что вам нужно протестировать систему с большим числом параметров, влияющих на её работу. Ярким примером такого рода может быть конфигурационное тестирование: например проверка работы системы под различными операционными системами или работа сайта в различных браузерах. Кто знает, какое сочетание параметров приведет к сбою? Каждый тестировщик знает, что все комбинации не проверить. К примеру, для проверки всех сочетаний 10 параметров с 10 значениями каждый, потребуется 10,000,000,000 тестов, в то время как метод перебора пар позволяет реализовать сравнимое по качеству тестирование (учитывая количество и критичность найденных в результате багов) используя всего 177 тестов.
Итак, в чем же трюк? Метод парного тестирования основан на довольно простой, но от того не менее эффективной идее, что подавляющее большинство багов выявляется тестом, проверяющим один параметр, либо сочетание двух. Ошибки, причиной которых явились комбинации трех и более параметров как правило значительно менее критичны, чем пары параметров и тем более одного, не говоря уже о том что никто не мешает дополнить свое тестовое покрытие кейсами на желаемые комбинации параметров.
Перебрать все пары немудрено, трудность в том, чтобы обеспечить при этом минимум тестов, комбинируя проверки нескольких пар в одном тесте. Тут нам на помощь приходят математические методы, уходящие корнями к английским математикам девятнадцатого века. Одним из плодов их трудов стали ортогональные матрицы. Я лишь упоминаю их вскользь, дабы любители линейной алгебры могли навести справки, благо информации в интернете предостаточно. Что важно нам, так это то, что велосипед изобретать не нужно, и методы, по которым мы можем сформировать оптимальное покрытие, давно изобретены.
Рассмотрим как происходит оптимизация. Возьмем для примера таблицу параметров и значений следующего вида:
Переберем значения первого параметра со вторым (строки №1-4), первого с третьим (строки №5-8) и второго с третьим (строки №9-12). Удалив повторяющиеся наборы параметров (выделены серым), получим следующую таблицу тестов:
Зеленым выделены уникальные пары всех параметров в таблице. Теперь начинается самое интересное, значения выделенные белым не являются необходимыми для перебора всех пар в таблице, поэтому могут быть заменены на любое другое значение. Поэтому заменив их, мы можем оптимизировать тесты, добавив проверку пар из 5, 6 и 7 строк во вторую и третью строки, получим:
Как видно из примера выше, оптимизация даже такого малого набора параметров не так проста как могло бы показаться. При этом сложность задачи возрастает пропорционально росту числа параметров. Однако эта задача решаема, в чем мы убедимся в последствии.
Применение
Как показывает опыт, метод эффективен лишь на поздних этапах разработки, либо дополненный основными функциональными тестами. Например, если вы проводите конфигурационное тестирование, то прежде чем использовать парное тестирование следует убедиться, что основной сценарий функционирует на всех операционных системах с параметрами по умолчанию (что-то типа BVT). Это значительно облегчит локализацию будущих багов, ведь при парном тестировании в одном тесте фигурирует множество параметров со значениями не по умолчанию, каждый из которых может стать причиной сбоя и его локализация в этом случае весьма затруднительна. А в случае провала BVT следует отказаться от использования метода парного тестирования, так как многие тесты будут провальными, а исключение даже одного теста влечет за собой потерю как правило нескольких пар и смысл использования метода теряется.
Поэтому метод следует использовать лишь на стабильном функционале, когда текущие тесты уже теряют свою эффективность.
Для того чтобы воспользоваться методом необходимо выполнить несколько простых шагов:
1. Определиться с функциональностью, которую будем проверять
Как говаривал Козьма Прутков «Нельзя объять необъятное», поэтому прежде всего необходимо разделить функциональность на части: компоненты, функции, сценарии. Функциональность небольшой программы, например по записи дисков, упрощенно можно представить в виде всего двух сценариев: запись диска, стирание диска. Выбираем запись диска и переходим к следующему шагу.
2. Исследовать выбранный сценарий и выявить его параметры и их значения
На данном этапе следуют спросить себя, какие параметры сценария могут повлиять на его выполнение? В качестве параметров могут выступать как настройки самой программы, так и внешние факторы.
Упрощенно, параметры и их значения при записи диска можно представить в виде:
Вы наверняка обратили внимание, что параметр «Скорость записи» имеет значения, недопустимые для “DVD”, как же быть?. У этой маленькой задачки, есть несколько вариантов решения, одно из которых – это разделить таблицу на две. Стоит учитывать, что на практике параметров в этом сценарии гораздо больше, и несостыковок, было бы значительно больше.
Итак, поделив таблицу по типу носителя получим:
говориМ о тестировании
простым языком
Тест-дизайн. Техника попарного тестирования
Как быть в ситуации, когда необходимо не просто протестировать продукт, а продукт с множеством взаимосвязанных входных данных? Здесь нам на помощь опять приходит тест-дизайн.
Сегодня мы поговорим об еще одной технике составления тестов — техника попарного тестирования (не путать с парным тестированием) или, как ее еще называют, Pairwise testing.
Эта техника используется, когда нам необходимо комбинировать очень много различный вариантов входных данных. Цель ее состоит в том, чтобы сократить количество полученных тестов, но при этом сохранить качественное покрытие.
По традиции приведу определение из ISTQB:
Попарное тестирование (pairwise testing) — разработка тестов методом черного ящика, в которой тестовые сценарии разрабатываются таким образом, чтобы выполнить все возможные отдельные комбинации каждой пары входных параметров.
Ее стоит использовать в том случае, когда входные данные связаны друг с другом. Точнее результат выполнения теста напрямую зависит от того, какие комбинации данных будут подаваться на входе.
Рассмотрим очень простой пример. Предположим, у нас есть форма с полями “Логин”, “Пароль” и кнопкой “Войти”.
Каждое поле может принимать два значения: пустое и заполненное. В обычной ситуации, когда результат работы формы не зависит от того, какие именно комбинации полей подаются на вход, нам достаточно провести всего три теста
Т.е. мы в наших тестах проверяем отдельно работу каждого поля, не задумываясь о том, что различные комбинации Логина/Пароля могут сломать систему. Но что, если у нас добавляется еще и зависимость полей? Тогда нам необходимо рассмотреть все возможные комбинации значений между полей. Для нашего примера это означает, что добавится еще один тест.
На первый взгляд выглядит достаточно просто, добавился всего один тест. Но давайте посмотрим на более реальном примере.
Опять же, даже здесь немного упростим проверку и выделим только самые базовые значения.
Таким образом общее количество тестов будет следующим: 2*2*2*2*2*2 = 64
Даже сейчас это большая цифра. Такое тестирование будет малоэффективным и потребует большое количество ресурсов. Вот здесь на помощь приходит техника попарного тестирования, которая позволяет сократить количество тестов во много раз.
Суть ее состоит в том, что мы берем только комбинации пар каждых значений, вместо комбинаций всех значений:
Вручную комбинировать каждую пару нет необходимости. Существуют программы, которые позволяют это сделать автоматически, достаточно только указать параметры и значения. Например, PICT, либо онлайн генераторы https://pairwise.teremokgames.com и т.д.
В нашем случае, после комбинации тестов с помощью попарного тестирования мы сократили количество проверок до 4-х
В каждом тесте мы проверяем сразу несколько пар комбинаций: E-mail — Никнейм, Никнейм — Пароль, Условия — Символы, E-mail — Пароль и т.д.
Подведем итог. Если мы столкнулись с тестированием механики, которая предусматривает различные комбинации входных данных, то в сокращении числа тестов нам как раз и поможет техника попарного тестирования.
И не забывайте пользоваться программами, которые избавят вас от ручного комбинирования.
Метод попарного тестирования
Nov 19, 2018 · 4 min read
Что же такое pairwise testing?
Pairwise testing — техника тест-дизайна, а именно метод обнаружения дефектов с использованием комбинационного метода из двух тестовых случаев. Он основан на наблюдениях о том, что большинство дефектов вызвано взаимодействием не более двух факторов (дефекты, которые возникают при взаимодействии трех и более факторов, как правило менее критичны). Следовательно, выбирается пара двух тестовых параметров, и все возможные пары этих двух параметров отправляются в качестве входных параметров для тестирования. Pairwise testing сокращает общее количество тест-кейсов, тем самым уменьшая время и расходы, затраченные на тестирование. Техника известна уже больше 20 лет, но только последние 5 лет мы можем наблюдать ее активное использование.
Дл я Pairwise testing используют алгоритмы, которые базируются на построении ортогональных матриц, или алгоритмы All-Pairs.
Тестирование с помощью ортогональных матриц
Данная техника тест-дизайна относится к статическим способам тестирование и используется в том случае, когда мы имеем дело с большим количеством входных данных, следовательно, исчерпывающие тестирование является недостижимым. Ортогональные матрицы применяются в конфигурационном, регрессионном, производительном, а так же в тестировании пользовательского интерфейса.
Для того, чтобы построить ортогональную матрицу для этого примера необходимо сделать так, чтобы два любые столбика (в нашем случае это параметры 1, 2 и 3) содержали в себе все возможные комбинации только один раз.
Таким образом, ортогональная матрица для нашего случая будет выглядеть таким образом:
Как мы видим, в столбцах 1 и 3 есть все возможные комбинации: (x,x),(x,y),(y,y),(y,x). Для других пар столбцов это правило работает аналогично.
Тестирование с помощью алгоритма All-Pairs
Аll-pairs testing — комбинаторный метод тестирование программного обеспечения, который проверяет все возможные дискретные комбинации параметров для каждой пары входных параметров системы. Исходя из этого, мы получим меньшее число комбинаций, чем при использовании ортогональных матриц.
Рассмотрим пример. Предположим, нам необходимо протестировать приложение для покупки/продажи б/у ноутбуков, мы имеем следующие переменные:
Если мы захотим протестировать все возможные комбинации, то мы должны составить 2 х 2 х 3 х 2 х 2 х 2 = 96 тест-кейса. Не многовато ли работы для тестирования формы?
Далее нам необходимо организовать переменные и значения.
Т.е. для каждого набора в столбце 1 мы помещаем оба значения столбца 2. То же самое мы повторяем с 3 столбцом.
У нас есть комбинация покупка&Киев и продажа&Харьков, но нету комбинации продажа&Киев и покупка&Харьков. Исправим это, поменяв местами значения во втором наборе третьего столбца.
Повторяем такие же манипуляции для колонок 4 и 5.
Колонка Доставка является более проблематичной, ведь нам не хватает комбинаций на покупка&встреча и продажа&почтой чтобы не нарушать отсортированные данные, нужно ввести еще 2 тестовых случая для этих комбинаций. Значком тильды “
” мы маркируем переменные, которые выступают произвольными. Таким образом мы получаем следующую таблицу.
Таким образом, мы получили готовые 8 тест-кейсов вместо 96.
Утилиты для автоматизации pairwise testing
Существует ряд ПО, которые помогут вам не только качественно, но и быстро создать тест-кейсы из большого количества параметров, самые популярные из них:
Заключение
Суммируя все вышесказанное, pairwise testing — прекрасный метод для повышения эффективности написания тест-кейсов. Он значительно сокращает количество комбинаций, которые будут покрыты, но остается очень хорошим с точки зрения обнаружения неисправностей. Метод очень прост в использовании, для его эксплуатации достаточно лишь определиться с функционалом для проверки, исследовать выбранный сценарий и его параметры и применить алгоритм, который определит оптимальное число тестов с полным перебором пар.
Что такое парное тестирование
Что пишут в блогах
Продолжу хвастаться статусом книги.
I’m sticking with “bug” rather than adopt another word such as “fault,” which is the current fad in publications because:
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Катрина Клоки (Katrina Clokie)
Перевод: Ольга Алифанова
Подход к парному тестированию
Парное тестирование – это способ подойти к тест-дизайну путем одновременного тестирования одной и той же функциональности двумя людьми, находящимися рядом друг с другом и постоянно обменивающимися идеями.
Объединяясь в пару, эти люди используют одно и то же устройство для тестирования. Один из них манипулирует клавиатурой (хотя клавиатура может переходить из рук в руки во время сессии), а другой генерирует идеи для тестов, следит за процессом и ведет записи, слушает, задает вопросы, ищет вспомогательные материалы…
Пара должна работать над одной и той же задачей, имеющей общую, четкую, ясную обоим цель. Хоть они и работают вместе, кто-то один берет на себя полноту ответственности. Этот человек может предварительно подготовиться, но лучше, если пара не будет загонять себя в жесткие рамки. Для начала вполне сгодится простой высокоуровневый чек-лист или набор идей для тестов.
Во время парной сессии тестировщики должны много разговаривать – не меньше, чем тестировать – с целью добиться общего понимания, что они, собственно, делают, и что еще важнее – зачем это вообще делается.
Достоинства парного тестирования
Я выписала преимущества этого подхода из разных источников и сгруппировала их:
1. Высокая креативность
Работа в паре заставляет обоих участников объяснять свои идеи и реагировать на чужие. Просто высказать свою идею вслух – уже хороший способ сконцентрироваться и сгенерировать новые мысли.
Когда над проблемой работают двое, и каждый привносит в решение свежую информацию и свежий взгляд, это ведет к пониманию, как легко человек может попасть под эффект «туннельного зрения», работая в одиночку.
Парное тестирование дает возможность тесного контакта между коллегами, которые узнают друг друга лучше и практикуются в коммуникации и поиске решений для возникающих проблем.
Товарищеские чувства и постоянная обратная связь по процессу тестирования, которая необходима для координации действий в паре, улучшает климат на рабочем месте.
2. Высокая производительность
Каждый должен сконцентрироваться на задаче – иначе он подведет напарника.
За счет работы в паре тот, кто владеет клавиатурой, может следовать за полетом своих мыслей, не отвлекаясь на заметки или поиск информации. Это позволяет не потерять ход размышлений.
Когда двое работают в паре, это сильно снижает желание окружающих отвлекать их от дела.
В сильной паре достоинства обоих участников взаимно компенсируют их недостатки, что позволяет людям учиться друг к друга.
Это хороший способ обучать новичков на личном примере напарника. Техника также полезна для опытных тестировщиков, если они раньше не работали в этой отрасли –они быстрее познакомятся с бизнес-спецификой.
Ниже – подборка отзывов о парном тестировании, которые, как мне кажется, могут быть полезны:
Я занимаюсь парным тестированием или демонстрацией? Важно уметь их различать. Если вы сидите рядом с кем-то, и этот кто-то играет ведущую роль в ваших диалогах в течение сессии тестирования – то это что угодно, только не парное тестирование.
Парное тестирование всегда основано на партнерстве. Расспросы и критика не должны звучать, как угрозы и обвинения. Это очень важно – ваш напарник фактически проводит ревью вашей работы на лету, и нужно уметь реагировать на его комментарии. Его обратная связь может содержать идеи для других тестов, и стоит попробовать их провести, если это годные мысли. Если у вашей сессии есть определенная цель, а ваши свежие идеи уводят вас от этой цели, можно отложить их на потом или сделать их целью следующей сессии.
Озвучивайте ход своих мыслей в процессе сессии. О чем вы думаете? Может, вы ищете файл? Какой тест вы сейчас пишете? Почему именно этот? Когда я как разработчик занимался парным тестированием, то зачастую молчал, создавая код. По большей части я в это время что-то искал, а мой напарник чувствовал себя ненужным, потому что не знал. Чем мне помочь. Когда он пожаловался на это, я начал описывать, что именно я хочу сделать, и он смог советовать мне, на какие секции кода обратить внимание.
Если вы тестировщик, задавайте вопросы. Иногда это непросто – вопросы кажутся вам идиотскими, особенно поначалу. Когда я был в паре на месте тестировщика, я не очень-то стремился высказываться, потому что не хотел, чтобы программист думал, что я учу его работать (а также о том, какой я идиот). Никто из тех, с кем я работал, ни разу не оскорбился и не решил, что я тупица. Более того, ряд моих «дурацких» вопросов привел к оживленной дискуссии, в ходе которой мы меняли стратегию, отказываясь от той, которую изначально выбирал разработчик.
Если кто-то в паре считает, что эта практика – исключительно одностороннее обучение, ничего хорошего из этого не выйдет. Парное тестирование эффективно только в обстановке взаимного уважения и доверия.
«Ведущий» партнер должен убедиться, что «ведомый» активно участвует в обсуждениях и понимает, что происходит. Поощряйте размышления, коммуникацию, держите партнера в курсе причин, побуждающих вас действовать так или иначе.
Доверяйте напарнику – он ведет вас по этому пути. Он тоже должен верить, что вы сообщите, если путь завел вас куда-то не туда. Хороший партнер непременно скажет вам об этом, и вы вместе вырулите на верную дорогу.
Доверие и общение – основа парного тестирования, а также базовый элемент создания хорошего ПО.
Я считаю, что парное тестирование идеально подходит для некоторых специфических ситуаций. Например, вы взяли новичка, который не знаком с системой и не знает, Как ее тестировать. Пусть он учится, тестируя в паре! Если вы обучаете кого-то, кто только начинает свой путь в тестировании (или пытаетесь обучить новым техникам опытного тестировщика), есть смысл совместно поработать над реальной, серьезной, важной задачей тестирования, деля одну клавиатуру на двоих в течение, скажем, часа. И, наконец, если вы и ваш коллега находите разные типы багов – поработайте вместе, чтобы поучиться друг у друга. Понаблюдайте, как он работает, вникните в его образ мыслей, чтобы понять, как он находит свои баги.
Хочется отдельно отметить, что все вышеперечисленные ситуации завязаны на обучение.
…этот подход сильно снижает боязнь ошибиться и борется с практикой взаимных обвинений… Если что-то пошло не так – это не вина одного и только одного человека.
Тестируя вдвоем, вы найдете баги, которые никогда не нашли бы в одиночку. Вы разные люди, которые по-разному подходят к тестированию, и совместно вы попробуете те способы, о которых никогда не додумались бы самостоятельно. К тому же вы найдете больше информации о баге, так как по-разному подходите к его локализации.
Организации все чаще нанимают людей с проблемами зрения или другими проблемами здоровья в качестве тестировщиков доступности, однако эти люди работают в одиночку. Можно повысить их ценность, устраивая парные сессии тестирования и добавив в команду тестировщика, не имеющего физических проблем.
«Календарь тестировщика» за ноябрь. Разумное парное тестирование
Авторами ноябрьского «Календаря тестировщика» стали Оля Фазулзянова, тестировщик Контур.Экстерна, и Оля Изюрьева, тестировщик Контур.Биллинга и организатор курса тестировщиков. Девушки рассказали о парном тестировании, о задачах, которые оно помогает решить, и привели пример неудачного использования практики.
В методологии XP есть практика — парное программирование. Во многих источниках написано о массе его преимуществ: высоком качестве кода, взаимозаменяемости разработчиков и т. д.
Если парное программирование настолько эффективно, то почему бы не применить аналогичные принципы в тестировании? Да, это можно сделать, парное тестирование существует давно и хорошо себя зарекомендовало. Но не стоит забывать, что любая практика является всего лишь инструментом для решения каких-либо задач.
В Википедии нет термина «парное тестирование», но есть определение для парного программирования, которое можно взять за основу. Тогда, на наш взгляд, мы получаем следующее.
Парное тестирование — это техника, при которой тестирование одной функциональности производится парой людей за одним рабочим местом. Один тестировщик («ведущий») управляет компьютером, второй («штурман») непрерывно следит за работой первого. При этом на всем протяжении работы над задачей они обмениваются идеями и обсуждают их.
Любая практика — всего лишь инструмент. Мы не хотим забивать гвозди микроскопом, поэтому всегда отталкиваемся от задачи. Давайте рассмотрим те задачи, для которых релевантно использование практики «парное тестирование».
Задача: наставничество
В любой момент в команду может прийти новый человек. Ожидания команды от него — достаточно быстрое погружение в коллектив и в специфику проекта и, конечно, качественное выполнение своей работы. Чтобы ожидания стремительно превращались в реальность, во многих компаниях существует процесс наставничества. А вот что будет, если наставничество реализовать через парное тестирование?
Пример:
В проект пришел новый тестировщик, с опытом или нет — не важно. Вы, как наставник, садитесь с ним за ваш рабочий компьютер и начинаете выстраивать процесс следующим образом: в самом начале за вами закреплена ведущая роль, и первоочередная цель — познакомить новичка с процессами проекта и предметной областью. Знакомство может быть через рассказ, презентацию или сразу через совместное тестирование задач.
Начать можно с обсуждения сути задачи, поиска ответов на вопросы и проработки плана тестирования. Когда все готово для тестирования, вы берете клавиатуру и мышь и показываете, как тестировать, а новичок наблюдает. Никто не запрещает меняться ролями и рабочими местами на последующих задачах. Главное, не менять суть — совместное тестирование задач за одним рабочим местом до тех пор, пока вы не будете уверены в своем напарнике.
Профит:
Мини-вывод:
Практика подойдет, если напарник — человек без опыта и нужно его быстрое преобразование из новичка в специалиста. Профит есть и при работе с опытным новичком: обучаются все, включая наставника. Ведь каждый человек работает по-своему и мыслит уникальным образом, используя свои практики и инструменты.
Задача: повышение квалификации
Мы можем столкнуться с тем, что для успешного выполнения своей работы нам нужно обладать знаниями смежных специализаций: уметь составлять документацию, автоматизировать задачи и т. д. Как быстро и недорого нарастить компетенции? Обратиться к члену своей команды.
Пример:
Вам как тестировщику приходит задача, которую целесообразнее покрыть юнит-тестами, но у вас не хватает квалификации, и вы идете к разработчику за помощью. Вы садитесь с ним за один рабочий компьютер и начинаете выстраивать процесс следующим образом: в самом начале ведущая роль обязательно за разработчиком, ведь он должен познакомить вас с кодовой базой и имеющимися тестами. Затем вы вместе накидываете сценарии и начинаете их автоматизировать. Первые тесты пишет разработчик, а вы наблюдаете, а следующие вы уже берете в свои руки.
Профит:
Мини-вывод:
Работа в паре позволяет получать знания в новой сфере быстро и эффективно, сразу закрепляя их на практике.
Задача: избавление от незаменимости (bus-factor)
Очень часто в командах есть люди — единственные носители определенных знаний. Зачастую таким человеком становится тестировщик, ведь он знает всё: пользовательские сценарии, как реализованы сервисы, что необходимо настроить на тестовой и многое другое. Но в жизни бывают ситуации, которые могут лишить проект источника знаний (увольнение, отпуск, больничный. ). Следовательно, чтобы минимизировать последствия, можно подстраховаться и заранее расшарить знания из одной головы в несколько. Как? Через парное тестирование, конечно!
Пример:
Вам как тестировщику нужно погрузить в свои задачи любого члена команды, передав сакральные знания. Вы садитесь с ним за один рабочий компьютер и начинаете выстраивать процесс следующим образом: за вами всегда закреплена ведущая роль, в самом начале вы рассказываете и/или показываете источники информации, по ходу актуализируя, подбираете и разбираете задачи, которые помогут закрепить полученные знания.
Профит:
Мини-вывод:
Если есть узкие специалисты, то парная практика для вас. Она повышает взаимозаменяемость и передачу актуальной информации.
Задача: получение обратной связи
Если команда тестирования состоит из нескольких человек, то применима практика обратной связи. Парное тестирование — подходящий инструмент для ОС.
Пример:
Вам или вашему коллеге необходима обратная связь. Вы садитесь с ним за один рабочий компьютер. Как выстраиваете процесс, не важно, главное — работать вместе.
Профит:
Мини-вывод:
Парные сессии дают тестировщикам возможность понаблюдать за работой коллег, в результате чего обратная связь будет более достоверной.
Мы разобрали задачи, при решении которых может помочь парное тестирование.
А теперь расскажем о реальном опыте, чтобы наглядно проиллюстрировать подводные камни, которые могут встретиться при использовании этой практики.
Случай из жизни, или Не делай как мы
На одной из ретроспектив команды тестировщиков были выявлены следующие проблемы:
Сформулировав эти проблемы, мы поставили перед собой задачи:
Договорились, что для их решения воспользуемся практикой парного тестирования.
Я и моя коллега вдвоем приступили к одной задаче тестирования.
Фронт работ был достаточно объемным, требовалось:
Все это нужно было сделать с нуля.
Сев за один компьютер, мы начали читать аналитику. Договорились прочитывать один абзац или часть текста, а затем обсуждать возникшие вопросы и уже накидывать первые тест-кейсы. Поскольку аналитика была довольно слабо проработана и содержала в себе вперемешку бизнесовую и техническую часть, порой на обсуждение 10 строк текста уходило 15–20 минут. Кроме того, чтобы окончательно разобраться с каждым вопросом, требовались уточнения от аналитика, разработчика или специалиста техподдержки. Все эти сообщения и письма писались тоже в паре.
Новая предметная область была достаточно сложной, поэтому составление тест-кейсов требовало настройки сложной среды и подготовки части тестовых данных. Тут тоже не обошлось без множества вопросов и совместных уточнений.
Столкнувшись со всем этим, мы решили притормозить и провести встречу, чтобы обсудить ход работы и успешность парного тестирования.
На встрече мы поняли, что, начав применять практику, мы совершенно забыли о цели ее использования. Все внимание сконцентрировалось только на тестировании, точнее даже, на подготовке к нему, так как до самого прогона тест-кейсов дело не дошло.
В ходе работы у нас не получилось провести полноценное ревью друг друга, ведь все действия мы выполняли вместе, перед этим их обсудив. Мы не подмечали ход мысли и действия напарника при раскручивании новой задачи. Не получилось и обменяться знаниями, так как предметная область была новой для нас обеих.
Строго говоря, поделиться знаниями получилось, но это были мелочи вроде:
Этими знаниями можно делиться и не прибегая к такой дорогой практике.
К концу встречи мы сделали для себя выводы:
Применяя практику, нельзя забывать о первоначальных задачах.
Вроде бы на старте все было сделано правильно. Мы сформулировали проблему, поставили задачи, выбрали инструмент решения, но во время самой работы акценты сместились. В нашем случае мы добились только того, что два тестировщика занимались одной задачей.
Подбирайте задачи по тестированию так, чтобы практика была применима.
Новая, сложная и объемная задача слабо подходит для парного тестирования:
— сложно обучить кого-то;
— не получается обменяться опытом;
— трудно собрать обратную связь.
Не замалчивайте проблемы.
Как только вы чувствуете, что что-то пошло не так, сразу говорите об этом, не ждите конца задачи или итоговой ретроспективы работы команды. Так вы быстрее сможете понять, что практика применяется неправильно, или может оказаться, что она вовсе не подходит для решения выбранной вами задачи.
Существует множество разных практик. Какие из них применять в работе, зависит только от вас. Главное, не забывайте, зачем вы их применяете, и не используйте практики ради практик.
P. S. Если вы в своей рабочей жизни использовали парное тестирование для других задач, расскажите о них в комментариях.