Руководство программных проверок

Тестирование программного обеспечения – Обзор

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

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

Кто проводит тестирование?

Это зависит от процесса и связанных заинтересованных сторон проекта (ов). В ИТ-отрасли у крупных компаний есть команда, отвечающая за оценку разработанного программного обеспечения в контексте заданных требований. Более того, разработчики также проводят тестирование, которое называется Unit Testing . В большинстве случаев следующие специалисты участвуют в тестировании системы в рамках своих соответствующих возможностей –

• Тестер программного обеспечения
• Разработчик программного обеспечения
• Руководитель проекта / менеджер
• Конечный пользователь

Различные компании имеют разные обозначения для людей, которые тестируют программное обеспечение на основе своего опыта и знаний, таких как Software Tester, Software Quality Assurance Engineer, QA Analyst и т. Д.

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

Когда начинать тестирование?

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

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

Тестирование проводится в разных формах на каждом этапе SDLC –

• На этапе сбора требований анализ и проверка требований также рассматриваются как тестирование.

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

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

На этапе сбора требований анализ и проверка требований также рассматриваются как тестирование.

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

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

Когда прекратить тестирование?

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

• Сроки тестирования

• Завершение выполнения тестового примера

• Завершение функционала и покрытие кода до определенной точки

• Уровень ошибок падает ниже определенного уровня, и высокоприоритетных ошибок не обнаружено

• Управленческое решение

Сроки тестирования

Завершение выполнения тестового примера

Завершение функционала и покрытие кода до определенной точки

Уровень ошибок падает ниже определенного уровня, и высокоприоритетных ошибок не обнаружено

Управленческое решение

Проверка и валидация

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

Sr.No.	верификация	Проверка
1	Верификация решает проблему: «Вы правильно ее строите?»	Валидация решает проблему: «Вы строите правильную вещь?»
2	Гарантирует, что система программного обеспечения соответствует всем функциональным возможностям.	Гарантирует, что функциональные возможности соответствуют предполагаемому поведению.
3	Проверка выполняется в первую очередь и включает проверку документации, кода и т. Д.	Проверка происходит после проверки и в основном включает проверку всего продукта.
4	Сделано разработчиками.	Сделано тестерами.
5	Он имеет статическую активность, так как включает в себя сбор отзывов, пошаговые руководства и проверки для проверки программного обеспечения.	Он имеет динамическую деятельность, так как включает в себя выполнение программного обеспечения в соответствии с требованиями.
6	Это объективный процесс, и для проверки программного обеспечения не требуется никаких субъективных решений.	Это субъективный процесс и включает субъективные решения о том, насколько хорошо работает программное обеспечение.

Тестирование программного обеспечения – мифы

Ниже приведены некоторые из самых распространенных мифов о тестировании программного обеспечения.

Миф 1: Тестирование слишком дорого

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

Миф 2: Тестирование отнимает много времени

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

Миф 3: тестируются только полностью разработанные продукты

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

Миф 4: полное тестирование возможно

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

Миф 5: протестированное программное обеспечение не содержит ошибок

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

Миф 6: пропущенные дефекты из-за тестеров

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

Миф 7: тестеры несут ответственность за качество продукции

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

Миф 8: Автоматизация испытаний должна использоваться везде, где это возможно, чтобы сократить время

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

Миф 9. Любой может протестировать приложение

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

Миф 10. Единственная задача тестера – найти ошибки

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

Тестирование программного обеспечения – QA, QC & Testing

Тестирование, обеспечение качества и контроль качества

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

Гарантия качества	Контроль качества	тестирование
QA включает в себя действия, которые обеспечивают реализацию процессов, процедур и стандартов в контексте проверки разработанного программного обеспечения и предполагаемых требований.	Он включает в себя действия, которые обеспечивают проверку разработанного программного обеспечения в отношении задокументированных (или не в некоторых случаях) требований.	Он включает в себя действия, которые обеспечивают выявление ошибок / ошибок / дефектов в программном обеспечении.
Ориентирован на процессы и процедуры, а не на проведение реальных испытаний в системе.	Ориентирован на фактическое тестирование, выполняя программное обеспечение с целью выявления ошибок / дефектов посредством реализации процедур и процессов.	Ориентирован на фактическое тестирование.
Процессно-ориентированные мероприятия.	Товарно-ориентированная деятельность.	Товарно-ориентированная деятельность.
Профилактические мероприятия.	Это корректирующий процесс.	Это профилактический процесс.
Это подмножество жизненного цикла тестирования программного обеспечения (STLC).	КК можно рассматривать как подмножество обеспечения качества.	Тестирование является подмножеством контроля качества.

Аудит и Инспекция

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

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

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

Тестирование и отладка

Тестирование – включает в себя выявление ошибок / ошибок / дефектов в программном обеспечении без их исправления. Обычно в выявлении ошибок участвуют профессионалы с опытом обеспечения качества. Тестирование проводится на этапе тестирования.

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

Тестирование программного обеспечения – Стандарты ИСО

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

