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

Почему вы решили стать тестировщиком?
- Воротник застегните, пожалуйста.

Книги

  • (PDF ) Тестирование программного обеспечения (Святослав Куликов, 2018) . Курс хоть и позиционируется как "базовый", но предметная область расписана глубоко, наглядно, со множеством примеров.
  • (PDF ) Как тестируют в Google (Джеймс Уиттакер, 2012; русский перевод 2014 - изд. "Питер") , книга среднего уровня не только об их опыте реформации процессов тестирования в компании, но и о методах разработки и менеджмента, описанное будет полезно больше для очень крупных компаний разрабатывающих "для самое себя" (типа того же Яндекса, ABBYY, Kaspersky Lab, например), но интересных мыслей и методик - много
  • (PDF ) Ключевые процессы тестирования (Рэкс Блэк, 2004; русский перевод 2006 - изд. "Лори").
    Рассматриваются вопросы организации и проведения тестирования в комплексе, читать выборочно;
  • (PDF ) Гибкое тестирование (Лайза Криспин и Джанет Грегори, 2009; русский перевод 2010 - изд. "Вильямс")
    , о практике тестирования при гибкой (Agile) разработке

Ссылки

  • Сферическое тестирование в вакууме: Как есть, как должно быть, как будет
  • Тестирование документации к программным продуктам

Тестирование: QC И QA

Цель тестирования (test objective, test target) или цель разработки и выполнения тестов:
  • обеспечить очищение ПО от ошибок до приемлимого уровня (вы не можете предоставить 100% покрытие, но вы должны сделать все возможное, и гарантировать, что очевидные ошибки исправлены);
  • убедиться, что ПО отвечает оригинальным требованиям и спецификации;
  • обеспечить уверенность в надёжности ПО (пользователям, заказчикам и т.д.).

Задача 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.

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

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

1. Тест-анализ

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

В общем и целом, необходимо выявить:

Определяем тестовое покрытие (скоуп/объём тестирования)

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

Матрица трассируемости требований (Requirement Traceability Matrix ) = двумерная таблица, содержащая соответствие требований (user/business requirements, software requirements) и подготовленных (test cases).
Основное её предназначение в отображении степени покрытия требований .

Примеры Матриц Трассировки:

(скачать в формате XLSX)

В соответствии с лучшими практиками, Бизнес-Требования следует максимально декомпозировать и нумеровать в соответствии со следующим правилом: BR001, BR002 и т.д.
Для каждого Бизнес-Требования будет одно или несколько Функциональных Требований, которые должны соответствовать соглашению по нумерации для соответствующего бизнес-требования: FR001.01, FR001.02, FR001.03, FR002 и т.д. Функциональные требования также должны быть максимально декомпозированы.

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

Если вы используете таск трекер Jira, Zephyr by Jira для тестовой документации и систему управления требованиями Сonfluence, то все сущности синхронизируются и такая трассируемость позволяет:

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

Соотношение привязки Требования и может быть:

  • 1 к 1 (атомарное требование, которое покрывается одним тест-кейсом, данный тест-кейс покрывает только это требование);
  • 1 к n (требование, которое покрывается несколькими тест-кейсами, данные тест-кейсы покрывают только это требование);
    когда одно требование в матрице трассируемости покрывается несколькими тестами, это может говорить об избыточности тестирования. В таком случае надо проанализировать, насколько требование атомарно.
  • n к n (требование, которое покрывается несколькими тест-кейсами, данные тест-кейсы покрывают это и другие требования).

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

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

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

Риски тестирования

Основные риски тестирования:

  1. Проектные - связанные с коммуникациями участников команды, инфраструктурой:
    - изменение скоупа тестирования после проверки основных тест-кейсов
    ...
  2. Продуктовые - связанные только с тестируемым функционалом и тестовыми средам:
    - отсутствие тестовых зон с заданной конфигурацей (медленные БД, (не)обезличенные БД, отсутствие каких-то тестовых данных)
    - недопустимое время на ожидание подготовки тестовых зон со стороны Администраторов
    ...

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

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

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

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

2. Тест-план и оценка трудозатрат

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

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

Оценка трудозатрат (Effort Estimation)

  1. Что оцениваем:
    • Человеческие умения: знания и опыт членов команды. Сильно влияют на оценку.
    • Ресурсы: людские, технические, и т.д.
    • Время
    • Стоимость: бюджет.
  2. Кто может сделать оценку?
    • Тест-аналитик
    • Тестировщик
  3. Методы оценки трудозатрат:

Из собственного опыта: для учёта времени при планировании, полезно определиться и подсчитать - на что в общем случае уходит время тестировщика:

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

3. Тест дизайн и покрытие

Ресурсы

Суть

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

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

Техники тест дизайна

  • Эквивалентное Разделение (Equivalence Partitioning - EP). Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала - 0.
  • Анализ Граничных Значений (Boundary Value Analysis - BVA). Если взять пример выше, в качестве значений для позитивного тестирования выберем минимальную и максимальную границы (1 и 10), и значения больше и меньше границ (0 и 11). Анализ Граничный значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
  • Причина / Следствие (Cause/Effect - CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как "Имя", "Адрес", "Номер Телефона" а затем, нажать кнопку "Добавить" - эта "Причина". После нажатия кнопки "Добавить", система добавляет клиента в базу данных и показывает его номер на экране - это "Следствие".
  • Предугадывание ошибки (Error Guessing - EG). Это когда тест аналитик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы "предугадать" при каких входных условиях система может выдать ошибку. Например, спецификация говорит: "пользователь должен ввести код". Тест аналитик, будет думать: "Что, если я не введу код?", "Что, если я введу неправильный код? ", и так далее. Это и есть предугадывание ошибки.
  • Исчерпывающее тестирование (Exhaustive Testing - ET) - это крайний случай. В пределах этой техники вы должны проверить все возможные комбинации входных значений, и в принципе, это должно найти все проблемы. На практике применение этого метода не представляется возможным, из-за огромного количества входных значений.

Тестовый случай

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

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

Уровни тестирования

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

Модульное тестирование

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

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

Интеграционное тестирование

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

Системное тестирование

Системное тестирование (System testing ) = процесс тестирования системы в целом с целью проверки того, что она соответствует установленным Спецификациям к Требованиям к ПО (SRS) .
Удостовериться, что Система умеет принять какие-то данные от поставщиков, обработать их, передать данные потребителям, всё это в правильной последовательности и формате. Дальнейшая судьба данных нас не волнует. Главное - наша система работает правильно в правильном окружении.
При этом выявляются дефекты как: неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные варианты использования, отсутствующая или неверная функциональность, неудобство использования и т.д.
Для минимизации рисков, связанных с особенностями поведения в системы в той или иной среде, во время тестирования рекомендуется использовать окружение максимально приближенное к тому, на которое будет установлен продукт после выдачи.
Выполняется тестировщиками .

Приёмочное тестирование

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

Сквозное тестирование

Сквозное тестирование (End-To-End , E2E или Chain testing ) = проверять не только наше окружение, но и все взаимосвязанные системы, через которые проходят данные принимаемые или отправляемые нашей системой. А это, в свою очередь, означает, что мы должны будем совместить несколько таких "пирамид тестирования" между собой. E2E тестирование это не просто приёмка (пользовательское тестирование), которое будет выполнять заказчик, это выстраивание мостика, с учётом всех возможных ситуаций, по которому пойдёт заказчик и поведёт за собой в ногу пользователей.
Выполняется тестировщиками .
Для сквозных сценариев используются с большой долей вероятности уже ранее разработанные тесты для каждой из систем, входящей в цепочку (сценарий) Бизнес-процесса. Можно все полные тестовые наборы компании представить в виде разреженной матрицы, где по столбцам распределены тесты для каждой системы (для простоты -- системные), а по строкам - бизнес-процессы. То есть для тех или иных бизнес-процессов надо выбрать\создать тесты, покрывающие бизнес-процесс, установить взаимосвязи. Если покрытия нет - это повод восполнить пробелы в тестовой модели, либо удостовериться, что качество обеспечивается другими уровнями тестирования ( , , ревью кода и прогон его через анализаторы).

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

Виды тестирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удобство (User Friendliness):

  • управление и работа с системой организованы очевидным образом, нет необходимости в специальном обучении;
  • эстетичность расположения и внешнего вида содержимого, цветов, иконок;
  • наличие раздела справки;
Эффективность (Efficiency):
  • сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д.? (меньше -- лучше);
  • универсальность формата окон/страниц в приложении/веб-сайте;
Правильность (Accuracy):
  • нет грамматических, синтаксических ошибок, не выводятся устаревшие или неверные данные;
  • нет битых ссылок;

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

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

Объектом тестирования в большинстве случаев являются весьма вероятные эксплуатационные проблемы, такие как:

  • отказ электричества на машине-сервере;
  • отказ электричества на машине-клиенте;
  • незавершенные циклы обработки данных (прерывание работы фильтров данных, прерывание синхронизации);
  • объявление или внесение в массивы данных невозможных или ошибочных элементов;
  • отказ носителей данных.

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

  1. проверить для всех элементов GUI размеры, позицию и принятие букв и цифр. Например, во всех полях ввода возможно производить ввод
  2. удостовериться, что графический интерфейс позволяет полностью реализовать весь функционал приложения
  3. проверить верность отображения предупреждающий сообщений и сообщений об ошибках
  4. проверить читабельность шрифтов, используемых приложением, их выравнивание, цвет
  5. проверить отображение и расположение изображений
  6. проверить расположение элементов интерфейса при различных разрешениях экрана

Тестирование совместимости (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 и т.д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

К автоматизации тестирования (automation testing) существуют следующие основные подходы:

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

  • серия программных продуктов Selenium

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

  • Автоматизированное Функциональное Тестирование
  • Как стать автоматизатором тестирования?
  • AUTOMATION TESTING Tutorial: Process, Planning & Tools
  • https://gist.github.com/codedokode/a455bde7d0748c0a351a - Автоматизированное тестирование
  • Антипаттерны тестирования ПО (unit-тесты, интеграционные тесты)

Баг-репорт

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

Составлять следует стремиться так, чтобы по названию или краткому описанию бага (summary) разработчик понял в чём соль проблемы, а прочитав детальное описание бага (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: ("ДОПИНФО:")
Чтобы сделать хороший баг-репорт отличным - используйте любую возможность дополнить его, как то:

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

Пример баг-репорта

Метрики по обеспечению качества

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

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

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

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

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

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

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


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

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

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

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

Подбор тестировщиков

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

Самое главное для нанимаемого тестировщика:

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

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

Лучшие начинающие тестировщики делятся на следующие категории:

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

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

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

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

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

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

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

Андерклокинг - снижение частоты работы оборудования.

Баг (дефект) - недостаток компонента или системы, который может привести к отказу определенной функциональности.

Приоритет багов - важность той или иной ошибки в ПО:

  • Trivial — косметическая малозаметная проблема.
  • Minor — очевидная, незначительная проблема.
  • Major — значительная проблема.
  • Critical — проблема, нарушающая работу c ключевыми функциями ПО.
  • Blocker — проблема, нарушающая функционирование ПО.

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

Валидация - определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе.

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

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

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

  • Atlassian JIRA
  • Bugzilla
  • YouTrack
  • Redmine

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

Обеспечение качества (Quality Assurance, QA) - совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации программного обеспечения

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

Ошибка (англ.Error ) – действие, которое порождает неправильный результат.

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

Классификация по типу тестирования:
Мобильное тестирование — тестирование мобильных приложений.
Консольное тестирование — тестирование приложений предназначенных для консолей.
Web-тестирование (Браузерное тестирование) — тестирование браузерных приложений.

Классификация по запуску кода на исполнение:
Статическое тестирование (англ.Static testing ) - тестирование без запуска кода на исполнение.
Динамическое тестирование (англ. Dynamic testing ) - тестирование с запуском кода на исполнение.

Классификация по доступу к коду и архитектуре ПО:
Черный ящик (англ. Black box ) — тестировщику не известно как устроена тестируемая система.
Белый ящик (англ. White box ) — тестировщику известно все детали реализации тестируемой системы.
Серый ящик (англ. Grey box ) — тестировщику известно только некоторые особенности устройства тестируемой системы.

Классификация по степени автоматизации:
Ручное тестирование (англ. Manual testing ) — тестирование ПО будучи его пользователем.
Автоматизированное тестирование (англ. Automated testing ) — тестирование ПО при помощи специальных программ.

Классификация по принципу работы с приложением:
Позитивное тестирование (англ. Positive testing ) — тестирование ПО на то, как оно должно работать.
Негативное тестирование (англ. Negative testing ) — тестирование ПО на то, как оно не должно работать.

Классификация по уровню детализации приложения:
Интеграционное тестирование — тестирование взаимодействия и связей нескольких компонентов приложения.
Системное тестирование — это тестирование всего приложения от начала и до конца.
Модульное тестирование — тестирование на уровне отдельного функционального компонента приложения.

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

Failure - сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы.

UX (англ. User eXperience — опыт пользователя ) - ощущение, испытываемое пользователем во время использования цифрового продукта.

UI (англ. User Interface — пользовательский интерфейс ) - это инструмент, позволяющий осуществлять взаимодействие «пользователь - приложение».

Анализ граничных значений (англ. Boundary Value Analysis - BVA ). Анализ граничных значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

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

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

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

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

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

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

Причина / Следствие (англ. Cause/Effect - CE ). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие).

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

Серьезность (англ. Severity ) - это атрибут, характеризующий влияние дефекта на работоспособность приложения.

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

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

Альфа-тестирование (англ. Alpha testing ) - имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования.

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

Релиз-кандидат или RC (англ. Release candidate ), Пре-релиз, иногда «гамма-версия» - стадия-кандидат на то, чтобы стать стабильной.

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

Пост-релиз или Post-RTM (англ. Post-release to manufacturing ) - издание продукта, у которого есть несколько отличий от RTM и помечается как самая первая стадия разработки следующего продукта.

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

Тест-дизайн (англ. Test design ) - это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (тест кейсы).

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

Тестирование взаимодействия (англ. Interoperability Testing ) - это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами.

Тестирование сборки (англ. Build Verification Test ) - тестирование направленное на определение соответствия, выпущенной версии, критериям качества для начала тестирования.

Тестирование пользовательского интерфейса (англ. UI Testing ) - тестирование, выполняемое с целью определения, удобен ли некоторый искусственный объект (такой как веб-страница, пользовательский интерфейс или устройство) для его предполагаемого применения.

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

Чек-лист (англ. Check list ) - это документ, описывающий что должно быть протестировано.

Эквивалентное Разделение (англ. Equivalence Partitioning - EP ). Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала - 0.

Z-конфликт (англ. Z-fighting ) — наложение текстур друг на друга.

Оверклокинг (англ. Overclocking ) — процесс увеличения частоты (и напряжения) компонента компьютера сверх штатных режимов с целью увеличения скорости его работы.

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

В. Что такое динамическое тестирование?

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

В. Что такое GUI-тестирование (GUI Testing)?

О. Тестирование GUI (графического интерфейса пользователя): интерфейс программного обеспечения проверяется на предмет соответствия требованиям.

В. Что такое формальное тестирование?

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

В. Что такое тестирование на основе рисков?

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

В. Что такое раннее тестирование?

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

В. Что такое исчерпывающее тестирование?

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

В. Что такое скопление дефектов?

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

В. Что такое «парадокс пестицида»?

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

В. Что такое статическое тестирование?

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

В. Что такое позитивное тестирование?

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

В. Что такое негативное тестирование?

О. Тестирование негативных сценариев в ПО: высвечивает ли система ошибку, когда она должна это делать, или не должна.

В. Что такое сквозное тестирование (еnd-to-end)?

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

В. Что такое исследовательское тестирование?

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

В. Что такое «обезьянье тестирование» (Monkey Testing)?

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

В. Что такое нефункциональное тестирование?

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

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

О. Проверяется, насколько хорошо реализованы в приложении все условия безопасности.

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

В. Что такое нагрузочное тестирование?

О. Анализ функциональности и производительности приложения в разных условиях.

В. Что такое стресс -тестирование?

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

В. Что такое процесс?

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

В. Что такое конфигурационное управление?

О. Процесс поиска, организации и контроля изменений в разработке ПО. Или методология контроля и управления проектом разработки ПО.

О. Составление:

  • Тест-плана
  • Тест-сценариев
  • Тест-кейсов
  • Выполнение тест-кейсов
  • Проверка результатов
  • Составление отчетов о дефектах
  • Дефект-трекинг
  • Закрытие дефектов
  • Тестовый релиз

В. Как расшифровывается CMMI?

О. Capability Maturity Model Integration (Модель зрелости процессов разработки).

В. Что такое разбор программы?

О. Неформальный анализ исходного кода программы с целью выявить дефекты и верифицировать техники программирования.

О. Тестирование отдельных программ, модулей или элементов кода.

В. Что такое тестирование уровня интеграции?

О. Тестирование соответствующих программ, модулей (или) единиц кода.

В. Что такое тестирование на уровне системы?

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

В. Что такое альфа-тестирование?

О. Тестирование всей компьютерной системы перед этапом пользовательского тестирования (UAT).

В . Что такое UAT?

О. Тестирование компьютерной системы клиентом, чтобы проверить, соответствует ли система требованиям.

В. Что такое тестовый план?

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

В. Что такое сценарий тестирования?

О. Идентификация всех возможных зон тестирования.

В. Что такое ECP (Equivalence Class Partition)?

О. Метод генерации тест-кейсов.

В. Что такое дефект?

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

В. Что такое критичность?

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

В. Что такое приоритет?

О. Указывает на срочность устранения дефекта.

В. Что такое повторное тестирование?

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

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

В. Что такое тестирование восстановления?

О. Проверяется возможность системы справиться с некоторыми неожиданными ситуациями.

В. Что такое тестирование глобализации (Globalization Testing)?

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

В. Что такое тестирование локализации?

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

В. Что такое тестирование установки?

О. Проверяется возможность успешной установки ПО, в соответствии с документацией по установке.

В. Что такое тестирование удаления?

О. Проверка возможности удаления ПО.

В. Что такое тестирование на совместимость?

О. Проверяется совместимость приложения с другим программным и аппаратным обеспечением.

В. Что такое стратегия тестирования?

О. Это часть тест-плана, описывающая, как проводится тестирование и какие разновидности тестирования необходимо сделать.

В. Что такое тест-кейс?

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

В. Что такое тест-кейс для валидации бизнес-процессов?

О. Этот тест-кейс составляется для того, что проверить определенное условие или требование.

В. Как определяется хороший тест?

О. Тест-кейс, у которого высокий приоритет обнаружения дефектов.

В. Что такое тестирование по сценарию использования?

О. Такое тестирование определяет, было ли ПО разработано согласно случаю использования.

В. Что такое возраст дефекта?

О. Время между датой обнаружения и датой закрытия дефекта.

В. Что такое дефект Showstopper?

О. Дефект, который вынуждает остановить ход тестирования.

О. Это последний этап STLC. Руководство составляет отчеты по тестам, разъясняет статистику проекта, исходя из имеющихся данных.

В. Что такое Bucket Testing?

О. Bucket Testing, или A/B-тестирование. Чаще всего исследуется эффект разного дизайна, используется метрика для веб-сайтов. Две версии сайта запускаются на одной или нескольких веб-страницах, чтобы определить разницу в кликах.

В. Что такое критерии запуска и завершения тестирования?

О. Критерии запуска - процесс, который должен быть представлен в начале системы. Это может быть:

  • SRS – ПО
  • Случай использования
  • Тест-кейс
  • План тестирования

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

  • Отчет по тестированию
  • Метрики
  • Отчет по анализу теста

В. Что такое тестирование валюты?

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

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

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

В. Что такое тестирование интерфейса?

О. Тестирование интерфейса проверяет взаимодействие отдельных модулей. Чаще всего используется для тестирования пользовательского интерфейса приложений с GUI.

В. Что такое гамма-тестирование?

О. Гамма-тестирование проводится когда ПО уже готово к релизу, проверяется соответствие требованиям.

Недавно был на собеседовании на Middle QA на проект, который явно превышает мои возможности. Уделил много времени тому, чего не знал вообще и мало времени повторению простой теории, а зря.

Ниже основы основ для повторения перед собеседованием для Trainee and Junior: определение тестирования, качество , верификация / валидация , цели, этапы, тест план, пункты тест плана, тест дизайн, техники тест дизайна, traceability matrix , test case, чек-лист, дефект, error/deffect/failure , баг репорт, severity vs priority, уровни тестирования, виды / типы, подходы к интеграционному тестированию , принципы тестирования, статическое и динамическое тестирование, исследовательское / ad-hoc тестирование, требования, жизненный цикл бага, стадии разработки ПО, decision table, qa/qc/test engineer, диаграмма связей.

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

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

Качество программного обеспечения (Software Quality) - это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности.

Верификация (verification) - это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.
Валидация (validation) - это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе .
Также можно встретить иную интерпритацию:
Процесс оценки соответствия продукта явным требованиям (спецификациям) и есть верификация (verification), в то же время оценка соответствия продукта ожиданиям и требованиям пользователей - есть валидация (validation). Также часто можно встретить следующее определение этих понятий:
Validation - ’is this the right specification?’.
Verification - ’is the system correct to specification?’.

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

Этапы тестирования:
1. Анализ продукта
2. Работа с требованиями
3. Разработка стратегии тестирования
и планирование процедур контроля качества
4. Создание тестовой документации
5. Тестирование прототипа
6. Основное тестирование
7. Стабилизация
8. Эксплуатация

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

Основные пункты тест плана
В стандарте IEEE 829 перечислены пункты, из которых должен (пусть - может) состоять тест-план:
a) Test plan identifier;
b) Introduction;
c) Test items;
d) Features to be tested;
e) Features not to be tested;
f) Approach;
g) Item pass/fail criteria;
h) Suspension criteria and resumption requirements;
i) Test deliverables;
j) Testing tasks;
k) Environmental needs;
l) Responsibilities;
m) Staffing and training needs;
n) Schedule;
o) Risks and contingencies;
p) Approvals.

Тест дизайн – это этап процесса тестирования ПО, на котором проектируются и создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.
Роли, ответственные за тест дизайн:
Тест аналитик - определяет «ЧТО тестировать?»
Тест дизайнер - определяет «КАК тестировать?»

Техники тест дизайна

Эквивалентное Разделение (Equivalence Partitioning - EP) . Как пример, у вас есть диапазон допустимых значений от 1 до 10, вы должны выбрать одно верное значение внутри интервала, скажем, 5, и одно неверное значение вне интервала - 0.

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

Причина / Следствие (Cause/Effect - CE). Это, как правило, ввод комбинаций условий (причин), для получения ответа от системы (Следствие). Например, вы проверяете возможность добавлять клиента, используя определенную экранную форму. Для этого вам необходимо будет ввести несколько полей, таких как «Имя», «Адрес», «Номер Телефона» а затем, нажать кнопку «Добавить» - это «Причина». После нажатия кнопки «Добавить», система добавляет клиента в базу данных и показывает его номер на экране - это «Следствие».

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

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

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

Допустим, какое-то значений (налог) для человека рассчитывается на основании его пола, возраста и наличия детей - получаем три входных параметра, для каждого из которых для тестов выбираем каким-то образом значения. Например: пол - мужской или женский; возраст - до 25, от 25 до 60, более 60; наличие детей - да или нет. Для проверки правильности расчётов можно, конечно, перебрать все комбинации значений всех параметров:

№ пол возраст дети
1 мужчина до 25 детей нет
2 женщина до 25 детей нет
3 мужчина 25-60 детей нет
4 женщина 25-60 детей нет
5 мужчина старше 60 детей нет
6 женщина старше 60 детей нет
7 мужчина до 25 дети есть
8 женщина до 25 дети есть
9 мужчина 25-60 дети есть
10 женщина 25-60 дети есть
11 мужчина старше 60 дети есть
12 женщина старше 60 дети есть

А можно решить, что нам не нужны сочетания значений всех параметров со всеми, а мы хотим только убедиться, что мы проверим все уникальные пары значений параметров. Т.е., например, с точки зрения параметров пола и возраста мы хотим убедиться, что мы точно проверим мужчину до 25, мужчину между 25 и 60, мужчину после 60, а также женщину до 25, женщину между 25 и 60, ну и женщину после 60. И точно так же для всех остальных пар параметров. И таким образом, мы можем получить гораздо меньше наборов значений (в них есть все пары значений, правда некоторые дважды):

№ пол возраст дети
1 мужчина до 25 детей нет
2 женщина до 25 дети есть
3 мужчина 25-60 дети есть
4 женщина 25-60 детей нет
5 мужчина старше 60 детей нет
6 женщина старше 60 дети есть

Такой подход примерно и составляет суть техники pairwise testing - мы не проверяем все сочетания всех значений, но проверяем все пары значений.

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

Тестовый сценарий (Test Case) - это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Пример:
Action Expected Result Test Result
(passed/failed/blocked)
Open page «login» Login page is opened Passed

Каждый тест кейс должен иметь 3 части:
PreConditions Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
Test Case Description Список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям
PostConditions Список действий, переводящих систему в первоначальное состояние (состояние до проведения теста - initial state)
Виды Тестовых Сценариев:
Тест кейсы разделяются по ожидаемому результату на позитивные и негативные:
Позитивный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
Негативный тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора.

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

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

Error - ошибка пользователя, то есть он пытается использовать программу иным способом.
Пример - вводит буквы в поля, где требуется вводить цифры (возраст, количество товара и т.п.).
В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message), с красным крестиком которые.
Bug (defect) - ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так как планировалось и программа выходит из-под контроля. Например, когда никак не контроллируется ввод пользователя, в результате неверные данные вызывают краши или иные «радости» в работе программы. Либо внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
Failure - сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы. То есть, существуют такие дефекты, которые приводят к сбоям (A defect caused the failure) и существуют такие, которые не приводят. UI-дефекты например. Но аппаратный сбой, никак не связанный с software, тоже является failure.

