Theory

Question 1

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

Answer 1

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

Question 2

Качество программного обеспечения

Answer 2

Это степень, в которой ПО обладает требуемой комбинацией свойств.

Question 3

Разница Quality Assurance и Quality Control

Answer 3

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

Question 4

Модели разработки ПО

Answer 4

Водопадная
V-образная
Итерационная инкрементальная
Гибкая модель (Agile)

Question 5

Жизненный цикл разработки ПО

Answer 5

1. Идея
2. Сбор и анализ требований
3. Проектирование. Дизайн и архитектура
4. Разработка
5. Тестирование
6. Внедрение и сопровождение
7. Вывод из эксплуатации

Question 6

Жизненный цикл тестирования

Answer 6

1. Анализ требований
2. Уточнение критериев приемки
3. Уточнение стратегии тестирования
4. Разработка тест-кейсов
5. Выполнение тест-кейсов
6. Фиксация найденных багов
7. Отчет с результатами тестирования

Question 7

Тест план

Answer 7

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

Question 8

Разделы тест-плана

Answer 8

1. Цель (purpose)
2. Области, подвергаемые тестированию (features to be tested)
3. Области, не подвергаемые тестированию (features not to be tested)
4. Тестовая стратегия (test strategy) и подходы (test approach)
5. Критерии (criteria)
6. Приемочные критерии, критерии качества (acceptance criteria)
   a. Критерии начала тестирования (entry criteria)
   b. Критерии приостановки тестирования (suspension criteria)
   c. Критерии возобновления тестирования (resumption criteria)
   d. Критерии завершения тестирования (exit criteria)
7. Ресурсы (resources) (необходимое ПО, аппаратные ресурсы, человеческие ресурсы, временные ресурсы, финансовые ресурсы)
8. Расписание (test schedule)
9. Роли и ответственность (roles and responsibility)
10. Оценка рисков (risk evaluation)
11. Документация (documentation)
12. Метрики (metrics)

Question 9

Тестовая документация

Answer 9

• Тест-план
• Чек-лист
• Тест кейс
• Тест репорт
• Requirement Traceability Matrix

Question 10

Требование

Answer 10

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

Question 11

Свойства качественных требований

Answer 11

• Завершённость (completeness)
• Корректность (correctness)
• Непротиворечивость (consistency)
• Недвусмысленность (ambiguousness)
• Проверяемость (verifiability)

Question 12

Как анализировать требования?

Answer 12

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

Question 13

Чек-лист

Answer 13

Список, содержащий ряд необходимых проверок во время тестирования программного продукта

Question 14

Тест-кейс

Answer 14

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

Question 15

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

Answer 15

1. Тестирование показывает наличие дефектов.
2. Исчерпывающее тестирование невозможно.
3. Раннее тестирование.
4. Скопление дефектов.
5. Парадокс пестицида.
6. Тестирование зависит от контекста.
7. Заблуждение об отсутствии ошибок.

Question 16

Верификация и Валидация

Answer 16

Процесс верификации. Это статическая практика проверки документов, дизайна, архитектуры, кода и так далее. Это значит, что
процесс верификации проходит без запуска кода. Верификация всегда отвечает на вопрос “делаем ли мы
продукт правильно?”. Эта проверка связана с тем, что мы убеждаемся в том, что система хорошо
спроектирована и безошибочно. Верификация всегда происходит ДО валидации.
Процесс валидации - это процесс оценки конечного продукта, когда необходимо проверить:
соответствует ли программное обеспечение ожиданиям и требованиям клиента. Это динамический процесс, в
отличии от верификации. Этот процесс всегда включает в себя запуск кода программы и отвечает на вопрос
“делаем ли мы правильный продукт?”. Процесс валидации всегда происходит ПОСЛЕ верификации, поэтому на
этапе валидации можно уловить ошибки, которые процесс верификации не позволил нам найти.

Question 17

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

Answer 17

