# БИБЛИОТЕКА Статистика Redmine Системная инженерия Стейкхолдеры Управление Критическая цепь Требования и IT Информация Социальные связи Саморазвитие Логика, интеллект Экономика и общество Сумма технологии ТЕСТИРОВАНИЕ Книги и ссылки QA и QC Цикл тестирования Тест план Тест-дизайн и покрытие Уровни тестирования Виды тестирования Баг-репорт Шаблоны документов XPATH Безопасность Нагрузочное Android Автоматизация Selenium WebDriver Генератор ИНН и т.п. РАЗРАБОТКА Ресурсы Цикл разработки ПО Continuous Integration OOP - базис Frontend HTTP/REST основы Apache web-server Регулярные выражения git Javascript Perl Python Полезности в Windows LINUX Ресурсы права, юзеры и группы crontab IP tables SSH консоль (терминал) tips & tricks useful apps БАЗЫ ДАННЫХ SQL MongoDB
Эта страница:
- Ресурсы: книги - Ресурсы: ссылки - Тестирование: QC И QA - Цикл тестирования - Тест-анализ - Тест план - Тест дизайн и покрытие - Уровни тестирования - Виды тестирования - Методы: ручное и авто - Баг-репорт - Способы организации тестирования - Шаблоны документов - Метрики по обеспечению качества - Из опыта подключения к проектам - Общение с заказчиками - Подбор тестировщиков
Ещё в этом разделе:
ТЕСТИРОВАНИЕ XPATH Безопасность Нагрузочное Android Автоматизация Selenium WebDriver Генератор ИНН и т.п. Различные расчёты
Другие разделы:
# MONGO DB SQL РАЗРАБОТКА БИБЛИОТЕКА LINUX ТЕСТИРОВАНИЕ
Тестирование и обеспечение качества
— Почему вы решили стать тестировщиком?
— Воротник застегните, пожалуйста.
Ресурсы: книги
  • читать Роман Савин - Тестирование WEB-стартапов, 2007 год, отличная книга начального уровня о тестировании с многочисленными примерами, написанная хорошим русским языком с юмором
  • читать Джеймс Уиттакер - Как тестируют в Google, 2012 (русский перевод 2014 - изд. "Питер"), книга среднего уровня не только об их опыте реформации процессов тестирования в компании, но и о методах разработки и менеджмента, описанное будет полезно больше для очень крупных компаний разрабатывающих "для самое себя" (типа того же Яндекса, ABBYY, Kaspersky Lab, например), но интересных мыслей и методик – много
  • читать Рэкс Блэк - Ключевые процессы тестирования, 2004 (русский перевод 2006 - изд. "Лори"), книга высокого уровня, рассматривающая вопросы организации и проведения тестирования в комплексе;
  • читать Лайза Криспин и Джанет Грегори - Гибкое тестирование, 2009 (русский перевод 2010 - изд. "Вильямс"), книга высокого уровня о практике тестирования при гибкой (Agile) разработке
Ресурсы: ссылки
Тестирование: QC И QA
Цель тестирования (test objective, test target) или цель разработки и выполнения тестов:
  • обеспечить очищение ПО от ошибок до приемлимого уровня (вы не можете предоставить 100% покрытие, но вы должны сделать все возможное, и гарантировать, что очевидные ошибки исправлены);
  • убедиться, что ПО отвечает оригинальным требованиям и спецификации;
  • обеспечить уверенность в надёжности ПО (пользователям, заказчикам и т.д.).
QA and QA scheme

Задача QC (Quality Control, контроль качества) это контролировать и фиксировать качество артефактов, или же, другими словами, промежуточных и конечных результатов работы. Его цель заключается в поисках дефектов и обеспечении их исправления. Таким образом тестирование является неотъемлемой частью контроля качества.
Здесь очень подходит термин Verification с вопросом "Are we building the product right?" - правильно ли мы делаем продукт, проверяется соответствие планам, спецификациям, дизайну, правилам составления кода, проход тест кейсов. Проверяем CORRECTNESS.

QA (Quality Assurance, обеспечение качества) - ISO9000 определяет обеспечение качества ПО, как часть менеджмента качества, ориентированную на создании уверенности в том, что требования к устранению багов будут выполнены. Целью QA является обеспечение гарантии того, что продукт будет соответствовать ожиданиям качества заказчика. Она состоит из процессов/действий, направленных на обеспечение качества разработки продукта на каждом из его этапов. Эти действия, как правило, предшествуют развитию продукта и продолжаются, пока процесс пребывает в состоянии развития. На самом QA лежит ответственность за разработку и внедрение процессов и стандартов для улучшения жизненного цикла разработки, и обеспечение уверенности в том, что эти процессы выполняются. Фокусом QA является предотвращение дефектов на всех этапах его реализации и постоянное его совершенствование.
Здесь очень подходит термин Validation с вопросом "Are we building the right product?" - правильный ли продукт мы делаем, удовлетворяет ли продукт нуждам пользователя. Проверяем COMPLETENESS.

