Home

Доклад Алексея Баранцева

Анализ границ - эту технику каждый тестировщик осваивает, наверное, самой первой.

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

Что будет, если пользователь, случайно или намеренно, пересечёт такую технологическую границу - введёт слишком большое число или слишком длинную строку? Должен ли тестировщик пытаться это выяснить? Или может быть достаточно предупредить пользователей, чтобы они не вводили "плохие" данные, а кто ввёл - мы ответственности не несём? А если всё таки мы решили, что тестировщику следует пытаться всё это проверить -как искать эти границы, если они нигде не описаны?

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

Это вторая, более полная версия доклада о границах, с более интересными и живыми примерами. Ведь на границах багов намного больше, чем мы можем себе представить.

Переходя все границы... (Алексей Баранцев, SQADays-11) from Stas Fomin on Vimeo.

Хотите узнать больше про различные техники тест-дизайна? Приходите на онлайн-тренинг Практикум по тест-дизайну или очный тренинг в Москве Тест-дизайн от А до Я

Запись доклада Алексея Лупана с онлайн-конференции Fun ConfeT&QA.

Мы так любим писать тест-кейсы, что учимся этому делу буквально с начала первого дня тестирования до исхода второго дня. Потом всю карьеру доучиваемся. То пишем мелкие тест-кейсики, то ваяем полотна Боттичелли. Подсказать алгоритм «золотой середины» написания грамотных тест-кейсов?

Продолжаем публикацию лучших докладов SQA Days 13. Сегодня представляем доклад Никиты Налютина "Математика для тестировщиков".

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

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

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

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

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

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

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

Словарь

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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