что такое дефект тестирование

Словарь тестировщика

Баг (bug, дефект) — отклонение фактического результата (actual result) от ожидаемого результата (expected result).

Если проще, то это ошибка.

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

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

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

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

Если проще, то это процесс проверки работоспособности продукта и его пригодности к использованию. То есть это не просто поиск багов.

◓ Пример из жизни.
Нам дали на проверку кружку. Что мы будем делать? Сначала продумаем, как именно ее можно проверить и набросаем себе план. И только затем присудим к делу. Осмотрим ее снаружи, проверим на трещины, оценим качество рисунка. Уроним ее на пол, чтобы проверить на прочность. Нальем в нее холодную воду, теплую, кипяток, чтобы посмотреть не лопнет ли она. Возьмем ее в руки, оценим, удобно ли держать. После расскажем о результатах нашей работы создателю кружки.

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

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

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

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

Если проще, то это то, что пишет заказчик, когда хочет получить продукт.

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

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

Спецификация (specialization, спек) — детальное описание того, как должно работать ПО.

Если проще, то это описание технических свойств своего продукта (размеры, различные параметры, материалы, функции, etc).

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

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

(!) Все что не соответствует ТЗ и спецификации как раз и будет багом.

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

Если проще, то это документ, в котором мы фиксируем найденный баг.

◓ Пример из жизни.
Вернемся к нашему забагованному прогнозу погоды. Что делать? Кому и как сообщить, что погода-то совсем не такая, как говорят? Надо просто написать отчет. Причем написать так, чтобы они поняли про какой именно район речь и что именно с этой погодой не так.

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

Система отслеживания ошибок (bug tracking system) — программа учета и/или контроля багов.
Ее обычно называют баг-трекер или баг-трекинг.

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

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

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

Если проще, то это правка.

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

◆ Пример из работы.
Мы создали баг-репорт и отправили в наш баг-трекер. Разработчик взял баг-репорт в работу, изучил его и внес изменения в код. То есть он исправил (пофиксил) код так, чтобы в продукте больше не было бага.

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

Если проще, то это продукт или кусок продукта, который можно тестировать.

◓ Пример из жизни.
Зять строит дом для тещи. Уже готов каркас и пару комнат. Эти комнаты уже можно показать жене на проверку. Именно эти пару комнат, которые ей уже можно смотреть и оценивать — это и есть билд, который будет тестировать жена.

◆ Пример из работы.
Разработчик создает продукт. Часть кода уже написана и готова к проверки. Именно эту часть он и отдает тестировщикам на проверку.

Релиз или RTM (англ. Release to manufacturing — промышленное издание) — издание продукта, готового к тиражированию.

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

◓ Пример из жизни.
Зять закончил строить дом для тещи. Жена все протестировала. Теперь можно привозить тещу и поздравлять ее с новосельем. То есть готовый дом — это и есть релиз.

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

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

Источник

Стиль ведения дефектов

Предисловие

Участвуя в разработке программного обеспечения, видел, что при написании кода программисты обычно задают стандарт оформления кода (codestyle) — следование определённым практикам, призванным улучшить жизнь программистов. Моя роль в разработке программного обеспечения заключалась в тестировании. В качестве одной из своих обязанностей, как тестировщик, я видел производство информации о качестве программного обеспечения. В качестве одной из классификаций, эту информацию можно было поделить на позитивную и негативную. Позитивная информация обычно заключалась в том, что ожидаемое поведение совпадало с действительным, и результаты тестирования можно было предоставить в виде данных в отчете о тестировании (фича 1- работает, сценарий 2 – работает, и т.д.). А вот негативная информация чаще всего производилась и оформлялась в виде дефектов. (конечно же, бывали и другие рабочие элементы, такие, как риски, запросы на изменение, и др.)

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

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

Обычно дефект включает в себя:

1. Название
2. Критичность
3. Описание: Информация о стенде, шагах воспроизведения, фактическом и ожидаемом результате.

В зависимости от багтрекиговой системы могут быть и другие поля.

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

1. Название должно отражать суть проявления дефекта на прикладном уровне

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

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

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

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

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

Касаемо стенда:

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

3. Описание дефекта не должно содержать не относящейся к нему информации

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

4. Описание дефекта должно содержать достаточное для воспроизведения количество информации

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

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

5. Базу дефектов в багтрекере стоит вести с расчетом на перспективу

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

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

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

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

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

Приведу грубый расчет. Помню, что за 8-часовой рабочий день мне удавалось актуализировать около 5 дефектов без описания. Если бы тестировщики при заведении дефектов тратили дополнительно по 5 минут на каждый заведенный дефект, делая описание подробнее, то на заведение 100 дефектов ушло бы дополнительно 500 минут = порядка 1 рабочего дня. Из этих 100 дефектов порядка 20 останутся незакрытыми в течение достаточно большого количества времени. На их актуализацию при расчете 5 дефектов/день может уйти порядка 4 рабочих дней.

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

Когда над проектом работает 1-2 программиста, обычно каждый полностью знает весь функционал. Но когда над проектом работает, скажем, 10 программистов – то каждый хорошо знает лишь тот функционал, в который он вносил изменения. И не стоит заставлять программистов изучать поведение незнакомого для них функционала. У них с лихвой достаточно задач по реализации нового функционала.

