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

Бэкграунд

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

Мы собрали 7 принципов тестирования, широко практикуемых в индустрии.

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

Кроме стандартных, неошибочных сценариев поведения, какие тест-кейсы тут можно набросать?

• Перемещать файл, когда он открыт в каком-то приложении
• Нет прав на перемещение файла в папку В
• Папка В находится на общем диске, и весь его объем уже забит
• Папка В уже имеет файл с таким же именем (ну и так далее)

Или представьте, что есть 15 полей ввода, каждое имеет по 5 возможных значений, таким образом количество возможных комбинаций равно 5 в 15-й степени.

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

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

Закройте глаза и представьте себе, что означает слово «исследовать». Вы наблюдаете и исследуете систему, чтобы узнать, как она действительно функционирует. Представьте, что вы получили по почте новое рабочее кресло, состоящее из 28 частей в отдельных пластиковых пакетах без каких-либо инструкций. Вы должны изучить свое новое прибытие, чтобы понять, как оно функционирует и как устроено. Обладая этим духом, вы можете стать исследовательским тестером. У вас не будет четко определенного плана тестирования тестовых случаев. Вы исследуете и исследуете свое программное обеспечение в поисках вещей, которые заставят вас сказать замечательное слово: «ИНТЕРЕСНО!». Узнав, вы исследуете дальше и найдете способы взломать программное обеспечение, о котором никогда не думали разработчики, а затем предоставите отчет, в котором подробно описаны многочисленные неверные предположения, ошибки и риски в программном обеспечении.

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

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

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

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

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

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

Артефакты

Спецификация (specification, спек) ― детализированное описание работы приложения, которое включает технические свойства.

Баг-репорт (bug report, отчёт об ошибке) ― описание действий или условий, которые привели к выявлению дефекта. О принципах составления безупречного баг-репорта мы уже рассказали в одной из наших статей.

Подобные отчёты создают в баг-трекинговой системе (bug tracking system, система отслеживания ошибок). Это программа для описания и контроля дефектов. Наиболее распространённой является Jira. Новичку привыкнуть к работе в этой системе непросто, но освоить азы вы сможете с поддержкой опытного преподавателя-практика на базовом курсе от QA Academy.

План тестирования (test plan) ― в этом документе содержатся все данные о проводимой проверке: описание программного продукта, стратегия тестирования, сроки выполнения поставленных задач, используемые в процессе инструменты и оборудование, оценка потенциальных рисков и прочее.

Чек-лист (checklist, контрольный список) ― перечень параметров, которые нуждаются в проверке.

Тест-кейс (test case, тестовый случай) ― своего рода сценарий или описание последовательности шагов при проведении тестирования.

Тестовый набор (test suite) ― несколько тест-кейсов, которые объединены по типу тестирования или другим признакам.

Почему тестирование так важно?

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

Почему код нуждается в тестировании?

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

В апреле 2015 финансовый терминал Bloomberg в Лондоне «упал» из-за бага в коде. Это затронуло 300 тысяч клиентов — трейдеров на финансовом рынке. Из-за этого бага британское правительство было вынуждено отложить размещение займа на 3 миллиарда фунтов.

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

Starbucks закрывала 60% кофеен в Штатах и Канаде, из-за масштабнейшего отказа платежных терминалов. В какой-то момент легендарная сеть отдавала кофе бесплатно, потому что не могла обработать покупки, а выгонять клиентов было не с руки.

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

Уязвимость в Windows 10, позволяющая злоумышленнику выйти из “песочницы” через уязвимость в подсистеме win32k.

В 2015 истребитель F-35 пал жертвой бага, не позволяющего правильно определять цели.

Airbus A300 авиакомпании China Airlines потерпел крушение в апреле 1994; в этой катастрофе 264 жертвы

В 1985 году в Канаде рентгеновский аппарат Therac-25 вышел из строя из-за ошибки в программе. Пациенты получили смертельную дозу радиации, погибли 3 человека, и 3 стали инвалидами.

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

В мае 1996 г. ошибка в коде привела к списанию со счетов 823 клиентов американского банка сумм на 0,92 миллиарда долларов.

Вот 7 принципов правильного тестирования

1. Все протестировать невозможно

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

Важнейший вопрос — как оценить эти риски?

Для этого нужно сделать мысленное упражнение: представьте, что вы тестируете операционную систему. Задайте себе вопрос: по своему опыту, какая операция, скорее всего, «положит» операционку? Уверен, ответ будет приблизительно такой: «открыть 10 приложений одновременно».

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

2. Классификация дефектов

Классификация дефектов — принцип, который предполагает, что небольшое количество модулей содержат в себе большинство багов. Это яркий пример применения в тестировании принципа Парето: 80% проблем таятся в 20% модулей.

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

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