• Unit тестирование (компонентное, модульное)
• Интеграционное тестирование
• Системное тестирование
• Приёмочное тестирование

Question 18

Разновидности интеграционного тестирования

Answer 18

1. Тестирование интеграции компонентов, т.е. как отдельные модули одного приложения
   взаимодействуют между собой.
2. Системное интеграционное тестирование, под которым понимают тестирование
   взаимодействия между всеми компонентами системы, либо взаимодействия разных систем
   между собой, либо тестирование интерфейсов с помощью которых взаимодействуют системы.
   Именно об интерфейсах я хочу поговорить более подробно. Существует три вида интерфейсов:
   ● Интерфейс программирования приложений, либо API. Этот набор методов можно
   использовать для доступа к функциональности другой программы. Например, API используется
   для того, чтобы наладить какую-то платежную систему для того или иного ресурса. Например,
   интернет-магазин, для него разработчик налаживает интеграцию с системой посредством
   данного интерфейса. Ему не нужно разрабатывать свою платежную систему, таких систем
   существует огромное количество. Самые известные из них это API взаимодействия с
   социальными сетями той же в Facebook или ВКонтакте.

● CLI (command line interface), интерфейс командной строки, там, где инструкция компьютеру
даётся путем ввода с клавиатуры текстовых строк, по-простому - это обычная командная строка
в системе Windows.
● GUI (graphical User Interface). В нём программные функции предоставляются графическими
элементами экрана. Например, это то, что мы видим в окне браузера, когда открываем страницу
в интернете.

Question 19

Альфа-тестирование / Бета-тестирование

Answer 19

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

Question 20

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

Answer 20

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

Question 21

Классификация тестирования по степени важности тестируемых функций

Answer 21

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

Question 22

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

Answer 22

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

Question 23

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

Answer 23

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

Question 24

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

Answer 24

Тестирование черного ящика (black box)
White box testing (тестирование белого ящика)
Gray box test (серый ящик)

Question 25

Функциональное / Нефункциональное тестирование

Answer 25

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

Question 26

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

Answer 26

1. Тестирование на отказ и восстановление 2. Тестирование производительности. 3. Тестирование удобства использования 4. Тестирование безопасности 5. Тестирование установки 6. Конфигурационное тестирование 7. Тестирование локализации (l10n) 8. Тестирование интернационализации (i18n) 9. Тестирование GUI (графического интерфейса)

Question 27

Виды тестирования производительности

Answer 27

1. Нагрузочное 2. Стресс-тестирование 3. Стабильности 4. Объемное тестирование

Question 28

Виды конфигурационного тестирования

Answer 28

1. Кроссплатформенное - значит, что мы тестируем наш продукта на различных типах и версиях оперативных систем. Например, мобилки – android, либо ios. 2. Кроссбраузерное тестирование - мы используем наше приложение на различных браузерах. Chrome, Mozilla, Opera.

Question 29

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

Answer 29

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

Question 30

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

Answer 30

Статическое | Динамическое

Question 31

Что должно быть в хорошем чек-листе?

Answer 31

● Версия нашей сборки (Build, билд). Окружение (Environment, инвайранмент), на котором проводилось тестирование. ● Дата проведения нашего теста. ● Тестировщик, который проводил данное тестирование. ● Тип тестов, который был использован для тех или иных проверок. ● Название самих проверок. ● Результат нашего тестирования, т.е. прошла эта проверка или нет.

Question 32

Тест-suite

Answer 32

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

Question 33

Атрибуты тест-кейса

Answer 33

``` ● Идентификатор ● Приоритет ● Ссылка на требования с которыми связан наш тест-кейс ● Название модуля ● Заглавие, в котором будет отражаться основная суть нашего тест-кейса ● Шаги по воспроизведению тест-кейса ● Ожидаемый результат ● Фактический результат ● Дефект ```

Question 34

Test design

Answer 34

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

Question 35

Класс эквивалентности и правила эквивалентного разбиения

Answer 35

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

Question 36

Правила анализа граничных значений

