1. Что такое тестирование?
Проверка соответствия между реальным поведением программы и ее ожидаемым поведением на конечном наборе тестов, выбранном определенным образом.
2. Цели тестирования.
· Обнаружение дефектов
· Повышение уверенности в уровне качества
· Предоставление информации для принятия решений
· Предотвращение дефектов
3. QA, QC, Testing.
Обеспечение качества (quality assurance) - часть менеджмента качества, направленная на создание уверенности, что требования к качеству будут выполнены.
Управление качеством (quality control) - часть менеджмента качества, направленная на выполнение требований к качеству.
Тестирование (testing) - Процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для заявленных целей и определения дефектов.
4. Основные виды тестирования.
· Функциональное тестирование
· Нефункциональное тестирование
· Тестирование структуры/архитектуры программного обеспечения (Структурное тестирование)
· Тестирование изменений: подтверждающее и регрессионное тестирование.
5. Load and performance testing различия.
Нагрузочное тестирование (load testing) - вид тестирования производительности, проводимый с целью оценить поведение компонента или системы под увеличивающейся нагрузкой (число одновременно работающих пользователей и/или число транзакций) для определения максимального уровня нагрузки компонента или системы.)
Тестирование производительности (performance testing): Процесс тестирования с целью определить производительность программного продукта.
6. Не функциональные виды тестирования.
· Нефункциональное тестирование - включает, но не ограничивается, нагрузочное тестирование, тестирование производительности, стресс-тестирование, тестирование удобства использования, тестирование восстановления, тестирование надежности и тестирование переносимости. Это тестирование того, “как” система работает.
· Тестирование структуры/архитектуры программного обеспечения (Структурное тестирование)
· Тестирование изменений: подтверждающее и регрессионное тестирование.
7. Тестирование инсталляции.
Тестирование установки (installation testing) - Проверяет работоспособность методов установки программы на всех поддерживаемых платформах.
8. Тестирование документации основные принципы.
Проверка точности пользовательской документации (documentation testing) - Проверяет точность всей пользовательской документации.
Системное тестирование включает проверку точности пользовательской документации. Для этого с помощью документации проверяют способ представления описанных ранее системных тестов. Например, если запланирован некий нагрузочный тест, то следует использовать документацию для подбора конкретных вариантов. Кроме того, путем непосредственной инспекции (в духе инспекции кода) необходимо проверить точность и ясность изложения пользовательской документации. Любые процедуры, фигурирующие в документации, должны кодироваться и пропускаться через программу.
9. Основные принципы Usability testing.
Оптимально, когда удобство использования тестируют конечные пользователи, а не тестировщики. Задача тестировщика может состоять в подготовке набора практических значений, связанных с реальной деятельностью, повторяющихся тестовых заданий, которые должен будет выполнить каждый пользователь. Проектируйте эти тестовые сценарии так, чтобы в процессе их выполнения пользователь столкнулся со всеми аспектами программного обеспечения, знакомясь с ними в каком-то определенном или случайном порядке.
Важную роль играет сбор и анализ подробных, точных данных. Реальным началом процесса сбора данных является разработка детальных пользовательских инструкций и списка задач. Заканчивается же этот процесс сведением в воедино результатов наблюдений, сделанных пользователями, или ответов пользователей на анкеты после проведения тестов.
Наконец, результаты тестирования должны быть правильно интерпретированы, и на основе полученных выводов разработчики должны внести в ПО соответствующие изменения.
10. Артефакты тестирования.
В соответствие с процессами или методологиями разработки ПО, во время проведения тестирования создается и используется определенное количество тестовых артефактов (документы, модели и т.д.). Наиболее распространенными тестовыми артефактами являются:
План тестирования (Test Plan) - это документ описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Набор тест кейсов и тестов (Test Case & Test suite) - это последовательность действий, по которой можно проверить соответствует ли тестируемая функция установленным требованиям.
Дефекты / Баг Репорты (Bug Reports / Defects)- это документы, описывающие ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Чек-лист - это документ, описывающий что должно быть протестировано. При этом чек-лист может быть абсолютно разного уровня детализации. На сколько детальным будет чек-лист зависит от требований к отчётности, уровня знания продукта сотрудниками и сложности продукта.
Чек-лист нужен для
· Не забыть требуемые тесты
· Для деления задач по уровню квалификации
· Для сохранения отчётности и результатов тестирования
Что должно быть в Чек-Листе:
· Список проверок (с требуемой степенью детализации)
· Статус проверок:
сборка, на которой проводилось тестирование
тестовое окружение (если применимо)
тестировщик
· Результат проверки
11. Гибкая методология разработки (Agile).
Это итеративный подход к управлению проектами и разработке ПО. Разработка сводится к серии коротких циклов (итераций) по 2-3 недели. После каждой итерации продукт готов к выпуску. И также после каждого цикла пересматриваются требования на актуальность. Примеры: SCRUM, Kanban.
12. Tracebility matrix, а нарисуйте
Матрица соответствия требований - это двумерная таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк - тестовые сценарии. На пересечении - отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки.
Матрица соответствия требований используется QA-инженерами для валидации покрытия продукта тестами. МСТ является неотъемлемой частью тест-плана.
https://disk.yandex.ru/i/Y1dx7fqBGe8OzQ
13. Основные поля test case.
Тестовый сценарий (test case) - Набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнения определенного пути программы или же для проверки соответствия определенному требованию.
14. Жизненный цикл бага
Блок-схема, показывающая основные статусы и возможные переходы от статуса к статусу в процессе его существования:
https://disk.yandex.ru/i/d0YkOGH8wDxFuw
15. Bug report, Основные поля bug report.
Отчет о дефекте (defect report): Документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию.
16. Приоритет и Серьезность
Серьезность (Severity) - это атрибут, характеризующий влияние дефекта на работоспособность приложения.
Приоритет (Priority) - это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.
Градация Серьезности дефекта (Severity)
S1 Блокирующая (Blocker)
Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы.
S2 Критическая (Critical)
Критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой.
S3 Значительная (Major)
Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.
S4 Незначительная (Minor)
Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
S5 Тривиальная (Trivial)
Градация Приоритета дефекта (Priority)
P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к.ее наличие является критической для проекта.
P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.
Порядок исправления ошибок по их приоритетам:
High -> Medium -> Low
17. Назовите баг с высшим приоритетом и низкой серьезностью и наоборот
Например, если на главной странице вместо "Сделать Яндекс стартовой страницей" была бы надпись с орфографической ошибкой: "Сделать Япдекс стартовой страницей" (высший приоритет - низкая серьёзность)
Например, ошибка на уровне архитектуры, исправление которой на текущий момент дороже, чем существование с ней (низкий приоритет - высокая серьезность)
18. Use case отличие от test case
Сценарий использования системы (use case): Последовательность операций во взаимодействии актера и компонента или системы со значимым результатом, при которой актером может быть как пользователь, так и все, что может обмениваться информацией с системой.
Тестовый сценарий (test case): Набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнения определенного пути программы или же для проверки соответствия определенному требованию.
19. Верификация и валидация.
Верификация (verification): Подтверждение посредством представления объективных свидетельств того, что установленные требования были выполнены.
Примечания
1. Термин “верифицирован” используют для обозначения соответствующего статуса.
2. Деятельность по подтверждения требования может включать в себя:
· Осуществления альтернативных расчетов;
· Сравнение спецификации на новый проект с аналогичной документацией н апробированный проект;
· Проведение испытаний и демонстраций;
· Анализ документов до их выпуска.
Валидация (validation): Подтверждение посредством представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены.
Примечания
1. Термин “валидация” используют для обозначения соответствующего статуса.
2. Условия применения могут быть реальными или смоделированными.
20. Граничные условия, классы эквивалентности.
Граничное значение (boundary value): Входное значение или выходные данные, которое находится на грани эквивалентной области или на наименьшем расстоянии от обеих сторон грани, например, минимальное или максимальное значение области.
Эквивалентная область (equivalence partition): Часть области входных или выходных данных, для которой поведение компонента или системы, основываясь на спецификации, считается одинаковым.
21. Различие между тестированием desktop and web.
Одно из мнений:
Веб-тестирование затрагивает ряд вопросов, которые обычно не возникают при традиционном тестировании десктоп приложений. Примерами специализированного веб-тестирования могут служить такие вещи как: тестирование совместимости браузера, тестирование Web доступности, проверка на «мертвые» ссылки, а также отслеживание сообщений между клиентом и сервером.
...
Проблемы производительности и безопасности в веб-приложенях будут иными, нежели в десктоп приложениях. Существуют различия в клиентской базе, в том, как развернуто приложение, и как часто оно используется. А также отличаются сервисная модель и обслуживание веб-приложений.
22. SCRUM.
Одна из гибких методологий. Основные артефакты: Product Backlog, Sprint Backlog, Sprint Goal, Sprint Burndown Chart.
23. Отличие Sanity от Smoke.
Тест работоспособности (sanity test): См. тест "на дым".
Тест "на дым" (smoke test): Выборка из общего числа запланированных тестовых сценариев, покрывающая основную функциональность компонента или системы. Проводится с целью удостовериться, что базовые функции программы в целом работают корректно, без углубления в детали. Ежедневная сборка и тест "на дым" являются передовыми практическими методами. См.
входной тест.
23. Отличие Sanity от Smoke.
Тест работоспособности (sanity test): См. тест "на дым".
Тест "на дым" (smoke test): Выборка из общего числа запланированных тестовых сценариев, покрывающая основную функциональность компонента или системы. Проводится с целью удостовериться, что базовые функции программы в целом работают корректно, без углубления в детали. Ежедневная сборка и тест "на дым" являются передовыми практическими методами. См.
входной тест.
24. Разработка Agile and Waterfall
Agile — это группа методик для гибкого управления проектами в команде разработки. Рабочий процесс при таком подходе разбивается на небольшие временные промежутки, их еще называют спринтами (от английского sprint — бег на короткую дистанцию) или итерациями. Во время каждого спринта команда разработки создает часть продукта, которую можно протестировать и оценить.
Waterfall — модель «Водопад», водопадная или каскадная разработка продуктов. Она подобно потоку воды направляет команды решать задачи последовательно и строго по изначальному плану.
25. Какая система разработки используется на проекте сейчас.
Итеративая разработка. Какая система разработки используется у вас - вам лучше знать
26. Какие роли на проекте занимает Junior,Middle,Senior.
Автор: Сергей Марков. Читать.
27. Различие между error, bug, failure.
Ошибка (error): Действие человека, которое приводит к неправильному результату. [IEEE 610]
Помеха (bug): См. дефект.
Дефект (defect): Изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию, например неверный оператор или определение данных. Дефект, обнаруженный во время выполнения, может привести к отказам компонента или системы.
Отказ (failure): Отклонение компонента или системы от ожидаемого выполнения, эксплуатации или результата.
