 Автор: Алексей Пехов
Многие специалисты и просто пользователи продуктов на базе 1С Предприятие 8 должно быть уже наслышаны о выпуске нового программного продукта для проведения тестирования любых (согласно официальным заявлениям) конфигураций, и имя ему - 1С Сценарное тестирование 8. Сразу уточню, что данный инструмент является разработкой непосредственно компании 1С, а не сторонних активистов. Информацию по этому продукту (помимо бесконечных перепечаток с сайта 1С) найти мне не удалось, из чего я могу сделать вывод, что ее просто нет. Да и сам продукт обзора найти нелегко, по крайней мере тем, кто не хочет платить 30к за лицензию или уже ей не обладает вкупе с поставкой КИП8. Так или иначе, но после некоторых мытарств мне таки удалось заполучить этот инструмент в свои руки. И вот с этого момента начну поподробней.
Очередное пополнение в коллекции слайдкастов с конференции SQA Days 2009 Piter -- выступление Юлии Нечаевой на тему "Анализ как часть тестирования, или Замените 'аналитика' тестировщиком". В докладе рассмотрены различные ситуации, связанные с присутствием либо отсутствием аналитика в проектной команде, описываются функции аналитика и проводится анализ, что из перечисленного может исполнять команда тестирования. В конце доклада иллюстрируется и анализируется ситуация, когда обязанности и полномочия аналитика передаются тестировщикам.
Запись доклада Алексея Лупана с онлайн-конференции Fun ConfeT&QA.
Мы так любим писать тест-кейсы, что учимся этому делу буквально с начала первого дня тестирования до исхода второго дня. Потом всю карьеру доучиваемся. То пишем мелкие тест-кейсики, то ваяем полотна Боттичелли. Подсказать алгоритм «золотой середины» написания грамотных тест-кейсов?
 Автор: 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) [Напряжение -- это переход в диссонансное звучание, а разрешение -- это, наоборот, переход в консонанс. Диссонансные аккорды звучат более жёстко, напряжённо, а консонансные более мягко и гармонично - прим. пер.] Если вся музыка будет напряженная, слушателю станет не по себе. Если будет только разрешаться -- то это скучные, утомительные повторения. Стив расширяет эту идею до фактических физических действий, которые гитарист использует для извлечения определенных звуков. К примеру, если вы играете с большим преобладанием напряжения, вы будете ограничены в возможностях выполнить определенные действия. Чтобы играть музыку, вам необходимо найти баланс между напряжением и разрешением, а, чтобы найти этот баланс, вам необходимо сочетание знаний, навыков и творческого подхода.
 Автор: Виктор Кулямин
Оригинальная публикация: Труды Института системного программирования РАН
Аннотация. Количество тестов в тестовых наборах для современного ПО довольно велико и продолжает увеличиваться. Кроме того, часто тесты связаны друг с другом разнообразными зависимостями, которые не всегда выделены явно, но должны учитываться при сопровождении тестов и внесении в них изменений. Проблемам организации сложных тестовых наборов и подходам к их решению и посвящена данная статья. Анализируются основные проблемы эксплуатации и развития тестов, для решения которых необходимо введение дополнительной структуры. Рассматриваются три базовых техники структуризации тестов — выделение модулей, определение квалификаторов и введение конфигурационных параметров.
17-18 ноября Майкл Болтон приезжает в Санкт-Петербург, где проведет один из лучших тренингов по тестированию ПО «Rapid Software Testing», разработанный им совместно с Джеймсом Бахом.
Наш сайт уже публиковал переводы заметок Майкла, а к приезду Майкла мы решили сделать целую серию переводов.
Оригинальная публикация: Test Framing
Автор:Michael Bolton
Перевод: Михаил Павлов
Несколько месяцев назад Джеймс Бах рассказал мне об идее обоснования тестов (test framing). Он определил это как один из необходимых навыков тестировщика и проделал определенную работу по уточнению этой идеи, выполнив обоснование тестов в качестве упражнения вместе с одним из своих онлайн-учеников.
Недавно мы дополнительно поработали над совершенствованием этого понятия. 30 сентября 2010 года я выступил с коротким сообщением об обосновании тестов на заседании Ассоциации по качеству программного обеспечения Китченер-Ватерлоо, а также провел четырехчасовой семинар на эту тему на EuroSTAR.
Обоснование тестов это способность проследить и/или построить логическую цепочку, которая связывает цель тестирования с тестами. Цель обоснования тестов состоит в том, чтобы уметь отвечать на вопросы типа:
- Почему вы выполняете (выполнили, собираетесь выполнять) этот тест (а не какие-то другие тесты)?
- Почему сейчас вы выполняете этот тест (уже выполнили его, собираетесь выполнять этот тест позднее)?
- Почему вы тестируете (тестировали, собираетесь тестировать) это требование, а не какое-либо другое?
- Как вы тестируете (тестировали, собираетесь тестировать) это требование?
 Автор текста: Баранцев Алексей
