Истина: Исследования Системой Тестирования и Независимая Аналитика

Home

Истина: Исследования Системой Тестирования и Независимая Аналитика

Тест-анализ и тест-дизайн

05.06.2020 00:00
Автор: Майкл Болтон (Michael Bolton)Оригинал статьиПеревод: Ольга АлифановаВ ходе этой серии статей мы рассматриваем альтернативу подходам на основе артефактов к выполнению и отчетности о тестирования: подход на основе деятельности.Мы с моей клиенткой Фридой обсуждали, как управлять тестированием, не завися от формализованных, скриптованных, процедурных тест-кейсов. Часть любого подхода к отчетности о работе – это коммуникация между менеджером или тест-лидом и исполнителем. В сессионном тест-менеджменте часть этой коммуникации – это разговор, который мы называем дебрифингом, и об этом мы говорили в прошлый раз.
Подробнее…

 

03.06.2020 00:00
Автор: Рикард Эдгрен (Rikard Edgren)ОригиналПеревод: Ольга АлифановаДобавьте в ваш прогон немного быстрых и не всегда полезных тестов (взято у Кейнера/Баха).
  1. Тест ботинка – найдите поле ввода, переведите в него курсор, положите ботинок на клавиатуру и уйдите на обед.
  2. Граничное тестирование – тестируйте на границах, потому что неверное кодирование границ – распространенная ошибка.
Подробнее…

 

14.05.2020 00:00
Автор: Рикард Эдгрен (Rikard Edgren)ОригиналПеревод: Ольга АлифановаЧасть тест-дизайна лучше отложить на этап выполнения тестов. Имея под рукой продукт, вы можете лучше принимать решения о деталях, а также поймете, какие вариации и отклонения будут быстрыми и полезными. Вы найдете часть нужной вам информации, а также информацию, о необходимости которой вы и не подозревали. Вы узнаете, какие области подвержены ошибкам, что можно быстро протестировать, о чем стоит узнать больше, что на самом деле можно делать с ПО, как все взаимосвязано, и, возможно, самое важное: что можно улучшить.Используйте эту информацию в тест-дизайне, пересоздайте и перегруппируйте ваши тесты, вернитесь к источникам информации, которые оказались более важными, чем вы думали изначально.
Подробнее…

 

28.04.2020 00:00
Ричард Брэдшоу (Richard Bradshaw) и Сара Дири (Sarah Deery)Оригинал статьиПеревод: Ольга АлифановаДля любых тест-методов и техник верно то, что глубокое понимание того, что это такое, когда их применять, и каковы их сильные и слабые стороны – это важнейший залог их эффективного использования. Эвристики – не исключение. Вы не можете применять чек-лист эвристических техник в любых контекстах и ожидать одинаковых результатов или решения своих проблем. Их нужно применять со знанием дела, мудро и осторожно.Как тестировщик, вы, скорее всего, знакомы с использованием эвристик для структурированного создания тестов, генерации новых тест-идей и исследования границ системы, но слышали ли вы об эвристическом праксисе? Праксис – это то, что происходит, когда тест-теория применяется к тест-практике. Это расхождение между теорией и практикой. Теория без практики – сотрясание воздуха. Практика без теории пустой звук. Лучшие тестировщики – это те, кто знает об этом и работает внутри праксис-разрыва.
Подробнее…

 

24.03.2020 01:00
Автор: Рикард Эдгрен (Rikard Edgren)ОригиналПеревод: Ольга АлифановаПроцесс синтезирования тест-идей очень трудно описать. Он включает в себя множество источников информации, понимание того, что важно, немного креативности для создания хитроумных идей тестов и эффективных способов их выполнения.Самый простой способ – это взять требования, перефразировать каждый пункт, и при желании добавить деталей, используя разбиение на классы эквивалентности. Наилучший способ – это пользоваться множеством источников информации и генерировать достойные прогона идеи тестов, которые с хорошим шансом будут эффективными. Невозможный способ – скомбинировать всю важную информацию всеми доступными путями.Лучше использовать каждый важный элемент, и каждую, с вашей точки зрения, значимую комбинацию. Вам помогут ревью, реальный подсказывающий тесты продукт, а также скорость тестов – это даст вам наилучшие идеи для вашей конкретной ситуации. Совместная командная работа над ментальной картой не займет много времени.
Подробнее…

 

11.03.2020 01:00
Автор: Рикард Эдгрен (Rikard Edgren)ОригиналПеревод: Ольга АлифановаХарактеристики качества описывают атрибуты, которые дают преимущество большей части программных продуктов. Они могут использоваться как для продукта целиком, так и для его частей. Целое состоит из частей. Качество части определяется целым.Это общие характеристики, служащие богатым источником триггеров для идей по тестированию любого приложения. Некоторые из них вам не подходят, некоторые легко удовлетворить, а некоторые очень важны и сложны. См. материал для печати на следующих страницах для подробного списка вдохновляющих концепций в областях Возможностей, Надежности, Удобства использования, Харизмы, Безопасности, Производительности, IT-руемости, Совместимости, Поддерживаемости, Тестируемости, Ремонтопригодности, Портируемости. Никаких чисел к этим описаниям не дается, метрики опасны, так как скрывают то, что на самом деле важно.Пройдитесь по этому списку с коллегами или заинтересованными лицами – они помогут вам сфокусироваться, и в то же самое время получат представление о сложности продукта (и его тестирования). Обсудите с командой каждый случай конфликта характеристик.Это разбиение на категории может также быть стартовой точкой более целенаправленного нефункционального тестирования, с полезным добавлением специализированного тестирования и облегченных методов.
Подробнее…

 

