Home

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

Доклад Максима Богуславского, руководителя отдела обеспечения качества, banki.ru на конференции CodeFest 2015.

В своем докладе я хочу рассказать о том:

• Почему не работают традиционные методы тест-дизайна от Карнера и Майлза в условиях конкуренции?
• Как тестировать огромный портал за 1 час?
• Как принять решение о допустимости деплоя в условиях сжатых сроков, неопределенности и известных дефектов?
• Как определить, что все идет в том ключе, который требуется, и продолжать работать без овертаймов?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Введение

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

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

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

Элизабет Хендриксон (Elisabeth Hendrickson)

Перевод: Артём Ваулин

Резюме: Эта статья ставит очень важный вопрос «Чего здесь нет, что должно бы быть?». Для выявления «дыр проектирования и требований» применяется идея, похожая на выявление черных дыр. Например, часто существуют зависимости между количеством ошибок, относящихся к определенной области, и тем была ли эта область полностью протестирована. Также дыры могут быть в том, что показывают типы ошибок. Хендриксон подготавливает почву для поиска и советует как «искать там, где ничего нет».

Автор: Екатерина Курач

Написать тест кейсы для «полного» тестирования продукта — просто невозможно. Мы можем разработать миллионы тестов, но будет ли время у нас их выполнить? Вероятнее всего — нет. Поэтому приходится тщательно выбирать тест кейсы, которые мы будем проводить.

Автор: Екатерина Курач

Классификация ODC (Orthogonal Defect Classification — ортогональная классификация дефектов) — это метод, разработанный корпорацией IBM с целью сбора информации о типах неисправностей, которые имеют место в разрабатываемых программных системах. Этот метод полезен при сборе и анализе тестовой информации с тем, чтобы направить усилия совершенствования процесса разработки в нужном направлении. Можно воспользоваться стандартной классификацией, разработанной авторами ODC, в качестве основы для отбора тестовых случаев.

Автор: Андрей Козлов

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

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

Я предлагаю модель, которая помогает существенно снизить риски неадекватного планирования. Суть её сводится к выделению сценариев использования приложения и наполнению их конкретными данными.

Автор: Алексей Пехов

Многие специалисты и просто пользователи продуктов на базе 1С Предприятие 8 должно быть уже наслышаны о выпуске нового программного продукта для проведения тестирования любых (согласно официальным заявлениям) конфигураций, и имя ему - 1С Сценарное тестирование 8. Сразу уточню, что данный инструмент является разработкой непосредственно компании 1С, а не сторонних активистов. Информацию по этому продукту (помимо бесконечных перепечаток с сайта 1С) найти мне не удалось, из чего я могу сделать вывод, что ее просто нет. Да и сам продукт обзора найти нелегко, по крайней мере тем, кто не хочет платить 30к за лицензию или уже ей не обладает вкупе с поставкой КИП8. Так или иначе, но после некоторых мытарств мне таки удалось заполучить этот инструмент в свои руки. И вот с этого момента начну поподробней.