Ознакомиться подробнее со всей хурмой здесь:
Обеспечение качества ПО и тестирование: что в них общего и различного?
QA и тестирование. В чем разница?

Цикл тестирования
Цикл Тестирования (Testing Cycle) напоминает типичный производственный цикл, обычно проходя в несколько этапов:
  1. Тест-анализ. Результат: появление в наличии тест базиса (test basis) - актуальных требований, спецификаций, архитектурных описаний, технического задания и т.п..
  2. Планирование (Test Management, Test Planning). Результат: тест-план (test plan)
  3. Проектирование тестов (Test Design, Test Development). Результат: набор тест-кейсов (test cases), которые необходимо пройти
  4. Выполнение (Test Execution). Используются методы тестирования (methods of testing). Результат: отчёт о тестировании, багрепорты (bug report)
  5. Анализ результатов тестирования (Test Result Analysis). Используются метрики (QA metrics). Результат: выводы для исправления ошибок в планировании и контроле над процессом тестирования/разработки.
Тест-анализ

Тест-анализ = процесс поиска/рассмотрения того, что можно использовать для получения информации, необходимой для тестирования. Т.е. информации, необходимой для составления тест-кейсов – или test basis. И чаще всего test basis представляет собой набор документов, состоящий из требований, спецификаций, описания архитектуры, интеграционных интерфейсов и т.п.

Выясняем есть ли какие-нибудь проектные документы, которые должны были появиться на более ранних этапах Жизненного Цикла разработки ПО - функциональные требования (ФТ), техническое задание (ТЗ), макеты дизайна, спецификации требований, схемы, хотя бы черновики и наброски.
Ещё не поздно актуализировать эти данные. Непонятные элементы на дизайне/макете? Спросить. Задокументировать.

Выявляем:

  1. Суть проекта/доработки: для каких целей создан продукт, кто и каким образом его использует
  2. Суть реализации: как работает продукт
  3. Скоуп (область) тестирования, в т.ч. исходя из объёма продукта, его архитектуры
  4. Ограничения

Точка зрения (Point of view)

Для начала, чтобы облегчить себе задачу, определяемся с точкой зрения на систему (Point of View).
Она зависит от того, какую проблему мы решаем и что конкретно анализируем.

Методы анализа и графические нотиации для визуализации

Существуют разные методы анализа и разные графические нотации для визуализации результатов анализа. Их выбор зависит от выбранной нами точки зрения.
Потоки работ
(Функционал)
Нотации моделирования бизнес-процессов:
  • IDEF0 (SADT)
  • IDEF3
  • DFD
  • BPMN 3.0
Связи компонентов
(Архитектура)
Язык описания моделей предметной области:
  • UML
  • SysML
Активности пользователлей
(UX-design)
TBD
Потоки данных
(Модель данных предметной области)
TBD

TBD

Тест план
Тест план (Test Plan) = документ, описывающий весь объём работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

В общем случае тест-план призван ответить на следующие вопросы:

  1. Что НАДО тестировать?
  2. Что БУДЕМ тестировать? Привет, Тест-Аналитик.
  3. КАК будем тестировать? Привет, Тест-Дизайнер.
  4. КОГДА будем тестировать? Оценка трудозатрат и сроков.
  5. Какие РИСКИ возможны? какие затраты времени, средств и труда они могут повлечь.

Из собственного опыта: для учёта времени при планировании, полезно определиться и подсчитать - на что в общем случае уходит время тестировщика:
  • разгребание авгиевых почт и мессенджеров
  • вникание в ТЗ/ФТ Задачи
  • составление вопросов и ожидание ответов от Составителей ТЗ/ФТ
  • составление/актуализация/дополнение тест-кейсов к Задаче (в отсутствие Аналитиков)
  • подготовка/проверка предусловий/предустановок в Системе (в отсутствие Администраторов Системы)
  • тестирование Задачи
  • составление багрепортов по выявленным ошибкам/недочётам
  • ожидание фиксов по выявленным и зарепорченным ошибкам. (это время может идти параллельно, если затык по одной задаче - репортим и берём следующую пока та в режиме ожидания фиксов)
  • тестирование пофикшенных багов
  • оформление отчёта о тестировании
  • помощь коллегам по цеху, консультации с ними по рабочим вопросам
  • мероприятия внутри отдела тестирования - совещания, митинги, обучение, праздники и т.п.
  • мероприятия вне отдела тестирования - совещания по другим проектам, демонстрации, обучение, праздники и т.п.
