Home

Автор: Джорис Меертц (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) – пожалуй, одна из самых «магических». Сотня параметров? Миллионы миллиарды триллионы дециллионы комбинаций? Нет проблем! Берём Магический Инструмент, закладываем в него данные об этих параметрах, нажимаем Магическую Кнопку. Месиво цифр – и на выходе всего десяток комбинаций, которые нужно проверить.

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

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

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

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

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

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

Е.Гузаревич, Д.Ермакович, OOO «Технологии качества», бренд A1QA

Тестирование приложений, построенных на SharePoint – задача нетривиальная, как и поиск информации на эту тему. В данной статье попытаемся расскрыть особенности тестирования приложений на SharePoint, например, что обязательно стоит тестировать и чем можно пренебречь. Кроме того, мы ознакомим читателей с программными ограничениями платформы.

Что такое SharePoint?

Прежде чем переходить непосредственно к особенностям тестирования, стоит сказать несколько слов о самой платформе SharePoint. По сути – это CMS (Content Management System), которая содержит развитую систему документооборота - DMS (Document Management System). Если быть совсем точным, то возможности SharePoint, как CMS, в «зачаточном» состоянии, а вот с задачами организации совместной работы, возможностями создания файлового архива и управления документами он справляется на «высшем уровне»! SharePoint чаще всего применяется для создания корпоративных интранет порталов, предназначенных для облегчения взаимодействия сотрудников в пределах одной компании или организации.

Итак, SharePoint — это веб-ориентированная платформа для совместной работы и система управления документами, разработанная и реализуемая Microsoft. Таким образом, эта платформа становится единым коммуникационным центром и электронным хранилищем информации одновременно. Это решение может использоваться для создания корпоративного веб-портала, на котором размещаются совместно используемые документы или специализированные приложения общего пользования. Данные в SharePoint организованы в виде списков (например, задачи, обсуждения, календари) и библиотек документов. Функциональность SharePoint представляется пользователю посредством веб-частей — элементов управления, показывающих списки и позволяющих редактировать их. Такие веб-части размещаются на страницах, в свою очередь, публикуемых на портале и доступных пользователю через браузер. По своему содержанию SharePoint - приложение ASP.NET 2.0, использующее IIS для отображения веб-страниц и SQL Server для хранения данных.

Доклад Алексея Баранцева

Анализ границ - эту технику каждый тестировщик осваивает, наверное, самой первой.

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

Что будет, если пользователь, случайно или намеренно, пересечёт такую технологическую границу - введёт слишком большое число или слишком длинную строку? Должен ли тестировщик пытаться это выяснить? Или может быть достаточно предупредить пользователей, чтобы они не вводили "плохие" данные, а кто ввёл - мы ответственности не несём? А если всё таки мы решили, что тестировщику следует пытаться всё это проверить -как искать эти границы, если они нигде не описаны?

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

Это вторая, более полная версия доклада о границах, с более интересными и живыми примерами. Ведь на границах багов намного больше, чем мы можем себе представить.

Переходя все границы... (Алексей Баранцев, SQADays-11) from Stas Fomin on Vimeo.

Хотите узнать больше про различные техники тест-дизайна? Приходите на онлайн-тренинг Практикум по тест-дизайну или очный тренинг в Москве Тест-дизайн от А до Я

Запись доклада Алексея Лупана с онлайн-конференции Fun ConfeT&QA.

Мы так любим писать тест-кейсы, что учимся этому делу буквально с начала первого дня тестирования до исхода второго дня. Потом всю карьеру доучиваемся. То пишем мелкие тест-кейсики, то ваяем полотна Боттичелли. Подсказать алгоритм «золотой середины» написания грамотных тест-кейсов?