ISO / IEC 9126

Этот стандарт касается следующих аспектов для определения качества программного приложения –

• Качественная модель
• Внешние показатели
• Внутренние показатели
• Метрики качества в использовании

Этот стандарт представляет некоторый набор атрибутов качества для любого программного обеспечения, такого как –

• функциональность
• надежность
• Юзабилити
• КПД
• Ремонтопригодность
• портативность

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

ИСО / МЭК 9241-11

Часть 11 этого стандарта касается того, в какой степени продукт может использоваться указанными пользователями для достижения указанных целей с помощью Эффективности, Эффективности и Удовлетворенности в указанном контексте использования.

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

ИСО / МЭК 25000: 2005

ИСО / МЭК 25000: 2005 широко известен как стандарт, в котором приведены рекомендации по требованиям и оценке качества программного обеспечения (SQuaRE). Этот стандарт помогает в организации и совершенствовании процесса, связанного с требованиями к качеству программного обеспечения и их оценками. В действительности ISO-25000 заменяет два старых стандарта ISO, то есть ISO-9126 и ISO-14598.

SQuaRE состоит из следующих частей:

• ISO 2500n – Отдел управления качеством
• ISO 2501n – Отдел качественных моделей
• ISO 2502n – Отдел измерения качества
• ISO 2503n – Отдел требований к качеству
• ISO 2504n – Отдел оценки качества

Основное содержание SQuaRE –

• Термины и определения
• Эталонные модели
• Общее руководство
• Руководства по индивидуальному разделению
• Стандарт, относящийся к разработке требований (то есть процесс спецификации, планирования, измерения и оценки)

ISO / IEC 12119

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

• Набор требований к программным пакетам.
• Инструкция по тестированию поставляемого программного пакета на соответствие указанным требованиям.

Разнообразный

Некоторые из других стандартов, связанных с процессами обеспечения качества и тестирования, упомянуты ниже –

Sr.No	Стандарт и описание
1	IEEE 829 Стандарт для формата документов, используемых на разных этапах тестирования программного обеспечения.
2	IEEE 1061 Методология для установления требований к качеству, определения, реализации, анализа и валидации процесса и продукта метрик качества программного обеспечения.
3	IEEE 1059 Руководство по проверке и проверке программного обеспечения.
4	IEEE 1008 Стандарт для модульного тестирования.
5	IEEE 1012 Стандарт для проверки и подтверждения программного обеспечения.
6	IEEE 1028 Стандарт для проверок программного обеспечения.
7	IEEE 1044 Стандарт для классификации программных аномалий.
8	IEEE 1044-1 Руководство по классификации программных аномалий.
9	IEEE 830 Руководство по разработке спецификаций системных требований.
10	IEEE 730 Стандарт для планов обеспечения качества программного обеспечения.
11	IEEE 1061 Стандарт для метрик и методологии качества программного обеспечения.
12	IEEE 12207 Стандарт для процессов жизненного цикла программного обеспечения и данных жизненного цикла.
13	BS 7925-1 Словарь терминов, используемых при тестировании программного обеспечения.
14	BS 7925-2 Стандарт для тестирования программных компонентов.

IEEE 829

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

IEEE 1061

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

IEEE 1059

Руководство по проверке и проверке программного обеспечения.

IEEE 1008

Стандарт для модульного тестирования.

IEEE 1012

Стандарт для проверки и подтверждения программного обеспечения.

IEEE 1028

Стандарт для проверок программного обеспечения.

IEEE 1044

Стандарт для классификации программных аномалий.

IEEE 1044-1

Руководство по классификации программных аномалий.

IEEE 830

Руководство по разработке спецификаций системных требований.

IEEE 730

Стандарт для планов обеспечения качества программного обеспечения.

IEEE 1061

Стандарт для метрик и методологии качества программного обеспечения.

IEEE 12207

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

BS 7925-1

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

BS 7925-2

Стандарт для тестирования программных компонентов.

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

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

Ручное тестирование

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

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

Автоматизация тестирования

Автоматическое тестирование, также известное как Test Automation, – это когда тестировщик пишет сценарии и использует другое программное обеспечение для тестирования продукта. Этот процесс включает в себя автоматизацию ручного процесса. Автоматизированное тестирование используется для повторного запуска тестовых сценариев, которые выполнялись вручную, быстро и многократно.

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

Что автоматизировать?

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

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

Когда автоматизировать?

Автоматизация тестирования должна использоваться с учетом следующих аспектов программного обеспечения –

• Крупные и важные проекты
• Проекты, которые требуют частого тестирования одних и тех же областей
• Требования не часто меняются
• Доступ к приложению для загрузки и производительности со многими виртуальными пользователями
• Стабильное программное обеспечение в отношении ручного тестирования
• Наличие времени

Как автоматизировать?

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

• Определение областей в программном обеспечении для автоматизации
• Выбор подходящего инструмента для автоматизации тестирования
• Написание тестовых скриптов
• Разработка тестовых костюмов
• Выполнение скриптов
• Создать отчеты о результатах
• Определите любую потенциальную ошибку или проблемы с производительностью