19.02.2020 01:00
Автор: Рикард Эдгрен (Rikard Edgren)ОригиналПеревод: Ольга АлифановаАналитическая [1]часть тест-дизайна отвечает на вопрос, что нам надо протестировать. Это включает идентификацию и изучение различных информационных источников, а также искусство выяснения, что важно или может быть важным.Я хочу остановиться на естественном инстинкте тестировщика, подталкивающем его к разбиению информации о продукте на элементы, которые можно применить в тестировании. Это могут быть детали требований, инсайты от разговора с заказчиком, слоганы с веб-сайта – это длинный список, как мы убедились в предыдущей главе.
Подробнее…

 

17.02.2020 01:00
Назина Ольга

Что такое предварительные шаги тест-кейса

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

Подробнее…

 

Страница 1 из 8

Источник: https://www.software-testing.ru/library/testing/test-analysis

Тест-аналитики – кто это?

Истина: Исследования Системой Тестирования и Независимая Аналитика
До сих пор нет однозначного мнения о необходимости выделения тест-аналитика в отдельную проектную единицу. Далеко не для всех очевидны различия функций аналитика, тест-дизайнера и тестировщика.

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

Я предлагаю читателю составить мне компанию и посмотреть, чем в течение дня занимается тест-аналитик (в мои обязанности входит работа не только тестировщиком, но и тест-аналитиком). Итак, добро пожаловать в мир аналитики!

Как выглядит мой обычный день в роли тест-аналитика

Утром мне на почту приходит письмо от заказчика с данными для получения дистрибутива продукта и формальными требованиями к нему. Плохие новости – технического задания как такового у нас нет. Хорошие новости – представитель заказчика оказался открытым к общению молодым человеком.

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

    • исследовать продукт;
    • составить логическую карту продукта;
    • разбить программный продукт на составные части;
    • расставить приоритеты тестирования.

Исследование программного продукта

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

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

Логическая карта

Сформировав предварительное представление о продукте, составляю логическую карту (интеллект-карту).

Интеллект-карта – это техника представления любого процесса, события, мысли или идеи в систематизированной визуальной форме.

Подобный подход позволяет достигнуть одновременно нескольких целей.

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

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

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

В центре располагается центральный блок (система). От центрального блока по часовой стрелке рисуются ветви (начиная с правой стороны). От ветвей первого уровня идет деление на более глубокие уровни.

Рекомендуется использовать от 5 до 7 ветвей на уровне.

Существует множество инструментов для построения карт:

Все они отличаются удобством использования, набором параметров и ценой (есть и бесплатные варианты).

Самым простым инструментом служит лист ватмана и фломастер, но карту в электронном виде все-таки удобнее корректировать и дополнять. Более подробно тема интеллект-карт раскрыта здесь.

Замечу, что во время процесса построения карты крайне желательно получать обратную связь от заказчика.

Декомпозиция

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

1. Каждое расчленение образует свой уровень.
Исходная система располагается на нулевом уровне. После ее расчленения получаются подсистемы первого уровня. Расчленение этих подсистем или некоторых из них приводит к появлению подсистем второго уровня и т. д.

2. Система расчленяется только по одному, постоянному для всех уровней признаку.

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

Другими словами, они должны отвечать на один и тот же вопрос относительно своего родителя. Например, для интернет-магазина это могут быть каталоги товаров, товары, информационные блоки самого товара (характеристики, отзывы, фото и т. д.).

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

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

При возникновении сложностей с однозначной адресацией некоторых подсистем к той или иной группе допускается создание для них отдельной группы (подсистемы) «Другие».

Для обозримости рекомендуют выделять на каждом уровне не более 7 подсистем. При этом сама система не может являться одной из подсистем. Наглядный пример декомпозиции представлен ниже.

По клику на картинку откроется полная версия. 

Глубина декомпозиции

Глубина декомпозиции (количество уровней) определяется удобством восприятия получаемой иерархической структуры конкретным специалистом. Для специалиста, хорошо знающего систему, декомпозиция может быть неглубокой и менее детализированной. Если же результат декомпозиции предназначен для специалиста, ранее не работавшего с системой, то декомпозировать следует более детально и глубоко.

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

По клику на картинку откроется полная версия.

Как можно видеть на иллюстрации выше, для некоторых модулей достаточно деления до второго уровня (так называемая «Пакетная установка»), а для других – до четвертого (так называемая «Расширенная установка»). Случается, что для некоторых модулей хватает и одного уровня.

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

Таким образом оказывается затронутым и вопрос приоритезации продукта.

Приоритезация

Глядя на полученный (пусть и небольшой) проект, я понимаю, что даже при всем своем желании протестировать абсолютно все в указанные сроки мы физически не успеем.

Что делать в такой ситуации? Я могу предложить заказчику несколько вариантов: например, мы можем увеличить сроки на тестирование или расширить команду.

Но даже такие меры не могут гарантировать, что нами будет проверен абсолютно весь функционал.

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

В общем случае выполнять приоритезацию можно по следующим критериям:
1. Требования клиента.Требования клиента очень важны и связаны с продвижением продукта и торговой деятельностью.

2. Степень риска.

Функционал, отказ которого принесет наибольшие потери, необходимо тестировать в первую очередь и наиболее тщательно.

3. Сложность системы.

В первую очередь следует протестировать наиболее сложные свойства. Это поможет избежать перерасходов бюджета и времени.

4. Временные ограничения.

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

Источник: https://quality-lab.ru/blog/test-analysts-who-is-this/

Pravovoe-obesp
Добавить комментарий