3. Парадокс пестицида

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

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

Тестировщики не могут всегда зависеть от уже существующих тест-кейсов. Они должны постоянно развиваться, улучшая существующие тест-кейсы. Но даже так, делая все добросовестно, никогда нельзя дать гарантий, что багов в продукте нет. На презентации Windows 98, которую, между прочим, проводил сам Билл Гейтс, система «упала».

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

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

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

Но что, если вы делаете работу добросовестно, соблюдаете все требования и делаете свой продукт на 99,99% свободным от багов и он все равно не соответствует требованиям клиента?

Это подводит нас к следующему принципу: отсутствие ошибок может лишь казаться.

5. Отсутствие ошибок может быть обманчивым

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

Для решения этой проблемы, следующий принцип: раннее тестирование.

6. Раннее тестирование

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

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

Тестирование зависит от контекста; это значит, что способ, которым вы тестируете сайт для e-commerce, будет отличаться от способа тестирования мобильного приложения. Софт бывает самый разный и подход к его тестированию тоже бывает самый разный. Необходимо применять разные подходы, методологии, техники и типы тестирования в зависимости от приложения. Тестирование POS-системы в ритейле отличается от тестирования АТМ-банкомата.

Граничное тестирование

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

If ( amt < 300 ) {
startWithdrawl ( )
}
else {
error ( «Вы можете снять % s», amt ) ;
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«QA Start‎» от ITVDN

Пройти курс

Длительность: 7 уроков.

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

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

Что узнаете:

• Методологии разработки ПО.
• Виды и уровни тестирования.
• Варианты тестовой документации.
• В чём заключается разница между тест-кейсами и чек-листами.
• Принципы работы с дефектами.

Плюсы:

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

Минусы:

ClassMarker

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

В бесплатном варианте ClassMarker позволяет создать не более 100 тестов. 400 тестов в месяц обойдутся в $16.50, а 1000 тестов — уже $33. У сервиса есть ежегодные пакеты для тех, кто редко проводит онлайн-тестирования. Минимальное количество тестов (50 в год) будет стоить $25 в год, а максимум (5000 в год) обойдется в $1000.

Как работают конструкторы тестов

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

При помощи конструктора тестов создаются разные типы вопросов и ответов:

1. Выбрать один вариант ответа из нескольких предложенных;
2. Выбрать несколько вариантов ответов из предложенных;
3. Вписать недостающие слова в пробелы в тексте;
4. Написать развернуто свой вариант ответа;
5. Выбрать верное или ложное утверждение.

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

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

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

Пример сценариев тестирования сайта

Дополнительные факторы, которые следует учесть при тестировании сайта:

• Какова ожидаемая нагрузка на сервер (например, количество запросов за единицу времени)?
• Какая производительность требуется при различных видах нагрузки (время ответа веб-сервера, время отклика базы данных на запрос)?
• Какие инструменты потребуются для тестирования производительности?
• Кто является целевой аудиторией? Какие браузеры будут использовать пользователи? Какова скорость подключения? Предназначен ли сайт для использования внутри организации или будет доступен в интернете для широкого круга пользователей?
• Какую производительность ожидает получить клиент (насколько быстро должны загружаться страницы, как должны себя вести анимации, апплеты, нагрузка и запуск)?
• Будут ли разрешены простои сервера и техническое обслуживание, а также обновление контента? Если да, в каком количестве?
• Какие средства безопасности требуются (файерволы, шифрование, пароли и т.д.), и какую работу они будут выполнять? Как их можно проверять?
• Насколько надежным должно быть интернет-соединение? Как оно будет влиять на резервное копирование системы?
• Как будет выполняться управление обновлением контента сайта?
• Требования для технического обслуживания, отслеживания и контроля содержимого веб-страниц, графических элементов, ссылок и т.д.
• Какая спецификация HTML будет соблюдаться? Насколько точно?
• Как будут проверяться и обновляться внутренние и внешние ссылки? Насколько часто?
• Как будет происходить управление и проверка CGI апплетов, сценариев JavaScript, компонентов ActiveX и т.д.?
• Максимальный размер веб-страницы не должен превышать 3-5 экранов, кроме случаев, когда контент сосредоточен на одной теме. Если размер веб-страницы больше, предоставьте внутренние ссылки для навигации по ней.
• Разметка веб-страницы и элементы дизайна должны быть последовательными и логично связанными.
• Отображение веб-страниц должно быть независимо от типа браузера.
• На каждой странице следует указать ссылку для связи.

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

СМСергей Марочканичавтор статьи «Web Testing Complete Guide (Web Application Testing Tips and Scenarios)»

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

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

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

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