Особенности тестирования в Agile

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

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

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

● Опытный QA также хорошо осведомлен об объеме выпуска и соответственно устанавливает границы своего тестирования.

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

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

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

Какие стратегии использует QA для проведения Agile-тестирования?

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

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

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

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

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

● Тестирование эффективности потока помогает определить, могут ли пользователи беспрепятственно перемещаться по продукту. Это помогает определить, сбивает ли вас с толку какая-либо часть потока, и помогает определить, нужно ли вам добавлять или удалять какие-либо шаги.

● Проверка бизнес-правил и определений данных - важная часть тестирования.

● Проведение исследовательского тестирования позволяет тестировщикам идти по неопределенному пути и находить скрытые риски и дефекты в приложении.

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

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

● Наличие приложений для обмена сообщениями в реальном времени, таких как Slack и Zoom, позволяет всем в команде быть на связи и быстро отвечать на важные вопросы.

Источники:

● Agile 101

● Гибкая методология разработки

● Руководство тестировщика по Agile тестированию

Доп. материал:

● ISTQB Agile Tester Extension Exam Theory Study Material Part 1

● ISTQB Agile Tester Extension Exam Crash Course Part 1

● Agile Glossary

● Agile Software Development, lessons learned by Jerome Kehrli

● Организация процесса тестирования в Agile команде с помощью квадрантов тестирования. - презентация

● 10 примеров эффективного общения для тестировщиков

● Как выживать тестировщику в Agile среде

● Стратегия тестирования краткосрочного проекта

Scrum

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

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

Ценности:

● Преданность (Commitment): Члены команды лично привержены достижению целей команды;

● Смелость (Courage): Члены команды поступают правильно и работают над сложными проблемами;

● Сфокусированность (Focus): Сконцентрируйтесь на работе, намеченной для спринта, и целях команды;

● Открытость (Openness): Члены команды и заинтересованные стороны открыто рассказывают обо всей работе и проблемах, с которыми сталкивается команда;

● Уважение (Respect): Члены команды уважают друг друга за способности и независимость.

Принципы:

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

● Инспекция (Inspection): Частые контрольные точки встроены в структуру, чтобы дать команде возможность поразмышлять о том, как работает процесс. Эти контрольные точки включают в себя Daily Scrum meeting и the Sprint Review Meeting;

● Адаптация (Adaptation): Команда постоянно изучает, как идут дела, и проверяет те пункты, которые кажутся бессмысленными.

События:

● Спринт (Sprint): это временной интервал в 2-4 недели, в течение которого команда создает потенциально готовый к поставке инкремент продукта;

● Планирование спринта (Sprint Planning): Команда начинает спринт с обсуждения, чтобы определить, над какими элементами из бэклога продукта (product backlog) они будут работать во время спринта. Конечным результатом планирования спринта является бэклог спринта (Sprint Backlog). Планирование спринта обычно состоит из двух частей. В первой части владелец продукта и остальная часть команды согласовывают, какие элементы бэклога продукта будут включены в спринт. Во второй части планирования спринта команда определяет, как они будут успешно доставлять идентифицированные элементы Product Backlog как часть потенциально возможного инкремента продукта. Команда может определить конкретные задачи, необходимые для этого, если это одна из их практик. Элементы Product Backlog, определенные для доставки, и задачи, если применимо, составляют бэклог спринта. После того, как команда и владелец продукта установят объем спринта, как описано в элементах Product Backlog, никакие дополнительные элементы не могут быть добавлены в журнал Sprint Backlog. Это защищает команду от изменений в рамках этого спринта;

● Ежедневная встреча (Daily Scrum/Meeting): это короткое (обычно не более 15 минут) обсуждение, во время которого команда координирует свои действия на следующий день. Дейли не предназначен для обсуждения статуса или обсуждения проблем;