Баг Репорт (Bug Report) - это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Шапка
Короткое описание (Summary) Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации.
Проект (Project) Название тестируемого проекта
Компонент приложения (Component) Название части или функции тестируемого продукта
Номер версии (Version) Версия на которой была найдена ошибка
Серьезность (Severity) Наиболее распространена пятиуровневая система градации серьезности дефекта:
S1 Блокирующий (Blocker)
S2 Критический (Critical)
S3 Значительный (Major)
S4 Незначительный (Minor)
S5 Тривиальный (Trivial)
Приоритет (Priority) Приоритет дефекта:
P1 Высокий (High)
P2 Средний (Medium)
P3 Низкий (Low)
Статус (Status) Статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle)

Автор (Author) Создатель баг репорта
Назначен на (Assigned To) Имя сотрудника, назначенного на решение проблемы
Окружение
ОС / Сервис Пак и т.д. / Браузера + версия /… Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования - имя и версия браузера и т.д.
…
Описание
Шаги воспроизведения (Steps to Reproduce) Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.
Фактический Результат (Result) Результат, полученный после прохождения шагов к воспроизведению
Ожидаемый результат (Expected Result) Ожидаемый правильный результат
Дополнения
Прикрепленный файл (Attachment) Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы

Severity vs Priority
Серьезность (Severity) - это атрибут, характеризующий влияние дефекта на работоспособность приложения.
Приоритет (Priority) - это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.
Severity выставляется тестировщиком
Priority – менеджером, тимлидом или заказчиком

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

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

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

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

