Тестирование программ: виды, этапы, принципы

Исследовательское тестирование и туры (Exploratory Testing & Test Tours)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Качество программного обеспечения — это степень, в которой ПО обладает требуемой комбинацией свойств.

Качество программного обеспечения — это совокупность характеристик ПО, относящихся к его способности удовлетворять установленные и предполагаемые потребности.

Характеристики качества ПО

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

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

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

Эффективность (Efficiency) – способность ПО обеспечивать требуемый уровень производительности, в соответствии с выделенными ресурсами, временем и другими обозначенными условиями.

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

Портативность (Portability) – характеризует ПО с точки зрения легкости его переноса из одного окружения (software/ hardware) в другое.

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

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

Возможно ли писать программы без тестировщиков

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

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

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

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

Семь принципов тестирования программного обеспечения

#1. Тестирование показывает наличие дефектов

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

Тестирование говорит о наличии дефектов и не говорит об их отсутствии.

#2. Исчерпывающее тестирование невозможно

Что такое исчерпывающее тестирование?

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

Почему невозможно достичь исчерпывающего тестирования Тестируете?

Предположим, нам нужно проверить поле ввода, которое принимает возраст от 18 до 20 лет, поэтому мы проверяем поле, используя 18,19,20. В случае, если одно и то же поле ввода принимает диапазон от 18 до 100, тогда мы должны протестировать, используя такие входы, как 18, 19, 20, 21, …., 99, 100. Это базовый пример, вы можете подумать, что вы могли бы достичь этого с помощью инструмента автоматизации. Представьте, что одно и то же поле принимает несколько миллиардов значений. Невозможно протестировать все возможные значения из-за ограничений по времени выпуска.

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

#3. Раннее тестирование

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

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

#4. Кластеризация дефектов

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

В соответствии с принципом Парето (правило 80-20), 80 % проблем возникают из 20 % модулей, а остальные 20 % проблем — из оставшихся 80 % модулей

Поэтому мы уделяем особое внимание тестированию 20% модулей, в которых мы сталкиваемся с 80% ошибок

#5. Парадокс пестицидов

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

#6. Тестирование зависит от контекста

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

#7. Отсутствие ошибок — заблуждение

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

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

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

Этапы

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

1. Анализ имеющегося продукта. Это – первоначальная идея (задумка) проекта.
2. Работа с требованиями. На предыдущем этапе происходит формирование технического задания. Теперь предстоит изучить его и доработать, если это необходимо.
3. Разработка стратегий тестирования и планирование процедур по контролю качества.
4. Создание тестовой документации. Это – этап, на котором формируется «отчетность» для тестировщиков. Вспомогательные документы, опираясь на которые, специалисты будут грамотно выстраивать процессы.
5. Тестирование прототипов.
6. Основной этап проверок. Здесь выявляется полноценная работоспособность приложения, а также соответствие первоначальным требованиям заказчика.
7. Стабилизация и отладка.
8. Релиз и эксплуатация.

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

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

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

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

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

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

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

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

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

Также часто называют E2E тестами (End-2-End) или сквозными. На этом уровне происходит валидация требований (проверка работы ПО в целом, не только по прописанным требованиям, что проверили на системном уровне).

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

Отмечу, что приемочные тесты проводят, когда (1) продукт достиг необходимо уровня качества и (2) заказчик ПО ознакомлен с планом приемки (в нем описан набор сценариев и тестов, дата проведения и т.п.).

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

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

QA, QC и тестирование

Так в чем же разница между QA и тестированием и что такое Quality Control?

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

Можно оформить их соотношение в виде таблицы:

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

Иными словами, Quality Assurance обеспечивает правильность и предсказуемость процесса, в то время как Quality Control предполагает контроль соблюдения требований. Тестирование же, в свою очередь, обеспечивает сбор статистических данных и внесение их в документы, созданные в рамках QC-процесса.

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

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

То есть качеству объекта внимание уделяется еще до создания самого объекта.

Автоматизация против ручного тестирования

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

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

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

Тестирование автоматизации:

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

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

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

О качестве

Что собой представляет качество ПО, понятно. Данный процесс имеет несколько «видов» контроля (проверок). Каждый предусматривает свои ключевые особенности:

1. QC – контроль качества продукта (системы). Представляет собой анализ результатов тестирования и качества новых версия проекта. К его задачам относят проверку: готовности приложения к релизу, соответствие требований и качества.
2. QA – это обеспечение качества продукта. Отражает процесс изучения возможностей по внесению изменений и улучшению разработки. Позволяет делать связи в команде программистов лучше. Это помогает повысить эффективность тестирования. Среди своих задач выделяет: непосредственное тестирование, проверку технических характеристики, оценку возможных рисков, планирование задач для улучшения (ускорения) выпуска продукта. Предусматривает анализ полученных в ходе тестов результатов. За счет QA удается составить отчеты и другие документы по системе.

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

Жизненный цикл тестирования программного обеспечения

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

Давайте подробнее рассмотрим каждый из этих 6 шагов:

Анализ требований

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

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

План тестирования

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

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

Разработка тестового случая

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

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

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

Настройка тестовой среды

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

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

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

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

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

Завершение тестового набора и анализ

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

Отсюда вы можете:

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

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

Что в итоге

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

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

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