● Обзор спринта (Sprint Review): в конце спринта вся команда (включая владельца продукта) рассматривает результаты спринта с заинтересованными сторонами продукта. Цель этого обсуждения - обсудить, продемонстрировать и потенциально дать заинтересованным сторонам возможность использовать инкремент для получения обратной связи. Обзор спринта не предназначен для предоставления отчета о состоянии (status report). Отзывы об обзоре спринта помещаются в Product Backlog для дальнейшего рассмотрения;

● Ретроспектива спринта (Sprint Retrospective): в конце спринта после обзора спринта (sprint review) команда (включая владельца продукта) должна подумать о том, как дела шли во время предыдущего спринта, и определить корректировки, которые они могут внести в будущем. Результатом этой ретроспективы является как минимум одно действие, включенное в бэклог следующего спринта;

● Упорядочение бэклога (Grooming);

Артефакты:

● Бэклог продукта (Product Backlog): это упорядоченный список всех возможных изменений, которые могут быть внесены в продукт. Пункты в бэклоге продукта являются вариантами, а не обязательствами, и то, что они существуют в бэклоге продукта, не гарантирует, что они будут доставлены. Владелец продукта постоянно ведет бэклог продукта, включая его содержание, доступность и порядок;

● Бэклог спринта (Sprint Backlog): это набор элементов из бэклога продукта, выбранных для доставки в спринте. После того, как команда определяет задачи, эти задачи необходимо выполнить для достижения цели спринта (Sprint Goal);

● Инкремент (Increment): это набор элементов из бэклога продукта, которые соответствуют Definition of Done к концу спринта. Владелец продукта может решить выпустить дополнение или развить его в будущих Спринтах;

● Критерии Готовности (Definition of Done): это общее соглашение команды о критериях, которым должен соответствовать элемент бэклога продукта, прежде чем он будет считаться выполненным$

● Пользовательские истории (User Story);

● Цель спринта (Sprint Goal);

● Диаграмма сгорания задач (Burndown chart).

Роли:

● Владелец продукта (Product Owner): роль, ответственная перед командой за управлением бэклогом продукта для достижения результатов, к которым стремится команда. Роль product owner-а существует в Scrum для решения проблем, когда команда разработки имеет множественные противоречивые направления движения или отсутствие направления вообще в отношении того, что создавать;

● Скрам Мастер (Scrum Master): роль, ответственная перед командой за то, чтобы команда придерживалась гибких ценностей и принципов и следовала процессам и практикам, которые команда согласилась использовать. Изначально это имя предназначалось для обозначения кого-то, кто является экспертом в Scrum и, следовательно, может обучать других. Роль обычно не имеет никаких фактических полномочий. Люди, выполняющие эту роль, должны руководить с позиции влияния, часто занимая позицию лидера-слуги (servant-leadership);

● Команда разработки (Development Team): состоит из людей, которые создают инкремент продукта внутри спринта. Основная ответственность команды разработки - обеспечить инкремент, который приносит пользу каждому спринту. Как распределить работу, это остается на усмотрение команды в зависимости от условий на тот момент.

Жизненный цикл Scrum:

● Создайте бэклог продукта;

● Владелец продукта и команда разработчиков проводят планирование спринта. Определите объем спринта в первой части планирования спринта и план реализации этого объема во второй половине планирования спринта;

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

● Команда разработчиков ежедневно координирует свою работу в рамках Daily Scrum;

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

● Команда повторяет шаги 2–5 до тех пор, пока не будет достигнут желаемый результат.

Стори поинты (Story points)

Чтобы оценить объем работы над Элементом Бэклога Продукта, Скрам-команды обычно используют Стори Поинты (1, 2). Это условная величина, позволяющая давать Элементам Бэклога относительные веса. Чаще всего для оценки в Стори Поинтах используются числа Фибоначчи (1, 2, 3, 5, 8, 13, …), что позволяет провести оценку достаточно быстро.

Источники:

● What is Scrum?

Доп. материал:

● Scrum Guide

● Scrum Glossary

● Мини-справочник и руководство по Scrum

● Scrum-мем на злобу дня

● Когда Scrum не работает. Пять основных проблем его применения

● Лекция 7: Этапы и мероприятия Scrum