S4 Незначительная (Minor)
Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.

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

Градация Приоритета дефекта (Priority)
P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта.
P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.

Уровни Тестирования

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

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

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

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

5. Приемочное тестирование (Acceptance Testing)
Формальный процесс тестирования, который проверяет соответствие системы требованиям и проводится с целью:
определения удовлетворяет ли система приемочным критериям;
вынесения решения заказчиком или другим уполномоченным лицом принимается приложение или нет.

Виды / типы тестирования

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

Функциональное тестирование (Functional testing)
Тестирование пользовательского интерфейса (GUI Testing)
Тестирование безопасности (Security and Access Control Testing)
Тестирование взаимодействия (Interoperability Testing)

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

Все виды тестирования производительности:
o нагрузочное тестирование (Performance and Load Testing)
o стрессовое тестирование (Stress Testing)
o тестирование стабильности или надежности (Stability / Reliability Testing)
o объемное тестирование (Volume Testing)
Тестирование установки (Installation testing)
Тестирование удобства пользования (Usability Testing)
Тестирование на отказ и восстановление (Failover and Recovery Testing)
Конфигурационное тестирование (Configuration Testing)

Связанные с изменениями виды тестирования

Дымовое тестирование (Smoke Testing)
Регрессионное тестирование (Regression Testing)
Повторное тестирование (Re-testing)
Тестирование сборки (Build Verification Test)
Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

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

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

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

Тестирование взаимодействия (Interoperability Testing) – это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование

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

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

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

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

Тестирование установки направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения.

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

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

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

Дымовое (Smoke) тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции.

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

Повторное тестирование - тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.
В чем разница между regression testing и re-testing?
Re-testing - проверяется исправление багов
Regression testing - проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвало новых багов.

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

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

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

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

Принцип 1 – Тестирование демонстрирует наличие дефектов (Testing shows presence of defects)
Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет. Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но, даже если дефекты не были обнаружены, это не доказывает его корректности.

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

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

Принцип 4 – Скопление дефектов (Defects clustering)
Усилия тестирования должны быть сосредоточены пропорционально ожидаемой, а позже реальной плотности дефектов по модулям. Как правило, большая часть дефектов, обнаруженных при тестировании или повлекших за собой основное количество сбоев системы, содержится в небольшом количестве модулей.

Принцип 5 – Парадокс пестицида (Pesticide paradox)
Если одни и те же тесты будут прогоняться много раз, в конечном счете этот набор тестовых сценариев больше не будет находить новых дефектов. Чтобы преодолеть этот “парадокс пестицида”, тестовые сценарии должны регулярно рецензироваться и корректироваться, новые тесты должны быть разносторонними, чтобы охватить все компоненты программного обеспечения,
или системы, и найти как можно больше дефектов.

