Home

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

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

Автор: Jonathan Kohl, Kohl Concepts Inc., www.kohl.ca
Оригинальная публикация на английском языке: "Exploratory Testing: Finding the Music of Software Investigation"

Переводчик: Валерий Худобородов, bugsclock.blogspot.com
Оригинальная публикация перевода на русский язык

Предисловие переводчика.

Exploratory я всегда переводил как исследовательский, а если вы встречаете слова разрешение и напряжение и не можете увязать с контекстом, вернитесь к первому абзацу и постарайтесь понять их абстрактный смысл. Термин эвристика можно также трактовать как "некая устоявшаяся практика". На мой взгляд это наиболее близкий по смыслу перевод, но для context driven testing school этот термин уже прижился сам по себе.

Мой друг Стив незаурядный игрок на классической гитаре. Наблюдение за его игрой -- вдохновляющее зрелище, он потратил годы на оттачивание сноровки и исключительно мастерски владеет инструментом. Стив может рассказать о технике своей игры, дать несколько уроков и показать ученикам, как усовершенствовать свои умения. Он может петь под гитару и говорит, что музыка это напряжение (tension) и разрешение (resolution) [Напряжение -- это переход в диссонансное звучание, а разрешение -- это, наоборот, переход в консонанс. Диссонансные аккорды звучат более жёстко, напряжённо, а консонансные более мягко и гармонично - прим. пер.] Если вся музыка будет напряженная, слушателю станет не по себе. Если будет только разрешаться -- то это скучные, утомительные повторения. Стив расширяет эту идею до фактических физических действий, которые гитарист использует для извлечения определенных звуков. К примеру, если вы играете с большим преобладанием напряжения, вы будете ограничены в возможностях выполнить определенные действия. Чтобы играть музыку, вам необходимо найти баланс между напряжением и разрешением, а, чтобы найти этот баланс, вам необходимо сочетание знаний, навыков и творческого подхода.

Очередное пополнение в коллекции слайдкастов с конференции SQA Days 2009 Piter -- выступление Юлии Нечаевой на тему "Анализ как часть тестирования, или Замените 'аналитика' тестировщиком". В докладе рассмотрены различные ситуации, связанные с присутствием либо отсутствием аналитика в проектной команде, описываются функции аналитика и проводится анализ, что из перечисленного может исполнять команда тестирования. В конце доклада иллюстрируется и анализируется ситуация, когда обязанности и полномочия аналитика передаются тестировщикам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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