QA

Каким образом происходит тестирование?

• Анализ и планирование;
• Тестирование документации. В данном случае мы проверяем полноту требований, их непротиворечивость, дублирование и прочее специфические аспекты;
• Подготовка к тестированию. Установка тестового окружения, настройка инструментария, подготовка плана/стратегии тестирования и автоматизации (предварительно оценив, требуется ли ее внедрение), разработка необходимой тестовой или иной вспомогательной документации, знакомство с архитектурой приложения, обучение;
• Выполнение тестирования. Тестирование нового функционала по разработанной документации или методом свободного поиска, исследовательского тестирования. Проверяем различные аспекты качества разрабатываемого приложения (см. выше ISO 9126);
• Производим анализ проведенного тестирования.

Какие программы используются для тестирования?

• Системы управления дефектами (MantisBT, Jira, FogBugz и множество других);
• Инструменты для управления тест-кейсами, чек-листами (TestLink, Zephyr, Sitechco, Jite);
• Инструменты автоматизации.

На данный момент существует ряд крупных систем (все они платные) для тестирования, в которых собран целый комплекс инструментария тестировщика. Примеры — HP Quality Center, Team Foundation Server.

Часто используемые вспомогательные инструменты:

Различные текстовые редакторы (Microsoft Word, Notepad), генераторы тестовых данных (generate data), захват экрана (Snagit, FireShot), Fidler, Firebug (плагин к FF), Web Developer Tools (плагин к FF), IE Developer Toolbar (инструментарий к IE), проверка битых ссылок (Xenu’s Link Sleuth), кроссбраузерное тестирование (IETester, Resize My Browser, SpoonBrowser).

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

По типу тестов:

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

По уровням тестирования:

• Компонентное (модульное) тестирование (component/unit testing). Проверка отдельных модулей программы, тестирование носит изолированный характер. Включает в себя как функциональные, так и нефункциональные виды тестирования;
• Интеграционное тестирование (integration testing). Тестирования взаимодействия между компонентами (модулями) системы. Включает в себя как функциональные, так и нефункциональные виды тестирования;
• Системное тестирование (system/end-to-end testing). Проверяется поведение системы в целом. Включает в себя как функциональные, так и нефункциональные виды тестирования;
• Приемочное тестирование (acceptance testing). Целью приемочного тестирования является оценка готовности системы для ее выпуска.

По знанию системы (доступности кода):

• Тестирование чёрного ящика (black box). Тестирование проводится без доступа к исходному коду;
• Тестирование белого ящика (white box). Тестирование проводится с доступом к исходу коду и с возможностью модификации кода;
• Тестирование серого ящика (grey box). Представляет собой объединение двух выше перечисленных видов тестирования. Для всех вышеперечисленных видов тестирования применяются практики статического (анализ программы происходит на основе исходного кода, который тестируется вручную, либо анализируется специальными инструментами) и динамического тестирования (происходит запуск исходного кода).

По объекту тестирования:

• Функциональное тестирование (functional testing). Проверка функций и характеристик разрабатываемого ПО на основе проектной документации;
• Тестирование производительности (performance testing). Проверка работоспособности системы под нагрузкой. Может служить для проверки и подтверждения других атрибутов качества системы, таких как масштабируемость, надёжность и потребление ресурсов. Выделяются следующие подвиды: нагрузочное тестирование (load testing), стресс-тестирование (stress testing), тестирование стабильности (stability testing);
• Юзабилити-тестирование & Тестирование интерфейса пользователя (usability testing & UI testing). Цель данного вида тестирования заключается в определении степени удобства и практичности пользовательского интерфейса;
• Тестирование безопасности (security testing). Проверка надежности системы от возможных рисков и угроз (потеря, конфиденциальность, целостность и доступность данных);
• Тестирование локализации (localization testing). Корректность перевода и работы отдельных компонентов системы (форматы дат, единицы измерения и т.д.);
• Тестирование совместимости (compatibility testing) Проверка возможности приложения взаимодействовать с различными программными продуктами, операционными системами и окружением.

По степени автоматизации:

• Ручное тестирование (manual testing). Тестирование проводится без инструментов автоматизации;
• Автоматизированное тестирование (automated testing). Тестирование на всех уровнях выполняется с использованием средств автоматизации;
• Полуавтоматизированное тестирование (semiautomated testing). Предполагается, что для определенных целей применяется автоматизации (автоматизации развертки окружения, автоматизация функционального тестирования, автоматизация генерации данных и т.д.)

По времени проведения тестирования:

• Тестирование при приёмке (smoke testing). Минимальный набор тестов на явные ошибки;
• Тестирование новой функциональности (new feature testing). Тестируется новые функции системы;
• Регрессионное тестирование (regression testing). Проверка изменений сделанных в системе для подтверждения того факта, что существующая ранее функциональность работает как и прежде;
• Тестирование при сдаче (acceptance testing). Целью приемочного тестирования является оценка готовности системы для его выпуска на рынок или передачи клиенту. Может включать в себя альфа-тестирование (alpha testing) и бета-тестирование (beta testing).

По признаку позитивности сценариев:

• Позитивное тестирование (positive testing). Проверка позитивных (правильных) пользовательских сценариев. На вход подается разрешенные (ожидаемые) данные;
• Негативное тестирование (negative testing). Проверка реакции системы на ввод негативных (не разрешенных) данных.

По степени подготовленности к тестированию:

• Тестирование по документации (formal testing). Тестирование приложения проводится по заранее подготовленным данным (тест-кейсы, чек-листы, чит-листы, спецификация и т.д.)
• Тестирование ad hoc или интуитивное тестирование (ad hoc testing) — тестирование проводится при полном отсутствии документации, без плана и цели;
• Тестирование методом свободного поиска или исследовательское тестирование (exploratory testing) — предполагается наличие минимально необходимой для тестирования документации.

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

Виды артефактов:
https://goo.gl/zeu9EE
1. Тест - кейс.
2. Тест - план.
3. Чек - лист.
4. Баг - репорт.
5. Отчет о тестировании.

Основные принципы в тестировании ПО

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

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

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

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

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

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

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

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

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

Отличи Sanity Testing от Smoke Testing тестирования

Санитарное или Санити тестирование (Sanity Testing)

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

Дымовое или Смоук тестирование (Smoke Testing)

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

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