Home

Автор: Александр Федоров

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

Автор: Алексей Баранцев

Ещё в самом начале предыдущего онлайн-тренинга "Практикум по тест-дизайну" я обещал ученикам написать о том, как выполнять разбиение входных данных на подобласти (классы эквивалетности) в ситуациях, когда в поле ввода можно указать произвольную строку, а по смыслу туда должно быть введено число. Увы, им пришлось выполнять домашние задания без моих подсказок (впрочем, может быть это совсем не плохо). Но я всё таки решил перед тем, как начнутся занятия следующей группы, написать небольшую “шпаргалку”.

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

А что рекомендуется делать с “нечислами”? Они все объединяются в один большой класс “невалидных” данных, из него наугад берётся одно-два значения и всё.

И всё? А вот и нет!

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

Сегодня мы представляем вашему вниманию очередной слайдкаст с конференции SQA Days 8 -- запись мастер-класса Александра Александрова "Надёжный тест-дизайн". Как всегда должны предупредить, что просматривать записи мастер-классов конечно не так эффективно, как участвовать в них лично, потому что это не просто выступление, оно сопровождалось интерактивными сессиями и упражнениями, которые в записи слушать неинтересно. Поэтому не пропустите следующую конференцию SQA Days 9, которая пройдёт в Казани весной 2011 года. Регистрация уже началась!

Автор текста: Баранцев Алексей

На тренингах меня часто спрашивают, почему при построении тестов, когда делается разбиение на классы эквивалентности и анализ границ, нужно не только взять какое-нибудь значение по одну сторону границы и значение по другую сторону, но и попасть на границу или как можно ближе к границе. Казалось бы, граничные значения должны относиться либо к одной стороне, либо к другой. Вы тоже так думаете? А вот и нет! Граница -- это совершенно особое место, иногда на ней не действуют законы ни левых, ни правых. И не только на самой границе, но и в непосредственной близости от неё.

Один из примеров, который я привожу для демонстрации "приграничного хаоса" опубликован у нас в Панбагоне: Почему графическому редактору Paint не хватает памяти, чтобы уменьшить размер рисунка? Если размер задать слишком большой, Paint сразу отвергает такие данные, они "за границей возможностей". Но если данные недостаточно велики, чтобы Paint их с ходу отверг, они всё же могут оказаться настолько большими, что Paint справляется с увеличением рисунка, но после этого больше ничего сделать не может. Это эффект попадания в область "приграничного хаоса" -- данные не признаются плохими, хотя по факту таковыми являются.

Ещё один пример такого рода, который я тоже люблю использовать для демонстрации этого явления, я нашёл в блоге I.M. Testy (автор Bj Rollison): Should we use boundary values in our combinatorial tests? Если в том же Paint при указании размеров полей страниц подобраться слишком близко к границе, отделяющей допустимые данные, приложение падает, хотя по обе стороны границы, но достаточно далеко от неё оно ведёт себя вполне адекватно и предсказуемо.

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

А чтобы вы всегда помнили об этом, мы приготовили для вас плакат, который вы сможете повесить над своим компьютером, или на доске, или на другом видном месте (скачать для печати в pdf формате).

Это наш новогодний подарок вам, и не забывайте, что Новый Год -- это тоже переход границы, не попадите в зону хаоса :)

17-18 ноября Майкл Болтон приезжает в Санкт-Петербург, где проведет один из лучших тренингов по тестированию ПО «Rapid Software Testing», разработанный им совместно с Джеймсом Бахом.

Наш сайт уже публиковал переводы заметок Майкла, а к приезду Майкла мы решили сделать целую серию переводов.

Оригинальная публикация: Test Framing
Автор:Michael Bolton
Перевод: Михаил Павлов

Несколько месяцев назад Джеймс Бах рассказал мне об идее обоснования тестов (test framing). Он определил это как один из необходимых навыков тестировщика и проделал определенную работу по уточнению этой идеи, выполнив обоснование тестов в качестве упражнения вместе с одним из своих онлайн-учеников.

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

Обоснование тестов это способность проследить и/или построить логическую цепочку, которая связывает цель тестирования с тестами. Цель обоснования тестов состоит в том, чтобы уметь отвечать на вопросы типа:

• Почему вы выполняете (выполнили, собираетесь выполнять) этот тест (а не какие-то другие тесты)?
• Почему сейчас вы выполняете этот тест (уже выполнили его, собираетесь выполнять этот тест позднее)?
• Почему вы тестируете (тестировали, собираетесь тестировать) это требование, а не какое-либо другое?
• Как вы тестируете (тестировали, собираетесь тестировать) это требование?

Автор: Scott Sehlhorst
Оригинал: Test Smarter, Not Harder
Перевод: Дмитрий Дудников по заказу Software-Testing.Ru

Эта статья о комбинаторных методах построения тестов первоначально была написана для developer.* в марте 2006 года. Недавняя статья на Dailytech обращает внимание на одно очень интересное исследование о новых методах генерации многомерных комбинаций (четверок и более), выполненное Лабораторией информационных технологий Национального института стандартов и технологий США (NIST, the National Institute of Standards and Technology). Данная переработанная и дополненная версия статьи учитывает эти результаты.

Введение

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

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

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

Оригинальная публикация: Dawn Haynes http://www.sqetraining.com/file/DawnHaynesArticle.pdf

Перевод: Лаборатория Качества.

Как сделать тестирование эффективнее и полезнее, почти не меняя действующую стратегию? За 10 лет я составила 10 эвристических правил «увеличения отдачи» от тестов с помощью разумных изменений в условиях, последовательности, данных или перспективе тестов во время их выполнения.

Слава Панкратов опубликовал запись мастер-класса по проектированию тестов, который он проводил на конференции Training Labs 2009.

Авторы: А. В. Баранцев, Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript , Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
Труды Института системного программирования РАН

Аннотация. В статье описывается решение задачи построения последовательностей действий пользователя, оптимизированных для ручного выполнения, на основе модели в виде диаграммы состояний и переходов. Сценарии для ручного выполнения необходимы, во-первых,  когда графический интерфейс является единственной возможностью взаимодействия с приложением, а его реализация не предусматривает или делает экономически невыгодным программную эмуляцию воздействий через него. Во-вторых, тестовые наборы для ручного выполнения могут быть необходимы для оценки практичности графического интерфейса пользователя, для проверки его соответствия выбранным стандартам и для приемочного пользовательского тестирования. 

Автор: Виктор Кулямин
Оригинальная публикация: Труды Института системного программирования РАН

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