● Как провести ретроспективу

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

Особенности тестирования в Scrum:

● Тестирование в рамках SCRUM. Тернии, грабли и успехи

● Регрессионное тестирование на Scrum-проектах: руководство по проведению

● QA-процесс в Miro: отказ от водопада и ручного тестирования, передача ответственности за качество всей команде

● Тесты должна писать разработка (?)

● The Role of QA in Sprint Planning

● Код-ревью для тестировщиков

Подходы к разработке/тестированию (... - driven development/testing)

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

● TDD - Test Driven Development: разработка на основе тестов основывается на повторении коротких циклов разработки: изначально пишется тест, покрывающий желаемое изменение, затем пишется программный код, который реализует желаемое поведение системы и позволит пройти написанный тест. Затем проводится рефакторинг написанного кода с постоянной проверкой прохождения тестов. Есть два уровня TDD:

○ Acceptance TDD (ATDD): вы пишете один приемочный тест. Этот тест удовлетворяет требованиям спецификации или удовлетворяет поведению системы. После этого пишете достаточно производственного / функционального кода, чтобы выполнить этот приемочный тест. Приемочный тест фокусируется на общем поведении системы. ATDD также известен как BDD - Behavior Driven Development;

○ Developer TDD: вы пишете один тест разработчика, то есть модульный тест, а затем просто достаточно производственного кода для выполнения этого теста. Модульное тестирование фокусируется на каждой небольшой функциональности системы. Это называется просто TDD. Основная цель ATDD и TDD - определить подробные, выполнимые требования для вашего решения точно в срок (JIT). JIT означает принятие во внимание только тех требований, которые необходимы в системе, что повышает эффективность.

● BDD - Behaviour Driven Development: это разработка, основанная на описании поведения. Определенный человек(или люди) пишет описания вида "я как пользователь хочу когда нажали кнопку пуск тогда показывалось меню как на картинке" (там есть специально выделенные ключевые слова). Программисты давно написали специальные тулы, которые подобные описания переводят в тесты (иногда совсем прозрачно для программиста). А дальше классическая разработка с тестами (TDD);

● TDD - Type Driven Development: при разработке на основе типов ваши типы данных и сигнатуры типов являются спецификацией программы. Типы также служат формой документации, которая гарантированно обновляется. Типы представляют из себя небольшие контрольные точки, благодаря которым, мы получаем множество мини-тестов по всему нашему приложению;

● DDD - Domain Driven Design: Предметно-ориентированное проектирование не является какой-либо конкретной технологией или методологией. DDD — это набор правил, которые позволяют принимать правильные проектные решения. Это набор принципов и схем, направленных на создание оптимальных систем объектов. Процесс разработки сводится к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит бизнес-логика, устанавливающая связь между реальными условиями области применения продукта и кодом;

● FDD - Features Driven Development: представляет собой попытку объединить наиболее признанные в индустрии разработки программного обеспечения методики, принимающие за основу важную для заказчика функциональность (свойства) разрабатываемого программного обеспечения. Основной целью данной методологии является разработка реального, работающего программного обеспечения систематически, в установленные сроки;

● MDD - Model Driven Development: разработка, управляемая моделями - это стиль разработки программного обеспечения, когда модели становятся основными артефактами разработки, из которых генерируется код и другие артефакты;

● PDD - Panic Driven Development: это своеобразный антипаттерн разработки, который, к сожалению, мы все время от времени практикуем. По сути это то, что получается, когда процессы плохо налажены и команда импровизирует в условиях горящих сроков (новые задачи приоритетнее старых, код решает конкретные срочные задачи, но копится технический долг, тестирование в конце и т.д.);

● ADD - API Driven Development: разработка на основе API - это практика сначала проектирования и создания API, а затем создания на их основе остальной части приложения;

● BDT - Behavior Driven Testing: втестировании на основе поведения ваши тесты основаны на user stories, которые описывают некоторые конкретные ожидаемые действия приложения. Вместо проверки деталей реализации вы фактически проверяете то, что важно больше всего: правильно ли приложение выполняет user stories. Еще одним преимуществом является понятность тестов для менеджеров, аналитиков и т.п.;