Многое из перечисленного, помимо собственно анализа Задачи и ея тестирования, - может "съедать" значительную часть рабочего времени.
Что почитать на тему: Шаблоны тест-планов: Экспериментальная формула оценки времени на задачу
Тест дизайн и покрытие

Ресурсы

Суть

Проектирование тестов (test design) — этап проектирования и создания тест-кейсов (тестовых случаев, тестовых дел, case - юр. "дело"), в соответствии с определёнными ранее критериями качества и целями тестирования.
Роли, ответственные за тест дизайн:

  • Тест-аналитик — определяет "ЧТО тестировать?"
  • Тест-дизайнер — определяет "КАК тестировать?"

Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Пример оформления: http://www.protesting.ru/documentation/test_case_example.zip
Этимология слова case восходит к юридиспруденции. Case - дело, случай.
В тестировании мы, по-сути, с помощью тест-кейсов, предоставляющих нам свидетельства и факты, поддерживаем аргументы, обосновывая заявления в том что проверяемая Система, ПО или Продукт соответствуют требованиям.

( скачать схему в XML )

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

Можно выделить три самых приоритетных и важных направления при составлении тест-кейсов и exploration-тестировании:
1. Основной workflow системы Обнаружение ошибок, которые будут устранены, или даже предотвращение их внесения позитивное
негативное
2. Нагрузка и производительность Проведение тестов, которые снижают затратные риски
3. Безопасность Проведение тестов, которые снижают затратные риски

Тестовое покрытие

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

Матрица трассируемости требований и тест-кейсов

TBD

Риск качества

Риск качества (Quality risk) - потенциальный вид ошибки, способ поведения системы, при котором она, вероятно, не соответствует обоснованным ожиданиям качества системы, имеющимся у пользователя или заказчика. Это потенциальный, а не обязательный результат.

Общие категории рисков качества
Функциональность Проблемы, в результате которых не работают конкретные функции
Нагрузка, производительность, объём Проблемы обработки ожидаемых пиковых нагрузок при параллельной работе нескольких пользователей
Надёжность, стабильность работы Проблемы, при которых система слишком часто зависает или долго не восстанавливается
Перегрузки, обработка ошибок и восстановление Проблемы, возникающие ввиду превышения допустимых пиковых нагрузок или из-за обработки недопустимых условий (например, побочный эффект от сознательного внесения ошибок)
Обработка времени и дат Ошибки в математических действиях с датами и временем, в их форматировании, в планируемых событиях и других операциях, зависящих от времени
Качество данных Ошибки в обработке, извлечении и хранении данных
Производительность проблемы с временем завершения задач при ожидаемой нагрузке
Локализация проблемы, связанные с локализацией продукта, в том числе в обработке страницы символов, языковой поддержке, в использовании грамматики, словаря, а также в сообщениях об ошибках и файлах помощи
Безопасность проблемы в защите системы и охраняемых данных от мошеннического и злонамеренного использования
Установка/перенос ошибки, которые препятствуют поставке системы
Документирование ошибки в руководствах по установке и работе с системой для пользователей и системных администраторов
Из этого также следует вывод о том, насколько важно изучить требования заказчика, придерживаться их и здравого смысла (заказчик не всегда прав, иногда полезно намекнуть ему о потенциальных рисках в результате реализации какого-либо из его легкомысленных требований).

Уровни тестирования
Модульное тестирование (Unit testing) = тестирование одного модуля кода (обычно это одна функция или один класс в случае ООП-кода) в изолированном окружении. Это значит, что:
  • если код использует какие-то сторонние классы, то вместо них подсовываются классы-заглушки: моки и стабы. Stub’ы предназначены для получения нужного состояния тестируемого объекта, а Mock’и применяются для проверки ожидаемого поведения тестируемого объекта.
  • код не должен работать с сетью (и внешними серверами), файлами, базой данных (иначе мы тестируем не саму функцию или класс, а еще и диск, базу, ит.д.)

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

Выполняется разработчиками, зачастую методом автоматического тестирования.
Подробнее:
"Моки и стабы" http://habrahabr.ru/post/134836/
"Автоматизация тестирования с xUnit" https://events.yandex.ru/lib/talks/1702/

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

Выполняется разработчиками, зачастую методом автоматического тестирования.
Подробнее:
http://www.protesting.ru/testing/levels/integration.html
http://www.guru99.com/integration-testing.html

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

Подробнее:
http://www.protesting.ru/testing/levels/system.html
http://www.guru99.com/system-testing.html

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

Подробнее:
http://www.protesting.ru/testing/levels/acceptance.html
http://www.guru99.com/user-acceptance-testing.html
Виды тестирования
Основные группы тестирования
функциональная группа
нефункциональная группа
тестирование связанное с изменениями (включают и функциональные и нефункциональные тесты)