Инструменты тестирования программного обеспечения

Следующие инструменты могут быть использованы для автоматизации тестирования –

• HP Quick Test Professional
• Селен
• IBM Rational Functional Tester
• SilkTest
• TestComplete
• Тестирование везде
• WinRunner
• LoadRunner
• Visual Studio Test Professional
• Watir

Тестирование программного обеспечения – Методы

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

Тестирование черного ящика

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

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

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

Тестирование белого ящика

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

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

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

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

Тестирование серой коробки

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

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

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

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

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

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

Тестирование программного обеспечения – Уровни

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

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

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

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

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

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

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

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

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

меры	Описание
я	Определение функциональности, для которой предназначенное приложение предназначено.
II	Создание тестовых данных на основе спецификаций приложения.
III	Вывод основан на данных испытаний и спецификациях приложения.
IV	Написание тестовых сценариев и выполнение тестовых случаев.
В	Сравнение фактических и ожидаемых результатов на основе выполненных тестовых случаев.

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

Модульное тестирование

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

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

Ограничения юнит-тестирования

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

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

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

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

Sr.No.	Метод тестирования интеграции
1	Восходящая интеграция Это тестирование начинается с модульного тестирования, за которым следуют тесты прогрессивно более высокого уровня комбинаций модулей, называемых модулями или сборками.
2	Интеграция сверху вниз В этом тестировании модули высшего уровня тестируются в первую очередь, а затем постепенно тестируются модули более низкого уровня.

Восходящая интеграция

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

Интеграция сверху вниз

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

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

Тестирование системы

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

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

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

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

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

• Системное тестирование позволяет нам тестировать, проверять и проверять как бизнес-требования, так и архитектуру приложения.

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

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

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

Системное тестирование позволяет нам тестировать, проверять и проверять как бизнес-требования, так и архитектуру приложения.

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

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

Регрессионное тестирование важно по следующим причинам:

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

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

• Смягчает риски, когда регрессионное тестирование выполняется в приложении.

• Тестовое покрытие увеличивается без ущерба для сроков.

• Увеличьте скорость для продвижения продукта.

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

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

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

Тестовое покрытие увеличивается без ущерба для сроков.

Увеличьте скорость для продвижения продукта.

Приемочное тестирование

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

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

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

Альфа-тестирование

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

• Орфографические ошибки

• Неработающие ссылки

• Облачно

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

Орфографические ошибки

Неработающие ссылки

Облачно

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

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

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

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

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

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

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

• Наличие более качественного приложения при его публикации широкой публике повысит удовлетворенность клиентов.

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

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

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

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

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

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

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

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

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

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

• Сетевая задержка

• Обработка на стороне клиента

• Обработка транзакций базы данных

• Балансировка нагрузки между серверами

• Рендеринг данных

Сетевая задержка

Обработка на стороне клиента

Обработка транзакций базы данных

Балансировка нагрузки между серверами

Рендеринг данных

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

• Скорость (т.е. время отклика, рендеринг и доступ к данным)

• Вместимость

• стабильность

• Масштабируемость

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

Вместимость

стабильность

Масштабируемость

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

Нагрузочное тестирование

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

В большинстве случаев нагрузочное тестирование выполняется с помощью автоматизированных инструментов, таких как Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test и т. Д.

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

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

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

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

• Завершение или перезапуск сетевых портов случайным образом

• Включение или выключение базы данных

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

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

Включение или выключение базы данных

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

Юзабилити-тестирование

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

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

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

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

В дополнение к различным определениям юзабилити существуют некоторые стандарты и модели и методы качества, которые определяют юзабилити в форме атрибутов и податрибутов, таких как ISO-9126, ISO-9241-11, ISO-13407 и IEEE std. 610,12 и т. Д.

Пользовательский интерфейс против юзабилити-тестирования

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

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

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

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

• конфиденциальность

• целостность

• Аутентификация

• Доступность

• авторизация

• Неотрекаемость

• Программное обеспечение защищено от известных и неизвестных уязвимостей

• Данные программного обеспечения в безопасности

• Программное обеспечение соответствует всем правилам безопасности

• Проверка и проверка ввода

• Атаки SQL-вставки

• Недостатки впрыска

• Вопросы управления сессиями

• Межсайтовые скриптовые атаки

• Уязвимости переполнения буфера

• Атаки с обходом каталогов

конфиденциальность

целостность

Аутентификация

Доступность

авторизация

Неотрекаемость

Программное обеспечение защищено от известных и неизвестных уязвимостей

Данные программного обеспечения в безопасности

Программное обеспечение соответствует всем правилам безопасности

Проверка и проверка ввода

Атаки SQL-вставки

Недостатки впрыска

Вопросы управления сессиями

Межсайтовые скриптовые атаки

Уязвимости переполнения буфера

Атаки с обходом каталогов

Тестирование переносимости

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

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

• Сборка исполняемого файла (.exe) для запуска программного обеспечения на разных платформах.

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