Принцип 6 – Тестирование зависит от контекста (Testing is concept depending)
Тестирование выполняется по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем сайт электронной коммерции.
Принцип 7 – Заблуждение об отсутствии ошибок (Absence-of-errors fallacy)
Обнаружение и исправление дефектов не помогут, если созданная система не подходит пользователю и не удовлетворяет его ожиданиям и потребностям.

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

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

Разница между ad hoc и exploratory testing в том, что теоретически, ad hoc может провести кто угодно, а для проведения exploratory необходимо мастерство и владение определенными техниками. Обратите внимание, что определенные техники это не только техники тестирования.

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

Требования к требованиям:
Корректность
Недвусмысленность
Полнота набора требований
Непротиворечивость набора требований
Проверяемость (тестопригодность)
Трассируемость
Понимаемость

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

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

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

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

Жизненный цикл разработки ПО:
Пре-альфа
Альфа
Бета
Релиз-кандидат
Релиз
Пост-релиз

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

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

Для этого они используют такой метод, как тестирование.

А знаете ли Вы, что впервые своеобразное тестирование проводилось еще в древности . А древнегреческий ученый Пифагор придумывал такие задачи, которые бы давали возможность увидеть: глуп ученик или умён. Он утверждал, что «не из каждого дерева можно выточить Меркурия».

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

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

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

Второй шаг – провести тестирование:

  1. Раздайте тесты с вопросами и заданиями, бланки для ответов.
  2. Объясните, с какой целью вы будете проводить тестирование.
  3. Зачитайте инструкцию или дайте отпечатанный текст.
  4. Тесты должны состоять из 20-25 заданий .
  5. Уточните, что на каждое задание даётся по одной минуте . По истечении времени тестирование сразу прекращается.
  6. Если человек не понимает, приведите пример выполнения подобных заданий.
  7. Отвечайте на вопросы кандидатов .
  8. Принятие ответов и их проверка. С результатами обработки можно ознакомить кандидата, но это необязательно.

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

Другие тесты при приеме на работу с ответами можно найти в сети Интернет.

Виды

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

Давайте подробно остановимся на каждом из них.

Профессиональные

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

составляют вопросы и несколько вариантов ответов: да, нет, в некоторых случаях.

При этом дается интерпретация ответов.

По таким объяснениям можно сразу увидеть ответ.

А с помощью готовых ключей к тесту определить количество правильных ответов и вынести своё решение.

Работодатель может предложить пройти тест для соискателей на знание некоторых приёмов работы excel(эксель).

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

Личностные или психологические

Интеллектуальные

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

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

Для правильного подбора заданий подойдет книга английского психолога Г. Айзенка .

Можно воспользоваться тестом Амтхауэра . Он определяет уровень умственных способностей по девяти критериям.

По результатам можно точно установить математического склада ума кандидат или гуманитарий и даже определить, к какой из 49 профессий подходит.

Онлайн тестирование на уровень интеллекта можно пройти .

Математические

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

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

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

Пройти онлайн тест по математике можно .

Логические

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

Логические тесты на работу первый взгляд абсурдны. В одной из задач сказано, что некоторые улитки — горы. Горы обожают кошек. Значит, все улитки обожают кошек.

Главное для тестируемого сосредоточиться, построить логическую цепочку , объяснить её, не обращая внимания на улиток и кошек. Специалист должен понять: умеет ли будущий работник логически рассуждать и нестандартно мыслить.

Тест на логику можно пройти онлайн .

Вербальные

Вербальные тесты полезны для проверки на должности преподавателей, переводчиков или секретарей .

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

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

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

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

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

Пройти вербальный тест онлайн можно .

На обучаемость

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

По механике

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

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

Онлайн тестирование по механике предложено .

На Полиграфе

Крупные компании при приеме на работу пользуются мобильным аппаратным комплексом .

Может ли работодатель применить детектор лжи ?

Закон не запрещает.

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

В чём заключается процесс тестирования? Вопросы трёх видов: настраивающие, коррекционные и фактические .

Если ответы на последние два честны, физиологические параметры человека одинаковы. Они трансформируются, если человек говорит неправду. Это фиксируется аппаратом.

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

Ответы дают безошибочное суждение о кандидате . По окончании проверки работодатель решает: будет кандидат работать или нет.

«Продайте ручку»

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

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

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

Резюме

Так стоит ли стараться применять тесты при подборе персонала?

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

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

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

Похожие статьи