Функциональные тесты базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing) и приёмочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы.

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

Функциональное тестирование (functional testing)

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

Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования (компонентном, интеграционном, системном, приёмочном). Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде случаев использования системы (use cases).

Подробнее:
http://www.protesting.ru/testing/types/functional.html

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

  • "Позитивное" (positive testing) -- это тестирование на данных или сценариях, которые соответствуют нормальному (штатному, ожидаемому) поведению системы.
    Основной целью "позитивного" тестирования является проверка того, что при помощи системы можно делать то, для чего она создавалась.
  • "Негативное" (negative testing) -- это тестирование на данных или сценариях, которые соответствуют нештатному поведению тестируемой системы – различные сообщения об ошибках, исключительные ситуации, "запредельные" состояния и т.п.
    Основной целью "негативного" тестирования является проверка устойчивости системы к воздействиям различного рода, валидация неверного набора данных, проверка обработки исключительных ситуаций (как в реализации самих программных алгоритмов, так и в логике бизнес-правил).

Позитивное тестирование является гораздо более важным, но это не означает, что "негативными" тестами можно пренебречь.

Подробнее о позитивном/негативном тестировании: http://www.guru99.com/positive-vs-negative-testing.html

Тестирование безопасности (security and access control testing)

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

Сканирование на предмет наличия уязвимостей (Vulnerability Scanning): Выполняется с помощью специальных программ-сканеров уязвимостей.

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

Тест на проникновение (Penetration testing): симулирует нападение злоумышленника. Это тестирование включает анализ конкретной системы с целью проверить потенциальную уязвимость к внешним попыткам взлома.

Оценка риска (Risk Assessment): включает в себя анализ рисков безопасности, наблюдаемых в организации. Риски классифицируются как слабые (low), средние (medium) и высокие (high). Этот вид тестирования рекомендует методы контроля и снижения рисков.

Подробнее:
http://www.protesting.ru/testing/types/security.html
http://www.guru99.com/what-is-security-testing.html
https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
http://bugscollector.com

Тестирование производительности (performance testing) или нагрузочное тестирование (load testing)

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

Стрессовое тестирование (stress testing) – тестирование приложения под экстремальными нагрузками, определение способности обрабатывать высокий уровень траффика или обработки данных. Целью является определить переломную точку приложения.

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

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

Объёмное тестирование (volume testing) – его задачей является получение оценки производительности при увеличении объёмов данных в базе данных приложения.

Подробнее:
http://www.protesting.ru/testing/types/loadtesttypes.html
http://www.guru99.com/performance-testing.html
Список инструментов:
http://en.wikipedia.org/wiki/Load_and_performance_test_tools#Load_testing_tools

Тестирование удобства использования (usability testing)

Тестирование удобства пользования - это метод тестирования, направленный на установление степени удобства использования, "обучаемости", понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. [ISO 9126]

Удобство (User Friendliness):
  • управление и работа с системой организованы очевидным образом, нет необходимости в специальном обучении;
  • эстетичность расположения и внешнего вида содержимого, цветов, иконок;
  • наличие раздела справки;
Эффективность (Efficiency):
  • сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д.? (меньше – лучше);
  • универсальность формата окон/страниц в приложении/веб-сайте;
Правильность (Accuracy):
  • нет грамматических, синтаксических ошибок, не выводятся устаревшие или неверные данные;
  • нет битых ссылок;
Подробнее:
http://www.protesting.ru/testing/types/usability.html

Тестирование на отказ и восстановление (failover and recovery testing)

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

Объектом тестирования в большинстве случаев являются весьма вероятные эксплуатационные проблемы, такие как:
  • отказ электричества на машине-сервере;
  • отказ электричества на машине-клиенте;
  • незавершенные циклы обработки данных (прерывание работы фильтров данных, прерывание синхронизации);
  • объявление или внесение в массивы данных невозможных или ошибочных элементов;
  • отказ носителей данных.
Подробнее:
http://www.protesting.ru/testing/types/failover.html
http://swaretesting.blogspot.ru/2011/06/failover-and-recovery-testing.html

Тестирование графического пользовательского интерфейса (GUI testing)

  1. проверить для всех элементов GUI размеры, позицию и принятие букв и цифр. Например, во всех полях ввода возможно производить ввод
  2. удостовериться, что графический интерфейс позволяет полностью реализовать весь функционал приложения
  3. проверить верность отображения предупреждающий сообщений и сообщений об ошибках
  4. проверить читабельность шрифтов, используемых приложением, их выравнивание, цвет
  5. проверить отображение и расположение изображений
  6. проверить расположение элементов интерфейса при различных разрешениях экрана
Подробнее:
http://www.guru99.com/gui-testing.html
http://swaretesting.blogspot.ru/2013/01/gui-and-usability-test-scenarios.html

