Home

Автор: Крис МакМахон (Chris McMahon)

Оригинал статьи: https://chrismcmahonsblog.blogspot.com/2017/11/test-automation-heuristic-minimum-data.html

Перевод: Ольга Алифанова

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

Как я уже писал, я стараюсь настраивать тестовые данные для UI-тестов через системное API (даже если API – это чистый SQL, это все равно хорошая практика). В этом случае, когда ваш браузер стартует тест, все данные уже на местах.

К примеру (который большей частью правдив), предположим, что у вас есть запись в системе для Пользователя, и единственное необходимое поле для этой записи – это «Фамилия». Если вы начнете проектировать тесты с записями, где указана только «Фамилия», вы быстро обнаружите, где система предполагает наличие еще и «Имени», «Адреса, «Почты» или «Телефона». Чтобы узнать об этом больше, прочитайте хорошо известную статью "Falsehoods Programmers Believe About Names"

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

Во-первых, я ожидал, что смогу удалить эту запись – не было никаких причин думать, что отсутствие этой конкретной строки предотвратит удаление. У меня ничего не вышло, но я ожидал сообщения об ошибке с текстом вроде «Информация в поле Х не может быть прочитана или отсутствует». Но система не обрабатывала такое исключение, потому что не ожидала его, и в результате я получил сообщение на уровне языка системы "ARRAY INDEX OUT OF BOUNDS". Не очень-то дружелюбно по отношению к пользователю.

Есть аргумент, который звучит как «Никакой нормальный пользователь так не сделает», на что QA канонично отвечают «я пользователь – и я только что это сделал», однако такой ответ поверхностен и слишком прост. Основная проблема в том, что как только ваша система попадает в руки пользователю, вы не можете предсказать, что они с ней сделают. Вы обязаны быть настолько полезными им, насколько это вообще возможно. Куда лучшим ответом было бы то, что вы ожидаете, что система будет обслуживать большое количество пользователей и разнообразных записей, и практически со стопроцентной вероятностью при таком масштабе случиться может что угодно. Есть неплохое эссе на эту тему, написанное в 2004 году - One In A Million Is Next Tuesday.

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

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

Обсудить в форуме