● MDT - Model Driven Testing: Тестирование на основе моделей - это метод тестирования черного ящика, при котором поведение тестируемого программного обеспечения во время выполнения проверяется на основе прогнозов, сделанных моделями. Модель - это описание поведения системы. Поведение может быть описано в виде наглядной схемы, Data Flow, Control Flow, Dependency Graphs, Decision Tables, State transition machines или mind map. Простой аналогией модели в тестировании является электрическая схема при разработке электроприбора. Этот подход к тестированию требуется, когда высока цена ошибки в большом продукте и нужно как можно раньше попытаться ее предотвратить;

● DDT - Data Driven Testing (table-driven testing or parameterized testing): в тестировании на основе данных тестовые данные хранятся в виде таблицы. Оно позволяет одним скриптом выполнять тесты для всех тестовых данных из таблицы и ожидать результатов теста в той же таблице;

● VDT - Value Driven Testing: тестирование на основе ценности - это подход, в основе которого лежит анализ ценности и экономической целесообразности тестирования;

Источники:

● TDDx2, BDD, DDD, FDD, MDD и PDD, или все, что вы хотите узнать о Driven Development

● The Basics of API-Driven Development

● Behavior-Driven Testing для iOS используя Quick и Nimble

● Тестирование на основе моделей

● What is Data Driven Testing? Learn to create Framework

● Что нужно знать о Value Driven Testing. Анализируем ценность и экономическую целесообразность тестирования

Доп. материал:

● Leadership in test: modelling and coverage

 

 

 

(Не обновлялось) Тестирование в разных сферах/областях (testing different domains)

Веб-тестирование

https://www.softwaretestingmaterial.com/web-application-testing-tutorial/

ВЕБ-ТЕСТИРОВАНИЕ, или тестирование веб-сайта, проверяет ваше веб-приложение или веб-сайт на наличие потенциальных ошибок, прежде чем оно будет опубликовано и доступно для широкой публики.

 

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

 

● Проверка, что все ссылки на ваших веб-страницах работают правильно и что нет битых ссылок.

o Исходящие ссылки

o Внутренние ссылки

o Якорные ссылки (слово или словосочетание, на котором поставлена ссылка)

o MailTo Ссылки

● Текстовые формы работают как положено.

o Проверка скриптов в форме работает как положено. Например, если пользователь не заполняет обязательное поле в форме, отображается сообщение об ошибке.

o Проверьте значения по умолчанию

o После отправки данные в формах отправляются в базу данных или связываются с рабочим адресом электронной почты.

o Формы оптимально отформатированы для лучшей читаемости

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

o Тестовые файлы cookie (сеансы) удаляются либо после очистки кэша, либо по истечении срока их действия. Удалите файлы cookie (сеансы) и проверьте, запрашиваются ли учетные данные при следующем посещении сайта.

o Протестируйте HTML и CSS, чтобы поисковые системы могли легко сканировать ваш сайт. Это будет включать

▪ Проверка на синтаксические ошибки

▪ Удобочитаемые цветовые схемы

▪ Стандартное соответствие. Убедитесь, что соблюдаются такие стандарты, как W3C, OASIS, IETF, ISO, ECMA или WS-I.

● Тест бизнес-воркфлоу - это будет включать в себя

o Тестирование вашего end-to-end workflow / бизнес-сценариев

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

● Примеры функциональных тест-кейсов:

o Все обязательные поля должны быть валидированы.

o Звездочка должна отображаться для всех обязательных полей.

o Не должно отображаться сообщение об ошибке для дополнительных полей.

o Проверьте, что високосные годы проверены правильно и не вызывают ошибок.

o Числовые поля не должны принимать буквы и должно отображаться соответствующее сообщение об ошибке.

o Проверьте наличие отрицательных чисел, если это разрешено для числовых полей.

o Тестовое деление на ноль должно быть правильно обработано.

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

