Основы тестирования ПО 2020: самый подробный гайд
Уже готов стать тестировщиком или хочешь освежить базовые понятия? Тогда этот гайд – то, что нужно! Команда ПОИНТ и курса Jedi.Point структурированно делится теоретическими основами тестирования: от видов до полезных инструментов.
Что такое Тестирование ПО?
Тестирование ПО – процесс, который помогает проверить выполнение всех бизнес-сценариев и требований пользователей, а также выявить все возможные проблемы и дефекты IT-продуктов.
В чем разница между тестированием, QC и QA?
Зачастую понятия «тестирование», «QA» и «QC» или путают, или используют для обозначения одного и того же. На самом деле эти термины характеризуют немного разные процессы:
- тестирование отвечает непосредственно за нахождение багов;
- QC (контроль качества) – за выполнение процесса тестирования (написание/прохождение кейсов, поиск/заведение дефектов etc);
- QA (обеспечения качества) – за создание системы контроля, которая будет предотвращать появление багов уже на этапе разработки ПО, сокращая количество выявленных дефектов на этапе тестирования; грубо говоря – построение самого процесса тестирования.
Зачем нужно тестирование и тестировщики?
Действительно, разве разработчики сами не могут проверять свои же продукты?
Тестировщик с нуля / Урок 1 / Что такое тестирование по
Еще 5-6 лет назад такой вопрос обсуждался в IT-кругах и на просторах Интернета. Но в 2020 ясно: тестировщики без работы не останутся, а тестирование должны осуществлять специалисты в сфере QA.
Во-первых, они проверяют все взаимодействия разных кусков кода и окружений, а не часть программы, которую сами же написали. Во-вторых, в процессе тестирования они ставят себя на место пользователя, для которого и создается продукт. В-третьих, логика их работы основана не только на создании ПО, но и включает возможность его поломки. И, в конце концов, время тестеров стоит дешевле, да и разработчикам не придется забивать себе голову дополнительной информацией.
Чтобы понять, как еще тестировщики помогают своим заказчикам, читайте также:
Виды тестирования ПО
Составить эталонную классификацию почти невозможно – выделяют аж 100 видов тестирования, которые можно сгруппировать по различным характеристикам.
Более того, периодически методы устаревают, и возникают новые термины.
С какими же основными классификациями и типами тестирования стоит ознакомиться начинающим тестировщикам?
Виды тестирования ПО по степени автоматизации
Среди тестировщиков существует огромное разделение на более узкие специальности: тестирование безопасности, производительности, удобства использования и др. Но в самом широком смысле их можно разделить на ручных тестировщиков и тестировщиков-автоматизаторов.
Любое тестирование можно выполнить как вручную, так и с помощью инструментов автоматизации.
Ручное тестирование – это тип тестирования программного обеспечения, при котором тестировщик вручную проводит тесты без помощи каких-либо средств автоматизации.
Автоматизированное тестирование, в свою очередь, выполняется с помощью таких фреймворков, как Selenium, PHPUnit, Mockery и других. Его целью является снижение затрат и рисков, связанных с человеческим фактором. Особенно эффективен данный тип на долгосрочных проектах с частыми релизами и объемным регрессом.
Каждое из этих направлений имеет свою область применения, потому что 100-% автоматизация невозможна. Например, проверка юзабилити всегда осуществляется вручную.
Разница между ручным и автоматизированным тестированием
Ручное тестирование | Автоматизированное тестирование |
тестировщик выполняет тесты вручную | выполняется с использованием инструментов |
требует квалифицированного труда и продолжительного времени | экономит время, бюджет, человеческий ресурс |
некоторые типы тестирования больше подходят для ручного выполнения | рекомендуется только для стабильных систем, в основном используется для регрессионного тестирования |
может стать повторяющимся и утомительным | рутинную часть можно переложить на инструменты автоматизации |
Также рекомендуем:
Виды по объекту тестирования
Функциональное тестирование (functional testing) проверяет часть системы, которая необходима для того, чтобы пользователь мог выполнить бизнес-сценарий от начала до конца. Оно выполняется первым, до нефункционального тестирования. Примеры: переход по разделам форума, поиск по сайту.
Методы и техники функционального тестирования:
- Модульное тестирование
- Тестирование серого ящика
- Тестирование черного ящика
- Тестирование белого ящика
- Пользовательское тестирование
- Регрессионное тестирование
- Смоук тестирование
- Исследовательское тестирование
- Сессионное тестирование — компромисс между исследовательским и скриптовым тестированием.
Агеева Нина, автор курса Погружение в тестирование. Jedi Point, рассказывает о сессионном тестировании
Нефункциональное тестирование необходимо для проверки работоспособности системы при различных условиях, которые могут влиять на удовлетворенность пользователя (надежность, удобство использования, масштабируемость).
Типы нефункционального тестирования:
- Тестирование безопасности (security testing)
Тестирование безопасности – это вид тестирования для выявления уязвимости программного обеспечения к различным атакам (SQL, XSS etc).
Рекомендуем ознакомиться:
- Тестирование локализации (localization testing)
Тестирование локализации – процесс адаптации продукта, который ранее был переведен на несколько языков для определенной страны или региона.
Тренер ПОИНТ Валерия Останко рассказывает о том, как тестировать локализации даже без знания языка
- Юзабилити тестирование (usability testing)
Тестирование юзабилити – это метод тестирования, направленный на выявление удобства и понятности интерфейса.
Оценивать удобство без субъективности и научиться создавать продукт, который будет нравиться вашим пользователям, вы можете на курсе Тестирование удобства использования. |
Виды тестирования по позитивности сценария
Негативное тестирование – проверка того, что при вводе недопустимых значений/совершении недопустимых действий программа ведет себя корректно – не совершает того, чего не должна и выдает человекочитаемое сообщение об ошибке.
Позитивные тестирование – проверка того, что программа работает правильно на «правильных» данных – не выдает ошибок, делает то, что должна.
Агеева Нина, автор курса Погружение в тестирование. Jedi Point, рассказывает о позитивном и негативном тестировании
Этапы тестирования
Для описания процесса тестирования поэтапно существует несколько методик. Одна из самых понятных и простых моделей – STLC.
STLC (Software Testing Life Cycle) означает жизненный цикл тестирования программного обеспечения.
Модель жизненного цикла тестирования программного обеспечения (модель STLC) состоит из шести основных фаз.
6 фаз STLC (Software Testing Life Cycle):
Анализ требований. На этом этапе тестировщики изучают требования с точки зрения тестирования и общаются с заказчиками для детального понимания. Также, если необходимо, выполняют технико-экономическое обоснование автоматизации.
Зачастую тестировщикам приходится сталкиваться с ситуацией, когда требования отсутствуют или недостаточно ясны. В таких случаях тестировщик использует методы и инструменты для организации тестирования в условиях отсутствия идеальных требований на проекте.
По этой теме рекомендуем почитать:
Научиться тестировать в условиях отсутствия идеальных требований на проекте можно на курсе: Тестирование без требований: выявление и восстановление информации о продукте |
Планирование тестирования. На данном этапе разрабатывается стратегия тестирования, выявляются риски, выбираются инструменты и распределяются роли в команде. Все это фиксируется в таких документах, как тест-план и тест-стратегия.
Агеева Нина, автор курса Погружение в тестирование. Jedi Point, подробно объясняет, что такое стратегия и как ее составить
Разработка тест-кейсов.
О том, почему мы пишем тест-кейсы, можно узнать в нашем видео:
Станислав Марков, тренер ПОИНТ и курса Погружение в тестирование. Jedi Point детально рассказывает о каждой фазе
А о том, как писать тест-кейсы, вы можете узнать на нашем Youtube-канале |
Настройка тестовой среды окружения. Этот шаг нужен для того, чтобы подготовить все условия для эффективного процесса тестирования. Он включает настройку тестового сервера, настройку сети, настройку тестовых ПК или устройств, а также формирование тестовых данных для тестовой среды.
Выполнение тестов. Команда QC начинает выполнение тест-кейсов в соответствии с планами тестирования и создает отчеты о багах. Также чаще всего на этом этапе происходит валидация багов. Она нужна для того, чтобы убедится, что дефекты, которые ты завёл ранее, ДЕЙСТВИТЕЛЬНО пофиксили.
Закрытие цикла – последний этап жизненного цикла тестирования программного обеспечения. Он включает в себя встречу членов группы тестирования для того, чтобы оценить показатели проекта.
Станислав Марков, тренер ПОИНТ и курса Погружение в тестирование. Jedi Point детально рассказывает о каждой фазе
Инструменты тестировщика
Инструменты тестирования – все продукты, которые помогают QA-инженерам организовывать свою работу на каждом этапе.
Выбор инструментов для работы тестировщика зависит от вида тестирования, личных предпочтений и места работы тестировщика. Со временем у каждого тестировщика появляется свой набор инструментов.
Инструменты для управления тестированием
Инструменты для автоматизации тестирования
Инструменты для кросс-браузерного тестирования
Инструменты для нагрузочного тестирования
Инструменты для баг трекинга
Инструменты для автоматизации тестирования мобильных приложений
Для iPhone и iPad:
Мобильные эмуляторы
- mobiReady
- BrowserStack
- CrossBrowserTesting
- Screenfly
- Mobile phone emulator
Инструменты для тестирования юзабилити
Инструменты для API- тестирования
Инструменты тестирования безопасности
- NetSparker
- OWASP
- Acunetix Vulnerability Scanner
CSS Валидаторы
Также рекомендуем:
Надеемся, наш гайд помог вам в понимании основ тестирования. Успехов в карьере тестировщика!
А тем, кто хочет узнать о каждом аспекте тестирования на практике, рекомендуем пройти курсы тестирования ПО.
И обязательно скачайте чек-лист “Что должен знать и уметь джуниор-тестировщик”, заполнив небольшую анкету.
Источник: qaschool.ru
Чек-лист для начинающих тестировщиков
Описываем подробный чек-лист того, что следует знать начинающему специалисту в тестировании. Поговорим, чему стоит научиться начинающему тестировщику в современных реалиях и что его ждет на первых этапах обучения.
Алия Токарева
Инженер-тестировщик 2 категории компании ICL Services
Процесс разработки
Перед тем, как углубляться в мир тестирования, необходимо знать рабочий процесс разработки программного обеспечения (SDLC), а это:
- жизненный цикл разработки,
- жизненный цикл тестирования,
- модели жизненного цикла,
- методологии управления проектами (особенно гибкие методологии, например, Scrum, Kanban).
Знания процесса разработки дает понять, в какой момент необходимо применить навыки тестирования, и что делать, когда еще функционал не разработан, но существуют требования.
Начала изучения тестирования
Для первых шагов тестирования необходимо знать базовый набор тестирования. Сюда можно отнести:
- Основы тестирования (основные цели тестирования, тестирование и отладка, почему тестирование необходимо, вклад тестирования в успех, обеспечение качества и тестирования);
- Чем отличаются ошибки, дефекты и отказы. Сюда же можно отнести первопричины дефекта и какой эффект бывает от первопричин (например, заказчик неверно написал формулу расчета, проектный менеджер не заметил эту первопричину, далее не увидел аналитик, тестировщик, разработчик, и в итоге воспроизводится неверный расчет уже на стороне пользователя).
Процесс тестирования
Возвращаясь к процессу разработки ПО, процесс тестирования (STLC) играет ключевую роль, и то, на каком этапе он поставлен (в зависимости от методологии управления проектом). Обычно более опытные тестировщики начинают процесс тестирования с трассировки требований, чтобы выявить и исключить первопричины дефектов.
Процесс тестирования имеет разный вид — например, в гибкой методологии управления проектами он существенно упрощен, ведь построение полного процесса тестирования для каждого спринта (обычно длится 2 недели) становится не только затратным, но и бессмысленным.
API-тестирование
На одном из этапах жизненного цикла разработки, программы не имеют графического интерфейса, поэтому знать, как проводить API-тестирование при помощи Postman или других аналогичных программных продуктов — это must have для каждого начинающего тестировщика. Особенно необходимо знать, что такое метод CRUD и какие запросы он в себя включает, а также почему такой метод не всегда эффективен в API-тестировании.
Уровни и типы тестирования
Для построения STLC важно знать, какие уровни и типы тестирования включаются в процесс. Например, поставлена задача провести тестирование одного компонента программы, у которого отсутствует любая интеграция — тогда в этом случает построение процесса тестирования будет основываться только на одном уровне. К уровням тестирования относятся:
- Компонентное тестирование (модульное тестирование — тестируется один или несколько модулей одной программы без взаимодействия друг с другом);
- Интеграционное тестирование (тестируется на взаимодействие между модулями программы или системами);
- Системное тестирование (более масштабное тестирование, в котором проходит проверку интеграция компонентов или группы компонентов между разными программами, а также фокусируется на поведении и возможностях целой системы);
- Приемочное тестирование (понимается тестирование перед выкладкой релиза, которое обычно фокусируется на поведении и возможностях системы или программы в целом).
Также важно уметь отличать типы тестирования:
- Функциональное тестирование;
- Нефункциональное тестирование;
- Тестирование методом белого ящика;
- Тестирование, связанное с изменениями.
Техники тест-дизайна
Эта часть тестирования отвечает за тестовую документацию, в которую обычно входят различные техники тест-дизайна трех методов (черный ящик, белый ящик и метод, основанный на опыте). Здесь рассмотрим только два метода:
1. К черному ящику следует отнести тесты:
- Анализ граничных значений (например, поле, принимающее 20 значений, имеет границы: нижнее 0 (пустое поле) и 1; верхнее: 20 и 21);
- Эквивалентное разбиение, которое помогает исключить некоторые тесты, чтобы предотвратить исчерпывающее тестирование (к примеру, в поле, принимающее 20 значений, нет смысла тестировать приграничные значения 2 и 19, потому что при вводе граничных значений 1 и 20 ошибок не возникло. P.S. если в этом поле запустить все 22 теста (от пустого поля до 21 символа) — то это уже является исчерпывающим тестированием, которое недостижимо);
- Тестирование с помощью таблицы альтернатив помогает выявить баги в программных модулях, которые имеют условия. Например, существует ли регистрация пользователя при покупке товара в интернет-магазине:
- Тестирование с помощью диаграммы (таблицы) состояния-переходов. К примеру, какое состояние будет иметь сайт интернет-магазина, если отменить операцию покупки на этапе оплаты? Или какое состояние примет веб-приложение, если указаны неверные реквизиты при оплате товара?
- Тестирование с помощью сценариев использования. Для примера, сможет ли зарегистрированный пользователь (участник) зайти в личный кабинет интернет-магазина (субъект)? Или удастся ли незарегистрированному пользователю открыть страницу личного кабинета? Или, если уже зарегистрированный пользователь указал неверные данные при входе, откроет ли страницу личного кабинета?
2. Метод, основанный на опыте, включающий в себя три вида:
- Предположение об ошибках;
- Исследовательское тестирование (обычно без применения каких-либо тестов);
- Тестирование на основе чек-листов.
Инструменты тестирования
Каждому начинающему тестировщику необходимо знать, какие инструменты функционального тестирования и управление тестированием следует применять в тестировании и уметь владеть данными инструментами, а также их классификацию:
- Инструменты управления тестированием и тестовым окружением (тест-план, инструменты управления требованиями — таблица трассировки, управление дефектами — Jira, YouTrack и т. д., управление конфигурацией — Git);
- Инструменты статического тестирования (рецензирование — планирование и контроль процесса рецензирования, передачи данных, совместное рецензирование для сбора показателей и составления отчетности);
- Инструменты проектирования и реализации тестов (техники тест-дизайна, maind-map, подготовка тестовых данных);
- Инструменты покрытия и выполнения тестов (таблица трассировки, TestRail, тест-кейсы, TestManagement и т. д.).
Баг
Баг-репорт
Для начинающего тестера must have здесь — не только найденный баг, но и правильное его оформление. Ведь плохое описание может ухудшить эффективность исправления бага разработчиком (по крайней мере программист затратит намного больше временного ресурса на понимание шагов в баг-репорте, чем на исправление ошибки). Поэтому баг-репорт должен содержать описание в технике SMART:
- S — (specific) конкретность, прозрачность;
- M — (measurable) измеримость;
- A — (attainable) достижимость, реалистичность;
- R — (relevant) актуальность;
- T — (time-bound) ограничения во времени
Баг-репорт состоит из:
- ID номер бага;
- Наименование (хорошее название — это шаг к быстрому понимаю бага разработчиком);
- Спецификация (версия ПО, ссылки, браузер, тестовая среда и т. д.);
- Предусловие (не всегда применяется, но иногда необходим, когда нужно выполнить какое-то условие перед воспроизведением бага);
- Шаги воспроизведения (которые должны иметь конкретность, прозрачность, локальность);
- Ожидаемый результат (важно помнить, что ожидаемый результат = требуемому результату);
- Полученный результат (описание самого бага или поведения программы);
- Аттачи (настройки INI, скриншоты, файлы, логи и т. д., которые помогают воспроизвести баг);
- Исполнитель (разработчик, который должен исправить дефект);
- Приоритетность;
- Комментарии (не всегда они применяются, но более опытные тестировщики описывают ходы, как можно исправить тот или иной баг).
Заключение
Этот чек-лист описывает первые шаги того, что должен знать начинающий тестировщик перед тем, как приступить к работе с реальными проектами. С расширением навыков тестирования увеличивается и чек-лист скиллов специалиста, и соответственно расширяется круг ответственности. Поэтому эта статья только приоткрывает «щелочку» двери в мир тестирования.
Источник: tproger.ru
Тестирование: цели и принципы
Откуда вообще возникла необходимость в тестировании? Люди совершают ошибки. Одни из них могут быть незначительными, другие иметь самые разрушительные последствия. Все, что производится человеком, может содержать ошибки (так уж мы, люди, устроены). Именно поэтому любой продукт нуждается в проверке – тестировании.
Если не тестировать, есть вероятность выпуска некачественного продукта, который пользователь даже не сможет нормально запустить. Если говорить обо мне, то я не буду пользоваться продуктом, который плохо работает и в котором постоянно всплывают ошибки и мешают работе в нем. А вы?)
Тестирование — это …
Тестирование (testing) — это процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для заявленных целей и для определения дефектов [глоссарий ISTQB].
Давайте разберем это определение по частям.
Во-первых, тестирование, это процесс исследования или изучения программы.
Во-вторых, исследуем мы зачем? Чтобы проверить, что программа соответствует ожиданиям, то есть мы запускаем программу и смотрим, что весь ее функционал соответствует техническому заданию.
И наконец, в третьих, как мы это будет делать? С помощью заранее написанных или подготовленных проверок.
Если все это совместить и сказать простым языком, то получим следующее определение.
Тестирование — это процесс исследования программы с целью определить, что программа работает в соответствии с заявленными требованиями с помощью заранее подготовленных проверок.
Цели тестирования
Цели тестирования сильно зависят от целей самого проекта. Но можно выделить основные общие цели:
- Проверка, все ли указанные требования выполнены.
Что это значит? У каждого продукта есть техническое задание (ТЗ) в том или ином виде. Именно оно определяет, как будет выглядеть программа. ТЗ задает соответствующие требования, а мы, как тестировщики, должны проверить, что все требования из ТЗ не только реализованы, но и работают правильно. - Создание уверенности в уровне качества объекта тестирования.
Напрямую тестирование не влияет на качество продукта. Грубо говоря, качество — это удовлетворение ожиданий пользователей. А удовлетворение зависит от очень многих факторов.
Тем не менее, поиск и исправление дефектов позволяет продукту работать именно так, как он был задуман. И, как минимум, можно сказать, что если программа работает корректно и соответствует заданным критериям, то достигнут определенный уровень качества объекта тестирования. - Предотвращение дефектов.
Тестирование — не только поиск багов на уже реализованном продукте. Существует также тестирование на более ранних этапах, например, тестирование документации.
Заранее протестировав тоже ТЗ, тестировщик может указать на потенциальные проблемы, которые могут появиться в результате разработки программы. А зная о таких проблемах заранее, можно избежать вполне реальных багов в будущем. - Обнаружение отказов и дефектов.
Здесь все просто: поиск багов в программном обеспечении (ПО) является неотъемлемой частью тестирования. - Предоставление заинтересованным лицам достаточной информации, позволяющей им принять обоснованные решения (особенно в отношении уровня качества объекта тестирования).
Тестирование — это все-таки услуга. Мы, как тестировщики, не влияем напрямую на исправление дефектов. Но можем показать текущее состояние продукта, выраженное в количестве багов, путем оформления баг-репортов. Заинтересованные лица (например, руководитель проекта) могут оценить текущие проблемы и принять решение о выпуске или не выпуске продукта. - Снижение уровня риска ненадлежащего качества программного обеспечения (например, пропущенные сбои в работе).
Чем лучше тестирование, тем меньший риск пропуска критичных багов. А значит, что риск возникновения ненадлежащего качества ПО уменьшается.
Принципы тестирования
За последние пятьдесят лет был предложен ряд принципов тестирования, которые являются общим руководством для тестирования в целом:
- Тестирование демонстрирует наличие дефектов, а не их отсутствие.
Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет. Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но, даже если дефекты не были обнаружены, тестирование не доказывает его корректности. Почему? Потому что есть пункт 2. - Исчерпывающее тестирование недостижимо.
Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. Вместо попытки исчерпывающего тестирования должны использоваться анализ рисков, методы тестирования и расстановка приоритетов, чтобы сосредоточить усилия по тестированию.
Элементарно, попробуйте посчитать сколько усилий необходимо приложить, чтобы проверить все комбинации калькулятора. И даже если вы продумаете абсолютно все варианты, то всегда найдется еще один, о котором вы не знаете. - Раннее тестирование сохраняет время и деньги.
Активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки программного обеспечения. Это как раз позволяет находить дефекты на ранних стадиях.
Раннее тестирование иногда называют «сдвигом влево» по ISTQB. Тестирование на ранних этапах жизненного цикла разработки программного обеспечения помогает сократить или исключить дорогостоящие изменения. Хотя бы потому что вовремя замеченную ошибку в ТЗ исправить намного проще, чем когда по этому ТЗ уже будет разработана функциональность. - Кластеризация дефектов (Скопление дефектов).
Обычно небольшое количество модулей содержит большинство дефектов, обнаруженных во время тестирования перед выпуском. То есть баги имеют свойство скапливаться где-то в одном месте и, если нашли интересную ошибку в функционале, есть очень большая вероятность найти рядом еще одну. - Парадокс (эффект) пестицида.
Если одни и те же тесты будут выполняться снова и снова, в конечном счете эти тесты больше не будут находить новых дефектов. Для обнаружения новых ошибок может потребоваться изменение существующих тестов и тестовых данных, а также написание новых тестов.
Тесты больше не эффективны при обнаружении дефектов, так же как пестициды через некоторое время больше не эффективны при борьбе с вредителями. - Тестирование зависит от контекста.
Тестирование выполняется по-разному в зависимости от контекста. Например, программное обеспечение управления производством, в котором критически важна безопасность, тестируется иначе, чем мобильное приложение электронной коммерции. - Заблуждение об отсутствии ошибок.
Некоторые организации ожидают, что тестировщики смогут выполнить все возможные тесты и найти все возможные дефекты, но принципы 2 и 1 говорят нам, что это невозможно.
Кроме того, ошибочно ожидать, что простое нахождение и исправление большого числа дефектов обеспечит успех продукту. Например, тщательное тестирование всех указанных требований и исправление всех обнаруженных дефектов может привести к созданию системы, которая будет трудной в использовании, не будет соответствовать потребностям и ожиданиям пользователей или будет хуже по сравнению с другими конкурирующими системами.
Итак, сегодня мы разобрали что такой тестирование и зачем оно необходимо, выяснили его цели и принципы. В следующей статье мы поговорим об этапах тестирования.
Источник: sedtest-school.ru
Тестирование ПО
02.01.2015
620
Рейтинг: 5 . Проголосовало: 1
Вы проголосовали:
Для голосования нужно авторизироваться
Введение
Знание о тестировании программного обеспечения критически важно не только для разработчиков программного обеспечения, программистов и профессиональных тестеров, но также и для покупателей, и пользователей. В последнюю категорию попадаем мы все.
Почему программное обеспечение нужно тестировать?
Цели тестирования программного обеспечения, независимо от того, кто совершает тестирование или где это сделано, состоят в том, чтобы обеспечить необходимое качество программного обеспечения и снизить риск ошибок в программе — «багов». Баг — код программы, который приводит к искажению или вовсе несовпадению фактического результата и того, который мы ожидаем.
Баги могут быть относительно малозначимыми (типографическая ошибка на экране), средней значимости (определенная комбинация нажатий клавиш приводит к ошибке в работе программы), или очень серьезными (процедура вычисления среднего арифметического числа из нескольких заданных является дефектной). Тестирование и отладка ПО – совсем не одно и то же.
Тестирование фокусируется на предотвращении багов и нахождении их в готовом коде. Отладка может быть логическим следствием тестирования. Цель отладки состоит в том, чтобы найти код, который привел к отказу программы и исправить его. Тестирование программного обеспечения может показать некоторые, но не все дефекты в коде программы. Оно также демонстрирует, что функция программы и ее производительность могут быть корректными или неправильными, или обнаружить логический отказ — это означает, что программа делает то, что ей сказали сделать, но чье-то обоснование (разработчика или программиста) было в некотором роде дефектным.
Кто участвует в процессе тестирования программного обеспечения?
Покупатель и/или пользователь ПО должны играть главную роль в процессе его тестирования. Заказчик должен работать с разработчиком во время процесса планирования и проектирования так, чтобы все стороны достигли договоренностей о том, из чего будет состоять заключительный продукт и как он должен выглядеть и работать.
Джоэл Джилмен в колонке «Law Report» журнала «Systems Integration» в феврале 1991 предложил, чтобы документ тестовых критериев был составлен и включен в исходные требования к продукту или контракт. Программисты должны быть ответственны за основное тестирование программного обеспечения. Хороший программист никогда не должен передавать программу к тестеру или отделу тестирования без первой обработки тестовых сценариев, которая определяет, отвечает ли программа определенным требованиям. Нужно отметить, однако, что у тестировщиков и программистов есть различные цели, когда они тестируют программное обеспечение. Борис Бейзер в «Software Testing Techniques »- превосходной книге по основам тестирования — сказал, что тестировщик — это «тот, кто пишет и/или выполняет тестирование программного обеспечения с намерением продемонстрировать, что программа не работает, в то время, как программист – это тот, чьи тестирования (если таковые имеются) предназначены, чтобы показать, что программа действительно работает».
Тема связана со специальностями:
Что являет собой тестирование ПО?
Тестирование программного обеспечения — процесс, цель которого состоит в том, чтобы предотвратить и раскрыть «баги» в ПО и определить, соответствует ли оно определенным требованиям. Считается, что половина работы по созданию программного обеспечения — это тестирование. Есть четыре общие категории, часто называемые этапами тестирования программного обеспечения. О них дальше и пойдет речь.
Юнит-тестирование тестирует самые маленькие части программного обеспечения — юниты . Цели такого тестирования состоят в том, чтобы оценить, удовлетворяет ли юнит требования спецификации и/или соответствует ли его структура оговоренной структуре проекта. Юнит-тестирование должно быть реализовано программистом. Есть множество инструментов, которые могут быть использованы, чтобы оценить, были ли протестированы все пути, которыми ПО может реализоваться.
Цель интеграционного тестирования состоит в том, чтобы протестировать то, что происходит, когда все части ПО объединены (интегрированы) в одно целое . Обычно, если проблема найдена, она имеет отношение к информации, упущенной при интеграции таких юнитов.
Видео курсы по схожей тематике:
TDD — Разработка через тестирование
Автоматизация тестирования мобильных приложений
Системное тестирование, исходя из своего названия, нацелено на тестирование всей системы. Оно направлено на нахождение проблем, кроме тех, которые могут быть приписаны юнитам и/или их взаимодействиям. В системном тестировании можно проверить систему на производительность, вопросы безопасности и другие проблемы этих типов.
Приемочные испытания — широкая категория, которая обеспечивает заключительную сертификацию и гласит, что система готова к реальному использованию. Они могут включать очень интенсивные тесты, которые проверяют положительные и отрицательные аспекты системы и ее функциональность. Причинами багов, найденных на этапе приемочных испытаний, обычно является неполное понимание своего задания разработчиком или отсутствием коммуникации между покупателем и разработчиками. Есть другие этапы тестирования, которые могут быть реализованы совместно с вышеперечисленными этапами. Это регрессивное тестирование, тестирование на надежность и удобство пользования, соответствие стандартам, тестирование функциональной совместимости.
Когда должен начинаться процесс тестирования?
Тестирование, конечно, не может начаться, пока тестируемый программный код не будет написан. Однако процесс тестирования должен зарождаться, когда начинается процесс разработки ПО. Время, потраченное на устранение ошибок, намного короче, когда тестирование запланировано в начале фазы проектирования, чем в ее конце. Системные требования должны быть записаны и согласованы всеми сторонами, и эти спецификации требований должны использоваться в качестве основного плана тестирования.
Когда разработчик должен прекратить тестировать и поставить продукт?
Решение может основываться на измерении коэффициентов ошибок. Однако ключевое решение будет всегда основываться на доступных ресурсах. Если до релиза продукта имеется определенный объем времени, можно было бы расширить тестирование на каждом этапе.
Однако, если бы программное обеспечение было обещано 6 месяцев назад, тестировщик мог бы рискнуть и сказать о том, что программа работает без серьезных багов, даже если он или она знает о некоторых незначительных ошибках. Все это сводится к оценке степени риска и способности определить, когда более или менее безопасно отослать продукт заказчику. Если дефектный продукт отослан, новая версия его все же может быть выпущена, однако это подразумевает совершенно новый набор оценок степени риска.
Как должен быть записан и выполнен план тестирования?
Планы тестирования на каждом этапе должны основываться на структурированных требованиях. Эти требования должны быть записаны и согласованы всеми сторонами еще до того, как будет написан программный код.
Тестовое планирование должно включать в себя шаги по проверке требований спецификации, проектировать тесты, и, наконец, определять процедуры (тестовые сценарии) и/или получать тест-кейсы. Тест-кейсы – это отдельная наука . Цель их состоит в том, чтобы идентифицировать все типы случаев, которые могли бы произойти согласно каждому сценарию. После того, как код, который будет протестирован, записан, тестер выполняет запланированные тесты, оценивает результаты и обеспечивает обратную связь. Эта обратная связь становится документально подтвержденным фактом для системы.
Бесплатные вебинары по схожей тематике:
Как стать Automation QA специалистом? Часть 2.
Successful testing on mobile devices
Источник: itvdn.com