Тестирование совместимости (compatibility testing)

Аппаратное обеспечение: совместимость с различными аппаратными конфигурациями.
Операционные системы: совместимость с различными операционными системами – Windows, *nix, Mac OS и т.д.
Программное обеспечение: совместимость с различным программным обеспечением. Например, MS Word совместим с MS Outlook, MS Excel, VBA и т.д.
Сеть: Оценка производительности системы в сети с изменяющимися параметрами, такими как пропускная способность, рабочая скорость, ёмкость. Проверка возможности применения приложения при различных вариантах значений этих параметров.
Браузер: проверка совместимости веб-сайта с основными по-популярности – Firefox, Google Chrome, Internet Explorer, Opera, Safari.
Устройства: совместимость с различными устройствами – принтеры, сканеры, средства беспроводной связи, USvoid-устройствами.
Мобильные устройства: совместимость с мобильными платформами, такими как Android, iOS и т.д.
Версии программного обеспечения: совместимость с различными версиями программного обеспечения. Например, совместимость Microsoft Word с Windows 10, Windows 8, Windows 7, Windows XP, Windows XP SP2 и т.д.

Подробнее:
http://www.guru99.com/compatibility-testing.html

Дымовое тестирование (Smoke testing)

Дымовые тесты выполняются каждый раз, когда мы получаем новый билд (версию), проекта (системы) на тестирование, при этом считая её относительно нестабильной. Нам нужно убедиться что критически важные функции Приложения/Системы работают согласно ожиданиям. Идея данного вида тестирования заключается в том, чтобы выявить серьёзные проблемы как можно раньше, и отклонить этот билд (вернуть на доработку) на раннем этапе тестирования, чтобы не углубляться в долгие и сложные тесты, не затрачивая тем самым время на заведомо бракованное ПО.

Санитарная проверка (Sanity check)

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

Регрессионное тестирование (regression testing)

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

Ре-тест (Re-test)

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

Пример, разъясняющий разницу между тестами после изменений

У нас есть веб-сервис с пользовательским интерфейсом и RESTful API. Будучи тестировщиками, мы знаем:

  • Что у него есть 10 точек входа, для простоты, в нашем случае расположенных на одном IP
  • все они принимают GET-запрос на вход, возвращая какие-либо данные в формате json

Тогда можно сделать ряд утверждений о том, какие типы тестов нужно использовать в какой момент времени:

  • Выполнив один простой GET-запрос к одной из этих точек входа, и получив ответ в формате json, мы уже убеждаемся что дымное тестирование пройдено.
    Если же одна из этих точек входа так же возвращает данные из БД, тогда как первая — нет, нужно дополнительно выполнить ещё один запрос, чтобы убедиться что приложение верно обрабатывает запросы к базе. И на этом "дымный" тест закончен.
    То есть мы выполнили запрос — от сервиса пришёл ответ, и он не "задымился", то есть не вернул ошибку 4хх или 5хх, и что-то невнятное, вместо JSON. На этом можно сказать что "дымный" тест пройден. Для проверки того, что работает так же и UI достаточно просто один раз открыть страницу в браузере.
  • Санитарное тестирование в данном случае будет состоять из выполнения запроса ко всем 10 точкам входа в API, сверкой полученного JSON с ожидаемым, а так же наличием требуемых данных в нём.
  • Регрессионные тесты будут состоять из Smoke + Sanity + UI выполняемые вместе в одной куче. Цель: проверить что добавление 11-ой точки входа не поломало, к примеру, восстановление пароля.
  • Ре-тест в данном примере это точечная проверка что, к примеру, сломавшаяся точка входа в api в следующем билде отрабатывает как задумывалось.
При этом, если это API принимает так же POST-запросы, то очевидно что в другой набор тестов sanity нужно включить именно эти запросы. По аналогии с UI мы будем проверять все страницы приложения.

Подробнее:
Методы: ручное и авто

Ручное (manual testing) – выполнение тестировщиком тестовых сценариев и тестовых случаев вручную.

К автоматизации тестирования (automation testing) существуют следующие основные подходы:
  • тестирование на уровне кода - модульное (unit testing). Это тестирование одного модуля кода (обычно это одна функция или один класс в случае ООП-кода) в изолированном окружении. Это значит, что если код использует какие-то сторонние классы, то вместо них подсовываются классы-заглушки (моки и стабы). Код не должен работать с сетью (и внешними серверами), файлами, базой данных, иначе мы тестируем не саму функцию или класс, а еще и диск, базу, и т.д.
  • тестирование API. API - это набор функций, которые можно вызывать, чтобы получить какие-то данные.
    Например, у Яндекс.Карт есть API геокодера. Отправив к нему запрос с географическим адресом, ты можешь получить координаты точки (и наоборот), а у Центробанка есть API, которое возвращает официальный курс валют в заданный день.
    Если у твоего приложения есть API, то можно тестировать его, посылая заранее подготовленные запросы и сравнивая пришедший ответ с ожидаемым.
  • тестирование пользовательского интерфейса - (GUI-тестирование). Имитация действий пользователя с помощью специальных тестовых фреймворков.

