УДК 004.415.53 ББК 32.973.26-018.2 Н19 Назина О. Е. Н19 Тест-дизайн. Практическое руководство для начинающих. — СПб.: БХВ-Петербург, 2023. — 512 с.: ил. ISBN 978-5-9775-1695-2 Подробно раскрываются концепции тест-дизайна, на конкретных примерах рассмотрены основные практические приемы тестирования: классы эквивалентности, граничные значения, техника Pairwise, исследовательское тестирование, построение деревьев решений, диаграмм состояний и переходов. Приведена подборка чек-листов для стандартных операций тестирования, которые можно использовать на практике и расширять в зависимости от потребностей и особенностей тестируемой системы. Для тестировщиков ПО УДК 004.415.53 ББК 32.973.26-018.2 Группа подготовки издания: Руководитель проекта Павел Шалин Зав. редакцией Людмила Гауль Редактор Григорий Добин Корректор Светлана Крутоярова Оформление обложки Зои Канторович «БХВ-Петербург», 191036, Санкт-Петербург, Гончарная ул., 20. ISBN 978-5-9775-1695-2 © Назина О. Е., 2023 © Оформление. ООО «БХВ-Петербург», ООО «БХВ», 2023
ОТ АВТОРА Если вы держите в руках эту книгу, то вы уже знаете, что такое тестирование. И вам наверняка любопытно пойти чуть дальше базовой теории. Акуда двигаться дальше? Можно уходить в автоматизацию, нагрузку… А можно развиваться в ручном тестировании! Для этого нужно научиться применять основные техники тест-дизайна. Да, про них говорят даже новичкам. Но «услышать» и «научиться применять» — это разные вещи. Грамотно выделять классы эквивалентности тестировщики учатся постоянно. Это как ремонт — его можно только начать! Поэтому я вынесла все базовые техники в эту книгу. Ее можно читать без опыта, а можно и с опытом. И всё равно, как я надеюсь, вы найдете здесь что-то интересное и полезное для себя. Только, пожалуйста, не надо просто читать. Обязательно пытайтесь применить эти практики в своей работе. Тогда книга принесет вам максимум пользы. Ну и плюс в конце каждой главы есть небольшие задания. Их тоже не стоит игнорировать! И удачи вам на пути становления крутым тест-дизайнером! В книге вас ждет много картинок — мне очень близка именно такая подача материала. Надеюсь, вам она тоже понравится. ;-) Обучение тест-дизайну как ремонт — какой-то бесконечный процесс!
https://www.weblancer.net/users/ Dementina_vikko/ Художник-иллюстратор уже лет 10, люблю рисовать маскотов, зверьё и всё, что вызывает положительные эмоции Графический дизайнер/иллюстратор. Искусство — это моё хобби и смысл жизни. Работаю в разных стилях и направлениях. Приоритетом для себя считаю работу над созданием игр и персонажей Художник книги по образованию. Занимаюсь графическим и веб-дизайном. Создать жизнь на страницах издания — задача, решение которой приносит огромное удовлетворение Я художник-иллюстратор, люблю развиваться и экспериментировать https://www.weblancer.net/users/ nabatinkoval/ https://www.weblancer.net/users/ Kristaart/ trblntrava.ru Анна Людмила Гуджиева Вика Кристина Гирева trbln_trava gl_graphic_designer Наши художники
https://www.behance.net/stacysovka https://www.behance.net/ _nyuta_art_ Привет, я Настасья — художник детской графики! Всем сердцем люблю создавать очаровательных бренд-персонажей, разрабатывать паттерны и, конечно же, иллюстрировать книги :) Автор книги С Викой я работала давно, а остальных нашла на Weblancer.ru По образованию магистр экономики, но с детства любила рисовать и в долгих поисках себя всё-таки пришла к работе иллюстратора, чему безумно рада Анастасия, 16 лет. Я — начинающий иллюстратор и полиглот. Также рисую иллюстрации к своему рассказу и набираюсь опыта Иллюстратор, дизайнер https://www.weblancer.net/users/ SkriD/ https://www.weblancer.net/users/ anastasia_dolce/ Настасья Диана Скриба Анастасия А также: Анна Иванова Ольга Назина Настя Денис Анна dolce.png illustrator_art_
ЧТО ТАКОЕ ТЕСТ-ДИЗАЙН И ЗАЧЕМ ОН НУЖЕН? Какой тест мне провести, а какой не стоит?
8 Что такое тест-дизайн и зачем он нужен? Тест-дизайн — это набор техник, которые позволяют нам приложить мало усилий и получить много результата. В терминах тестирования это означает: провели минимум тестов, нашли максимум багов. Ведь если в арсенале есть только молоток, вам придется им и гвозди забивать, и винтики закручивать. Или наоборот, отверткой гвозди забивать, что можно, но очень неудобно. Поэтому приятно иметь доступ к самым разным техникам — когда есть из чего выбирать, задачи решаются быстрее и приятнее. Итак, основные техники тест-дизайна: Boundary Value Testing Equivalence Class Testing State & Transition Diagram Testing Decision Table Testing User Case Testing Allpairs Algorithm testing … Классы эквивалентности Граничные значения Схемы состояний и переходов Таблицы решений Варианты использования Попарное тестирование … Их мы и рассмотрим в следующих главах! Тест-дизайн — это не наука Но сначала стоит усвоить эту истину. Закон Ньютона— он ив Африке закон Ньютона, не меняется и всегда работает одинаково. В тестировании же «серебряной пули» нет. Нельзя один раз написать мегаклевый чек-лист и сказать, что он подойдет вообще подо всё. В каждой программе свои баги, свои проблемы иособенности. Есть некоторые фишки, которые стоит проверять всегда, но всё равно даже универсальный чек-лист1 вам придется подкручивать под особенности своей системы. Каждый 1 Погуглите «чит-листы». Tест-дизайн — мало тестов, максимум багов
Что такое тест-дизайн и зачем он нужен? 9 разработчик совершает какие-то свои ошибки, каждая функциональность хоть немного, но отличается от той, что вы видели раньше. Поэтому техники тест-дизайна — это лишь набор эвристик, с помощью которых мы можем улучшить наши результаты1 . А можем и не улучшить, если мы неправильно использовали эвристику. ;-) Но в любом случае опираться на что-то нужно. Любая техника — это лучше бездумного прокликивания в надежде напороться на ошибку. Это как ориентир. Когда-то я была у Алексея Баранцева на тренинге, и он рассказал такую историю (я не помню ее точно, поэтому немного перевру. Главное, что останется смысл): Военная группа заблудилась где-то в Альпах. Генерал достает из-за пазухи карту и говорит: «Слушайте, вот у меня карта, я точно знаю, куда нам надо идти. Нам туда!» Группа пошла за генералом. Они шли-шли-шли и наконец вышли к людям. Те уже вызвали спасательную бригаду; она приехала, группу забрала, привезла обратно в штаб, и всё было хорошо. Но полковник подошел к генералу и попросил показать ему эту карту. Он взял карту, посмотрел на нее и говорит: 1 Эвристика — совокупность исследовательских методов, способствующих открытию ранее неизвестного. Ой! Яблоко всегда упадет вниз, если его ничего не держит Вот бы и в тестировании тоже так было!
10 Что такое тест-дизайн и зачем он нужен? — Слушай, это же не Альпы, это Гималаи! — Я знаю. — Это не та карта. Как ты смог их вывести?? Генерал пожал плечами: — Нам нужен был ориентир. Мы им воспользовались и смогли выйти. Без паники. Никто же не знал, что реальной карты нету. А если бы они остались на месте или стали плутать туда-сюда, то поднялась бы паника, в итоге ситуация бы усугубилась, и они бы просто замерзли. Вот видите? Карта же не та была! Но они всё равно выжили. И даже не волновались, так как были уверены в том, что идут в правильном направлении. Точно так же в техниках тест-дизайна. Если вообще ничего не делать, вы никуда не придете и багов не найдете. Аесли вы будете хоть куда-то идти, пусть даже вы определили неправильные эвристики или неверно выделили классы эквивалентности, всё равно вы куда-нибудь да придете. Со временем вы научитесь корректировать свои ориентиры и находить более быструю дорогу к тому же самому результату. Нам туда! Техники тест-дизайна помогают нам найти оптимальный вариант тестирования!
Часть I О ТОМ, КАК ПРОЕКТИРОВАТЬ ТЕСТЫ…
12 Часть 1. О том, как проектировать тесты… Когда нужно накидать чек-лист проверок на любую функциональность, мы проходим через несколько этапов: 1. Сгенерировать идеи «что тут можно проверить?» 2. Пополнить список «опасными точками». 3. Удалить всё лишнее (времени-то в обрез на проверку!) Помогает нам в этом тест-дизайн. В главах этой части мы рассмотрим самые важные техники, которые помогают за минимум усилий получить максимум результата. Если проектировать тесты плохо, то можно попасть впросак: не подумали о важной проверке — пропустили ошибку; накидали кучу идей, а потом выкинули «лишнее», среди которого были нужные тесты, — и снова пропустили баг. Но как понять, что лишнее, а что нет? Ведь проводить исследование системы бесконечно просто нет времени. И в выделении «умных» тестов, покрывающих самое важное, нам помогут классы эквивалентности и граничные значения. А потом при помощи анализа тестов и техники Pairwise мы научимся уменьшать их количество! Я помогу вам сделать работу быстрее и лучше!
Глава 1 КЛАССЫ ЭКВИВАЛЕНТНОСТИ Классы эквивалентности — самая важная тема тест-дизайна. Именно они помогают нам уменьшить количество тестов, улучшив при этом результат. Давайте разбираться, как! Эти тесты эквивалентны пройденным. Выкидываем
14 Часть 1. О том, как проектировать тесты… 1.1. Что такое «классы эквивалентности»? Классы эквивалентности в калькуляторе Начнем сразу с примера, чтобы понятнее было. Допустим, мы разрабатываем новый модный калькулятор. Возможно, вы уже знаете этот пример, так как его используют во многих книгах по тестированию, показывают на конференциях… Не будем нарушать традиций! Итак, мы разрабатываем калькулятор. На текущий момент готова только функция сложения, и нам надо ее проверить. Как будем проверять? Если у нас нет доступа к коду, мы не можем сказать уверенно, как разработчик эту функцию реализовал. И чтобы точно сказать, что «всё работает, багов нет», нам придется проверить сумму каждого с каждым: 1 + 0 1 + 1 1 + 2 … 1 + 999999999999999 2 + 0 2 + 1 …. 2 + 999999999999999 … 9999999999999999 + 1 … Уже получится очень много тестов, а это мы еще до дробных значений не дошли. Что, если один знак после запятой? А если два? А если три-четыре-десять? Тестов получаются триллионы. На одну простую функциональность… Мы просто не можем позволить себе полный перебор всех значений, иначе на проверку одного только сложения уйдет несколько лет работы полной командой. А еще вычитание, умножение, деление, комбинации, у-у-у-у-у… Ну и потом, если нам надо делать полный перебор — это значит, что и разработчик у нас слегка туповатый, и в коде тоже делает перебор вместо функции суммирования. Но в таком случае он бы тоже несколько лет писал простую функциональность, а раз он ее сделал за пару дней — значит, там всё как-то пооптимальнее работает. Вариации 1+0= 1+1= ... 1+9999999999999= 2+0 2+1 ... 1.0+0.1 1.0+0.2= ...
Глава 1. Классы эквивалентности 15 Вот и нам надо пооптимальнее работать. Какие месяцы и годы? Нам и двух дней, да что уж там, порой двух часов не дадут на проверку функции. Что логично — функциональность простая, зачем ее долго тестировать? Поэтому мы начинаем делать предположения. Наверное, если «2+2» работает, то и «2+3» будет работать, так как сама функция сложения работает. Проверки получаются эквивалентными друг другу, если вывести их на уровень абстракции «сложить два простых числа». Потом мы начинаем думать, что еще можно складывать, кроме двух простых чисел? И сразу получаем следующее разделение. Что складывать? Как складывать? Что можно складывать? Для этого надо подумать — а какие вообще бывают числа? Простые — которые делятся только на 1 и сами на себя. Обычные: 1, 2, 3… Те, что чаще всего используются. Большие значения — мы чуть позже поговорим о граничных значениях и обсудим, почему большие значения надо выносить в отдельный класс. Но фишка в том, что, если «1+1» работает, то «максимум + максимум» может и упасть. Ну и просто, мало ли, число не влезет на экран, что делать будем? Глазки потупив, говорить, что тестировали? Дробные— стоп, а какие возможны варианты их записи? Дробная часть через точку или запятую — уже два разных класса! А как мы можем складывать? Два числа — один знак сложения. Три и более — несколько знаков сложения. Одинаковые числа. Разные числа. Все эти идеи — и есть набор тестов, которые нам стоит провести, чтобы проверить функцию сложения. Мы не можем позволить себе полный перебор всех комбинаций, поэтому стараемся уменьшить их количество. Мы предполагаем, что если проверено «2+2», то и «2+3» работать будет, эти значения эквивалентны Вариации 2+2=2+3=... 2.0+0.2=2.0+0.3=... 20000+20000= 3000+3000
16 Часть 1. О том, как проектировать тесты… Для этого нам приходится предполагать, что комбинации из одной группы равны по смыслу. То есть эквивалентны друг другу. Это и называется классами эквивалентности — группировка проверок по какому-то принципу. И вся соль тестирования — правильно определить принципы одинаковости: Если класс будет слишком общий («сложение чисел») — мы пропустим баги, так как проверим только «2+2», а на больших или дробных значениях всё упадет. Если класс будет слишком узкий (числа до 10, до 20…) — получится слишком много тестов. Поэтому вся наша задача сводится к наиболее правильному предположению о том, какие проверки дадут одинаковый результат, то есть какие из них можно выкинуть. Выводим определение Обратимся к классикам. Гленфорд Майерс в своей книжке «The ART of software testing» пишет следующее: Главное — понять принцип разбиения. Не слишком детализированный, но и не слишком общий Вариации Принцип Простые числа Дробные через точку Дробные через запятую Тысячи Максимальное, которое влезает Мах+1 Мах+Мах 1+0=1+1=... ... 1.0+0.1=1.0+0.2=... 10000+10000= 20000+20000
Глава 1. Классы эквивалентности 25 Резюме Выделите классы эквивалентности (отдельно гречка, отдельно чечевица), поищите исключения и каждый раз используйте немного разные крупинки из кучки одного и того же класса. Для выделения классов: 1. Подумайте, каким бывает «тестируемое поле». 2. Представьте, каким не бывает «тестируемое поле». 3. Поищите границы. 1.2. Главные ошибки в выделении классов Поле ввода: буковки, циферки, перемешал… Основная проблема начинающих тест-дизайнеров в том, что они ищут «серебряную пулю», а потом пытаются применить ее везде и всюду. Так выглядит типичный чек-лист на абсолютно любое поле: 1. Русские символы — проверки по полю (длинное/короткое имя, простое, распространенное…). 2. Английские символы — транслит, на английском, перепутали раскладку… Антуан де Сент-Экзюпери Маша Ivan Покахонтас Котёночек Olga Victor Mefistofel Ева Маxim Ольга QA Lead Junior QA Junior QA Апполинария Айгуль
30 Часть 1. О том, как проектировать тесты… а потом уже «круши, ломай, ПО побеждай» (очень длинная строка, явный треш на входе и т. д). 1.3. Как выделять классы эквивалентности? Проверить разные варианты выполнения функции Обычно мы тестируем какую-то функциональность системы — возможность создать пользователя, поискать по сайту, купить платьишко, отредактировать блог-пост, забанить спамера, заблюрить картинку… Так вот, нам надо поставить себя на место пользователя и подумать, какими способами мы можем выполнять свою задачу. Например, мы тестируем интернет-магазин — возможность заказать товар. Ставим себя на место покупателя и рассматриваем разные варианты. Что мне надо сделать для заказа? 1. Найти товар. 2. Добавить в корзину. 3. Изменить количество (по необходимости). 4. Оформить доставку. Каждый пункт можно (и нужно!) тестировать по отдельности, так как на каждый пункт можно написать с десяток разных тестов. Поэтому берем какое-то действие и рассматриваем разные варианты его выполнения.
Глава 1. Классы эквивалентности 33 Размер. Вес. Цвет. … Сначала вычленяем атрибуты, потом рассматриваем каждый. Какой размер может быть? Это одни классы эквивалентности. А вес? Совершенно другие… И так ищем классы по каждому атрибуту. Какие у стола есть атрибуты? Размер, вес, цвет... Аналогично и в ПО — вычленяем атрибуты того же поиска: способы поиска — через строку поиска, через категорию товара, через каталог «самое популярное», загрузив фоточку… поля, по которым поиск работает: размер, название, цена, наличие на складе… алгоритм — исправляются ли опечатки, можно ли искать по нескольким словам… Спуститься на физический уровень После тестирования черного ящика нужно спуститься на физический уровень. Если вы знаете, как устроено ваше приложение, это может помочь с идеями для тестов. Выпишите всё, что знаете про это приложение. А еще лучше — зарисуйте! Так нагляднее.
34 Часть 1. О том, как проектировать тесты… Схема развертывания Схема развертывания — это схема, которая описывает, на каких компьютерах расположены части программы. И как они взаимодействуют между собой. Вот, допустим, у меня есть два сервера для студентов: Users и Buggy. Оба написаны на языке программирования PHP и поднимаются через сервер Apache. Находятся на одном сервере, общаются друг с другом через REST API. Оба работают с базой данных MySQL (каждый со своей) и предоставляют три точки входа: веб-интерфейс в браузере — для простых пользователей; REST API — для интеграций с другими системами; SOAP API — для интеграций с другими системами. Исходный код Если у вас есть доступ к исходному коду системы — пользуйтесь этим! Посмотрите, какие ограничения накладывает сама программа. На каком языке программирования она написана? Какие типы данных используются? Клавиатура Сервер БД Сервер приложений User MySQL Database MySQL Database Интерфейс пользователя (Браузер) TCP/IP or local socket SOAP клиенты Apache Apache Users REST клиенты REST Over HTTP Buggy HTTP HTTP HTTP
38 Часть 1. О том, как проектировать тесты… Если есть доступ к коду, поищите вдохновение там. Или хотя бы узнайте про используемые технологии — это поможет найти границы при тестировании точечных полей. И помните, что класс эквивалентности — это не одно значение, а целая область. И если мы выделяем класс «женские имена», то внутри может быть множество значений: Анна, Алла, Ольга, Мария, Светлана, Яна… А рядом будет другая область со своими значениями. 1.4. Что можно разбивать на области? Что мы разбиваем на области: входные данные; выходные данные; внутреннее состояние; внешнее окружение. Мужские имена Внешнее окружение Выходные данные Внутреннее состояние Входные данные Женские имена Могут быть и женским, и мужским (Антон, Александр, Павел, Сергей...) (Алла, Ольга, Мария, Светлана) (Саша, Женя...)
Глава 2 ГРАНИЧНЫЕ ЗНАЧЕНИЯ Зная области для проверок, нужно обязательно попытаться найти среди них границы. Этому мы и будем здесь учиться!
80 Часть 1. О том, как проектировать тесты… 2.1. Что такое «граничные значения»? Помните историю про Золушку? Мы выделили разные мешки (гречка, ячмень, пшено) — разные классы эквивалентности. И у каждого из мешков есть свои границы, иначе бы крупа просто рассыпалась! Эти границы очень важно проверять. Тогда, когда мы можем это сделать… У мешка гречки граница вроде бы есть, но это не точечное значение, поэтому и проверить ее тяжело, разве что визуальным осмотром. Другое дело, если речь идет о цифрах. Там с границами всё проще! У нас есть числовая ось и есть граничное значение: с одной стороны поведение системы одно; с другой — другое. То есть граница — это место, где меняется поведение системы. Поэтому проверяем ее двумя тестами: самой границы и пограничного значения из другого интервала. Чтобы захватить разное поведение системы. Почему так важно проверять границу? Потому что обычно границу «ставит» человек, разработчик. И он может ошибиться — и поставить ее не там, где надо: У каждого класса эквивалентности есть границы Другое поведение системы Одно поведение системы
Глава 2. Граничные значения 81 сдвинуть саму границу вправо или влево — 7 вместо 6; написать в коде «больше» вместо «больше или равно». Там, где у нас есть человеческий фактор, стоит тщательно проверить результат! Классики тоже это подтверждают. Гленфорд Майерс в своей книге «The Art of Software Testing» пишет следующее: Вместо того чтобы выбирать произвольный элемент из класса эквивалентности, проверьте поведение программы на точках, которые являются границами этого класса эквивалентности. Поэтому давайте разбираться, как границы искать, и какие они бывают. Важно проверить, что разработчик не ошибся с границей!
82 Часть 1. О том, как проектировать тесты… 2.2. Типы границ Про типы границ я впервые услышала на тренинге Алексея Баранцева (уже не помню точно, что это был за тренинг, я их много прошла). Алексей вывел собственную типизацию границ: физическая — которую физически нельзя преодолеть; логическая — ограничение, накладываемое логикой, а не программой; технологическая — ограничение, накладываемое используемой технологией; произвольная — ограничение, накладываемое человеком: аналитиком, разработчиком, заказчиком… Лично я предпочитаю совмещать физическую и логическую. Потому что физическая — это то, что мы вообще преодолеть не можем. При всем желании мы не введем строку отрицательной длины, ну никак не сможем. Но то, что физически сделать нельзя, часто в программе сделать можно. Например, ввести в количество участников митапа «1,5 человека» физически невозможно, но программа-то позволяет. Значит, для программы это уже логическая граница — мы же понимаем, что это невозможно. Так что в моей классификации есть всего три типа границ (мнемоника: ЛТП1 ): 1. Логическая — ограничение, накладываемое логикой, а не программой. 2. Технологическая — ограничение, накладываемое используемой технологией. 3. Произвольная — ограничение, накладываемое разработчиком. Логическая граница Логическая граница — ограничение, накладываемое логикой, а не программой. Это те аксиомы, которые мы знаем с детства. Или физические ограничения реального мира. Давайте посмотрим на примерах, что может быть логической границей. 1 Мнемоника — техника для лучшего запоминания. В нашем случае мы используем первые буквы типов границ и получаем короткую аббревиатуру. 3 П 2 Т 1 Л
Глава 3 АНАЛИЗ ТЕСТОВ Написали чек-лист проверок? Пора его сокращать! И выкидывать лишнее. В этой главе: анализируем чек-листы; удаляем ненужное. Это выкинуть, эти объединить Но я же... Я их полдня писал!!
152 Часть 1. О том, как проектировать тесты… учиться видеть в поле конкретное поле, а не простую строку. Видеть, какие тесты можно применить именно под это поле. А потом уже подключаем знание «да это просто строка» и выкашиваем ненужное. Поэтому в этой главе у нас именно анализ тестов. Хотя в самой книге мы рассматриваем техники тест-анализа такого, каким его видят американские Сначала генерируем МНОГО идей, потом будем выкидывать лишнее Чтобы выкинуть лишнее, сначала надо нагенерить идей! Чек-лист В нижнем регистре Первая заглавная, остальные мелкие Распространенное имя Редкое имя Свое имя Короткое имя Длинное имя
Глава 3. Анализ тестов 153 авторы или ISTQB1 . Просто знайте: в терминах часто бывает путаница. Если готовитесь сдавать на сертификат, обязательно посмотрите, что подразумевается под конкретным термином там. В этой главе мы будем включать мозг и избавляться от лишних тестов. Не более того. Тем не менее, тема очень важна — ведь у вас обычно мало времени на тестирование. Так что совмещаем то, что можно совместить, и выкидываем то, что можно выкинуть. 3.2. Как выкидывать лишнее вручную? Было бы здорово дать некий алгоритм, который поможет всегда и везде, но нет, увы. Универсальный подход здесь только «сесть и подумать». Асамое главное — «вместе с водой не выплеснуть ребенка». Убирайте тесты аккуратно, особенно в первые годы работы. Возможно, выкинутое было отнюдь не лишним… Но общий принцип анализа примерно такой: 1. Объединить позитивные тесты. 2. Выкинуть одинаковые классы эквивалентности. 3. Не тестировать одну функциональность 10 раз: проверять ее в одном месте, а в остальных лишь то, что она в принципе работает. Рассмотрим каждый пункт по отдельности. 1 ISTQB (International Software Testing Qualifications Board) — сертификационный совет по тестированию программного обеспечения, который работает на международном уровне. Эй, про меня забыла! Выкидываем лишнее!
Глава 3. Анализ тестов 197 Почему я не понимаю описание? Слишком много всего сразу проверяется. Первый же тест — комбинация десятка параметров. И результат, соответственно, на 10 строк текста. А ведь хороший тест — это маленькая конкретная проверка. Особенно, когда это автотест, то есть время тратит робот, а не человек. Ну что? Переделали. Тестов стало 150, поделенных на 9 папочек, но зато все простые и понятные. Выглядело это примерно так: ДО Наименование теста Описание Ожидаемый результат test_swr_01_ fio_agrnum_ billnum_ brthd_ph Поиск по ФЛ. Введены ФИО, номер договора, номер ЛС, дата рождения. В блоке searchArea (атрибуты, по которым идет поиск): PhysicalParty. fullName, PhysicalParty. birthdate, Agreement. number, BillingAccount. number Найден один контрагент. В ответе возвращаются данные контрагента: сначала реквизиты карточки; затем атрибуты с их полями; затем описания исходных записей (карточка не объединена — выведен только один элемент source) с реквизитами hid, sourceSystem, rawId, clientBase; далее — связанные карточки (AGREEMENT, BILLING_ACCOUNT, PRODUCT), в них есть описание связи: тип связи и идентификатор исходной карточки (id), с которой связан договор, лицевой счет, продукт; информация о персональном менеджере договора; блок searchWhy с информацией об атрибутах, в которых были найдены введенные значения: PhysicalParty. fullName, PhysicalParty. birthdate, Agreement.number (по ЛС совпадений не найдено) ПОСЛЕ Наименование теста Описание Ожидаемый результат 01_query_ physical_ fields (это название папки тестов) Проверяем блок query по полям ФЛ test_ swr_01_01_ surname Запрос — Лазарева searchArea = PhysicalParty. fullName В БД: Лазарева Инна Контрагент найден
Глава 4 ТЕХНИКА PAIRWISE В предыдущей главе мы говорили о том, как анализировать свои тесты — выкидывать лишнее, уменьшая объем работы и не снижая при этом качество. Анализ тестов на тему «что выкинуть» может проводить не только человек, но и компьютер! Проведи 15 тестов вместо 1000, я помогу тебе их выбрать
208 Часть 1. О том, как проектировать тесты… 4.1. Введение К сожалению, работу по анализу тестов нельзя автоматизировать целиком — тут всё еще нужен взгляд человека. Робот не может включить мозги (по крайней мере пока) — он делает ровно то, что вы ему запрограммируете. А общей «серебряной пули» анализа нет, увы. Но есть отдельные техники, которые автоматизируют какую-то конкретную задачу. В частности, техника Pairwise существенно сокращает полный перебор параметров, у которых мало значений (в идеале 2–3). Техника применяется для тестирования попарных значений. Эффективна она тогда, когда у нас много параметров, но мало значений в каждом: параметр 1: да / нет; параметр 2: да / нет; параметр 3: да / нет; параметр 4: раз / два / три; параметр 5: вкл / выкл; … При этом параметры взаимосвязаны — их результаты складываются или как-то влияют друг на друга. Например, фильтры в интернет-магазине или приложение, в котором можно установить целую кучу галочек. Вручную перебирать все варианты — скукота. Pairwise позволяет сократить количество проводимых тестов, причем иногда в разы. Проводится автоматически: вы загружаете свои параметры в программу и на выходе получаете набор тест-кейсов. Удобно! Ну тут же яма, обойди!
210 Часть 1. О том, как проектировать тесты… составления матрицы. Ведь вручную вы всегда можете ошибиться, особенно, когда параметров и значений много, робот же будет работать четко по своему алгоритму. Да и времени на ручное составление вы потратите часы, а система сделает это за минуту. Так что просто знайте: все программы работают так, чтобы проверить все значения попарно: каждое с каждым. А уж что там скрыто «под капотом»… Это как если сейчас копаться в алгоритмах расчетов с помощью перфокарт, которые в свое время тщательно выверяли, потому что доступ к машинам тогда был сильно дозированным. Можно, конечно, но зачем? 4.3. Как это делается? Возьмем для примера «Дадату» и проверим загрузку файлов в систему. Так, что мы о ней знаем? На главной странице мы видим ограничение на тип и размер файлов. Доступные типы файлов: Excel и CSV. Возьмем пару файлов CSVс типовыми разделителями: «;» и «,». Вполне законно также посмотреть загрузку файла формата TXT1 . Разумеется, проверим и явный негатив — попробуем, скажем, загрузить картинку. Размер файла: от 0 до 20 Мбайт. Проверим значение внутри, границы и пограничные. Выпишем всё это в виде таблички: 1 Если вы сейчас мысленно возмутились, что в ТЗ нет ничего про TXT-файлы, настоятельно рекомендую погуглить, что такое CSV.
Глава 4. Техника Pairwise 211 Тип файла Размер файла Excel 0 байтов CSV «;» 1 байт CSV «,» 2 Мбайт TXT 20 Мбайт JPG 20,1 Мбайт Две колонки есть, идем дальше. Когда начинаем загружать файл, видим, что система поддерживает определенный набор типов данных: ФИО. Дата рождения. Телефон. Почтовый адрес. Электронная почта. Паспорт. Автомобиль. А еще тут можно исключить столбец из обработки или оставить тип как есть — исходно система сама пытается определить тип данных, вы просто корректируете ее по необходимости. Добавим в табличку!
Часть II О ТОМ, КАК ИСКАТЬ ВДОХНОВЕНИЕ ДЛЯ ТЕСТОВ…
224 Часть II. О том, как искать вдохновение для тестов… Не всегда получается сразу применить классы эквивалентности и написать полный чек-лист проверок. Иногда мы просто не знаем, с какой стороны подойти к задаче. Какие еще тесты написать, какие проверки выполнить… Поэтому в следующих главах мы рассмотрим техники тест-дизайна, которые помогают нам посмотреть на систему свежим взглядом. Придумать новые идеи для тестов. Иногда даже баги найти. ;-) Часть техник связана с созданием документации. Да, тестировщик не аналитик. Но писать требования самому безумно интересно. Вы узнаёте детали реализации, прикидываете будущий комплект тест-кейсов и просто приносите много добра! Таблицы решений (Decision Table) и схемы состояний и переходов (State & Transition Diagramm) хороши для свежего взгляда на систему, когда уже не знаешь, что можно еще проверить. Их можно использовать даже единоразово. Один раз нарисовали табличку на 100 колонок — получили новые тесты — нашли новые баги, а табличку потом перенесли в архив или выкинули. Свою работу она уже сделала! Это тоже нормально! Главное, что на текущем этапе вы свой результат получили! Вы нарисовали, вы визуализировали, возможно, вы эту схему показали коллегам, чтобы вместе обсудить, как это стоит реализовывать. Так что используйте техники из глав, представленных в этой части. Чтото приживется, что-то отработает один раз. Но пользу обязательно принесет! С этой стороны я на приложение ещё не смотрела
Глава 5 ЧИТ-ЛИСТЫ В этой главе я дам вам чек-листы на стандартные действия (их еще называют чит-листами), чтобы вы могли использовать их как основу для собственных тестов. Как тестировать поиск 1. Где работает 2. Релевантность выдачи 3. Контекст поиска 4. Регистронезависимость 5. По включению 6. … Чит-листы подкидывают идеи для проверок!
226 Часть II. О том, как искать вдохновение для тестов… 5.1. Что такое «чит-лист»? Чит-лист — это такой универсальный чек-лист, который можно применить почти к любой программе. Разумеется, его нужно адаптировать под вашу систему: добавить вашу бизнес-логику или выкинуть «лишние» тесты. Но начинать не с чистого листа всегда проще! Поэтому я собрала для вас шпаргалки по разным типовым ситуациям: какие вопросы задать аналитику; какие проверки провести. 5.2. Поиск Что надо узнать? По каким полям поиск должен работать / по каким нет. Ищет по включению или полному соответствию? Регистрозависимый ли поиск? Какая максимальная длина поисковой строки? А если длина превышена, запрос обрезается? Как работает поиск при пустом запросе? Что надо проверить? Поиск ищет по всем полям, указанным в ТЗ? Поиск не ищет по тем полям, которые не указаны в ТЗ? Релевантность выдачи: то, что я ищу, в начале списка или в конце? Учитывается ли контекст поиска: ищу я по всему сайту или только по разделу игрушек? Регистронезависимость поиска: найдет ли «Платье», если я ввела «платье»? Ищет ли по включению или полному соответствию: «ту» найдет мне «туфли»? Найдет ли два слова из одного поля? В любом порядке введенные? Найдет ли два слова из разных полей? Ошибка во вводе: исправляются ли опечатки, ищет ли похожее? Исправляет ли система неправильную раскладку? Ищет ли на разных языках? А если сразу на двух попробовать? Поиск со спецсимволами работает? А с эмоджи? Не упадет система при вводе какашки? «Тримаются» ли открывающие и закрывающие пробелы? Пустое поле или только пробелы в поле как система обработает? Нижнюю границу: от скольких символов ищет? Верхнюю произвольную границу — указанную в ТЗ.
228 Часть II. О том, как искать вдохновение для тестов… Но сначала надо проверить основное — то, что поиск вообще осуществляется. Что он ищет по всем тем полям, по которым должен. Иначе сами представьте: идет у нас чек-лист на 30 проверок по названию, а потом уже «что поиск работает по описанию, категории товара, бренду…». А времени на тестирование нет, и выделяется буквально 5–10 минут. В итоге тестировщик провел первые 20 тестов и гордо говорит: — Всё отлично! Поиск работает! А если всякую чухню в него вбить, не падает! При этом поиск работает по одному полю из 10 обязательных. И пользователи пытаются искать, а у них ничего не получается, потому что ищут не по названию. Нехорошо… В любом чек-листе надо думать о приоритетах. Сначала — самое важное. Как в чек-листе в целом, так и внутри каждого блока проверок, постепенно идем от важного к неважному. От позитива к негативу. Чтобы при ограниченном времени не пытаться в спешке понять, что в чек-листе важно, вращая глазами туда-сюда и ища эти пункты. А что самое важное в поиске? Для этого думаем, зачем его вообще делают. Чтобы искать. По чему? По каким-то полям и признакам. По каким? Узнаем и проверяем, ищет он по ним или нет. Поиск не ищет по тем полям, которые не указаны в ТЗ Если предыдущий пункт еще очевиден новичкам, то этот— не особо… Поэтому давайте сначала подумаем: а зачем тестировать то, что поиск не работает Проверил сколько успел, работает! Надо же было с самого важного начать...
Глава 6. Исследовательское тестирование 433 Illegal inputs — вводить значения, которые не должны быть введены: входные данные неверного типа, неверного формата, слишком длинные, слишком короткие и т. д. Аналогично туру по плохим районам. Wrong turn tour — выполнять действия в неправильном порядке. Возьмите группу правильных действий и перемешайте их так, чтобы последовательность оказалась неверной. Пример из жизни Примеры у нас, как всегда, будут про «Дадату». Регистрация
434 Часть II. О том, как искать вдохновение для тестов… Поле Имя: Opposite tour: • Кукушка; • Идиот; • (тут был мат); • Яйцо; Illegal inputs: • ВБАтющ35ш щ8п48пд8ш5ц; • Ё!”№;%:?*()_+{}”:<>?|)(*&^%$#@!~; • (пустота); • (пробел); • (строка на 10 млн символов). Поле Почта: Opposite tour: • Пролетарская, 15; • Мега Белая Дача; Illegal inputs: • aa@[email protected]; • aa@mailru; • aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa [email protected] (сгенерить 1 млн символов). То есть различие в том, что в одном туре данные плохие (неверный формат, длинная строка и т. д.), а во втором — совсем бессмысленные. Обработка данных Система умеет обрабатывать данные разных типов: Возьмем дату рождения. Тут, кстати, туры очень похожи. Например, «31 февраля» — это вроде про Illegal inputs, но ведь это абсолютно бессмысленно с точки зрения ДР, верно?
Глава 7 ВАРИАНТ ИСПОЛЬЗОВАНИЯ Хороший вариант использования — это готовые тесты! Причем самые важные, так как покрывают главный сценарий пользователя. Поэтому если ваши аналитики не пишут сценарии, попробуйте сделать это сами! Заодно посмотрите на систему немного с другой стороны. Вариант использования показывает основной путь пользователя и его альтернативы
444 Часть II. О том, как искать вдохновение для тестов… 7.1. Что такое «вариант использования»? Вариант использования — это описание того, как пользователь использует нашу систему. Что он делает, как система реагирует. Какой основной сценарий использования и какие у него есть альтернативы. Например: Предусловия У пользователя подключена NFC-система на телефоне через приложение BananaPay (оплата телефоном аки картой). В приложении настроена основная карта для оплаты. Основной сценарий оплаты телефоном 1. Кассир вводит данные для оплаты в платежный терминал. 2. Система предлагает приложить карточку. 3. Пользователь прикладывает телефон к платежному терминалу. 4. Система считывает данные основной карточки из BananaPay. 5. Система списывает сумму, введенную на шаге 1, с карточки пользова тема списывает сумму, введенную на шаге 1, с карточки пользователя. 6. Система отображает сообщение об успешном списании средств. Альтернативы • Шаг 3. Пользователь слишком рано убрал телефон. Система не успела Шаг 3. Пользователь слишком рано убрал телефон. Система не успела считать данные и выдала ошибку. Возврат к шагу 2. • Шаг 5. На карточке пользователя недостаточно денег. Система выводит Шаг 5. На карточке пользователя недостаточно денег. Система выводит ошибку, завершение сценария. Параметры Тип карты: VISA, Mastercard, Мир…
Глава 9 СХЕМА СОСТОЯНИЙ И ПЕРЕХОДОВ (STATE & TRANSITION DIAGRAM) Рецензии не существует Рецензия в состоянии редактирования Рецензия опубликована Рецензия на модерации Рецензия удалена Рецензия остается в базе приложения Редактировать рецензию Редактировать рецензию Опубликовать рецензию Рецензия не одобрена и удаляется модератором Рецензия отправляется на модерацию Рецензия одобрена Удалить рецензию Написать рецензию Схема состояний и переходов показывает ТЗ в графическом виде. В этой главе мы научимся ее рисовать.
468 Часть II. О том, как искать вдохновение для тестов… 9.1. Что такое «схема состояний и переходов»? Схема состояний и переходов (State & Transition Diagram, S&T) наглядно показывает, как некий объект тестирования переходит из одного состояния в другое. Вот он находился в точке А, потом произошло какое-то действие, и объект попал в состояние B. Потом он попадет в состояние С и так далее… Принцип не меняется: было одно состояние, стало другое. Мы рисуем: кружочки — состояния объекта; стрелочки — то, благодаря чему объект из состояния А переходит в состояние В. Это действие, но его может совершить не только пользователь, но и система сама. Допустим, задача запустилась автоматически в 10 часов вечера. Такая схема позволяет нам сразу визуально оценить, какие переходы вообще возможны, и что надо протестировать. Ведь нам надо протестировать и эту стрелку, и эту… Так что стрелочки — это наши готовые тест-кейсы! 9.2. Составляем схему Очень важно: S&T рисуется на объект. Один объект! В идеале — на объект, имеющий аналог в базе данных продукта. Шаг 1. Вы выбираете объект в своем проекте. Шаг 2. Думаете, какие у него состояния. Они не должны пересекаться, то есть: объект не может быть разом в двух состояниях, и при этом он всегда хоть в каком-то одном есть. Шаг 3. Рисуете эти состояния кружочками. Шаг 4. Соединяете их стрелочками. Стрелочки — это действия, их надо подписать. Шаг 5. Смотрите, что получилось и анализируете, есть ли у объекта другие состояния? А другие действия между текущими состояниями? Переход на шаг 2. Состояние Состояние Переход/ Действие
470 Часть II. О том, как искать вдохновение для тестов… — В ДЗ получила фидбэк, что сделала не схему состояний и переходов, а некую инструкцию по просмотру сериала, по факту показывающую одно его состояние — в процессе просмотра. Но суть как раз в том, что сериал из непросмотренного может быть перемещен в другие состояния, отраженные в виде разделов в личном кабинете, с помощью четырех кнопок, которые на схеме являются действиями. Больше никакие действия с сериалом пользователю не доступны (загрузка, редактирование и т. д.). — Ну смотрите, Вы продолжаете описывать и смотреть на вещи, как пользователь, а надо как тестировщик. Сериалы из пустоты не берутся. Ктото их закачивает. Значит, всё же связка «сериала не существует» и «сериал загружен на сайт» — уже есть. — Да, конечно, есть, но выполнять ее может очень ограниченный круг лиц, и я в процессе тестирования этого сделать не могу (студенты выбирали любой общедоступный проект и тестировали его. Разумеется, доступа в админку у них не было). — По-хорошему у тестировщиков на это есть права, и им дают необходимый доступ. — То есть важны состояния только по отношению к сайту, а что там с этим сериалом происходит в аккаунте, уже считается как одно — просмотр? Тестировщик я без году неделя, а пользователь — много лет. ;-) Поэтому и прошу постановки мозгов. Постановка мозгов через тортики Тут моя коллега решила объяснить рисование карты на примере… Тортика! Дальнейший диалог был просто потрясающий, не могу не поделиться им с вами (разумеется, с разрешения коллеги, — всё же это ее идея, а не моя). Итак, приступаем: — Вот смотрите… торт любите? Или другую еду какую-нибудь? — Допустим. — Отлично. Чтобы приготовить торт, нам нужны
Глава 9. Схема состояний и переходов (State & Transition Diagram) 483 в гуглодокументах. Попробуйте использовать несколько разных инструментов, а потом выберите тот, что больше по душе. Но в целом бумага и ручка — вполне себе вариант! 9. Резюме Рисунок — мощнейший инструмент визуализации. Вот вы читаете эту книгу, и тут везде картинки. На что вы смотрите в первую очередь — на картинку или на текст? Поэтому я за то, чтобы рисовать! Нарисовали? Добавили в ТЗ! Всем удобнее, даже заказчику. Ведь с картинками текст становится понятнее. Настоятельно рекомендую рисовать схему состояний и переходов. Пусть даже одноразово, маркером на доске, чтобы обсудить новое ТЗ, которое пришло от аналитиков. Зарисовали, позвали аналитика и стали обсуждать: — А вот смотрите, эта стрелочка… может, нам стоит сделать еще вот это? — А что будет, если вот так? Кстати, лайфхак. Если зарисовали маркером и жалко свое творчество (уж больно продуктивное общение с командой вышло), — сфотографируйте и выложите в конфлюенс рисунок! Не обязательно тратить время на перерисовку. ;-) Вопросы для самопроверки 1. Что такое S&T? 2. Что мы рисуем в кружочках в S&T? 3. Нужно ли подписывать стрелочки? Если да, то как? 4. Действие над объектом может совершать только человек? 5. Можно ли рисовать страницы интерфейса в S&T? 6. Какие есть плюсы у этой техники? Домашнее задание: магнитики на холодильнике Схема S&T для этой книги рассыпалась на кусочки! Попробуйте собрать ее. Учтите, что некоторые магнитики лишние. Кружочки: Книги нет. В процессе создания.
484 Часть II. О том, как искать вдохновение для тестов… В стадии черновика. На редактировании. Отдана в печать. Напечатана. Выпущена. Стрелочки: Написать главу 1. Исправить опечатки. Придумать картинки. Придумать идею книги. Начать делать. Вставить картинки в книгу. Отдать редактору. Правки по комментариям. Обсудить. Отдать в печать. Напечатать. Разослать по почте. Добавить в магазин.
ЗАКЛЮЧЕНИЕ Техники тест-дизайна — это очень мощный инструмент для написания тестов. Они помогают: сделать больше полезных тестов; выкинуть лишние. В итоге: минимум тестов — максимум пользы на выходе. Так что обязательно применяйте их в своей работе! Техники, которые вы будете применять ежедневно, — классы эквивалентности и граничные значения. Они будут уместны везде, вообще в любой задаче. И простыми они выглядят только на первый взгляд. А вот применить их в системе чуть более сложной, чем интернет-магазин, — это уже навык, который нарабатывается только опытом. Пробуйте, «наступайте на грабли» и пополняйте свой список «обязательно к тестированию». От себя хочу напомнить никогда не забывать про классы: Ноль / не ноль (в нуле постоянно встречаются баги); Один — много (одна штука и две — разные вещи). А еще не забывайте про: разные вкладки — о, сколько багов можно встретить, меняя в разных вкладках один и тот же объект… отмену действия — и повтор. Повторить то же, что отменили, + повторить немного иначе. Дает ли система так сделать? Техники тест-дизайна очень полезны, применяйте их в работе!
498 Часть II. О том, как искать вдохновение для тестов… А если у вас кончились идеи, какие тесты можно еще написать, — обратитесь ко второй части книги. Там вы найдете кучу разных техник, которые помогают посмотреть на систему свежим взглядом. Удачи вам в поиске вдохновения и хороших и нужных тестов!;-) Да-да, спасибо, мы самые важные границы!