Сборка исполняемого файла (.exe) для запуска программного обеспечения на разных платформах.

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

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

• Модульное тестирование было выполнено на связанных компонентах.

• Интеграционное тестирование выполнено.

• Тестовая среда была создана.

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

Модульное тестирование было выполнено на связанных компонентах.

Интеграционное тестирование выполнено.

Тестовая среда была создана.

Тестирование программного обеспечения – Документация

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

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

• План испытаний
• Тестовый сценарий
• Прецедент
• Матрица прослеживаемости

План испытаний

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

План тестирования включает в себя следующее –

• Введение в документ плана испытаний
• Допущения при тестировании приложения
• Список тестовых случаев, включенных в тестирование приложения
• Список возможностей для тестирования
• Какой подход использовать при тестировании программного обеспечения?
• Список результатов, которые должны быть проверены
• Ресурсы, выделенные для тестирования приложения
• Любые риски, связанные с процессом тестирования
• График выполнения задач и этапов

Тестовый сценарий

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

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

Прецедент

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

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

• Идентификатор теста
• Модуль продукта
• Версия продукта
• Лист регистраций изменений
• Цель
• Предположения
• Предпосылки
• меры
• Ожидаемый результат
• Фактический результат
• Постусловий

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

Матрица прослеживаемости

Матрица отслеживания (также известная как матрица отслеживания требований – RTM) – это таблица, которая используется для отслеживания требований в течение жизненного цикла разработки программного обеспечения. Он может использоваться для прямой трассировки (например, от требований к дизайну или кодированию) или назад (то есть от кодирования к требованиям). Существует множество пользовательских шаблонов для RTM.

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

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

Тестирование программного обеспечения – методы оценки

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

Функциональный точечный анализ

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

• Выходы
• расспросы
• входные
• Внутренние файлы
• Внешние файлы

Анализ тестовых точек

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

Метод Марк-II

Это метод оценки, используемый для анализа и измерения оценки на основе функционального представления конечного пользователя. Процедура для метода Mark-II заключается в следующем –

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

Разнообразный

Вы можете использовать другие популярные методы оценки, такие как –

Структура, содержание и процесс написания проверок

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

Меня зовут Мария Лещинская, я QA-специалист в Surf. Наша компания разрабатывает мобильные приложения с 2011 года. За это время мы создали структуру и содержание проверок, которые помогли улучшить процесс тестирования приложений. 

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

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

Очень важный инструмент при тестировании — тест-кейсы и чек-листы (далее — проверки), покрывающие приложение. Без них невозможно поддерживать качество на необходимом уровне. 

Хорошая проверка: 

1. Понятна и информативна

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

2. Единообразна для любого проекта: имеет общую структуру внутри одной компании

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

3. Покрывает необходимый процент фич

Чтобы обеспечивать определенный процент покрытия фичи, нужно:

• знать, как посчитать этот процент, 

• понимать, как количественно вычислять, что было покрыто. 

При хаотичном написании проверок это ресурсозатратно и сложно.

4. Обеспечивает прозрачность работы QA

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

5. Обеспечивает возможность быстро и удобно модифицировать проверки  

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

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

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

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

Осталось ответить на вопрос: почему писать «одинаково» настолько важно?

1. Большое количество проектов

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

Бывает и наоборот: один тестировщик находится на нескольких проектах одновременно. Может быть тяжело, если на одном проекте проверки написаны по структуре Х, а на другом — Y. На переключение между разными структурами уйдут время и силы: ведь нужно актуализировать старые проверки, писать новые…

2. Мы разные

У каждого своё мировоззрение, опыт и видение «как правильно»: это делает нас сильнее, но придаёт свои особенности в работе. Каждый из нас говорит на своем языке. Чтобы успешно взаимодействовать, нужно знать ещё один — общий.

3. Высокий темп разработки 

Быстрая скорость разработки проектов не позволяет тратить много времени на онбординги и активности по написанию. Общая структура написания помогает уменьшить время на понимание проекта.

4. Стремление делать качественно

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

Всё это делает необходимым переход к единообразному написанию проверок с долей свободы.

Содержание структуры

Приложения состоят из экранов, шторок, попапов, полей ввода, кнопок, чек-боксов, свитчеров и так далее…

Мы решили разбить все составляющие на элементы и места, где они находятся. А далее — углубиться в клиент-серверную архитектуру приложения (без неё сегодня никуда). Данные на экране почти всегда берутся из запроса: он может отдать корректный и некорректный ответы. Поэтому стоит проверять и экран отдельно, и в прямом взаимодействии с запросом. Аналогично работает и с элементом.

Выделили группы:

1. Проверки, связанные с экраном (в том числе шторка/popup и так далее)

→ Инициализация
→ PTR/КЭШ
→ Навигация: Закрытие/Возврат
→ Логика взаимодействия между экранами в стеке и МП
→ Компоновка
→ Работа с запросами

2. Проверки, относящиеся к элементу (поле, карусель, чек-бокс, радиобаттон и так далее)