o Тест всплывающего сообщения («Это поле ограничено 500 символами») должно отображаться, если данные достигают максимального размера поля.

o Проверьте, должно ли отображаться подтверждающее сообщение для операций обновления и удаления.

o Величины должны быть в подходящем формате.

o Проверьте все поля ввода на ввод специальных символов.

o Проверьте функциональность тайм-аута.

o Проверьте функциональность сортировок.

o Проверьте, что FAQ и Политика конфиденциальности четко определены и доступны для пользователей.

o Проверьте, все ли работает и не перенаправляется ли пользователь на страницу ошибки.

o Все загруженные документы открываются правильно.

o Пользователь должен иметь возможность скачать загруженные файлы.

o Проверьте функциональность электронной почты системы. Тестируемый скрипт корректно работает в разных браузерах (IE, Firefox, Chrome, Safari и Opera).

o Проверьте, что произойдет, если пользователь удалит файлы cookie, находясь на сайте.

o Проверьте, что произойдет, если пользователь удалит файлы cookie после посещения сайта.

 

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

● Навигация:

o Меню, кнопки или ссылки на разные страницы вашего сайта должны быть легко видны и согласованы на всех веб-страницах.

● Проверьте содержимое:

o Содержание должно быть разборчивым, без орфографических или грамматических ошибок.

o Изображения, если они присутствуют, должны содержать «альтернативный» текст

● Примеры тестов юзабилити:

o Содержание веб-страницы должно быть правильным без каких-либо орфографических или грамматических ошибок

o Все шрифты должны быть в соответствии с требованиями.

o Весь текст должен быть правильно выровнен.

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

o Текст подсказки должен быть там для каждого поля.

o Все поля должны быть правильно выровнены.

o Должно быть достаточно места между метками полей, столбцами, строками и сообщениями об ошибках.

o Все кнопки должны быть в стандартном формате и размере.

o Домашняя ссылка должна быть на каждой странице.

o Отключенные поля должны быть недоступны.

o Проверьте наличие битых ссылок и изображений.

o Сообщение о подтверждении должно отображаться для любого вида операции обновления и удаления. Проверить сайт на разных разрешениях (640 х 480, 600х800 и т. д.)

o Убедитесь, что вкладка должна работать правильно.

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

o Если при отправке появляется сообщение об ошибке, информация, заполненная пользователем, должна быть там.

o Название должно отображаться на каждой веб-странице

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

o Проверьте, не усекаются ли выпадающие данные из-за размера поля.

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

 

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

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

● Веб-сервер: тестовый веб-сервер обрабатывает все запросы приложений без какого-либо отказа в обслуживании.

● Сервер базы данных: убедитесь, что запросы, отправленные в базу данных, дают ожидаемые результаты. Проверьте реакцию системы, когда невозможно установить соединение между тремя уровнями (Приложение, Интернет и База данных) и соответствующее сообщение отображается конечному пользователю.

 

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

● Проверьте, отображаются ли какие-либо ошибки при выполнении запросов

● Целостность данных поддерживается при создании, обновлении или удалении данных в базе данных.

● Проверьте время ответа на запросы.

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

 

● Примеры тест-кейсов для тестирования базы данных:

o Проверьте имя базы данных: имя базы данных должно соответствовать спецификациям.

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

o Проверьте, допускает ли столбец null значение или нет.

o Проверьте первичный и внешний ключ каждой таблицы.

o Проверьте хранимую процедуру:

o Проверьте, установлена ​​ли сохраненная процедура или нет.

o Проверьте имя хранимой процедуры

o Проверьте имена параметров, типы и количество параметров.

o Проверьте требуемые параметры.

o Проверьте хранимую процедуру, удалив некоторые параметры

o Проверьте, когда выход равен нулю, это должно повлиять на нулевые записи.

o Проверьте хранимую процедуру, написав простые запросы SQL.

o Проверьте, возвращает ли хранимая процедура значения

o Проверьте хранимую процедуру с образцами входных данных.

o Проверьте поведение каждого флага в таблице.

