Home

Выступление Елизаветы Батуриной на онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA, весна 2013 года.

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

Кейс, с одной стороны, помогает понять, что должна делать Система, т.е., что ожидается. А с другой стороны, показывает что может сломаться в данной ситуации и как это выявить.

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

Тестирование, основанное на кейсах, является более объективным, чем исследовательское тестирование. Вторым достоинством является четкое понимание времени, которое надо на проведение тестирования.

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

На прошлой неделе был опрос про использование инструментария для работы с тест-кейсами.

Более 150 человек приняли участие в опросе и сейчас мы подводим итоги.

Сначала диаграмма на которой представлены инструменты для работы с тест-кейсами, набравшие два и больше голосов. Все инструменты в порядке убывания голосов представлены в конце статьи.

Автор: Майкл Фритциус (Michael Fritzius)

Оригинал статьи: https://testzius.wordpress.com/2016/05/30/how-much-detail-is-too-much/

Перевод: Ольга Алифанова

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

В ручном тестировании очень важно контролировать, что уже проверено, а что еще нет.

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

Я видел разные форматы кейсов:

• Общие описания, как должно работать,
• Пошаговые инструкции,
• Ad-hoc тесты без инструкций.

Аргументация у этих подходов тоже различается:

• Концентрироваться надо на функциональности, а не на специфических шагах тестирования.
• Тесты должны быть просты и понятны даже уборщице Маше.
• Исследовательское тестирование лучше всего находит баги, и не надо ограничивать себя тест-кейсами.

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

Автор: Джорис Меертц (https://patternsofproof.wordpress.com/)

Оригинал статьи: https://patternsofproof.wordpress.com/2015/06/02/on-the-value-of-test-cases/

Перевод: Ольга Алифанова

Подгнило что-то в Датском королевстве...

Уильям Шекспир - Гамлет

Я несколько недель наблюдал за использованием тест-кейсов в проекте по разработке ПО. Команда приступила к созданию кейсов, когда функциональные спецификации были объявлены достаточно проработанными. Кейсы были разбиты на отдельные шаги и заведены в систему управления тестами (в данном случае - в HP Quality Center). Они были проанализированы, и команда планировала приступить к их выполнению, как только продукт будет передан в тестирование.

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

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

В своей новой статье Наталья Руколь, автор и ведущая Школы Тест-Аналитика, рассказывает о самой сложной части тест-анализа: отказа от тестов по причине нехватки времени. Как, когда, какие?

Тяжкая миссия тестировщика

Какая самая главная задача тестировщика? Какой навык является наиболее ценным для хорошего тестирования?

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

• Что может влиять на выполнение той или иной операции?

• При каких значениях всё может сломаться?

• Как “положить” систему?

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

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

• чёткое разбиение на классы эквивалентности и доменный анализ,

• комбинаторику значений параметров действия,

• pairwise и triplewise

• и т..д.

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

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

У некоторых тестировщиков такая ситуация вызывает постепенную демотивацию: мы не можем протестировать всё! Но просветлённые тестировщики смотрят на ту же проблему под другим углом: “отлично! вот это challenge! мне надо придумать, как протестировать это всё действительно быстро!”. А чтобы протестировать в сжатые сроки, от каких-то тестов придётся отказаться. Каждый из них может найти потенциальный дефект, и получается, что, отказываясь от проведения того или иного теста, мы повышаем вероятность пропуска дефекта. Насколько критичного? Зависит от теста, которому мы говорим “прости и прощай, но не в этот раз”. И получается, что главная задача тестировщика в этом случае - выбрать, какие тесты мы не будем проводить. Не будем тестировать, Карл!

После того, как мы опубликовали рассказ о четырёх способах упорядочения тестов, предлагаемых тестовым фреймворком TestNG, в комментариях неоднократно звучал вопрос -- не является ли создание зависимостей между тестами плохой практикой?

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

И в качестве ответа на эти комментарии Алексей Баранцев написал две статьи, которые разъясняют, почему, с одной стороны, тесты действительно должны быть независимыми, а с другой стороны -- их всё-таки можно упорядочивать, и все четыре описанных способа могут применяться, в том числе даже жёсткие зависимости между тестовыми методами.

Итак,
Почему зависимости между тестами это плохо?
и
Почему иногда всё-таки можно делать зависимые тестовые методы?

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

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

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

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

Тест-анализ -- фундаментальная составляющая тестирования. На Amazon'е этой теме посвящено множество книг, но ни одна из них пока что не переводилась на русский язык.

Что же такое тест-анализ? Какие задачи решает тест-аналитик? Какие виды анализа и исследования тестируемого ПО существуют?

Для ответов на эти вопросы мы публикуем 1-й вебинар Натальи Руколь по курсу "Школа Тест-Аналитика".  Из него вы узнаете о роли тест-аналитика, задачах тест-анализа и форматах исследования программных продуктов.

Доклад Алексея Лупана на онлайн-конференции для специалистов по тестированию Fun ConfeT&QA, весна 2012.

Обычный тестировщик начинает карьеру с тест-кейсов, и ими же завершает свой прекрасный жизненный цикл.

Крик из толпы: «Камон! Долой тест-кейсню!»

Мы вооружаемся плюсами тестирования без тест-кейсов, мы минимизируем минусы этого прекрасного подхода, мы захватываем почту-телеграф-телефон-твиттер!

С площади гудит: «Дааааааайошь старые порядки взад!»

Нам с трибуны докладывает Мурка в кожаной тужурке: «Товарищи! Доколе мы терпим засилье тест-кейсов?! Нам нужен Fun! Fun, товарищи! Fun!»

Давайте начнем прямо сейчас, давайте «Отречемся от старого мииииииира»…

Выступление Алексея Баранцева на онлайн-конференции для тестировщиков Fun ConfeT&QA.

Техника покрытия попарных комбинаций (pairwise testing) – пожалуй, одна из самых «магических». Сотня параметров? Миллионы миллиарды триллионы дециллионы комбинаций? Нет проблем! Берём Магический Инструмент, закладываем в него данные об этих параметрах, нажимаем Магическую Кнопку. Месиво цифр – и на выходе всего десяток комбинаций, которые нужно проверить.

Я встречал две крайности в применении этой техники.

Одна крайность – использование везде, с потрясающе простым обоснованием применимости – «ну, тестов же мало получается, это классно!» Другая крайность – полный отказ от использования этой техники, с не менее замечательным объяснением – «непонятно, как это работает, а тестов получается подозрительно мало, не верю!»

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

Я расскажу, не прибегая к теории, какие существуют кнопки и рычаги управления техникой покрытия попарных комбинаций:

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

Ах да, конечно, обязательно покажу Магические Инструменты, как же без этого :)