→ Позитивные проверки
→ Негативные проверки
→ Логика работы элемента
→ Работа с запросами

3. Проверки, относящиеся целиком к фиче

→ Точки входа в тестируемую фичу
→ Взаимодействие текущей тестируемой фичи с другими

4. Чек-листы, помогающие в регрессионном тестировании

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

Экран (в том числе шторка/popup)

→ Инициализация или Отправка данных

Примеры наименований

• Данные на экране отображаются в соответствии с полученным ответом на запрос

  • Данные из ответа запроса для формирования экрана берутся из нужных параметров

  • Отображение Empty State (если данные не пришли).
    Непосредственно данный экран рассматривается отдельно: компоновка, работа элементов и запросов.

• Корректный запрос сформирован и отправлен

  • Данные в запросе отправляются в нужных параметрах (согласно сваггеру и ТЗ)

Позитивный по бизнесу кейс: запрос возвращает в ответе ошибку на неверно-введённый пароль. Результат легко воспроизводимый и часто ожидаемый.

Негативный по бизнесу кейс: запрос возвращает в ответе ошибку 502. Редко встречается, сложно воспроизводить (по крайней мере, так ожидается).

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

→ Инициализация или Отправка данных — ошибка на запрос

Примеры наименований

• Ответ на запрос получен с ошибкой

  • Таймаут (проверить ограничение ожидания ответа на запрос в МП)

  • Основные ошибки от сервера (индивидуально для проектов)

    • 500

    • 401

    • 400

    • и так далее

• Отображение Error State
  Непосредственно данный экран рассматривается отдельно: компоновка, работа элементов и запросов.

→ Инициализация или Отправка данных — отсутствие интернета

Примеры наименований

• Отображение соответствующего уведомления (например, snackbar на экране)

• Отображение экрана (индивидуально для проектов)

  Возможные варианты:

  • Отображение Error State в случае отсутствия сети (актуально при инициализации экрана)

  • Отображение состояния load-state (актуально при инициализации экрана)

  • Отсутствие изменений на UI или наоборот явное изменение в состоянии отсутствия сети (актуально при PTR или изменении фильтра/сортировки, выбора значений с запросами)

• Обновление Error State (PTR или кнопка)

→ PTR и КЭШ, если есть

→ PTR, если есть

Примеры наименований

В этом случае аналогично текущей структуре лучше создать три разных проверки:

• Фича. Название экрана — PTR

• Фича. Название экрана — PTR, ошибка на запрос

• Фича. Название экрана — PTR, без интернета

→ КЭШ, если есть (работы с ним/без него)

Примеры наименований

В этом случае аналогично текущей структуре лучше создать несколько разных проверок:

• Фича. Название экрана — инициализация, с/без кэша

• Фича. Название экрана — инициализация, с/без кэша, ошибка на запрос

• Фича. Название экрана — инициализация, с/без кэша, без интернета

→ PTR и кэш, если есть (и используются на одном экране)

В этом случае, согласно текущей структуре, лучше создать несколько разных проверок:

• Фича. Название экрана — PTR, с/без кэша

• Фича. Название экрана — PTR, с/без кэша, ошибка на запрос

• Фича. Название экрана — PTR, с/без кэша, без интернета

Навигация: Закрытие экрана / Возврат назад на предыдущий экран

Примеры наименований

Если запроса нет, достаточно одной проверки по закрытию экрана. Если запрос используется, лучше создать три разных проверки:

• Фича. Название экрана — закрытие

• Фича. Название экрана — закрытие, ошибка на запрос

• Фича. Название экрана — закрытие, без интернета

• Фича. Название экрана — назад на предыдущий экран

• Фича. Название экрана — назад на предыдущий экран, ошибка на запрос

• Фича. Название экрана — назад на предыдущий экран, без интернета

Со следующими шагами:

• Назад по кнопке, если есть

• Физическая кнопка «Назад» на Android

• Бэксвайп на iOS

→ Логика взаимодействия между экранами в стеке и МП

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

Примеры наименований

• Сохранение данных в стеке экранов одной фичи — если предусмотрено / Очистка данных при переходе и возврате на экраны — если сохранение не предусмотрено

  Частный случай: сохранение/очистка в кэше — свернуть и запустить приложение -> отображение данных как и до сворачивания

• Сворачивание приложения во время флоу — сохранение положения МП

→ Компоновка

Примеры наименований

• Описание элементов: их наименования + дизайн (скриншот, ссылка на фигму). Если это кнопка, то здесь же проверяется её пресс-стейт

Элемент (поле, карусель, чек-бокс, радиобаттон и тп)

→ Позитивные проверки

Примеры наименований

• Заполнение поля корректными значениями

• Вставка в поле корректных значений

Для текстового поля без ограничений вставка или заполнение поля смайликами — позитивная проверка: она очевидно возможная.

Для поля ввода суммы с цифровой клавиатурой вставка смайликов — негативная проверка: она очевидно неожиданная для текущей логики поля.