o Убедитесь, что данные правильно сохраняются в базе данных после каждой отправки страницы.

o Проверьте данные, если выполняются операции DML (Обновить, удалить и вставить).

o Проверьте длину каждого поля: длина поля на Frontend и backend должна быть одинаковой.

o Проверьте имена баз данных QA, UAT и production. Имена должны быть уникальными.

o Проверьте зашифрованные данные в базе данных.

o Проверьте размер базы данных.

o Также проверьте время ответа каждого выполненного запроса.

o Проверьте данные, отображаемые на Frontend, и убедитесь, что они совпадают с backend.

o Проверьте достоверность данных, вставив неверные данные в базу данных.

o Проверьте триггеры.

 

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

● Вам нужно проверить, правильно ли отображается ваше веб-приложение в браузерах, работает ли JavaScript, AJAX и аутентификация нормально. Вы также можете проверить совместимость мобильного браузера. Рендеринг веб-элементов, таких как кнопки, текстовые поля и т. д., изменяется с изменением в операционной системе. Убедитесь, что ваш сайт работает нормально для различных комбинаций операционных систем, таких как Windows, Linux, Mac и браузеров, таких как Firefox, Internet Explorer, Safari и т. д.

● Примеры тестов на совместимость:

o Протестируйте сайт в разных браузерах (IE, Firefox, Chrome, Safari и Opera) и убедитесь, что сайт отображается правильно.

o Используемая версия HTML совместима с соответствующими версиями браузера.

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

o Протестируйте шрифты, которые можно использовать в разных браузерах.

o Протестируйте код Javascript в разных браузерах.

o Проверьте анимированные GIF-файлы в разных браузерах.

 

6. Тестирование производительности: Это нужно, чтобы обеспечить работу вашего сайта при любых нагрузках. Деятельность по тестированию ПО будет включать, но не ограничиваться:

● Время отклика приложения сайта на разных скоростях соединения

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

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

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

 

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

● Проверка несанкционированного доступа к защищенным страницам

● Запрещенные файлы не должны быть загружаемыми без соответствующего доступа

● Сессии автоматически прекращаются после длительного отсутствия активности пользователя

● При использовании SSL-сертификатов веб-сайт должен перенаправить на зашифрованные SSL-страницы.

 

● Примеры тестовых сценариев для тестирования безопасности:

o Убедитесь, что веб-страница, содержащая важные данные, такие как пароль, номера кредитных карт, секретные ответы на секретный вопрос и т. д., Должна быть отправлена ​​через HTTPS (SSL).

o Убедитесь, что важная информация, такая как пароль, номера кредитных карт и т. д., Должна отображаться в зашифрованном виде.

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

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

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

o Проверьте доступ к защищенным и незащищенным веб-страницам напрямую без входа в систему.

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

o Убедитесь, что куки не должны хранить пароли.

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

o Проверьте атаки SQL-инъекций.

o Проверьте роли пользователей и их права. Например, запрашивающая сторона не должна иметь доступа к странице администратора.

o Убедитесь, что важные операции записаны в файлы журналов, и эта информация должна быть отслеживаемой.

o Убедитесь, что значения сеанса находятся в зашифрованном формате в адресной строке.

o Убедитесь, что информация о файлах cookie хранится в зашифрованном формате.

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

 

8. Тестирование толпы (Crowd Testing): Вы берете большое количество людей (толпу) для выполнения тестов, которые в противном случае были бы выполнены выбранной группой людей в компании. Краудсорсинговое тестирование представляет собой интересную и перспективную концепцию и помогает выявить многие незамеченные дефекты. Оно включает в себя практически все типы тестирования, применимые к вашему веб-приложению.

 

Доп. материалы:

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

Тестирование банковского ПО

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

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

● Оно должно поддерживать тысячи одновременных пользовательских сессий

● Банковское приложение должно интегрироваться с другими многочисленными приложениями, такими как торговые счета, утилита оплаты счетов, кредитные карты и т. д.

● Должно обрабатывать быстрые и безопасные транзакци