7. По мере получения информации о дефекте стоит актуализировать шаги воспроизведения

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

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

Впоследствии, при обсуждении, вложения могут добавляться, их количество может вырастать до десятков. Удобно оперировать указанием на вложения, например: на скриншоте 15… использовать скрипт из вложения 7… см. сообщение в логе архива 25.

9. Стоит отмечать в описании дефекта информацию о частичных исправлениях

Если в одном дефекте собрана информация о нескольких схожих ошибках, например, в описании присутствует:

Ошибка выводится в браузерах:

1. Firefox
2. Google Chrome
3. Internet Explorer
4. Safari

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

1. Firefox
2. Google Chrome
3. Internet Explorer
4. Safari

10. В компании стоит определиться со стандартом критичности дефектов

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

11. Дефекты следует заводить как можно быстрее

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

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

12. Не следует игнорировать мелкие дефекты, стоит оформлять их в багтрекере

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

Когда продукт маленький – мелкие дефекты не очень сильно заметны. Но когда продукт становится большим — сценарии более емкими – наличие мелких дефектов начинает донимать.
Можно привести такую аналогию: представим небольшой населенный пункт, например, деревню из двух улиц, на перекрестке которых одна маленькая ямка с грязью. Вроде на каждом (единственном) перекрестке яма, но передвигаться по деревне легко, просто объезжая всякий раз эту яму. И она мало кому мешает. Проходит время. Населенный пункт увеличивается до города-милионника. На каждом перекрестке по ямке с грязью. Если ездить по такому городу на работу через часть-города – то передвигаться, объезжая по одной ямке на каждом перекрестке, станет уже далеко не так комфортно. И возникнет большое желание перебраться в другой город или переизбрать администрацию города. Аналогично с программными продуктами – следует способствовать тому, чтоб у пользователей было желание в них работать, вместо желания удалять.

13. Если дефект был заведен кем-то помимо тестировщика, то при необходимости стоит его подкорректировать

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

Источник

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

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

ОСНОВНЫЕ ТЕРМИНЫ

Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:

планированием работ (Test Management)

проектированием тестов (Test Design) — этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт.

анализом результатов (Test Analysis)

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

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

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

Верификация (verification)

Валидация (validation)

Соответствие продукта требованиям (спецификации)

Соответствие продукта потребностям пользователей

Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.

Следует уметь различать, что:

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

Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.

Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).

Жизненный цикл бага

Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.

Градация Серьезности дефекта

Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.

НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА

Эквивалентное Разделение (Equivalence Partitioning) — это техника, при которой функционал (часто диапазон возможных вводимых значений) разделяется на группы эквивалентных по своему влиянию на систему значений. ПРИМЕР: есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.

Анализ Граничных Значений (Boundary Value Analysis) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных. Если брать выше ПРИМЕР: в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

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

Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.

Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).

Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.

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

Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.

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

Пример таблицы принятия решений

ВИДЫ ТЕСТИРОВАНИЯ

Классификация по целям

Функциональное тестирование (functional testing) рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом, т.е. проверяется корректность работы функциональности приложения.

Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.

Тестирование пользовательского интерфейса (GUI Testing) — проверка интерфейса на соответствие требованиям (размер, шрифт, цвет, consistent behavior).

Тестирование удобства использования (Usability Testing) — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Состоит из: UX — что испытывает пользователь во время использования цифрового продукта, и UI — инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».

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

Инсталляционное тестирование (installation testing) направленно на проверку успешной установки и настройки, а также обновления или удаления приложения.

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

Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться, т.е. обеспечивать сохранность и целостность данных, после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети).

Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.

Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.

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

Тестирование стабильности или надежности (Stability / Reliability Testing) — это проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.

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

Объемное тестирование (Volume Testing) — тестирование, которое проводится для получения оценки производительности при увеличении объемов данных в базе данных приложения.

Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.

Классификация по позитивности сценария

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

Негативное — тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций; при таком тестировании часто выполняются некорректные операции.

Классификация по знанию системы

Тестирование белого ящика (White Box) — метод тестирования ПО, который предполагает полный доступ к коду проекта, т.е. внутренняя структура/устройство/реализация системы известны тестировщику.

Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).

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

Классификация по исполнителям тестирования

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

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

Классификация по уровню тестирования

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

Интеграционное тестирование (Integration Testing) направлено на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое, т.е. проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

Подходы к интеграционному тестированию

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

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

Большой взрыв («Big Bang» Integration) Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.

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

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

Классификация по исполнению кода

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

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

Классификация по хронологии выполнения

Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок, т.е. проверяется исправление багов.

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

Приёмочное тестирование проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.

ДОКУМЕНТАЦИЯ

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

Основные атрибуты требований:

Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.

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

Недвусмысленность — требование должно содержать однозначные формулировки.

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

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

Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию:

Что нужно тестировать?

Как будет проводиться тестирование?

Когда будет проводиться тестирование?

Критерии начала тестирования.

Критерии окончания тестирования.

Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.

Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.

Источник