• Ограничение на размер поля

  • Техника классов эквивалентности и граничных значений (позитивные проверки)

• Заполнение поля максимально возможной длиной, если длина большая и текст может зайти на границу экрана (проверка на корректное расширение/скролл поля и отображение в нём значения)

• Пустое поле (если заполнять его необязательно)

→ Негативные проверки

Примеры наименований

• Заполнение поля некорректными значениями

  Не стоит забывать о проверке на подскролл к невалидным полям, если:

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

  • Эти поля или элементы валидируются по кнопке

• Вставка в поле некорректных значений

• Ограничение на размер поля

  • Техника классов эквивалентности и граничных значений

• Пустое поле (если заполнять его обязательно)

→ Логика работы элемента

Примеры наименований

• Общие действия с элементом и его реакция на них

Примеры:

→ Открытие определенного вида клавиатуры при активации поля

→ Расширение поля при заполнении

→ Выставление курсора в конец заполненной строки при активации поля

→ Валидация поля при снятии фокуса

→ Валидация поля при нажатии кнопки

→ Маска (для номера телефона, например)

→ Корректная активация/деактивация чек-бокса/радиобаттона

→ Зацикленная карусель / Незацикленная карусель

Фича

→ Точки входа в тестируемую фичу

Примеры наименований таких проверок

• Указываются проверки покрывающие все места, откуда можно попасть к тестируемой фиче с других экранов

→ Взаимодействие текущей тестируемой фичи с другими

Примеры наименований таких проверок

Примеры:

→ Темная тема (если поддерживается)
Смена темы и работа с тестируемой фичей

→ Пуш-уведомления + диплинки (если поддерживаются)
Переход по диплинку во флоу тестируемой фичи

→ Планшет (если поддерживается)
Компоновка, режим сплит-вью (если поддерживается)

— Huawei (если поддерживается)
Специфичные проверки (см. Особенности тестирования Android без Google-сервисов)

Готовые чек-листы

→ Обязательный чек-лист проверок

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

• Изменение размера шрифтов из настроек устройства

• Смена темы из настроек устройства

• Изменение языка из настроек устройства

• Смена времени из настроек устройства

• Использование кастомной клавиатуры Android (в частности, для полей и поисковой строки)

• Входящий звонок/смс во время прохождения флоу фичи

• Поворот устройства

• Выход из приложения двойным «Назад» на Android

• Свернуть приложение и запустить снова

• Свернуть приложение во время ожидания ответа на запрос

• Отключить интернет во время ожидания ответа на запрос

→ Дополнительный чек-лист проверок

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

• Запустить приложение без доступа к интернету вообще

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

• Запуск и сразу же сворачивание приложения

• Сворачивание приложения во время отображения системного окна оплаты Apple/Google/Samsung/Huawei Pay

• Отображение на планшетах (в режиме совместимости, если нет поддержки планшетов)

• Автоподстановка кода из смс (иногда идет по-умолчанию в iOS проектах)

• Работа приложения при пуш-уведомлении другого стороннего приложения (сообщение ВКонтакте, Twitter и так далее)

• Работа приложения после срабатывания будильника/таймера/смс/другого системного приложения

• Работа открытого приложения после разблокировки приложения

• Работа свернутого приложения после разблокировки приложения

• Работа приложения при сообщении о нехватке заряда

• Работа приложения при зарядке

• Работа приложения после отключения от зарядки

• Работа приложения при воспроизведении музыки

• Работа приложения с мобильным интернетом 3G/4G/слабым интернет-соединением

• Работа с фичей «картинка в картинке» (если поддерживается)

Эти же чек-листы в Google Docs

Что даёт структура проверок

• Понятность,

• прозрачность,

• единообразие

• возможность обеспечить необходимое покрытие,

• возможность быстрой модификации.

Один из существенных дополнительных плюсов —  использование этого подхода в автотестировании. Например, это мастхэв при работе с Flutter внутри widget-тестов. Каждый элемент во Flutter — это виджет (будь то эĸран или элемент): виджет-тесты отлично маппятся с нашими проверками, которые детально покрывают ĸаждый элемент или эĸран. 

---

Когда QA работает с sanity или smoke тестированием, нет смысла тратить время на детальную проверку каждого элемента. Нужны сценарные проверки, которые покроют целиком путь пользователя. О том, как работать со сценарными проверками, поговорим в следующей статье.

А как вы решаете вопрос с организацией проверок? Придерживаетесь хаотичного или системного подхода? Поделитесь в комментариях!

Больше полезного — в наших телеграм-каналах:

* Surf iOS Team

* Surf Android Team

* Surf Flutter Team

В них мы публикуем кейсы, лучшие практики, новости и вакансии Surf, а также проводим прямые эфиры.

Присоединяйтесь!

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

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

Необходимость тестирования программного обеспечения

Перечислим классические программные ошибки:

