Всем привет! Меня зовут Герасимов Сергей, я – Senior QA Manual Engineer (да, я хвастаюсь) в компании “Петрович-Тех”.
Представьте ситуацию: вы молодой, красивый и умный тестировщик, сидите спокойно, тыкаете кнопочки, изучая колбеки ваших любимых платежных сервисов, и тут появляется нетривиальная задача: составить чек-листы для проверки всего функционала оформления заказа.
Звучит просто, но что кроется за ней?
В своей прошлой статье я рассказывал о тестировании оплат, техниках тест-дизайна, которые использовал, и всячески открещивался от попарного тестирования. Но вот злой рок дошел до меня, и сегодня я хочу рассказать о недавнем опыте использования “попарки” на практике.
Условия и смысл задачи
Давайте дадим короткую справку: попарное тестирование – это техника тест-дизайна, которая обеспечивает полное тестовое покрытие. Более подробно о нем можно прочитать здесь. На этом наш дескрипшн закончим.
Сайт “Петрович” – это огромная система с кучей различных товаров, вариантов доставки на любой вкус и цвет по разным регионам и самых разных услуг, где абсолютно каждый пользователь может выбрать что-то для себя.
И вот как, при наличии всех-всех условий и подусловий, собрать в один чек-лист работу всего заказа целиком?
Что уже есть: произведен рефакторинг кода со стороны 1С, принимающей информацию с сайта. Теперь требуется проверить, что вся информация, которую вносит пользователь со своей стороны, передается в 1С корректно. Нужно составить чек-лист для проверки всего функционала оформления, не упустив деталей.
И да, возможно, сейчас знающие мудрые тестировщики-старожилы скажут: «Серёг, вообще-то есть базовый принцип: исчерпывающее тестирование – невозможно, так что...»
А я вам отвечу: «Я всё понимаю, но наша задача – не проверить все возможные комбинации, а проверить весь базовый функционал. И на основе этого составить дальнейшие проверки».
Продолжаем. Под задачу выделяют два тестовых стенда с полным набором – БД, пространство в 1С и прочее. В проекте участвует 4 тестировщика: два со стороны сайта, два со стороны 1С.
Планирование и распределение задач
Ваш рассказчик был со стороны сайта. Первое, что мы сделали с коллегой – начали определять принципы, по которым поделим зоны ответственности между собой. Т.к. “Петрович” работает в огромном количестве субъектов РФ, решили сделать деление по городам. Почему? Потому что в разных городах разные условия, стоимости, типы товаров и прочие нюансы.
Я тестировал Москву, города-спутники Москвы, города РФ (где нет наших точек продаж и партнеров) и города-Умельцы (партнеры “Петровича”), моему товарищу достались Санкт-Петербург и весь СЗФО.
Декомпозиция оформления заказа
Далее мы приступили к декомпозиции чекаута. Тестировщики или разработчики, кто сталкивался темой оформления заказа в маркетплейсах, понимают, что практически в любой форме заказа есть сотни параметров и тысячи вариаций. Как же организовать максимальное тестовое покрытие?
Для начала мы выписали все блоки чекаута, по которым выполняется заказ. Возьмем для примера только форму доставки, хотя у нас еще есть самовывоз. В блоки чекаута вошли:
Адрес
Чек-бокс ограничения арки/подземного паркинга и высоту этого ограничения
Наличие объекта
Наличие мастера на адресе, его имя и телефон
Комментарий водителю
День доставки
Время доставки (тип доставки и временной интервал)
Дополнительные услуги (всевозможный перечень)
Промокод на доставку
Способ оплаты
Электронная почта
Телефон для звонков и СМС, с именем контакта
Чек-бокс обратного звонка оператора, с возможностью выбрать день и время звонка
Комментарий к заказу
Наличие бесплатного подъема
Пункты по одной из двух страниц чекаута готовы. Теперь нам нужно выделить то, что еще может влиять на наш заказ, так как перед чекаутом идет корзина. Добавляем дополнительные параметры:
Город (по ним мы делили зоны ответственности между собой)
Тип покупателя: физлицо и юрлицо
Система лояльности и ее использование/неиспользование
Наличие авторизации пользователя
Тип товара (они делятся)
Чувствуете, да? Я вот тоже выделил и прочувствовал масштаб задачи.
Большинство пунктов имеет свои подусловия: типы доставки и оплаты, временные интервалы, трата баллов или их начисление, типы товаров и их наличие, куча параметров дополнительных услуг и т.д. Честно говоря, мы не особо руководствовались логикой в начале и пытались выделить все параметры по каждому пункту. Но получалось слишком много. К тому же стояла задача создать большой чек-лист в Аллюре, который тоже непонятно как скомпоновать.
Сначала мы оценили количество кейсов в 1000 штук, но позже, глядя на всё написанное, мы пришли к мысли: речь уже идет о десятках тысяч вариаций.
Разумеется, нас это не устраивало! Но как тогда прогнать такой большой объем проверок? Тут-то мы и пришли к попарному тестированию.
Как же я не люблю эту технику. Ее использование практически всегда означает большую задачу с миллионом параметров, которые надо покрыть. Это ведет к заморочкам над тестируемым объектом. А я человек ленивый :)
Инструменты: как выбирали и что выбрали
Встал вопрос инструментов. Составлять кейсы вручную, используя все параметры, очень долго и муторно. Мы начали изучать «рынок». Прочитав ряд статей про разные инструменты, решили остановиться на двух инструментах: Pairwise и Pict от Майкрософт.
Pict – довольно известный инструмент. Мы обратили на него внимание, когда поняли, что у нас слишком большое количество входных данных. Pairwise – самый простой и, наверное, самый популярный инструмент для попарного тестирования.
Мы решили остановиться на Pairwise. Он не требует настройки и дополнительных трудозатрат. В отличии от Pict, который надо разворачивать, ставить, проверять, что работает и т.д. Можно было бы, конечно, и этим заняться, но нам не хотелось создавать себе дополнительные задачи.
Проблемы и решения: от чего отказались, что упразднили, как построили работу
Итак, дело было за малым: сделать так, чтобы Pairwise переварил наши данные. Не будем разбирать все сложности, из-за которых у инструмента случалось несварение, но приведу пару примеров.
Чтобы не выписывать по миллиону специальных условий, мы решили поделить города, физические / юридические лица и тип получения на несколько отдельных таблиц. Это позволит нам не затрагивать их при введении данных в Pairwise. В итоге, так мы сформировали несколько таблиц, называющихся так:
Москва. Физ.лицо. Доставка
Москва. Физ.лицо. Самовывоз
Москва. Юр.лицо. Доставка
Москва. Юр.лицо. Самовывоз
И дальше по тому же принципу.
Теперь конкретней. Например, в таблицах связанных с доставкой, изначально было поле «Зона». Как вы понимаете, у любого магазина, предоставляющего услуги логистики, есть деление зон доставки. Наш “Петрович” – не исключение. И первое, с чем мы столкнулись, это деление зоны на разные части и их тестирование.
Так как в одном только Питере 9 зон доставки (а это уже сложно для Pairwise), мы поначалу решили сократить зоны до 3: первая, последняя и любая между ними. Но в таком случае нужно проверить и негативные сценарии, например, за последней зоной. Также мы вспомнили, что есть вариант доставки в место на границе: некоторые дома могут стоять на стыке зоны, предположим, 2 и 3. Скрин одной из ранних таблиц (кое-что скрыл из-за NDA, но смысл остается тот же):
И вот мы уже вернулись к 5 зонам. Что опять-таки сложно переварить Pairwise-у.
До кучи мы столкнулись с первым уточнением требований. Пишу тимлиду, надеясь, что нам не надо тыкать каждую зону:
Сошлись на том, что оставим три зоны, а две негативные оставим ровно на два кейса на каждый город. А чуть позже, гоняя Excel-ки с кейсами, мы пришли к тому, чтобы вообще упразднить зоны доставки. И оставить один вариант «Любая» и те самые негативные варианты. Почему? Потому что нам не важно, какая зона доставки запишется: важно – записалась она или нет. Таким образом мы просто исключили целый столбец вводимых данных из таблицы Pairwise.
Точно так же мы поступили и с другими столбцами. Например, “Доп. услуги” мы сильно сократили: оставили по одному кейсу с конкретными услугами (отдельно Дополнительный подъем, отдельно Разгрузка и т.д.). Таких кейсов вышло всего 9. Остальное мы заменили на «Комбинация любых доступных или без услуг». Чтобы не загружать те 9 кейсов с разными услугами в Pairwise, мы дописали их вручную в нашу итоговую таблицу:
Так мы упразднили остальные столбцы, где данных было слишком мало и которые, к примеру, ограничивались ответом «Да/Нет». На скрине выше видны примеры таких параметров «Комментарий водителю» и «Промокод на доставку».
У нас получилось сократить количество вводимых данных в Pairwise до нескольких столбцов: Тип товара, тип доставки, оплата и день:
Отдельно мы прописали условия, по которым есть пересечения и ограничения:
Нажимаем «Generate Pairwise»:
И получаем 40-50 кейсов вместо тысячи предполагаемых на каждую таблицу:
Выводы
Получившиеся кейсы мы дополнительно обрабатывали вручную. Правили, обдумывали дополнительные условия и что-то дописывали. Например, негативные кейсы. Таким образом у нас добавилось еще плюс-минус 3-10 кейсов к каждой таблице. Попарное тестирование дало нам почву подумать над сложными и спорными кейсами, которые мы обнаружили в процессе их формирования. Некоторые из них выносили на обсуждение к аналитикам.
Вынес из этой истории важную мысль: при формировании чек-листов стоит уделить время на их формальную перепроверку. Нередко забываешь прописать какой-то специфический параметр, и появляется совершенно бредовый кейс.
Несмотря на все минусы, сложность обработки и затраченное время результат очень порадовал. Ведь 50 кейсов на одну из 8-9 таблиц гораздо лучше, чем тысяча ;)
На этом всё, с вами был Senior QA Manual Engineer Герасимов Сергей. Пишите по статье свои вопросы в комментариях. И кстати, минутка рекламы: приходите работать к нам в “Петрович-Тех”. У нас много интересных задач, крутое комьюнити, и у нас хорошо платят. Так что если вы, как и я, любите деньги, ознакомьтесь с нашими вакансиями тут, пишите свои вопросы по трудоустройству мне в тг – @GersKing, я отвечу на все вопросы и оперативно передам ваше резюме в руки нашим HR и тимлидам.
Почему я пишу об этом здесь? Всё просто – за каждого приведенного IT-сотрудника нам платят премию. А я уже говорил, что люблю деньги? :)