Некоторые инструменты для автоматизации тестов

Полезные статьи

Баг-репорт

Баг репорт (bug report) - документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата. Составлять надо так, чтобы прочитав короткое описание бага (Bug Summary), разработчик понял в чём соль проблемы, а прочитав детальное описание бага (Bug Description) он примерно представлял в каких строках кода ему надо искать ошибку.

Значимость/серьёзность (severity) ошибок
0 остановка системы server down остановка работы системы
1 Потеря данных data loss Потеря пользовательских, операторских, системных данных
2 Потеря функциональности functional loss Блокирование основной функциональности. Могут включать в себя нефункциональные проблемы, например связанные с производительностью, которые вызывает неприемлимые задержки в использовании функций
3 Дыра в безопасности security loss
4 Потеря функциональности с наличием обходного пути functional loss but alternate path exists Блокирование основной функциональности, но для пользователя существует разумный обходной путь
5 Частичная потеря функциональности partial functionality loss Блокирование использования некоторой несущественной функциональности
6 Косметическая ошибка cosmetic error Значительные недостатки в пользовательском интерфейсе или в способности системы реагировать на запросы пользователя

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

Правила оформления subject (темы/названия) баг-репорта:
"Catalog Editor: Remove - ask user to delete catalog if user removed all products from catalog" - правильное православное кошерное халяльное название.
"Organizer", "Catalog properties page" - за такие названия тасков всего 400 лет назад отправляли на костёр.
Структура правильного названия таска:
<Где (название страницы)> : <Какой элемент/функция страницы> - <суть ошибки/задания>
Образцы:
Catalog Editor: Copy - not all existing catalogs shown in "select catalog" combobox
Catalog Library -> Duplicate Catalog - If 'Use audience' option is marked, 'Shared with' data must be copied to the new catalog

Шаблон структуры баг-репорта:
DO: ("ДЕЙСТВИЯ", "ШАГИ ВОСПРОИЗВЕДЕНИЯ")
Укажите последовательность действий, поведайте - что именно было сделано вами для достижения того состояния системы, при котором вы столкнулись с ошибкой

RESULT: ("РЕЗУЛЬТАТ:")
Опишите последствия ваших действий, расскажите, что случилось, когда достигнута "точка невозвращения" и как баг проявляет себя

EXPECTED RESULT: ("ОЖИДАЕМЫЙ РЕЗУЛЬТАТ:")
Описание ожидаемого поведения системы при прохождении пользователем шагов, указанных в "DO". Ожидаемый результат должен соответствовать требованиям заказчика описанным документации либо здравому смыслу. Разработчик должен знать что ему надо сделать.

ADDITIONAL INFO: ("ДОПИНФО:")
Чтобы сделать хороший баг-репорт отличным - используйте любую возможность дополнить его, как то:
- Добавьте скриншоты (отметив на них, если нужно, важные места).
- Добавьте лог сервера или текст сообщения об ошибке (если эти сведения доступны).
- Добавьте свои соображения и предположения по поводу встреченного бага (коротко, если таковые имеются).


Пример баг-репорта: bug report example
Подробнее:
http://www.protesting.ru/testing/bugreport.html
Способы организации тестирования
Просто в качестве заурядного примера: organizing a testing principal scheme
Шаблоны документов
Метрики по обеспечению качества

Метрика (QA metric) - это количественный масштаб и метод, который может использоваться для измерения.

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

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

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

  • Метрики по тестовым случаям
  • Метрики по багам / дефектам
  • Метрики по задачам

Метрики по тест-кейсам

Название Описание
Passed/Failed Test Cases Метрика показывает результаты прохождения тест кейсов, а именно отношение количества удачно пройденных к завершившимся с ошибками. В идеале, к концу проекта, количество провальных тестов стремиться к нулю
not runned yet Test Cases Метрика показывает количество тест кейсов, которые еще необходимо выполнить в данной фазе тестирования. Имея данную информацию, мы можем проанализировать и выявить причины, по которым тест не были проведены

Метрики по багам

Название Описание
Opened/Closed Bugs Метрика показывает отношение количества открытых багов к закрытым (исправленным и перепроверенным)
Reopened/Closed Bugs Метрика показывает отношение количества переоткрытых багов к закрытым (исправленным и перепроверенным)
Rejected/Opened Bugs Метрика показывает отношение количества отклоненных багов к открытым
Bugs by Severity Количество багов по серьезности
Bugs by Priority Количество багов по приоритету