• Пользователь вбивает в поле ответ на вопрос и жмет клавишу Далее программа завершает работу, а информация не сохраняется. То же самое происходит и при следующей попытке.
• Пользователь играет в шутер. Вдруг персонажи начинают странно двигаться, подергиваться и т.д. Сначала программа попросту не реагирует на нажатие клавиш, а потом и вовсе выдаёт «Game over».
• Пользователь заходит в личный кабинет интернет-магазина и нажимает «Оплатить». Однако его перебрасывает на главную страницу. Кроме того, в аккаунт приходится заново входить.

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

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

Формы тестирования программного обеспечения

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

Скачать
файл

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

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

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

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

Виды тестирования ПО

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

Функциональное и нефункциональное

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

Как правило, тестируются только готовые функции, которые уже должны правильно работать. Однако объектами проверки могут стать и «неожидаемые» функций и варианты поведения приложения.

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

Статическое и динамическое

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

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

Обе эти стадии являются необходимыми.

Прочие разновидности тестирования

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

• Нагрузочное. Речь идёт о тестировании программы в условиях высоких нагрузок, которые могут быть больше, чем планировали разработчики. Эти тесты обязательны для онлайн-сервисов, которые должны правильно работать даже при наличии большого числа посетителей на пиковой или регулярной основе (онлайн-магазины во время распродаж, новостные ресурсы при резонансных событиях и т.д.).
• Тестирование UX. В этом случае специалист сосредотачивается на пользовательском опыте. Тестировщику необходимо поставить себя на место клиента. На основе составленных им замёток в процессе взаимодействия с приложением будут вноситься соответствующие изменения.
• Конфигурационное. Это проверка совместимости программы с аппаратным обеспечением и прочими software-элементами (различными версиями OS и процессоров). Конфигурационное тестирование необходимо для межплатформенных программ и в процессе перехода поставщика платформы на принципиально новую аппаратную базу (яркий пример — появление ноутбуков с чипами М1 от Apple).

Тестирование «белого ящика» и «чёрного ящика»

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

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

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

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

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

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

Понятия «альфа-тестирование» и «бета-тестирование» связаны с этапом до выпуска продукта, объёмом тестирующего сообщества и ограничениями по способам проверки. Тестирование «белого ящика» и «чёрного ящика» относятся к методам, которыми пользуется специалист.

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

Таким образом, тестировщик может проводить мероприятия по тестированию белого ящика даже после того, как программа перейдет на этап «бета». Однако это возможно в том случае, если специалист не является частью «бета-тестирования» (группы/процесса).

Место тестирования в процессе создания ПО

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

Многое зависит и от принятой модели развития. К примеру, модель «Водопад» предполагает, что формальное тестирование выполняется на этапе тестирования. Если же используется инкрементальная модель, то проверка осуществляется в конце каждого приращения/итерации и вся программа тестируется на конечном этапе.

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

• На стадии сбора требований тестированием является проверка этих требований.
• На стадии проектирования тестированием является проверка проекта для повышения качества дизайна.
• После написания кода тестированием считается итоговая проверка.

Этапы тестирования программного обеспечения

Анализ тестирования

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

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

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

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

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

Планирование и подготовка теста

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

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

Параллельно с этим специалисты подготавливают тестовые наборы и тестовые данные.

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

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

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

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

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

Выполнение теста

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

Закрытие теста

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

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

Документация для тестирования ПО

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

В данном документе должны иметься ответы на нижеперечисленные вопросы:

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

Важнейшие разделы:

• Идентификатор тест плана (Test plan identifier).
• Введение (Introduction).
• Объект тестирования (Test items).
• Функции, которые следует проверить(Features to be tested).
• Функции, которые не нужно проверять (Features not to be tested).
• Тестовые подходы (Approach).
• Критерии прохождения тестирования (Item pass/fail criteria).
• Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements).
• Результаты тестирования (Test deliverables).
• Задачи тестирования (Testing tasks).
• Ресурсы системы (Environmental needs).
• Обязанности (Responsibilities).
• Роли и ответственность (Staffing and training needs).
• Расписание (Schedule).
• Оценка рисков (Risks and contingencies).
• Согласования (Approvals).

Нельзя не упомянуть чек-лист (check list). В данном документе указываются объекты, которые необходимо протестировать. При этом чек-листы могут различаться по степени детализации.

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

Тестовый сценарий (test case) представляет собой артефакт, в котором описывается комплекс мероприятий, определенных условий и параметров, требуемых для проверки реализации тестируемой функции или её элемента.

Перечислим составные части тест кейса:

• Предусловия (PreConditions). Это перечень операций, которые необходимы для приведения системы к пригодному для выполнения основного теста состоянию. Иногда под PreConditions подразумевается набор условий, реализация которых указывает на то, что система пригодна для проведения основного теста.
• Шаги (Steps). Речь идет о перечне операций, с помощью которых одно состояние системы сменяется другим. Это нужно для того, чтобы получить результат, с помощью которого можно будет сделать вывод об удовлетворении реализации поставленным требованиям.
• Ожидаемый результат (Expected result). Это то, что необходимо получить в конечном итоге.

Правила качественного тестирования ПО

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

• Не стоит пренебрегать ручным тестированием. Автоматические проверки помогут отыскать лишь те ошибки, которые предусмотрены в скрипте тестирования. С помощью ручных методов можно найти непредсказуемые дефекты.
• Следует писать тестовые примеры на простом языке или псевдокоде вместе с вашим кодом. В противном случае новым специалистам и менеджерам придётся тратить много времени на синтаксический анализ сценария проверки.
• Необходимо применять только контролируемые изолированные испытательные среды во избежание влияния извне. Если вы будете пользоваться ПК или открытым облаком, то на тесты могут повлиять посторонние факторы. Это скажется на производительности и результате.
• Нужно выбирать конкретные метрики, которые подвергаются количественной оценке. Показатели должны описывать лишь один атрибут и строиться из чисел, дабы упростить процесс формирования отчетов. Это относится как к спецификациям, так и к тестовым случаям.
• Стоит провести тестирование до того, как вы приступите к проверке качества. Благодаря такому подходу вы распределите рабочую нагрузку тестирования по всему процессу и снизите потери времени на исправление ошибок в центральном компоненте.
• Не забывайте про пошаговые тесты. Разработайте подусловия в своих тестах. Это позволит выявить места, в которых приложение не проходит проверку.
• Лучше обеспечить как можно большее тестовое покрытие. Если вы проверите все варианты применения программы, то продукт будет готов к самым разным входам и средам.

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

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

• Усидчивость и настойчивость. Специалист должен быть достаточно терпеливым, чтобы длительное время выполнять поиск ошибок. Профессионал своего дела знает, что не существует безошибочных приложений. Если в программе не было найдено никаких дефектов, то это указывает на низкое качество тестирования.
• Критическое мышление, способность работать с информацией.
• Умение подмечать даже самые, на первый взгляд, незначительные детали. Тестировщику необходимо проверять все возможные сценарии.
• Коммуникабельность и навыки командной работы. Специалисту нужно будет общаться с разработчиками, дизайнерами, бизнес-аналитиками, представителями заказчика.
• Самоконтроль. Разработчики далеко не всегда настроены на исправление дефектов, поэтому тестировщикам приходится по нескольку раз повторять, что была найдена ошибка. Таким образом, специалист должен сочетать в себе настойчивость и дипломатичность.
• Ответственность и педантичность. Благодаря этим качествам тестировщик будет пытаться довести свою работу до конца.
• Способность грамотно формулировать свои мысли. Это позволит разработать качественный план и тест-кейс. При обнаружении дефекта специалисту необходимо донести до разработчиков все нюансы его появления.
• Желание оттачивать свои навыки. Специалист должен быть нацелен на обучение новым техникам тестирования. Для этого ему нужно работать с соответствующей литературой, ездить на конференции, семинары, проходить курсы и т.д.

Профессионал должен знать:

• основы тестирования, его разновидности и техники;
• способы разработки тест-кейсов, тест-планов;
• языки запросов SQL, базы данных;
• языки программирования;
• системы контроля версий: Git, CVS ипр.

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

• Системы для разработки тест-кейсов и обнаружения ошибок.
• Файловые менеджеры, текстовые и XML-редакторы.
• Генераторы тестовых данных итак далее.

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

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

Лучшие курсы по специальности тестировщика ПО

• Инженер по тестированию PRO

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

• Инженер по ручному тестированию

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

• Инженер по тестированию Мастер

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

• Инженер по тестированию

Программа рассчитана на 1 год. Участники получат теоретическую базу, смогут определиться со специализацией, найдут работу или откроют свое дело в сфере ИТ. При этом трудоустройство возможно уже через полгода после начала обучения.

• Инженер по автоматизированному тестированию

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

• Специалист по тестированию

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

7 книг о тестировании программного обеспечения

• Р. Калбертсон, К. Браун, Г. Кобб «Быстрое тестирование»

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

• С. Круг «Не заставляйте меня думать»

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

• А.Купер «Психбольница в руках пациента»

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

• Дж. Арбон, Дж. Каролло, Дж. Уиттакер «Как тестируют в Google»

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

• Э. Дастин, Д. Рэшка, Дж. Пол. «Автоматизированное тестирование программного обеспечения»

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

• Станислав Куликов «Тестирование программного обеспечения. Базовый курс»

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

• С. Слукин «Введение в тестирование программного обеспечения»

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

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

Работа тестировщика входит в пятерку самых популярных работ в сфере IT, согласно статистике за 2020 год. Рынок растет очень быстро, а IT-компании постоянно создают новые команды тестировщиков. А вот еще немного впечатляющей статистики – на тестирование уходит 50% всего времени и более 50% общей стоимости любого проекта по созданию софта. А это приличный бюджет. Это означает, что налаживание процессов тестирования позволит сэкономить не только время, но и деньги.

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

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

Типы тестирования

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

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

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

А какие еще есть типы тестов?

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

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

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

Методы тестирования

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

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

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

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

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

Уровни тестирования

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

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

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

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

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

Запись на курс Manual QA

‍

‍