Программные ошибки тестирование документации

Как тестировать документацию. Простой алгоритм

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

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

Введение

Повторенье — мать учения, пробежимся по базовым определениям, чтоб изъясняться на одном языке:

Тестирование (testing) — процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для заявленных целей и для определения дефектов. (Источник — ISTQB Glossary)

Итак, тестирование — это процесс с тремя вопросами к тестируемому объекту

• соответствует ли он требованиям? 

• подходит цели? 

• какие есть дефекты (баги)?

Статическое тестирование (static testing): тестирование артефактов разработки программного обеспечения, таких как требования, дизайн или программный код, проводимое без исполнения этих артефактов. Например, с помощью рецензирования или статического анализа. (Источник — ISTQB Glossary)

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

Рецензирование (review): оценка состояния продукта или проекта с целью установления расхождений с запланированными результатами и для выдвижения предложений по совершенствованию. (Источник — ISTQB Glossary)

Алгоритм тестирования документации

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

1. подготовка/планирование,

2. проектирование тестов,

3. выполнение тестов,

4. отчетность,

5. завершающие действия (опционально).

Ревью (==рецензирование) документации — это тоже тестирование. 

А значит, имеем алгоритм

1.  Готовимся — выясняем, с чем мы собираемся иметь дело: 

   1. с какой целью создается документ, его официальное определение,

   2. какие обязательные сведения в нем должны содержаться,

   3. какие сведения дополнительны, но хорошо бы иметь,

   4. находим примеры в интернете, формируем личную насмотренность.

2. Проектируем Check list:

   1. включаем в него общепринятые требования в компании,

   2. подбираем подходящие best practices с просторов сети,

   3. если есть идеи потенциальных дефектов, записываем.

3. Выполняем рецензирование:
   Entry criteria: Документ соответствует цели своего создания.

   1. читаем, проверяем выполнение пунктов Check list.

4. Exit criteria: найдено 1-2 minor дефекта.
   Формируем отчетность: 

   1. cоставляем список дефектов, рекомендаций по улучшению, нераскрытых вопросов,

   2. ранжируем в порядке серьезности и приоритетности,

   3. отправляем автору,

   4. после получения обновленного варианта возвращаемся в шаг 3.

Entry criteria (критерий входа) — условие, выполнение которого обязательно для основного рецензирования. Если оно не выполняется, тестирование останавливается, документ передается на доработку.

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

Да, я приемлю считать работу над документом успешно завершенным, если в моем видении там осталась 1-2 очень незначительных замечания. Бесконечное полирование съедает драгоценное время, к тому же в рецензировании присутствует субъективность, что минорный дефект для меня — то допустимая норма для другого.

Пример тестирования требований

Какой самый частый документ, который вы тестируете? Я — Jira ticket, тип Story. Задача в Джире, которая будет_включена/уже_включена в новый спринт — типичный объект раннего тестирования. Чем она вернее и полнее описана изначально, тем больше шансов вовремя получить качественный функционал.

У каждой команды могут быть регламентированы свои стандарты оформления тикетов, прежде всего стоит поискать в документации или поинтересоваться у старших коллег, есть ли принятые стандарты в вашей компании. Есть ли их нет опираемся на распространенные общепринятые нормы ниже.

Подготовка

Jira задача с типом Story — документ, описывающий функционал, который необходимо спроектировать, написать код и протестировать.

Для меня Jira задача обязательно должна содержать:

• summary — короткое заглавие,

• description — описание предстоящей работы,

• user story — вид бизнес требования на разговорном языке, используется в Agile,

• acceptance сriteria — это критерии, которым должна соответствовать работа, для того, чтобы быть принятой заказчиком.

Дополнительно могут быть:

• use cases — прописанные сценарий пользования системой с новым функционалом,

• release number — номер релиза к которому он готовится,

• epic — основной тикет, который объединяет в группу другие,
  И т.п. 

Check list

• user story — небольшая изолированная единица функциональности, которую можно продемонстрировать, 

• user story написана в формате As a < type of user >, I want < some goal > so that < some reason >,

• ticket подходит к целям спринта,

• описание функциональности понятно
  (например, нет неизвестных терминов, сленга),

• acceptance criteria тестируемы
  (например, система должна работать стабильно весь год или интерфейс должен быть удобный — не тестируемые критерии),

• функциональность не зависит от другой функциональности в спринте
  (либо зависимость указана),

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

• функциональность приоритезирована,

• новый функционал не противоречит, согласуется с существующим ранее.

Рецензирование

Мое рецензирование jira задач не похоже на классическое книжное ревью, потому что у нас часто бывает, что Product Manager торопится и не прописывает все детали. По классическому алгоритму я должна бы собрать все замечания и вернуть ему документ на доработку. Но, когда мы говорим про Jira ticket это ненужная потеря времени, и я просто сама в процессе рецензирования дописываю недостающее. Важно, если хоть немного сомневаюсь в чем-то, прошу его проверить и подтвердить верность моих суждений, а вместе с тем адресую замечания, которые остаются. Получается рецензирование на рецензирование.

Кстати, интересный факт, я всегда считала, что заполнение jira ticket полностью обязанность Product Manager. Но недавно у нас проводила тренинги Liz Keogh, английский agile консультант, и она рассказала, что на сегодня считается успешной практикой, когда раздел Acceptance criteria заполняют именно разработчики. Это на уровне документации заставляет их детально подумать, 

• как они будут реализовать программный код,

• что непонятно, и какой информации не хватает в требованиях.

Отчетность

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

Заключение

В этой части просто повторю, что уже писала в одной из своих ранних статей. Не верю, что бывают универсальные алгоритмы, которые подойдут в любую команду, но верю, что насмотренность на чужие (даже самые простые) практики дает фундамент генерировать те способы работы, которые поднимут уровень рабочего комфорта в вашем случае. Удачи!

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

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

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

Как известно, хорошая документация должна обладать следующими свойствами:

• требования должны быть полными, правильно и в полной мере описывать функцию, которую необходимо реализовать;
• однозначность — одинаковое восприятие требований всеми членами команды, никаких расхождений в трактовке быть не должно;
• непротиворечивость: не должно быть противоречивых требований, конфликтующих между собой;
• необходимость: требования должны отражать функциональности, действительно необходимые для пользователя, для удовлетворения пользователей;
• осуществимость: насколько прописанные требования возможно реализовать;
• тестируемость: возможность проверить все прописанные требования после их реализации, если требование является полным, одинаково воспринимается всеми участниками проекта, ни одна важная деталь не упущена — данное требование может быть протестировано.  

Примеры часто встречающихся дефектов документации:

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

Тестирование документации цель:

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

Перспективы использования тестирования документации:

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

Брайан Хэнкс в своём материале на тему требований ‘Requirements in the Real World’ подчеркивает, что:

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

Когда же тестирование документации наиболее актуально:

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

Помимо уменьшения рисков, устранения несоответствий, тестирование документации может решать важные вопросы, касающиеся бизнес-целей проекта:

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

Какая документация подвержена тестированию:

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

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

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

1. review требований

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

 2) вопросы — это одна из наиболее простых и эффективных техник выявления требований. Если что-то  в документах остается непонятным — задавайте вопросы. Для получения ответов на задаваемые вопросы, можно обратиться к менеджеру, более опытному специалисту, который ранее получил соответствующую информацию от заказчика, или к самому заказчику.

 3) тест-кейсы — требование должно быть проверяемым, значит должны существовать способы проверки корректности реализованного требования. Чем тщательнее продуман чек-лист, тем вероятнее определение проверяемости требований. Прежде, чем записывать возможные тест-кейсы, убедитесь в том, что вы понимаете требование. Для хорошего понимания конкретного требование поможет анализ других требований, которые вполне возможно будут каким либо образом связаны. Но если требование так и не удалось понять — скорее всего в нем есть неточность или ошибка. Когда же все требования будут хорошо сформулированы и протестированы, можно продолжать использование этой техники, совмещая разработку тест-кейсов с дополнительным тестированием.

 4) исследование поведения системы: тестировщик моделирует процесс работы  системой, созданной по тестируемым требованиям и ищет неоднозначные варианты поведения системы (чем-то мне напоминает исследовательское тестирование).  

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

Содержание
лекции: виды
контроля качества разрабатываемого
ПО; ручной контроль; структурное,
функциональное и оценочное тестирование;
классификация ошибок; методы и средства
отладки ПО.

Цель лекции:
ознакомиться с видами и способами
контроля и тестирования ПО, методами и
средствами отладки программ.

Недостаточно
выполнить проектирование и кодирование
программного продукта,
также необходимо обеспечить его
соответствие требованиям и спецификациям.
Многократно проводимые исследования
показали, что чем раньше обнаруживаются
те или иные несоответствия или ошибки,
тем боль­ше
вероятность их исправления и ниже его
стои­мость [4].
Современные
технологии разработки ПО преду­сматривают
раннее обнаружение ошибок за счет
выполнения контроля ре­зультатов
всех этапов и стадий разработки. На
начальных этапах кон­троль
осуществляют вручную или с использованием
CASE-средств,
на последних — он принимает форму
тестирования.

Тестирование
—
это процесс выполнения программы, целью
которого является
выявление ошибок. Никакое тестирование
не может доказать отсут­ствие
ошибок в сложном ПО, поскольку выполнение
полного тестирования становится
не­возможным
и имеется вероятность, что остались
невыявленные ошибки. Соблюдение основных
правил тестирования и научно обоснованный
подбор тестов может уменьшить их
количество. Процесс разработки согласно
современной модели жизненного цикла
ПО предполагает три стадии тестирования:
автономное
тестирование компонентов ПО; комплексное
тестирование разрабатываемого ПО;
системное
или оценочное
тестирование на соответствие основным
критериям качества. Для повышения
качества тестирования рекомендуется
соблюдать следу­ющие основные
принципы:

1. предполагаемые
   результаты должны быть известны до
   тестирования;

2. следует избегать
   тестирования программы автором;

3. необходимо
   досконально изучать результаты каждого
   теста;

4. необходимо
   проверять действия программы на неверных
   данных;

5. необходимо
   проверять программу на неожиданные
   побочные эффекты на неверных данных.

Вероятность
наличия необнаруженных ошибок в части
программы пропорциональна количеству
ошибок уже най­денных в этой части.
Удачным
считают
тест, ко­торый обнаруживает хотя бы
одну ошибку. Формирование набора тестов
имеет большое значение, поскольку
тести­рование является одним из
наиболее трудоемких этапов создания
ПО. Доля стоимос­ти тестирования в
общей стоимости разработки возрастает
при увеличении сложности ПО и повышении
требо­ваний к их качеству.

Существуют
два принципиально различных подхода к
формированию тестовых наборов: структурный
и функциональный.
Структурный
подход
базируется
на том, что известна
структура
тести­руемого
ПО, в том числе его алгоритмы («стеклян­ный
ящик»).
Тесты строятся для проверки правильности
реализации заданной логики в коде
программы. Функциональный
подход
основывается на том, что структура ПО
не известна («черный
ящик»).
В этом случае тесты строят, опираясь на
функциональные спецификации. Этот
подход называют также подходом,
управляемым данными,
так как при его использовании тесты
строят на базе различных способов
декомпозиции множества данных. Наборы
тестов, полученные в соответствии с
методами этих подходов, объединяют,
обеспечивая всестороннее тестирование
ПО.

Ручной
контроль
используют на ранних эта­пах разработки.
Все проектные решения анализируются с
точки зрения их правильности и
целесообразности как можно раньше, пока
их можно легко пересмотреть. Различают
статический
и динамический
подходы к ручному контролю. При статическом
подходе
анализируют структуру, управляющие и
инфор­мационные связи программы, ее
входные и выходные данные. При динамическом
—
выполняют ручное
тестирование (вручную
моделируют про­цесс выполнения
программы на заданных исходных данных).
Исходными данными для таких проверок
являются: техническое зада­ние,
спецификации, структурная и функциональная
схемы программного продукта, схемы
отдельных компонентов, а для более
поздних этапов — алгоритмы и тексты
программ, а также тестовые наборы.
Доказано, что ручной контроль способствует
существенному увеличе­нию
производительности и повышению надежности
программ и с его помо­щью можно находить
от 30 до 70 % ошибок логического проектирования
и кодирования. Основными методами
ручного контроля являются: инспекции
исходного текста,
сквозные
просмотры,
проверка
за столом,
оценки
программ.

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

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

При
комплексном
тестирова­нии
используют тесты, построенные по методам
эквивалентных классов, граничных условий
и предположении об ошибках, поскольку
структурное тестирование для него не
при­менимо.
Одним
из самых сложных является вопрос о
завершении тестирования, так как
невозможно гарантировать, что в программе
не осталось ошибок. Часто тестирование
завершают потому, что закончилось время,
отведен­ное на его выполнение. Его
сворачивают, обходясь минимальным
тестированием
[15], которое
предпо­лагает:
тестирование граничных значений,
тщательную проверку руководства,
тестирование минимальных конфигураций
технических средств, возможности
редактирования команд и повторения их
в любой последовательности, устойчивости
к ошибкам пользователя.

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

Отладка
—
это процесс локализации
(определения
оператора программы, выполнение которого
вызвало нарушение
вычислительного процесса) и исправления
ошибок, обнаружен­ных
при тестировании ПО. Для
исправления ошиб­ки
необходимо определить ее причину.
Отладка
требует от программиста глубоких знаний
специфики управления используемыми
техническими средствами, операционной
системы, среды и языка программирования,
реализуемых процессов, природы и
специфики ошибок, методик отладки и
соответствующих программных средств;
психологически
дискомфортна (нужно искать собственные
ошибки в условиях ограниченного времени);
оставляет возможность
взаимовлияния ошибок в разных частях
программы. Четко
сформулированные методики отладки
отсутствуют. Различают:

1. синтаксические
   ошибки –
   сопровождаются комментарием с указанием
   их мес­тоположения, фиксируются
   компилятором (транслятором) при
   выполнении синтаксического и частично
   се­мантического анализа;

2. ошибки
   компоновки —
   обнаруживаются компоновщиком (редакто­ром
   связей) при объединении модулей
   программы;

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

1. ошибки
   определения исходных данных (ошибки
   передачи, ошибки преобразования, ошибки
   перезаписи и ошиб­ки данных);

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

3. ошибки
   накопления погрешностей результатов
   вычислений (игнорирование ограничений
   разрядной сетки и способов уменьшения
   погрешности).

Отладка
программы в любом случае предполагает
обдумывание и логи­ческое осмысление
всей имеющейся информации об ошибке.
Большинство ошибок можно обнаружить
по косвенным признакам посредством
тщатель­ного анализа текстов программ
и результатов тестирования без получения
дополнительной информации с помощью
следующих методов:

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

2. индукции
   (основан
   на тща­тельном анализе симптомов
   ошибки, которые могут проявляться как
   неверные результаты вычислений или
   как сообщение об ошибке);

3. дедукции
   (вначале формируют множество причин,
   которые могли бы вызвать данное
   проявление ошибки, а затем анали­зируя
   причины, исключают те, которые
   противоречат имеющимся данным);

4. обратного
   прослеживания
   (для точки вы­вода неверного результата
   строится гипотеза о значени­ях
   основных переменных, которые могли бы
   привести к получению данного результата,
   а затем, исходя из этой гипотезы, делают
   предположения о значениях переменных
   в предыдущей точке).

Для
получения дополнительной информации
об ошибке выпол­няют добавочные тесты
и используют специальные методы и
средства: отладочный
вывод;
интегрированные
средства отладки;
независимые
отладчики.

Общая
методика отладки программных продуктов,
написанных для выполнения в операционных
системах MS
DOS
и Win32:

1
этап —
изучение проявления ошибки;

2
этап – определение
локализации
ошибки;

3
этап —
определение причины ошибки;

4
этап — исправление
ошибки;

5
этап — повторное
тестирование.

Процесс
отладки можно существенно упрос­тить,
если следовать основным рекомендациям
структурного подхода к про­граммированию:

1. программу наращивать
   «сверху-вниз», от интерфейса к
   обрабатываю­щим подпрограммам,
   тестируя ее по ходу добавления
   подпрограмм;

2. выводить пользователю
   вводимые им данные для контроля и
   прове­рять их на допустимость сразу
   после ввода;

3. предусматривать
   вывод основных данных во всех узловых
   точках ал­горитма (ветвлениях, вызовах
   подпрограмм).

Дополнительную
информацию по теме можно получить в [1,
2, 4, 7, 9, 14, 15].

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Что такое тестирование документации? В мозгах начинающих тестировщиков плотно засела мысль «Проверить ТЗ на полноту, непротиворечивость и прочая, прочая…», А когда даешь им задание найти и проверить всю документацию на уже реализованном проекте, в котором нет внутренних ТЗ, возникает ступор. Что же тогда проверять? Ой, много чего 

Сегодня я хочу поговорить о сообщениях об ошибках. Да да, это тоже документация! Поэтому их надо все найти и проверить.

В систему можно загружать файл? Тогда пробуем грузить пустой файл, неправильного формата, расширения, разрешения…

В форме редактирования есть обязательные поля? Пробуем их не заполнять или заполнять неправильно…

Система передает ответы через SOAP/JSON? А если отправить неправильный запрос, пустой, с неполными или некорректными данными?

И так далее, и тому подобное.
Если есть доступ к коду — отлично! Смотрим, в какие сообщения разработчики оборачивают эксепшены, находим их в приложении и проверяем отображение.

Каким должно быть сообщение об ошибке?
— Коротким, иначе пользователь заснет, читая его.
— Понятным, иначе как понять, что я сделала не так?

Из сообщения должно быть понятно:
— В чем моя ошибка?
— Что мне сделать, чтобы исправить ее?

При этом сообщение должно быть в мире пользователя. Мне будет одинаково непонятны тексты:
— Извините, что-то сломалось.
— Error 38759245, see line 333 in code

Не лучше будет вариант:
— Неправильно введены данные.

Особенно на форме из 100 полей. Какие именно данные я ввела неверно? И даже если их подсветили красным, а что неверно то? Как верно будет? Вы мне скажите, что делать то надо.

Примеры

Dadata

В Дадату можно загружать файлы формата Excel или CSV. Если попробовать грузануть туда JPEG, система понятно объясняет, что надо сделать:

Сообщение об ошибке в Дадате понятно

Wildberries

Ни в коем случае не хочу ругать магазин, потому что сама им пользуюсь и все нравится 
Но вот сообщения об ошибках в Галерее стиля — просто упасть и не вставать, никогда.
Вчера я попробовала загрузить фото и невольно потестировала документацию сайта, в очередной раз…

Итак, заходим в личный кабинет, оттуда в «Мои образы» — https://lk.wildberries.ru/mylooks.
Читаем информацию, но увы, ни слова о том, какие файлы допустимы:

Вроде никаких ограничений нет…

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

Итак, возрадовались возможности создать образ, грузим фоточку

Выбираем фото для образа…

Ага, вот и первое ограничение! Файлы должны быть размером поменьше…

Упс, вот и первое ограничение…

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

Грузим снова:

Не хочешь 2 Мб, на тебе 100 Кб

И что бы вы думали, мне говорят?

Что значит «поддерживается только jpg»? А я что гружу?

Моя реакция:

Я ведь jpg и гружу, але!

Я гружу JPEG, а мне говорят, что формат неверный, «грузи JPEG»? о_О

Ладно-ладно! Снова открываю фоточку, снова вырезаю ножницами и сохраняю как PNG, на рисунке чуть выше мы его видим, он в 6 раз побольше весит, качество получше, все дела… Но ситуация повторяется…

Ох ох ох, у меня так было на первых попытках загрузки фоток, пошли «старым дедовским методом» — вставить картинку в Paint, уменьшить масштаб и сохранить как jpg. И вуаля, блин! Загрузилось!

Эти картинки сперты у моей выпускницы из блога. Эмоции примерно те же

Я, как пользователь, посылаю разработчикам лучи

ненав

, добра и нежности в такие минуты.

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

Файл должен быть не менее 500 пикселей в ширину и N в высоту.

Пикселей!!! Я грешила на размер файла (слишком маленький), но до пикселей без подсказки не догадалась бы вообще!

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

А можно вспомнить про финт ушами и поставить улучшение. Нам надо его продумать для начала. Как сделать так, чтобы у пользователей не возникало проблем и игрищ в «измени размер исходной картинки 5-ю способами»?

Давайте сформулируем предложение по улучшению.

Подсказывать правильный формат и размер файлов для загрузки в ГС.

1. Указать ограничения еще до того, как пользователь начнет грузить файлы. В раздел [«Мои образы»|https://lk.wildberries.ru/mylooks] (Прим. автора — так обозначаются гиперссылки в JIRA) добавить надпись:

Принимаются фото:
— jpg, jpeg, gif, png, bmp до 2Мб
— не менее 500 пикселей в ширину и 700 в высоту

2. Если пользователь грузит файл неподходящий под требования, выводить конкретное сообщение.

Не подошел формат → «Вы пытаетесь загрузить файл неподдерживаемого формата. Загрузите jpg, jpeg, gif, png или bmp».
Слишком большой → «Размер файла не должен превышать 2000 Кб».
Не прошел по пикселям → «Файл должен быть не менее 500 пикселей в ширину и 700 в высоту».

Если это сделать сложно, то выводить одно сообщение:
«Поддерживаются файлы jpg, jpeg, gif, png, bmp до 2Мб.
Не менее 500 пикселей в ширину и 700 в высоту».

**********************************************

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

Какие пиксели? Что надо делать, чтобы сделать их больше или меньше?
Имхо, лучше грузить фото покрупнее, до 3-4 Мб и ужимать их на программном уровне, чтобы не хранить тяжесть в базе. В галерее все равно небольшая фоточка отображается, поэтому обидно вряд ли будет, если делать как «радикал», который сам уменьшает фото до 800 px.

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

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

И мы, как тестировщики, в процессе тестирования документации должны такие баги находить и как минимум извещать команду разработки.

PS — опубликовав пост, дала на него ссылку на форуме, может быть, команда разработки сайта меня услышит )))

А на форуме у меня нет аватарки. Так-то, по хорошему, можно было бы аватарку из магазина подтягивать… Но ладно, пойдем загрузим…

Иду в «Мой кабинет» на форуме, далее «Изменить фотографию», выбираю фото и…

БЛИН, ДА ВЫ ЧТО, ИЗДЕВАЕТЕСЬ, ЧТО ЛИ?!!!

Расстроилась и ушла, потому что из сообщения вообще непонятно, что мне надо сделать как пользователю, чтобы исправить ошибку. Хотя вангую на вес фото, но блин… Сообщения об ошибках должны быть в мире пользователя, в мире! Эх…

См также:
Pretty roses — пользователи не любят запретов
Сообщения об ошибках (Статья Майкла Болтона)

Твой пароль плохой. Угадай, какой хороший
У вас некорректное выражение, найдите его (ребенок)

Сообщение об ошибке «Ты совсем дурак?»

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

PPS — добавила пост в общую копилку багов.

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

В этой статье мы обсудим самые распространенные типы ПО дефекты и способы их выявления.

Что такое дефект?

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

Обязательно прочтите: Разница между дефектом, ошибкой, ошибкой и сбоем

Типы программных ошибок при тестировании программного обеспечения

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

Ошибки программного обеспечения подразделяются на три типа:

1. Дефекты программного обеспечения по своей природе
2. Дефекты программного обеспечения по их приоритету
3. Дефекты программного обеспечения по их серьезности

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

#1. Дефекты программного обеспечения по своей природе

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

#1. Функциональные ошибки

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

Функциональные ошибки можно исправить, выполнив функциональное тестирование.

#2. Ошибки на уровне модуля

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

Ошибки на уровне модуля можно исправить, выполнив модульное тестирование.

#3. Ошибки уровня интеграции

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

Ошибки интеграции можно исправить, выполнив интеграционное тестирование.

#4. Дефекты юзабилити

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

Во время тестирования удобства использования тестировщики программного обеспечения проверяют приложения на соответствие требованиям пользователей и Руководству по доступности веб-контента (WCAG) для выявления таких проблем. Однако они могут оказать существенное влияние на общее качество программного обеспечения.

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

#5. Дефекты производительности

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

Ошибки юзабилити можно исправить, выполнив тестирование производительности.

#6. Дефекты безопасности

Ошибки безопасности — это тип дефекта программного обеспечения, который может иметь серьезные последствия, если его не устранить. Эти дефекты могут позволить злоумышленникам получить доступ к конфиденциальным данным или системам или даже позволить им получить контроль над уязвимым программным обеспечением. Таким образом, очень важно, чтобы ошибкам уровня безопасности уделялось первоочередное внимание и устранялись как можно скорее.

Ошибки безопасности можно исправить, выполнив тестирование безопасности.

#7. Дефекты совместимости

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

Ошибки совместимости можно исправить, выполнение тестирования совместимости.

#8. Синтаксические ошибки

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

#9. Логические ошибки

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

Общие симптомы логических ошибок включают:

• Неверные результаты или выходные данные
• Неожиданное поведение
• Сбой или зависание программного обеспечения

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

#2. Дефекты программного обеспечения по степени серьезности

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

#1. Критические дефекты

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

#2. Серьезные дефекты

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

#3. Незначительные дефекты

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

#4. Тривиальные дефекты

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

#3. Дефекты программного обеспечения по приоритету

#1. Дефекты с низким приоритетом

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

#2. Дефекты со средним приоритетом

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

#3. Дефекты с высоким приоритетом

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

Некоторые распространенные примеры дефектов с высоким приоритетом включают:

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

#4. Срочные дефекты

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

#4. Дополнительные дефекты

#1. Отсутствующие дефекты

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

#2. Неправильные дефекты

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

#3. Дефекты регрессии

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

Часто задаваемые вопросы — Типы программных ошибок< /h2>

Почему так важна правильная классификация дефектов?

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

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

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

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

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

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

Как найти лежащие в основе ошибки программного обеспечения?

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

1) Репликация. Первым этапом является воспроизведение ошибки. Это включает в себя попытку воспроизвести тот же набор шагов, в котором возникла ошибка. Это поможет проверить, является ли ошибка реальной или нет.
2) Изоляция. После того, как ошибка воспроизведена, следующим шагом будет попытка ее изоляции. Это включает в себя выяснение того, что именно вызывает ошибку. Для этого тестировщики должны задать себе несколько вопросов, например:
– Какие входные данные вызывают ошибку?
– При каких различных условиях возникает ошибка?
– Каковы различные способы проявления ошибки?
3) Анализ: после Изолируя ошибку, следующим шагом будет ее анализ. Это включает в себя понимание того, почему возникает ошибка. Тестировщики должны задать себе несколько вопросов, таких как:
– Какова основная причина ошибки?
– Какими способами можно исправить ошибку?
– Какое исправление было бы наиболее эффективным? эффективно?
4) Отчет. После анализа ошибки следующим шагом является сообщение о ней. Это включает в себя создание отчета об ошибке, который включает всю соответствующую информацию об ошибке. Отчет должен быть четким и кратким, чтобы разработчики могли его легко понять.
5) Проверка. После сообщения об ошибке следующим шагом является проверка того, была ли она исправлена. Это включает в себя повторное тестирование программного обеспечения, чтобы убедиться, что ошибка все еще существует. Если ошибка исправлена, то тестер может подтвердить это и закрыть отчет об ошибке. Если ошибка все еще существует, тестировщик может повторно открыть отчет об ошибке.

Заключение

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

Задавая правильные вопросы и применяя правильные методы, тестировщики могут помочь обеспечить чтобы дефекты обнаруживались и исправлялись как можно раньше в процессе разработки.
TAG: qa