Переводчик Н. Григорьева

 

Чхави Досадж

Сам себе тестировщик. Пошаговое руководство по тестированию ПО. — СПб.: Питер, 2024.

 

ISBN 978-5-4461-2226-4

© ООО Издательство "Питер", 2024

 

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

 

Отдельное спасибо Анне Дудениной (Anna Doudenina) за то, что помогла воплотить идею этой книги в жизнь

О книге

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

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

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

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

Благодарности

Я хотел бы поблагодарить своих коллег из Резервного банка Австралии за помощь в работе над книгой.

Сандипа Джайна (Sandeep Jain), архитектора решений — за разработку диаграмм проектных решений.

Хари Ягнамурти (Hari Yagnamurthy), старшего бизнес-аналитика — за помощь при работе над бизнес-требованиями.

Анну Дуденину (Anna Doudenina), дизайнера пользовательского интерфейса — за создание эскизов веб-страниц проекта IMT.

Аруна Шри Кумара (Arun Sree Kumar) — за создание диаграмм для этой книги.

Отказ от ответственности

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

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

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

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

Эта глава отвечает на вопрос, что такое тестирование ПО и почему оно необходимо.

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

4 июня 1996 года Европейское космическое агентство произвело запуск беспилотной ракеты «Ариан-5» (Ariane 5). Ракета потерпела аварию через 37,5 секунды после старта из Французской Гвианы. Она должна была совершить свой первый полет после десяти лет разработки, в которую было вложено 7 миллиардов долларов. Потерпевшая аварию ракета и груз на борту были оценены в 500 миллионов долларов. Комиссия по расследованию причин взрыва через две недели опуб­ликовала отчет. Оказалось, что причиной аварии стала ошибка в программном обеспечении инерциальной навигационной системы. Эта ошибка привела к тому, что ракета отклонилась от режима вертикального взлета, и система самоуничтожения была активирована прежде, чем непредсказуемая траектория полета привела бы к более серьезным проблемам. Такой сценарий не учитывался и не проверялся в ходе формально проведенного тестирования ПО, иначе эта ошибка была бы обнаружена и устранена до запуска.

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

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

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

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

Тестирование помогает минимизировать риски

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

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

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

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

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

Тестирование позволяет определить уровень качества ПО и помогает в принятии решений

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

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

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

Тестирование обеспечивает соответствие системы поставленной цели

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

Как правило, первоначальное тестирование проводится для выявления дефектов, но их отсутствие не означает, что система полностью отвечает заявленным целям. Перед выпуском релиза ПО на продакшен проводится тестирование на уровне пользователя (UAT — user acceptance testing, то есть пользовательское приемочное тестирование), проверяющее, что система соответствует своему назначению, и попутно укрепляющее доверие пользователей к системе.

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

Тестирование имитирует реальные сценарии работы ПО

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

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

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

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

Одна из причин заключается в том, что протестировать всё невозможно. Для большинства систем исчерпывающее тестирование невыполнимо, то есть невозможно проверить все комбинации входных данных и предусловий. Чтобы понять, что такое исчерпывающее тестирование, рассмотрим простой пример. Представим, что тестируемая программа содержит одноразрядное поле, которое принимает только символы алфавита в верхнем регистре. Если мы используем методику исчерпывающего тестирования, то допустимыми входными данными являются 26 символов алфавита в верхнем регистре. Рассмотрим использование этой методики на одноразрядном поле, принимающем только символы в верхнем регистре. В этом случае необходимы валидные тесты для проверки того, что все 26 букв (английского) алфавита в верхнем регистре принимаются. Необходимо также проверить, что все недопустимые входные данные отклоняются. Тестирование потребуется для цифр от 0 до 9, 26 символов нижнего регистра и 32 специальных символов, включая пробел. Таким образом, для полной проверки этого одноразрядного поля требуется 94 тестовых сценария. Если мы решим применить методику исчерпывающего тестирования для программы, содержащей 10 полей ввода, где каждое поле может иметь 5 возможных значений, то для проверки всех допустимых комбинаций входных значений потребуется 10 в пятой степени (105) тест-кейсов, то есть 100 000, но маловероятно, что можно проверить подобное количество тестовых случаев.

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

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

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

2. Модели разработки программного обеспечения

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

Обычно жизненный цикл разработки ПО относится к одной из следующих категорий:

• последовательные модели разработки;

• итеративные и инкрементные модели разработки.

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

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

Примерами последовательной модели разработки являются:

• каскадная (водопадная) модель;

• V-модель.

Водопадная модель

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

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

Водопадная модель

V-модель

V-модель является развитием водопадной модели. В ней процесс тестирования интегрирован в процесс разработки для реализации принципа раннего тестирования.

V-модель

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

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

• Спецификация требований — описание потребностей пользователя.

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

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

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

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

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

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

• Тестирование на соответствие спецификации программы происходит на этапе модульного тестирования (юнит-тестирования).

• Тестирование на соответствие технической спецификации происходит на этапе интеграционного тестирования.

• Тестирование на соответствие функциональной спецификации происходит на этапе системного тестирования.

• Тестирование на соответствие спецификации требований происходит на этапе приемочного тестирования.

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

Итеративные и инкрементные модели разработки

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

Итеративная и инкрементная разработка

Примерами такой разработки являются:

Rational Unified Process, RUP (рациональный унифицированный процесс): каждая итерация, как правило, длится относительно долго (например, два-три месяца), и приращение функций на ней соответственно велико, например две или три группы связанных функций.

Scrum (agile-разработка): каждая итерация, как правило, длится относительно недолго (например, несколько дней или недель), и прирост функций на ней соответственно невелик, например несколько улучшений и/или две-три новые функции.

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

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

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

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

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