Home

Подведены итоги очередной онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA.
Как обычно публикуем лучший по результатам голосования доклад.
Это доклад Натальи Руколь "Тест-анализ на основе состояний и переходов".

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

• Как эти тесты продумать?
• Как обеспечить высокое покрытие не избыточным количеством тестов?
• Какие инструменты есть для тестирования состояний и переходов и как их использовать?

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

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

Последнее время тестирование по заранее написанным тестам (назовём такое тестирование скриптовым) выходит из моды. У противников скриптового тестирования много аргументов, хотя в большую часть из них я, увы, не верю. В этой статье я хочу рассказать о своём взгляде на скриптовое тестирование и его существенных плюсах. Вполне вероятно, что эти плюсы окажутся вам незакомыми. Не потому, что подход неправильный! Возможно, вы просто сталкивались с его неудачной реализацией? Для этого вторая часть статьи: о том, как внедрять скриптовое тестирование наиболее эффективно.

Словарь

В рамках этой статьи я буду называть скриптовым тестирование, перед началом которого создаются тесты, и уже по ним осуществляются проверки. В качестве альтернативы скриптовому подходу можно рассматривать ad hoc, хаотическое и исследовательское тестирования, но о них в отдельной статье — оде тестированию исследовательскому. Пока что мы просто поделим тестирование на скриптовое (основанное на заранее написанных тестах) и без-скриптовое, то есть любое другое

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

Оригинальная публикация

Если в качестве инструмента у вас имеется лишь молоток, каждая проблема начинает напоминать гвоздь. Абрахам Маслоу

В этой небольшой заметке я бы хотел рассмотреть инструмент для попарного тестирования от Microsoft – PICT (Pairwise Independent Combinatorial Testing). Уже несколько раз я применял его в своей работе и был доволен теми гибкими опциями, которые он имеет.

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

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

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

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.

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

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