Answer 36

Первое правило - определение классов эквивалентности. Второе правило - определение границ этих диапазонов. Третье правило - проведение трёх тестов: для границ на самой границе, на значение выше этой границы и на значение меньше этой границы.

Question 37

Что такое баг (дефект)?

Answer 37

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

Question 38

Атрибуты баг-репорта

Answer 38

- Описание - Шаги по воспроизведению - Компонент, в котором непосредственно был обнаружен данный дефект. - Версия билда - Серьезность (severity) - Приоритет (priority) - Статус - Автор - Назначение - Окружение - Прикрепленные файлы

Question 39

Классификация Severity

Answer 39

● Blocker - такой тип ошибки, который приводит нашу программу в нерабочее состояние. Если мы обнаруживаем такой дефект, то дальнейшие работы с программой или её функциями попросту невозможны. ● Critical - это критические дефекты. Они приводят наш ключевой функционал в нерабочее состояние. Также это могут быть существенные отклонения от бизнес-логики нашего приложения, либо же какая-то неправильная реализация требуемых функций. Возможна потеря пользовательских данных, в отличие от blocker, наше приложение не приходит в абсолютно нерабочее состояние, и в принципе другие функции могут работать нормально, поэтому есть такая градация, как critical. ● Major (мажорные) - это какие-то серьёзные ошибки, которые свидетельствуют об отклонении от бизнес логики или нарушающие работу программы, но в то же время они не имеют физическое воздействие на наше приложение, возможно есть некоторый обходной путь, либо его еще могут называть workaround. ● Minor (минорные) - это какой-то незначительный дефект, не нарушающий функционал нашего приложения, но который является несоответствием ожидаемого результата. Например, это может быть ошибка нашего дизайна. ● Trivial - какие-то тривиальные баги, которые не имеют влияния на функционал или работу нашей программы, но который может быть обнаружен визуально.

Question 40

Классификация Priority

Answer 40

● High - от каких дефектов будут избавляться в первую очередь. Т.е. этот баг должен быть исправлен как можно быстрее, так как он критически влияет на работоспособность нашей программы. ● Medium - этот дефект также должен быть обязательно исправлен, но он не оказывает какое-то критическое воздействие на работу приложения. ● Low - ошибка также должна быть исправлена, но она не имеет критического влияния на программу и устранение может быть отложено на какой-то более длительный срок, в зависимости от наличия других дефектов.

Question 41

Виды окружения

Answer 41

● DEV окружение - обычно работают разработчики, т.е. они туда заливают какие-то фичи, возможно также подключаются тестировщики к тестированию каких-то отдельных фич на DEV окружении, и также могут заводить дефекты. Если мы обнаруживаем такие дефекты на этом окружении, мы прописываем в этом поле DEV. ● STAGE окружение - на него попадает уже какая-то стабильная версия нашего приложения, на нем чаще всего работают тестировщики и именно на stage доводят это приложение до определенного предрелизного состояния. ● PROD окружение - если на stage не остаётся дефектов, то такое приложение переводится на стадию прод, где у нас работают наши конечные пользователи.

Question 42

Правил названия бага

Answer 42

В заголовке ответить на три вопроса: ГДЕ? ЧТО? КОГДА? Где? - это может быть название вашего модуля, в котором вы обнаружили ваш баг. Что? - это непосредственно что происходит, когда вы обнаруживаете ваш баг, т.е. то, к чему привёл дефект. Когда? - при каких условиях это происходит. Например: «login page: The button ‘Sign In’ is displaced after clicking on the page»

Question 43

Жизненный цикл дефекта

Answer 43

* Обнаружен (submitted) (иногда называется «Новый» (new)) * Назначен (assigned) * Исправлен (fixed) * Проверен (verified) * Закрыт (closed) * Открыт заново (reopened) * Рекомендован к отклонению (to be declined) * Отклонён (declined) * Отложен (deferred)

Question 44

&

Answer 44

Амперсанд / Ampersand