Метрики "Open/Closed Bugs", "Bugs by Severity" и "Bugs by Priority" хорошо визуализируют степень приближения продукта к достижению критериев качества по багам.
Метрики "Reopened/Closed Bugs" и "Rejected/Opened Bugs" направлены на отслеживание работы отдельных участников групп разработки и тестирования.

Метрики по задачам

Название Описание
Deployment tasks Метрика показывает количество и результаты установок приложения. В случае, если количество отклоненных командой тестирования версий будет критически высоким, рекомендуется срочно проанализировать и выявить причины, а также в кротчайшие сроки решить имеющуюся проблему.
Still Opened Tasks Метрика показывает количество все еще открытых задач. К окончанию проекта все задачи должны быть закрыты. Под задачами понимаем следующие виды работ: написание документации (архитектура, требования, планы), имплементация новых модули или изменение существующих по запросам на изменения, работы по настройке стендов, различные исследования и многое другое.

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

Из опыта подключения к проектам

Аутсорсинговая компания.

  1. Знакомство с разработчиками. Выявление тех, с кем можно наиболее комфортно (бесконфликтно) и удобно (skype, рабочее место рядом) общаться, расспрашивать о непонятных моментах в проекте.
  2. Выявление ключевых персонажей на проекте
  3. Выясняем - есть ли какие-нибудь проектные документы - инструкция, хелпы, техническое задание, спецификации, схемы, хотя бы черновики разработчиков и менеджеров проекта.
  4. Если нас подключили на стадии, когда продукт уже почти готов или готов, то выясняем адрес локального тест-сервера, либо получаем дистрибутив приложения и инструкции по установке тест-сервера у себя на машине и его своевременному обновлению из репозитория.
  5. Если требуется, составление TechDoc - технического документа - на основе спецификации и требований заказчика (образец примитивного TechDoc)
  6. Выяснение подробностей у заказчика в случае, когда сложная система не описана достаточно подробно.
    Если неясна работа элементов на предоставленном дизайне, можно запросить ответы в таком формате;
    Если не всё ясно в документации, например, если требование звучит как "Пользователю предоставляется возможность работы с электронной почтой", "Электронная почта будет поддерживать вложения", "Браузер будет обеспечивать доступ к популярным wevoid-сайтам", то надо уточнить "Какая кодировка электронной почты должна поддерживаться?", "Какие именно виды вложений должны допускаться в почту и насколько большими по размеру они могут быть?", "Что должно происходить, если сайты содержат элементы ActiveX, cookies, скрипты и т.д.?". Если этого не сделать, то высока вероятность того, что реализация как попало вызовет появление "дефектов" со стороны заказчика.
  7. Выявление основных сценариев поведения пользователя системы на основе документации и требований заказчика (если документации нет - то на основе логики системы).
    Например:
    Регистрация аккаунта → вход в систему → получение услуг(и) → выход из системы
  8. Заполнение сценариев случаями.
    Например:
    1. Регистрация:
      - регистрация бесплатного аккаунта
      - регистрация платного аккаунта
    2. Вход в систему:
      - вход через форму ввода логин/пароль
      - вход посредством механизма одноразовой аутентификации (почитать о механизме: http://www.intuit.ru/studies/courses/110/110/lecture/3206?page=2)
    3. Получение услуг(и):
      - пользование услугой X/Y/Z...
      - восстановление пароля
      - смена пароля
      - удаление аккаунта
    4. Выход из системы:
      - выход посредством запроса от пользователя
      - автоматический разлогин по таймауту
  9. Оформление случаев в позитивные тест-кейсы/тест-процедуры
  10. Ручное/автоматизированное прохождение позитивных тест-кейсов/тест-процедур
  11. Создание сообщения(й) об ошибках в баг-трекинговой системе
  12. Оформление случаев в негативные тест-кейсы/тест-процедуры
  13. Ручное/автоматизированное прохождение негативных тест-кейсов/тест-процедур
  14. Создание сообщения(й) об ошибках в баг-трекинговой системе, ВАЖНО оставлять в баг-репортах ссылки на соответствующие места с описанием требований к неработающему функционалу в спецификации проекта, уведомление разработчиков о появлении баг-репортов для ускорения начала процедура правки багов/закрытия_недоработок.
  15. Создание документа Acceptance Test Procedures на основе сценариев и тест-кейсов/тест-процедур (образец ATP document’а)
  16. Во время встреч и бесед с заказчиками ОЧЕНЬ рекомендется делать краткие записи, на основе которых после разговора - формировать meeting summary, и рассылать его всем причастным лицам. Таким образом происходит какая-никакая фиксация договорённостей, на основе которых потом создаются таски, и на которые (договорённости) можно будет впоследствии ссылаться.
  17. Хотя Redmine и является достаточно хорошим средством контроля над ходом разработки, всё же для итераций в несколько месяцев бывает полезно создать документ, в котором был бы отражён ход разработки.
  18. ...
Общение с заказчиками
Оценка проекта и общение с заказчиками
  • Не "кормить клиента завтраками". Если и обещать что-то, то с привязкой к конкретному времени/датам. И сдерживать обещания.
  • Вежливость и корректность - ибо они подчёркивают профессионализм. Никаких эмоций.
  • Слова благодарности могут хоть немного компенсировать ранее проявленную жёсткость.
  • В самом начале проекта узнавать у заказчиков - какие адреса (с их стороны) ставить в копию каждого письма (CC). С нашей стороны очень желательно чтобы были в копии все разработчики, менеджеры, начальство, тестировщики.
  • Не писать бесполезных писем, не несущих никакой смысловой нагрузки.
  • Не забывай заполнить тему (subject) письма!
  • В приветствии не ставится запятая перед именем. Пример: Hi Oz
  • Предложения должны быть краткими и простыми. Длинные предложения сложно читать, и они трудны для восприятия. Наиболее распространенная ошибка для изучающих английский язык – дословный перевод с родного языка, это усложняет предложение.
  • Желательна одна тема на один email. Не рекомендуется обсуждать все насущные темы в одном письме. Только в случае когда вопросов больше 3-х, но они небольшие.
  • Будь позитивнее, больше используй слова activity, agreed, evolving, fast, good question, helpful, join us, mutual, productive, solve, team, together, tools, useful. Воздержись от использования слов busy, crisis, failure, forget it, hard, I can’t, I won’t, impossible, never, stupid, unavailable, waste. Твоя лексика показывает твоё отношение к жизни.
  • Слова-связки (Linking words):
    Sequence (Последовательность) Firstly, ... Secondly, ... Finally, ...
    Talking generally (говоря в общем) In general, ... Usually, ... On the whole, ...
    Contrast (контрастируя) However, ... Nevertheless, ... On the other hand, ...
    Adding another point (другая точка зрения) In addition, ... Moreover, ... On another point, ...
    Examples (примеры) For example, ... For instance, ... e.g.
    Alternatives (альтернативы) Either ... or... Alternatively, ... Instead of....
    Real (surprising) situation (реальная ситуация) In fact, ... Actually, ... As a matter of fact, ...
    Something is obvious (что-то очевидное) Clearly, ... Obviously, ... Of course, ...
    Most important point (самое важное) Especially, ... Above all, ... In particular, ...
    Rephrasing (другими словами) In other words, ... That is to say, ... i.e.
    Result/ consequence (результат, последствия) As a result, ... Therefore, ... For this reason, ...
    New topic (начать говорить на другую тему) In relation to... Regarding... With reference to...
  • ПРОВЕРЬ-ПЕРЕСМОТРИ ПИСЬМО ПЕРЕД ОТПРАВКОЙ
Подбор тестировщиков

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

Самое главное для нанимаемого тестировщика:
  • желание учиться
  • самостоятельность
  • неконфликтность и гибкость. Тестировщики должны стремиться отстаивать и защищать качество разумно и в пределах бизнес-контекста, но делать это твердо и убедительно. Если тестировщик готовит отчет об ошибке, который не нравится разработчику, и сталкивается с противостоянием "несчастного" программиста, ему не нужно склонять голову, класть руки в карманы и смиренно бормотать: "Хорошо-хорошо, я думаю, что отзову этот отчет об ошибке". Вместо этого тестировщик должен выпрямить спину, выслушать аргументы программиста и затем сказать что-то вроде этого: "Да, но если бы я был заказчиком и увидел такое поведение системы, у меня не было бы поводов для восторга". Твердый, но гибкий характер является требованием к хорошему тестировщику.
  • способность к напряжённой и сконцентрированной работе. Должно быть понимание ключевых приоритетов и нацеливание тестирования на следование им. Это трудно сделать, поскольку приоритеты часто меняются. Есть тестировщики, которые из-за неспособности концентрировать своё внимание испытывали трудности в выполнении поставленных перед ними задач на должном уровне качества и в надлежащие сроки. Хотя они обладали хорошими знаниями в тестировании, этот единственный пробел в их характере ограничивает их потенциал. тестировщики должны сообщать плохие новости группе разработки. Тестировщик время от времени сталкивается с сопротивлением и защитной реакцией, выступая в роли гонца с плохой новостью. Оба этих явления порождают дополнительные стрессы в жизни тестировщиков. Хорошие тестировщики заставляют себя работать в условиях недооценки и плохого понимания их роли со стороны других участников проекта.

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

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

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

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

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

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

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

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