|
Запись доклада Алексея Лупана с онлайн-конференции Fun ConfeT&QA. Мы так любим писать тест-кейсы, что учимся этому делу буквально с начала первого дня тестирования до исхода второго дня. Потом всю карьеру доучиваемся. То пишем мелкие тест-кейсики, то ваяем полотна Боттичелли. Подсказать алгоритм «золотой середины» написания грамотных тест-кейсов?
Переводчик: Валерий Худобородов, bugsclock.blogspot.com
Мой друг Стив незаурядный игрок на классической гитаре. Наблюдение за его игрой -- вдохновляющее зрелище, он потратил годы на оттачивание сноровки и исключительно мастерски владеет инструментом. Стив может рассказать о технике своей игры, дать несколько уроков и показать ученикам, как усовершенствовать свои умения. Он может петь под гитару и говорит, что музыка это напряжение (tension) и разрешение (resolution) [Напряжение -- это переход в диссонансное звучание, а разрешение -- это, наоборот, переход в консонанс. Диссонансные аккорды звучат более жёстко, напряжённо, а консонансные более мягко и гармонично - прим. пер.] Если вся музыка будет напряженная, слушателю станет не по себе. Если будет только разрешаться -- то это скучные, утомительные повторения. Стив расширяет эту идею до фактических физических действий, которые гитарист использует для извлечения определенных звуков. К примеру, если вы играете с большим преобладанием напряжения, вы будете ограничены в возможностях выполнить определенные действия. Чтобы играть музыку, вам необходимо найти баланс между напряжением и разрешением, а, чтобы найти этот баланс, вам необходимо сочетание знаний, навыков и творческого подхода.
Аннотация. Количество тестов в тестовых наборах для современного ПО довольно велико и продолжает увеличиваться. Кроме того, часто тесты связаны друг с другом разнообразными зависимостями, которые не всегда выделены явно, но должны учитываться при сопровождении тестов и внесении в них изменений. Проблемам организации сложных тестовых наборов и подходам к их решению и посвящена данная статья. Анализируются основные проблемы эксплуатации и развития тестов, для решения которых необходимо введение дополнительной структуры. Рассматриваются три базовых техники структуризации тестов — выделение модулей, определение квалификаторов и введение конфигурационных параметров.
Перевод: Лаборатория Качества. Как сделать тестирование эффективнее и полезнее, почти не меняя действующую стратегию? За 10 лет я составила 10 эвристических правил «увеличения отдачи» от тестов с помощью разумных изменений в условиях, последовательности, данных или перспективе тестов во время их выполнения.
17-18 ноября Майкл Болтон приезжает в Санкт-Петербург, где проведет один из лучших тренингов по тестированию ПО «Rapid Software Testing», разработанный им совместно с Джеймсом Бахом. Наш сайт уже публиковал переводы заметок Майкла, а к приезду Майкла мы решили сделать целую серию переводов. Оригинальная публикация: Test Framing Несколько месяцев назад Джеймс Бах рассказал мне об идее обоснования тестов (test framing). Он определил это как один из необходимых навыков тестировщика и проделал определенную работу по уточнению этой идеи, выполнив обоснование тестов в качестве упражнения вместе с одним из своих онлайн-учеников. Недавно мы дополнительно поработали над совершенствованием этого понятия. 30 сентября 2010 года я выступил с коротким сообщением об обосновании тестов на заседании Ассоциации по качеству программного обеспечения Китченер-Ватерлоо, а также провел четырехчасовой семинар на эту тему на EuroSTAR. Обоснование тестов это способность проследить и/или построить логическую цепочку, которая связывает цель тестирования с тестами. Цель обоснования тестов состоит в том, чтобы уметь отвечать на вопросы типа:
На тренингах меня часто спрашивают, почему при построении тестов, когда делается разбиение на классы эквивалентности и анализ границ, нужно не только взять какое-нибудь значение по одну сторону границы и значение по другую сторону, но и попасть на границу или как можно ближе к границе. Казалось бы, граничные значения должны относиться либо к одной стороне, либо к другой. Вы тоже так думаете? А вот и нет! Граница -- это совершенно особое место, иногда на ней не действуют законы ни левых, ни правых. И не только на самой границе, но и в непосредственной близости от неё. Сегодня мы представляем вашему вниманию очередной слайдкаст с конференции SQA Days 8 -- запись мастер-класса Александра Александрова "Надёжный тест-дизайн". Как всегда должны предупредить, что просматривать записи мастер-классов конечно не так эффективно, как участвовать в них лично, потому что это не просто выступление, оно сопровождалось интерактивными сессиями и упражнениями, которые в записи слушать неинтересно. Поэтому не пропустите следующую конференцию SQA Days 9, которая пройдёт в Казани весной 2011 года. Регистрация уже началась! Автор: Александр Федоров Каждый тестировщик пишет тесты по определенному принципу. Даже тот, кто слыхом не слыхал ни о каких методиках, так или иначе руководствуется рядом принципов, которые, как правило, держит в голове, или в редких случаях на бумаге. Но скажите, какой бывалый тестировщик не представлял себе фантастическую ситуацию, когда эти принципы реализованы в коде: софт создает тест-кейсы. Конечно до такой радужной перспективы еще очень далеко, но первые шаги на этом поприще уже сделаны… Автор: Наталья Руколь Страшный сон любого ответственного тестировщика – пропуск ошибки. Вы стараетесь-стараетесь, проверяете продукт, тестируете его по 8+ часов ежедневно, а после выпуска пользователь в течение недели сообщает о критичной проблеме. Как такое может быть, почему и как исправить?
Автор: Алексей Федорко Если в качестве инструмента у вас имеется лишь молоток, каждая проблема начинает напоминать гвоздь. Абрахам Маслоу В этой небольшой заметке я бы хотел рассмотреть инструмент для попарного тестирования от Microsoft – PICT (Pairwise Independent Combinatorial Testing). Уже несколько раз я применял его в своей работе и был доволен теми гибкими опциями, которые он имеет. |
Автор: Jonathan Kohl, Kohl Concepts Inc., 
Автор: 
Оригинальная публикация: 
Автор текста: