Home

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

Любой тест состоит из последовательности шагов и набора параметров, которые необходимы для выполнения теста. Так, для создания архива при помощи программы архиватора необходимо не только выбрать данные для архивации и инициировать создание архива, но и определиться с тем, какого типа данные архивируются и где они расположены. В этом примере выбор данных и создание архива будут являться шагами (сценарием), а тип данных и их расположение – параметрами. Один и тот же сценарий может выполняться с различными параметрами – в результате возникает закономерный вопрос, какие параметры и когда использовать. Сегодня мы рассмотрим одну из важных сторон этого вопроса: комбинирование параметров.

Тесты можно разделить на два типа:

1. На проверку одного параметра
2. На проверку взаимодействия нескольких (двух и более) параметров

Целью статьи является рассмотрение этих двух типов тестов, преимуществ и недостатков их использования друг перед другом. Они могут напомнить о видах тестирования, модульном и интеграционном, однако поскольку взаимодействие параметров возможно в рамках одного модуля (интеграционное тестирование подразумевает проверку взаимодействия между модулями), я предлагаю использовать иную терминологию: «простой» и «комбинаторный» тест.

Автор: Наталья Руколь

Страшный сон любого ответственного тестировщика – пропуск ошибки. Вы стараетесь-стараетесь, проверяете продукт, тестируете его по 8+ часов ежедневно, а после выпуска пользователь в течение недели сообщает о критичной проблеме. Как такое может быть, почему и как исправить?

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

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

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

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

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

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

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

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

Сегодня мы представляем вашему вниманию очередной слайдкаст с конференции 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.