На тренингах меня часто спрашивают, почему при построении тестов, когда делается разбиение на классы эквивалентности и анализ границ, нужно не только взять какое-нибудь значение по одну сторону границы и значение по другую сторону, но и попасть на границу или как можно ближе к границе. Казалось бы, граничные значения должны относиться либо к одной стороне, либо к другой. Вы тоже так думаете? А вот и нет! Граница -- это совершенно особое место, иногда на ней не действуют законы ни левых, ни правых. И не только на самой границе, но и в непосредственной близости от неё.
Один из примеров, который я привожу для демонстрации "приграничного хаоса" опубликован у нас в Панбагоне: Почему графическому редактору Paint не хватает памяти, чтобы уменьшить размер рисунка? Если размер задать слишком большой, Paint сразу отвергает такие данные, они "за границей возможностей". Но если данные недостаточно велики, чтобы Paint их с ходу отверг, они всё же могут оказаться настолько большими, что Paint справляется с увеличением рисунка, но после этого больше ничего сделать не может. Это эффект попадания в область "приграничного хаоса" -- данные не признаются плохими, хотя по факту таковыми являются.
Ещё один пример такого рода, который я тоже люблю использовать для демонстрации этого явления, я нашёл в блоге I.M. Testy (автор Bj Rollison): Should we use boundary values in our combinatorial tests? Если в том же Paint при указании размеров полей страниц подобраться слишком близко к границе, отделяющей допустимые данные, приложение падает, хотя по обе стороны границы, но достаточно далеко от неё оно ведёт себя вполне адекватно и предсказуемо.
У меня есть и другие примеры подобного рода, демонстрирующие эффект "приграничного хаоса", а может быть и вы встречались с чем-то подобным. Поэтому я призываю вас не забывать о том, что самые трудноуловимые, но и самые красивые баги часто водятся на границах, и если вы проявите должную настойчивость и сумеете попасть в эту область, где законы порядка не действуют, ваши усилия будут вознаграждены сторицей.
А чтобы вы всегда помнили об этом, мы приготовили для вас плакат, который вы сможете повесить над своим компьютером, или на доске, или на другом видном месте (скачать для печати в pdf формате).
Это наш новогодний подарок вам, и не забывайте, что Новый Год -- это тоже переход границы, не попадите в зону хаоса :)
Автор: Роман Ивлиев
Представить современного человека без мобильника, врача без аппарата для снятия кардиограммы, сложный станок без ЧПУ, самолет без автопилота практически невозможно. Все эти устройства объединяет одно: наличие спрятанного внутри них ПО. В этом слайдкасте речь идет о наиболее распространенных проблемах и особенностях тестирования встраиваемого программного обеспечения, о подходах, которые могут облегчить жизнь специалистам по тестированию, ускорить процесс и обеспечить качественный результат.
Сегодня мы представляем вашему вниманию очередной слайдкаст с конференции SQA Days 8 -- запись мастер-класса Александра Александрова "Надёжный тест-дизайн". Как всегда должны предупредить, что просматривать записи мастер-классов конечно не так эффективно, как участвовать в них лично, потому что это не просто выступление, оно сопровождалось интерактивными сессиями и упражнениями, которые в записи слушать неинтересно. Поэтому не пропустите следующую конференцию SQA Days 9, которая пройдёт в Казани весной 2011 года. Регистрация уже началась!
|
Оригинальная публикация: