Ошибки выявляемые при функциональном тестировании

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

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

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

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

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

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

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

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

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

7.2.3. Функциональное тестирование

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

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

В задачи функционального тестирования входят:

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

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

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

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

• корректное оформление требований и ограничений к качеству ПО;
• корректное описание модели функционирования ПО в среде эксплуатации у заказчика;
• адекватность модели ПО заданному классу.

7.3. Инфраструктура процесса тестирования ПС

Под инфраструктурой процесса тестирования понимается:

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

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

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

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

Поэтому предпочтительным является метод «белого ящика», при котором можно использовать структуру объекта для организации тестирования по различным ветвям. Например, можно выполнить тестовые наборы, которые проходят через все операторы или все контрольные точки компонента для того, чтобы убедиться в правильности их работы.

7.3.1. Методы поиска ошибок в программах

Международный стандарт ANSI/IEEE-729-83 разделяет все ошибки в разработке программ на следующие типы.

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

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

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

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

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

Ошибки на этапах процесса тестирования.Приведенные типы ошибок распределяются по этапам ЖЦ и им соответствуют такие источники их возникновения [7.12]:

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

Рассмотрим процесс тестирования, исходя из рекомендаций стандарта ISO/IEC 12207, и приведем типы ошибок, которые обнаруживаются на каждом процессе ЖЦ.

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

Характерными ошибками этого процесса являются:

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

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

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

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

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

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

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

Все ошибки, которые возникают в программах, принято подразделять на следующие классы [7.12]:

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

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

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

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

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

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

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

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

На современном этапе развития средств поддержки разработки ПО (CASE-технологии, объектно-ориентированные методы и средства проектирования моделей и программ) проводится такое проектирование, при котором ПО защищается от наиболее типичных ошибок и тем самым предотвращается появление программных дефектов.

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

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

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

Приведем следующую классификацию типов отказов:

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

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

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

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

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

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

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

В зависимости от степени доступа к коду системы можно выделить два типа функциональных испытаний:

⦁ тестирование black box (черный ящик) – проведение функционального тестирования без доступа к коду системы,
⦁ тестирование white box (белый ящик) – функциональное тестирование с доступом к коду системы.
Тестирование black box проводится без знания внутренних механизмов работы системы и опирается на внешние проявления ее работы. При этом тестировании проверяется поведение ПО при различных входных данных и внутреннем состоянии систем. В случае тестирования white box создаются тест-кейсы, основанные преимущественно на коде системы ПО. Также существует расширенный тип black-box тестирования, включающего в себя изучение кода, – так называемый grey box (серый ящик).

Ключевые преимущества

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

Основные этапы функционального тестирования

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

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

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

Направления функционального тестирования

Регрессионное тестирование — Тестирование функциональности продукта после исправления ошибок или реализации новых функциональных возможностей

Тестирование безопасности — Оценка уязвимости ПО к различным атакам и попыткам несанкционированного доступа к данным.

Системное тестирование — Проверка соответствия ПО требованиям, заявленным в спецификации

Тестирование мобильных приложений — Выявление дефектов в работе графического интерфейса

Тестирование установки — Тестирование процесса инсталляции/деинсталляции программного обеспечения

Конфигурационное тестирование — Проверка работы ПО на различных программных и аппаратных окружениях.

Интеграционное тестирование — Тестирование взаимодействий между компонентами системы и между несколькими системами.

Smoke-тестирование — Короткий цикл тестов для выявления правильной работы основных функций приложения.

Тестирование документации — Проверка документов на соответствие принятым стандартам, а также соответствие определенным характеристикам

Обеспечение тестового покрытия — Оценка плотности покрытия системы тестами

Тестирование удобства использования — Определение степени удобства использования, понятности и привлекательности разрабатываемого продукта

Регрессионное тестирование

Каждый раз при внесении изменений в систему, либо дополнения ее новым функционалом, существует

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

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

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

Ключевые преимущества

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

Основные этапы

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

Интеграционное тестирование

Многие современные ИТ-системы взаимодействуют с другими системами и модулями, поэтому крайне

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

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

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

Ключевые преимущества

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

⦁ Предотвращение появления критичных ошибок в опытно-промышленной эксплуатации;
⦁ Снижение влияния человеческого фактора;
⦁ Экономия затрат на исправление дефектов.

Основные задачи

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

Способы проведения интеграционного тестирования подбираются в зависимости от интеграционных решений.

Этапы

⦁ Разработка тест-плана – руководства к действию для тестировщиков;
⦁ Формирование тестовых данных и создание тест-кейсов;
⦁ Реализация сценариев для запуска тест-кейсов;
⦁ Выполнение тест-кейсов и исправление ошибок;
⦁ Повторение цикла тестирования до успешной интеграции.

Тестирование безопасности

Тестирование безопасности проводится с целью оценки устойчивости системы к противоправным

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

таких систем функционального тестирования оказывается недостаточно.

Ключевые преимущества

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

Основные задачи

⦁ Анализ архитектуры и построение  модели угроз и рисков
⦁ Определение критериев защищенности
⦁ Поиск уязвимостей в исходном коде
⦁ Fuzz тестирование
⦁ Тестирование на проникновение
⦁ Тестирование, основанное на рисках
⦁ Проведение нагрузочного тестирования

Этапы

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

Smoke-тестирование

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

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

Ключевые преимущества

⦁ Выявление критичных ошибок в первые несколько часов (минут) после установки
⦁ Снижение рисков вывода некачественного продукта;
⦁ Минимизация рисков при интеграции систем;
⦁ Сокращение затрат на исправление дефектов;
⦁ Ускорение проверки за счет автоматизации.

Основные задачи

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

Системное тестирование

Системное тестирование предназначено для тестирования

готового ПО в том состоянии, в котором оно будет внедряться в опытно-промышленную эксплуатацию.

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

Ключевые преимущества

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

Основные задачи

⦁ Определение подхода к составлению тестовых сценариев
⦁ Создание плана и методики испытаний
⦁ Подготовка тестовых данных
⦁ Проведение тестирования
⦁ Выявление некорректного использования ресурсов

Этапы

⦁ Тестовый план
⦁ Разработка тестов
⦁ Подготовка тестовых данных
⦁ Тестовые прогоны – автоматизированные и обычные
⦁ Составление отчета
⦁ Регрессионое тестирование после исправления ошибок

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

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

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

Ключевые преимущества

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

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

⦁ Бизнес-требования
⦁ Функциональные требования
⦁ Техническое задание
⦁ Руководства пользователей

Тестирование мобильных приложений

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

Ключевые преимущества

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

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

Обеспечение тестового покрытия

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

Ключевые преимущества

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

Основные задачи

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

Тестирование установки

Тестирование установки (инсталляционное тестирование) позволяет удостовериться в том, что ПО корректно устанавливается и настраивается, накат новых версий происходит без ошибок, а также есть возможность деинсталлировать и удалить данное ПО. Тестирование инсталляции необходимо проводить при создании ПО, после появления новой версии, а также при изменении конфигурации стенда.
Инсталляционное тестирование ПО рекомендуется проводить на разных платформах, ручным методом или с помощью автоматизации. На данный тип работ по тестированию влияют следующие факторы:
⦁ Какие платформы и операционные системы поддерживаются?
⦁ Каким образом будет распространяться программное обеспечение?
⦁ Кто будет устанавливать программное обеспечение?

Ключевые преимущества

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

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

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

Тестирование удобства использования

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

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

Результаты тестирования удобства использования обеспечат положительные отзывы пользователей системы в будущем. Если система предназначена для регулярного использования, например, сотрудниками call-центра, операционистами в банке или продавцами-консультантами в магазине, эргономичность системы снизит их трудозатраты на выполнение  повседневных операций. Если система предназначена для обслуживания клиентов, например, интернет-магазин или  интернет-банк, удобство и простота системы оставят положительные воспоминания о работе с ней, что сохранит клиентов и привлечет новых.

Основные задачи

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

В рамках данной задачи оценивается:

⦁ Сколько шагов нужно сделать для выполнения задачи?
⦁ Сколько времени требуется на выполнение задачи?
⦁ Сколько ошибок делает пользователь-новичок при выполнении задачи?
⦁ Какое впечатление осталось у пользователя от работы с программой?
⦁ Эмоции пользователя во время выполнения задачи.

Конфигурационное тестирование

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

Ключевые преимущества

⦁ Конфигурационное тестирование полностью имитирует фактическое использование системы.
⦁ Позволяет своевременно выявить системные ошибки ПО в работе под разными конфигурациями, и, таким образом, предотвратить проблемы при работе с ним.

Основные этапы конфигурационного тестирования

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

Software testing is the process of testing and verifying that a software product or application is doing what it is supposed to do. The benefits of testing include preventing distractions, reducing development costs, and improving performance. There are many different types of software testing, each with specific goals and strategies. Some of them are below:

1. Acceptance Testing: Ensuring that the whole system works as intended.
2. Integration Testing: Ensuring that software components or functions work together.
3. Unit Testing: To ensure that each software unit is operating as expected. The unit is a testable component of the application.
4. Functional Testing: Evaluating activities by imitating business conditions, based on operational requirements. Checking the black box is a common way to confirm tasks.
5. Performance Testing: A test of how the software works under various operating loads. Load testing, for example, is used to assess performance under real-life load conditions.
6. Re-Testing: To test whether new features are broken or degraded. Hygiene checks can be used to verify menus, functions, and commands at the highest level when there is no time for a full reversal test.

What is a Bug?

A malfunction in the software/system is an error that may cause components or the system to fail to perform its required functions. In other words, if an error is encountered during the test it can cause malfunction. For example, incorrect data description, statements, input data, design, etc.

Reasons Why Bugs Occur?

1. Lack of Communication: This is a key factor contributing to the development of software bug fixes. Thus, a lack of clarity in communication can lead to misunderstandings of what the software should or should not do. In many cases, the customer may not fully understand how the product should ultimately work. This is especially true if the software is designed for a completely new product. Such situations often lead to many misinterpretations from both sides.

2. Repeated Definitions Required: Constantly changing software requirements creates confusion and pressure in both software development and testing teams. Usually, adding a new feature or deleting an existing feature can be linked to other modules or software components. Observing such problems causes software interruptions.

3. Policy Framework Does Not Exist: Also, debugging a software component/software component may appear in a different or similar component. Lack of foresight can cause serious problems and increase the number of distractions. This is one of the biggest problems because of what interruptions occur as engineers are often under pressure related to timelines; constantly changing needs, increasing the number of distractions, etc. Addition, Design and redesign, UI integration, module integration, database management all add to the complexity of the software and the system as a whole.

4. Performance Errors: Significant problems with software design and architecture can cause problems for systems. Improved software tends to make mistakes as programmers can also make mistakes. As a test tester, data/announcement reference errors, control flow errors, parameter errors, input/output errors, etc.

5. Lots of Recycling: Resetting resources, redoing or discarding a finished work, changes in hardware/software requirements may also affect the software. Assigning a new developer to a project in the middle of nowhere can cause software interruptions. This can happen if proper coding standards are not followed, incorrect coding, inaccurate data transfer, etc. Discarding part of existing code may leave traces on other parts of the software; Ignoring or deleting that code may cause software interruptions. In addition, critical bugs can occur especially with large projects, as it becomes difficult to pinpoint the location of the problem.

Life Cycle of a Bug in Software Testing

Below are the steps in the lifecycle of the bug in software testing:

1. Open: The editor begins the process of analyzing bugs here, where possible, and works to fix them. If the editor thinks the error is not enough, the error for some reason can be transferred to the next four regions, Reject or No, i.e. Repeat.
2. New: This is the first stage of the distortion of distractions in the life cycle of the disorder. In the later stages of the bug’s life cycle, confirmation and testing are performed on these bugs when a new feature is discovered.
3. Shared: The engineering team has been provided with a new bug fixer recently built at this level. This will be sent to the designer by the project leader or team manager.
4. Pending Review: When fixing an error, the designer will give the inspector an error check and the feature status will remain pending ‘review’ until the tester is working on the error check.
5. Fixed: If the Developer completes the debugging task by making the necessary changes, the feature status can be called “Fixed.”
6. Confirmed: If the tester had no problem with the feature after the designer was given the feature on the test device and thought that if it was properly adjusted, the feature status was given “verified”.
7. Open again / Reopen: If there is still an error, the editor will then be instructed to check and the feature status will be re-opened.
8. Closed: If the error is not present, the tester changes the status of the feature to ‘Off’.
9. Check Again: The inspector then begins the process of reviewing the error to check that the error has been corrected by the engineer as required.
10. Repeat: If the engineer is considering a factor similar to another factor. If the developer considers a feature similar to another feature, or if the definition of malfunction coincides with any other malfunction, the status of the feature is changed by the developer to ‘duplicate’.

Few more stages to add here are:

1. Rejected: If a feature can be considered a real factor the developer will mean “Rejected” developer.
2. Duplicate: If the engineer finds a feature similar to any other feature or if the concept of the malfunction is similar to any other feature the status of the feature is changed to ‘Duplicate’ by the developer.
3. Postponed: If the developer feels that the feature is not very important and can be corrected in the next release, however, in that case, he can change the status of the feature such as ‘Postponed’.
4. Not a Bug: If the feature does not affect the performance of the application, the corrupt state is changed to “Not a Bug”.

Bug Report

1. Defect/ Bug Name: A short headline describing the defect. It should be specific and accurate.
2. Defect/Bug ID: Unique identification number for the defect.
3. Defect Description: Detailed description of the bug including the information of the module in which it was detected. It contains a detailed summary including the severity, priority, expected results vs actual output, etc.
4. Severity: This describes the impact of the defect on the application under test.
5. Priority: This is related to how urgent it is to fix the defect. Priority can be High/ Medium/ Low based on the impact urgency at which the defect should be fixed.
6. Reported By: Name/ ID of the tester who reported the bug.
7. Reported On: Date when the defect is raised.
8. Steps: These include detailed steps along with the screenshots with which the developer can reproduce the same defect.
9. Status: New/ Open/ Active
10. Fixed By: Name/ ID of the developer who fixed the defect.
11. Data Closed: Date when the defect is closed.

Factors to be Considered while Reporting a Bug:

1. The whole team should clearly understand the different conditions of the trauma before starting research on the life cycle of the disability.
2. To prevent future confusion, a flawed life cycle should be well documented.
3. Make sure everyone who has any work related to the Default Life Cycle understands his or her best results work very clearly.
4. Everyone who changes the status quo should be aware of the situation which should provide sufficient information about the nature of the feature and the reason for it so that everyone working on that feature can easily see the reason for that feature.
5. A feature tracking tool should be carefully handled in the course of a defective life cycle work to ensure consistency between errors.

Bug Tracking Tools

Below are some of the bug tracking tools–

1. KATALON TESTOPS: Katalon TestOps is a free, powerful orchestration platform that helps with your process of tracking bugs. TestOps provides testing teams and DevOps teams with a clear, linked picture of their testing, resources, and locations to launch the right test, in the right place, at the right time.

Features:

• Applies to Cloud, Desktop: Window and Linux program.
• Compatible with almost all test frames available: Jasmine, JUnit, Pytest, Mocha, etc .; CI / CD tools: Jenkins, CircleCI, and management platforms: Jira, Slack.
• Track real-time data for error correction, and for accuracy.
• Live and complete performance test reports to determine the cause of any problems.
• Plan well with Smart Scheduling to prepare for the test cycle while maintaining high quality.
• Rate release readiness to improve release confidence.
• Improve collaboration and enhance transparency with comments, dashboards, KPI tracking, possible details – all in one place.

2. KUALITEE: Collection of specific results and analysis with solid failure analysis in any framework. The Kualitee is for development and QA teams look beyond the allocation and tracking of bugs. It allows you to build high-quality software using tiny bugs, fast QA cycles, and better control of your build. The comprehensive suite combines all the functions of a good error management tool and has a test case and flow of test work built into it seamlessly. You would not need to combine and match different tools; instead, you can manage all your tests in one place.

Features:

• Create, assign, and track errors.
• Tracing between disability, needs, and testing.
• Easy-to-use errors, test cases, and test cycles.
• Custom permissions, fields, and reporting.
• Interactive and informative dashboard.
• Integration of external companies and REST API.
• An intuitive and easy-to-use interface.

3. QA Coverage: QACoverage is the place to go for successfully managing all your testing processes so that you can produce high-quality and trouble-free products. It has a disability control module that will allow you to manage errors from the first diagnostic phase until closed. The error tracking process can be customized and tailored to the needs of each client. In addition to negative tracking, QACoverage has the ability to track risks, issues, enhancements, suggestions, and recommendations. It also has full capabilities for complex test management solutions that include needs management, test case design, test case issuance, and reporting.

Features:

1. Control the overall workflow of a variety of Tickets including risk, issues, tasks, and development management.
2. Produce complete metrics to identify the causes and levels of difficulty.
3. Support a variety of information that supports the feature with email attachments.
4. Create and set up a workflow for enhanced test visibility with automatic notifications.
5. Photo reports based on difficulty, importance, type of malfunction, disability category, expected correction date, and much more.

4. BUG HERD: BugHerd is an easy way to track bugs, collect and manage webpage responses. Your team and customers search for feedback on web pages, so they can find the exact problem. BugHerd also scans the information you need to replicate and resolve bugs quickly, such as browser, CSS selector data, operating system, and screenshot. Distractions and feedback, as well as technical information, are submitted to the Kanban Style Task Board, where distractions can be assigned and managed until they are eliminated. BugHerd can also integrate with your existing project management tools, helping to keep your team on the same page with bug fixes.

Software testing is the process of testing and verifying that a software product or application is doing what it is supposed to do. The benefits of testing include preventing distractions, reducing development costs, and improving performance. There are many different types of software testing, each with specific goals and strategies. Some of them are below:

1. Acceptance Testing: Ensuring that the whole system works as intended.
2. Integration Testing: Ensuring that software components or functions work together.
3. Unit Testing: To ensure that each software unit is operating as expected. The unit is a testable component of the application.
4. Functional Testing: Evaluating activities by imitating business conditions, based on operational requirements. Checking the black box is a common way to confirm tasks.
5. Performance Testing: A test of how the software works under various operating loads. Load testing, for example, is used to assess performance under real-life load conditions.
6. Re-Testing: To test whether new features are broken or degraded. Hygiene checks can be used to verify menus, functions, and commands at the highest level when there is no time for a full reversal test.

What is a Bug?

A malfunction in the software/system is an error that may cause components or the system to fail to perform its required functions. In other words, if an error is encountered during the test it can cause malfunction. For example, incorrect data description, statements, input data, design, etc.

Reasons Why Bugs Occur?

1. Lack of Communication: This is a key factor contributing to the development of software bug fixes. Thus, a lack of clarity in communication can lead to misunderstandings of what the software should or should not do. In many cases, the customer may not fully understand how the product should ultimately work. This is especially true if the software is designed for a completely new product. Such situations often lead to many misinterpretations from both sides.

2. Repeated Definitions Required: Constantly changing software requirements creates confusion and pressure in both software development and testing teams. Usually, adding a new feature or deleting an existing feature can be linked to other modules or software components. Observing such problems causes software interruptions.

3. Policy Framework Does Not Exist: Also, debugging a software component/software component may appear in a different or similar component. Lack of foresight can cause serious problems and increase the number of distractions. This is one of the biggest problems because of what interruptions occur as engineers are often under pressure related to timelines; constantly changing needs, increasing the number of distractions, etc. Addition, Design and redesign, UI integration, module integration, database management all add to the complexity of the software and the system as a whole.

4. Performance Errors: Significant problems with software design and architecture can cause problems for systems. Improved software tends to make mistakes as programmers can also make mistakes. As a test tester, data/announcement reference errors, control flow errors, parameter errors, input/output errors, etc.

5. Lots of Recycling: Resetting resources, redoing or discarding a finished work, changes in hardware/software requirements may also affect the software. Assigning a new developer to a project in the middle of nowhere can cause software interruptions. This can happen if proper coding standards are not followed, incorrect coding, inaccurate data transfer, etc. Discarding part of existing code may leave traces on other parts of the software; Ignoring or deleting that code may cause software interruptions. In addition, critical bugs can occur especially with large projects, as it becomes difficult to pinpoint the location of the problem.

Life Cycle of a Bug in Software Testing

Below are the steps in the lifecycle of the bug in software testing:

1. Open: The editor begins the process of analyzing bugs here, where possible, and works to fix them. If the editor thinks the error is not enough, the error for some reason can be transferred to the next four regions, Reject or No, i.e. Repeat.
2. New: This is the first stage of the distortion of distractions in the life cycle of the disorder. In the later stages of the bug’s life cycle, confirmation and testing are performed on these bugs when a new feature is discovered.
3. Shared: The engineering team has been provided with a new bug fixer recently built at this level. This will be sent to the designer by the project leader or team manager.
4. Pending Review: When fixing an error, the designer will give the inspector an error check and the feature status will remain pending ‘review’ until the tester is working on the error check.
5. Fixed: If the Developer completes the debugging task by making the necessary changes, the feature status can be called “Fixed.”
6. Confirmed: If the tester had no problem with the feature after the designer was given the feature on the test device and thought that if it was properly adjusted, the feature status was given “verified”.
7. Open again / Reopen: If there is still an error, the editor will then be instructed to check and the feature status will be re-opened.
8. Closed: If the error is not present, the tester changes the status of the feature to ‘Off’.
9. Check Again: The inspector then begins the process of reviewing the error to check that the error has been corrected by the engineer as required.
10. Repeat: If the engineer is considering a factor similar to another factor. If the developer considers a feature similar to another feature, or if the definition of malfunction coincides with any other malfunction, the status of the feature is changed by the developer to ‘duplicate’.

Few more stages to add here are:

1. Rejected: If a feature can be considered a real factor the developer will mean “Rejected” developer.
2. Duplicate: If the engineer finds a feature similar to any other feature or if the concept of the malfunction is similar to any other feature the status of the feature is changed to ‘Duplicate’ by the developer.
3. Postponed: If the developer feels that the feature is not very important and can be corrected in the next release, however, in that case, he can change the status of the feature such as ‘Postponed’.
4. Not a Bug: If the feature does not affect the performance of the application, the corrupt state is changed to “Not a Bug”.

Bug Report

1. Defect/ Bug Name: A short headline describing the defect. It should be specific and accurate.
2. Defect/Bug ID: Unique identification number for the defect.
3. Defect Description: Detailed description of the bug including the information of the module in which it was detected. It contains a detailed summary including the severity, priority, expected results vs actual output, etc.
4. Severity: This describes the impact of the defect on the application under test.
5. Priority: This is related to how urgent it is to fix the defect. Priority can be High/ Medium/ Low based on the impact urgency at which the defect should be fixed.
6. Reported By: Name/ ID of the tester who reported the bug.
7. Reported On: Date when the defect is raised.
8. Steps: These include detailed steps along with the screenshots with which the developer can reproduce the same defect.
9. Status: New/ Open/ Active
10. Fixed By: Name/ ID of the developer who fixed the defect.
11. Data Closed: Date when the defect is closed.

Factors to be Considered while Reporting a Bug:

1. The whole team should clearly understand the different conditions of the trauma before starting research on the life cycle of the disability.
2. To prevent future confusion, a flawed life cycle should be well documented.
3. Make sure everyone who has any work related to the Default Life Cycle understands his or her best results work very clearly.
4. Everyone who changes the status quo should be aware of the situation which should provide sufficient information about the nature of the feature and the reason for it so that everyone working on that feature can easily see the reason for that feature.
5. A feature tracking tool should be carefully handled in the course of a defective life cycle work to ensure consistency between errors.

Bug Tracking Tools

Below are some of the bug tracking tools–

1. KATALON TESTOPS: Katalon TestOps is a free, powerful orchestration platform that helps with your process of tracking bugs. TestOps provides testing teams and DevOps teams with a clear, linked picture of their testing, resources, and locations to launch the right test, in the right place, at the right time.

Features:

• Applies to Cloud, Desktop: Window and Linux program.
• Compatible with almost all test frames available: Jasmine, JUnit, Pytest, Mocha, etc .; CI / CD tools: Jenkins, CircleCI, and management platforms: Jira, Slack.
• Track real-time data for error correction, and for accuracy.
• Live and complete performance test reports to determine the cause of any problems.
• Plan well with Smart Scheduling to prepare for the test cycle while maintaining high quality.
• Rate release readiness to improve release confidence.
• Improve collaboration and enhance transparency with comments, dashboards, KPI tracking, possible details – all in one place.

2. KUALITEE: Collection of specific results and analysis with solid failure analysis in any framework. The Kualitee is for development and QA teams look beyond the allocation and tracking of bugs. It allows you to build high-quality software using tiny bugs, fast QA cycles, and better control of your build. The comprehensive suite combines all the functions of a good error management tool and has a test case and flow of test work built into it seamlessly. You would not need to combine and match different tools; instead, you can manage all your tests in one place.

Features:

• Create, assign, and track errors.
• Tracing between disability, needs, and testing.
• Easy-to-use errors, test cases, and test cycles.
• Custom permissions, fields, and reporting.
• Interactive and informative dashboard.
• Integration of external companies and REST API.
• An intuitive and easy-to-use interface.

3. QA Coverage: QACoverage is the place to go for successfully managing all your testing processes so that you can produce high-quality and trouble-free products. It has a disability control module that will allow you to manage errors from the first diagnostic phase until closed. The error tracking process can be customized and tailored to the needs of each client. In addition to negative tracking, QACoverage has the ability to track risks, issues, enhancements, suggestions, and recommendations. It also has full capabilities for complex test management solutions that include needs management, test case design, test case issuance, and reporting.

Features:

1. Control the overall workflow of a variety of Tickets including risk, issues, tasks, and development management.
2. Produce complete metrics to identify the causes and levels of difficulty.
3. Support a variety of information that supports the feature with email attachments.
4. Create and set up a workflow for enhanced test visibility with automatic notifications.
5. Photo reports based on difficulty, importance, type of malfunction, disability category, expected correction date, and much more.

4. BUG HERD: BugHerd is an easy way to track bugs, collect and manage webpage responses. Your team and customers search for feedback on web pages, so they can find the exact problem. BugHerd also scans the information you need to replicate and resolve bugs quickly, such as browser, CSS selector data, operating system, and screenshot. Distractions and feedback, as well as technical information, are submitted to the Kanban Style Task Board, where distractions can be assigned and managed until they are eliminated. BugHerd can also integrate with your existing project management tools, helping to keep your team on the same page with bug fixes.

Чит-лист функционального тестирования, памятка тестировщику

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

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

Я использую чит‑лист с тремя целями:

1. передаю его своим коллегам, чтобы маст-хэв тесты не были забыты,

2. заглядываю в него перед проверкой тестового покрытия коллег на малознакомом проекте,

3. проверяю себя в ходе вычитки техзадания и при тест‑дизайне.

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

Чит‑лист разбит на 4 категории — Данные, Операции, Функциональности, Технология. В каждой категории собраны проверки для функционального тестирования системы с соответствующего ракурса. Я для себя приоритизирую категории сверху вниз:

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

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

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

• И наконец смотрю, каким образом реализована функциональность и какие типовые проверки в связи с этим нужно провести.

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

1. Данные: для описания товаров используются строковые поля, числовые и дата. Рассматриваем проверки из групп «Строка», «Число», «Дата и время»,

2. Операции: это операция добавления, группа в чит‑листе «Операция добавления записи (Insert)»,

3. Функциональности: положим, для размещения товара нужно загрузить его фотографии, это группа «Функция загрузки файла»,

4. Технология: мы проверяем систему на уровне UI‑интерфейса и это WEB приложение, соответственно читать нужно группы «UI интерфейс» и «WEB приложение».

Данные

При наличии входных параметров, например, полей ввода,  проанализировать dataset. Выбрать набор данных, на которых проводить тесты.

• Строка

Выбрать 3 базовых значения

Наиболее популярные корректные данные с точки зрения целевой аудитории (ЦА), бизнес‑сценариев, предметной области.

Выбрать MIN и MAX длину строки

Выбрать допустимые и недопустимые символы

• Число

Исследовать число, выбрать базовое значение

Выбрать диапазон допустимых чисел

• Дата и Время

Исследовать дату/время, выбрать базовое значение

Выбрать диапазон допустимых дат

Операции

При наличии CRUD операций, выбрать перечень операций, задействованных в проверяемой функциональности. Проверить на уровне выборки, сохранения, обновления, удаления данных в БД. Проверить, что все поля сохранены, в полном объеме: строка не обрезана, разрядность числа сохранена, значение даты и времени сохранены корректно.

• Операция добавления записи (Insert)

Сохранение базовых значений

Сохранить записи, состоящие из базовых значений и значений по‑умолчанию, выбранные в ходе тест‑дизайна данных (раздел «Данные») => Сохранение успешно.

Сохранение граничных значений

Сохранить записи, состоящие из граничных допустимых значений, выбранные в ходе тест‑дизайна данных (раздел «Данные») => Сохранение успешно.

Блокировка сохранения только необязательных параметров

Блокировка сохранения дубликатов

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

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

Ввести недопустимые значения, выбранные в ходе тест‑дизайна данных (раздел «Данные»), сохранить запись => Поля, заполненные некорректно, подсвечены цветом. Сохранение заблокировано.

Автоматическое удаление конечных пробелов

Ввести пробелы в начале и конце строки, сохранить запись => Запись сохранена без конечных пробелов в начале и в конце.

Блокировка DDOS добавления

Отправить несколько запросов на добавление одной записи одновременно (эмуляция добавления во время зависания сервера) => Сохранена запись по первому пришедшему запросу, остальные отклонены.

• Операция редактирования записи (Update)

Удаление части данных из записи

Взять максимально заполненную запись, в которой заполнены все возможные поля, добавлены связанные и дочерние данные. В режиме редактирования удалить все необязательные, связанные и дочерние данные, сохранить изменения => Изменения сохранены, данные удалены в полном объеме.

Обогащение записи данными

Выбрать минимально заполненную запись, в которой заполнены только обязательные поля. В режиме редактирования добавить данные, не обязательные для заполнения, всевозможные связанные и дочерние данные, сохранить изменения => Изменения сохранены, данные добавлены в полном объеме.

Изменение данных в записи

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

Сохранение данных без изменения

Выбрать любую запись. В режиме редактирования записи ничего не менять, сохранить => Запись сохранилась, дубликатов не создалось

• Операция удаления записи (Delete)

Удаление записи

Выбрать атомарную запись, удалить ее, подтвердить удаление => После подтверждения, запись удаляется.

Блокировка каскадного удаления связанных данных

• Язык поискового запроса (Select) 

Простой поиск по фрагменту слова

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

Простой поиск по словосочетанию

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

Поиск в разных регистрах

Выполнить поиск по фрагменту слова в ВЕРХНЕМ регистре, потом сделать поиск этого же фрагмента в нижнем регистре => Количество записей в выборке при поиске в ВЕРХНЕМ и нижнем регистре совпадают.

Поиск на разных языках

Найти в базе данных слово на отличном языке, вычислить количество записей с этим словом. Выполнить поиск по выбранному слову => В выборку попали все записи с искомым словом.

Поиск слов с буквой Ё

Поиск слов со спецсимволами в составе

Найти в базе данных слово со спецсимволами в составе, (пример слова со спецсимволом «юго‑запад») вычислить количество строк с выбранным спецсимволом. Последовательно выполнить несколько вариаций поиска выбранного слова включая и не включая спецсимвол (пример поискового запроса «юго‑запад», «югозапад», «юго запад») => Количество записей в выборке при поиске слова со спецсимволом совпадают, в выборку попали все записи с искомым словом.

Расширенный поиск

• Операция ETL (обновления массива записей, Select-Insert-Update-Delete)

Миграция массива данных

Миграция добавленных, обновленных и удаленных данных в массиве

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

Миграция нетипичных данных и граничных значений

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

Обработка некорректных данных в массиве

Миграция максимально большого массива данных

Функциональности

При тестировании типовой функциональности, выбрать ее из списка и выполнить типовые проверки.

• Функция регистрации

Регистрация учетной записи

Ошибка подтверждения пароля при регистрации

Ввести различные значения в поля «Пароль» и «Подтверждение пароля» => Поля подсвечены цветом, сообщение об ошибке отражает суть ошибки. Регистрация заблокирована.

Блокировка регистрации без согласия на обработку персональных данных

• Функция сброса пароля

Сброс пароля учетной записи

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

Авторизоваться в нескольких клиентах (устройствах/ браузерах). В одном из них изменить пароль => После смены пароля происходит автоматический разлогин во всех клиентах. В каждом из них авторизация успешна только с новым паролем.

Прерывание во время сброса пароля

Вызывать сброс пароля, получить в почте ссылку на форму сброса пароля. Перейти по ссылке, закрыть форму. Повторно перейти по ссылке, изменить пароль => После прерывания операции смены пароля, пользователь может авторизоваться по старому паролю. После завершения операции пользователь может авторизоваться только по новому паролю.

Ошибка подтверждения пароля при сбросе

Сбросить пароль, перейти по ссылке в почте, на форме изменения пароля ввести разные пароли в поле «Пароля» и «Подтверждения пароля» => Выводится сообщение об ошибке, авторизация по старой паре логин — пароль успешна.

Блокировка смены пароля на тот же самый

Попытаться сменить пароль на тот же самый => Сообщение об ошибке, сохранение нового пароля заблокировано, авторизация по старой паре логин — пароль успешна.

Блокировка многократного сброса пароля по одной ссылке

Вызвать сброс пароля, получить в почте ссылку на форму смены пароля. Перейти по ссылке, на форме сменить и сохранить новый пароль. Повторно перейти по ссылке из письма => Происходит переход на форму с сообщением об ошибке, на форме есть ссылка на вызов функции сброса пароля.

Блокировка использования устаревшей ссылки на сброс пароля

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

• Функция авторизации

Стандартная авторизация

Авторизоваться => Доступ есть, в URL нет логина/пароля пользователя, в логах и куках нет пароля пользователя.

Блокировка авторизации без логина

Авторизоваться без логина => Доступ отсутствует, сообщение об ошибке отражает суть ошибки.

Блокировка авторизации без пароля

Авторизоваться без пароля => Доступ отсутствует, сообщение об ошибке отражает суть ошибки.

Блокировка авторизации с ошибочным паролем

Авторизоваться с неверным логином/ паролем => Доступ отсутствует, сообщение об ошибке отражает суть ошибки.

Блокировка перебора паролей

Блокировка авторизации под заблокированной учетной записью

Авторизоваться под заблокированной учетной записью => Доступ отсутствует, сообщение об ошибке отражает суть ошибки.

Уведомление об авторизации с другого устройства

Предварительно выяснить, есть ли функция уведомлений о несанкционированном доступе. Авторизоваться в системе с одного клиента (браузера/ устройства). Повторно авторизоваться со второго клиента (браузера/устройства) => Пользователь успешно авторизован в обоих случаях, получает уведомление (например в почту) об авторизации на втором клиенте.

Сохранение сессии при авторизации

Автоматическое продление аутентификации при достижении refresh date

Установить короткий срок refresh date и expiration date. Авторизоваться, дождаться времени наступления refresh date, выполнить действие в интерфейсе => Доступ сохранен, expiration date продлен.

• Функция принудительной авторизации (force auth)

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

Блокировка авторизации после «протухания» ссылки force auth

Дождаться протухания ссылки force auth и перейти по ней => Сообщение об ошибке, пользователю доступна форма авторизации.

• Функция разлогина

Принудительный разлогин пользователем

Авторизоваться в разных вкладках браузера, разлогиниться на одной из них => Доступ отсутствует во всех вкладках браузера.

Принудительный разлогин со всех устройств

Предварительно выяснить, есть ли функция разлогина со всех устройств во время принудительного разлогина. Авторизоваться на разных клиентах (браузерах/устройствах), разлогиниться с одного из них, обновить страницу на втором => Пользователь попадает на форму авторизации.

Разлогин при потере аутентификации на клиенте

Авторизоваться, удалить куки в браузере, обновить страницу => Доступ отсутствует, пользователь попадает на форму авторизации.

Разлогин при истечении access token

Установить короткий срок refresh date и expiration date. Авторизоваться, дождаться времени наступления expiration date, выполнить действие в интерфейсе => Доступ заблокирован, пользователь попадает на форму авторизации.

• Функция платежа и покупки

Успешный платеж

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

Блокировка платежа из-за нехватки средств

Сделать попытку платежа на сумму превышающую баланс на банковской карты => Транзакция заблокирована, запрос вернул сообщение об ошибке, текст ошибки отражает ее суть, баланс пользователя в системе НЕ увеличен, покупка НЕ проведена. Сохранилась история о попытке пополнения баланса.

Блокировка платежа из-за недоступности платежной системы

Предварительно эмулировать недоступность платежной системы, сделать попытку платежа => Транзакция заблокирована, запрос вернул сообщение об ошибке, текст ошибки отражает ее суть, баланс пользователя в системе НЕ увеличен, покупка НЕ проведена. Сохранилась история о попытке пополнения баланса.

Отложенная отмена платежа

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

• Функция фильтров, сортировок, пагинации

Выборка записей по фильтру

Выборка записей по комбинации фильтров

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

Сортировка записей

Работа с отфильтрованными и отсортированными данными

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

• Функция поисковых запросов

Автоматическое удаление конечных пробелов

Ввести в поисковую строку слово с пробелами в начале и в конце слова. Выполнить поиск => В результатах выборка с искомыми словами без учета введенных пробелов.

Сохранение параметров поиска при переключении страниц

Выполнить поиск, который даст поисковую выборку на несколько страниц. Выполнить переключения между страницами, перейти к последней странице, потом к первой => Результаты поиска сохраняются.

Поиск на разных уровнях, в разных областях

Выяснить области поиска, он выполняется в рамках страницы или всего сайта, среди статей, документов, картинок, сообщений, т.д., по заголовкам и/или по содержанию. Последовательно выполнить поиск несколько раз таким образом, чтобы в выборку попали записи из каждого уровня и области => Результаты выборки соответствуют поисковому запросу.

Включение и отключение поиска

Включение поисковой подсказки

Ошибка поиска: слишком большая выборка

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

Ошибка поиска: ничего не найдено

Выполнить поиск фразы, которой нет в базе данных => Сообщение об ошибке, текст ошибки соответствует ее сути.

• Функция ETL (извлечение — преобразование — загрузка данных)

Загрузка по расписанию или событию

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

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

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

Прерывание и восстановление загрузки

Инициировать старт загрузки, прервать процесс в середине, снова инициировать старт => В системе‑инициаторе загрузки сохранились логи о количестве загруженных записей и всех записях, которые должны были загрузиться при первой операции. При повторной загрузке данные загружены в полном объеме, нет дубликатов и недостающих записей, в логах системы сохранен статус об успешной загрузке.

Влияние загрузки на работу пользователей

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

• Функция загрузки файла

Загрузка файла

Одновременная загрузка нескольких файлов

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

Долгая загрузка тяжелого файла

Блокировка загрузки файла с недопустимым расширением

Выполнить загрузку нескольких файлов недопустимого расширения (пример, txt, xls, xlsx, exe, jpeg, xml, html, zip) => Сообщение об ошибке, текст ошибки соответствует ее сути, загрузка заблокирована.

Блокировка загрузки файла недопустимого веса

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

Блокировка загрузки битого файла

Выполнить загрузку битого файла => Сообщение об ошибке, текст ошибки соответствует ее сути, загрузка заблокирована.

Блокировка загрузки файла из недопустимого места

Ввести некорректный путь до файла (некорректная ссылка или некорректный адрес файла на ПК) => Сообщение об ошибке, текст ошибки соответствует ее сути.

Блокировка загрузки файла с недопустимым названием

Выяснить, есть ли требования к наименованию файла (длине наименования, составу символов, поддерживаемым языкам). Выполнить загрузку файла с недопустимой длиной названия, недопустимыми символами в названии => Сообщение об ошибке, текст ошибки соответствует ее сути, загрузка заблокирована.

• Функция импорта данных из файла EXCEL

Загрузка шаблона файла

Блокировка загрузки файла, не соответствующего шаблону

Загрузка файла, сохраненного в разных редакторах

Последовательно загрузить EXCEL, сохраненный в разных редакторах (пример, MS Office, Google Docs, Libre Office) => Файл загружен в систему, кодировка загруженных данных корректная.

• Функция импорта данных из файла CSV

Обработка разделителей при загрузке

Загрузка экранированных спецсимволов

Выяснить, есть ли в CSV экранирование спецсимволов и каких (пример, «»», «»», «n»). Выполнить загрузку CSV файла со всеми спецсимволами, которые должны экранироваться => Файл загружен в полном объеме, спецсимволы загружены в систему корректно: без косой черты, распознаны и сохранены как текст.

• Функция блокировки пользователей

Блокировка пользователя

Автоматическая разблокировка пользователя

Дождаться срока окончания блокировки пользователя, авторизоваться под ним => Авторизация в систему успешна.

Принудительная разблокировка пользователя

Принудительно разблокировать пользователя, авторизоваться под ним => Авторизация в систему успешна.

Технология

Выбрать тип проверяемого ПО и базовые проверки для него.

• UI интерфейс

Проверить удобство добавления и редактирования текста в полях ввода

Проверить подсказки к полям ввода

Рассмотреть все поля ввода на форме => Поля снабжены подсказками (tooltip, hint, placeholder), подсказки разворачиваются полностью, в тексте нет опечаток.

Проверить удобство работы с многошаговой формой

Проверить управление с клавиатуры

Проверить согласованность состояния и внешнего вида элементов

Проверить единообразие

• WEB приложение

Проверить на соответствие 152ФЗ

Проверить брендирование страниц

Проверить в разных масштабах страницы

Увеличить масштаб страницы до 150% (Ctrl+), уменьшить масштаб страницы до 70% (Ctrl‑) => Текст масштабируется и ни на что не наезжает, фотографии и картинки не разъезжаются, горизонтальный скролл не появляется.

Проверить на ошибки фронта

Проверить кроссбраузерность

Проверить переходы по прямым ссылкам

Проверить загрузку страниц на медленном соединении

Сэмулировать медленное соединение в браузере (на вкладке Network в DevTools), пройтись по страницам, выполнить самые «медленные» операции => Картинки начинают загружаться сразу, есть кэширование, по возможности есть предварительная загрузка контента. При выполнении «долгих» операций выводится preloader.

Проверить работу с пользовательскими настройками браузера

Включить в браузере настройку «Блокировщик всплывающих окон», перезагрузить страницу, вызвать всплывающее окно => Критичная информация из всплывающего окна выводится альтернативным способом — открывается в новой вкладке (пример, предпросмотр документа), выводится на этой же странице.

• Мобильное приложение

Проверить установку, обновление, удаление приложения

Проверить разрешения приложения

Проверить на разном соединении, потерю и восстановление связи

Проверить обработку типовых жестов

Проверить реакцию на команды со смартфона

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

Проверить реакцию на входящие сигналы

Запустить приложение, принять входящий звонок, получить и прочитать смс, получить и прочитать push‑уведомление, получить и выключить звонок будильника => После совершения операции приложение также открыто и работает в штатном режиме.

Проверить работу с пользовательскими настройками телефона

Проверить потребление ресурсов телефона

• Почтовые письма

Проверить в разных почтовых клиентах

• API-интерфейс

Проверить Request

Выполнить API запрос => Данные передаются по безопасному протоколу https, сертификат исправен. Обработка запроса системой получателем выполняется только после авторизации запроса в системе получателе. Генерируется токен.

Проверить Response

Разобрать ответ => В позитивных тестах, код 200 не гарантирует корректной работы. В негативных тестах, код ошибки не всегда соответствует фактической ошибке. В теле ответа должно выводиться пояснение, что не так.

Проверить URL кодирование/декодирование

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

1. Функциональное тестирование (тестирование с управлением по данным) – критерии формирования тестовых наборов: предположение об ошибке.

Предположение
об ошибке. Часто
программист с большим опытом находит
ошибки, «не применяя никаких методов».
На самом деле он подсознательно использует
метод «предположение об ошибке».

Процедура метода
предположения об ошибке в значительной
степени основана на интуиции.

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

1. Тестирование модулей: восходящие, нисходящие, комбинированное, модули-заглушки, тестирование специалистами-тесторами, документирование тестирования, регрессивное тестирование.

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

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

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

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

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

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

вся система.

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

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

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

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

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

В поле тип проблемы
указывают один из вариантов:

1 — ошибка кодирования
— программа ведет себя не так, как следует
из общепринятых представлений, например,
2 + 2 = 5 — на что разработчик может выдать
резолюцию «соответствует проекту»;

2 —
ошибка
проектирования — программа ведет себя
в соответствии с проектом, но специалист
по тестированию не согласен с данным
решением в проекте — на что разработчик
может отреагировать, наложив резолюцию
«не согласен с предложением»;

3 — предложение
-предложение по улучшению проекта;

4 — расхождение с
документацией — обнаружено, что программа
ведет себя не так, как указано в
документации;

5 — взаимодействие
с аппаратурой — обнаружены проблемы при
использовании определенного вида
аппаратуры;

6 — вопрос — программа
делает что-то не совсем понятное.

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

«Система не
запоминает настройки принтера, выполняемые
в окне настройки». Если программист
исправляет ошибку, то тестирование
повторяют сначала, так как при исправлении
ошибки программист может внести в
программу новые ошибки. Такое тестирование
называют «регрессионным».

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

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