Версия: 0.9 (Жду ваших отзывов и комментариев)
Вопросы взяты отсюда.
Выложены ответы на все 27 вопросов.
Просьба отредактировать название темы на: "Вопросы на собеседовании для QA. Собеседование для тестировщиков."
Поскольку в данной ветке форума тема не совсем корректна (много вопросов более высокого уровня) - у меня вопрос - можно ли эту тему будет перенести в другую ветку форума, а эту закрыть?
Если да, то в какую ветку форума лучше перенести и кому по этому поводу лучше обратиться?
Планирую оформить теоретические вопросы в формате pdf , дополнив некоторые из-них (в частности п.24), и выложить сюда.
Также думаю добавить новые ответы на вопросы отсюда. Автор вопросов: Александр Селяев.
Теоретические вопросы на собеседовании по тестированию:
1. Что такое тестирование?
Проверка соответствия между реальным поведением программы и ее ожидаемым поведением на конечном наборе тестов, выбранном определенным образом.
[IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004]
2. Цели тестирования.
· Обнаружение дефектов
· Повышение уверенности в уровне качества
· Предоставление информации для принятия решений
· Предотвращение дефектов
[Сертифицированный тестировщик. Программа обучения Базового уровня. Версия 2011]
3. QA, QC, Testing.
Обеспечение качества (quality assurance) - часть менеджмента качества, направленная на создание уверенности, что требования к качеству будут выполнены.
Управление качеством (quality control) - часть менеджмента качества, направленная на выполнение требований к качеству.
Тестирование (testing) - Процесс, содержащий в себе все активности жизненного цикла, как динамические, так и статические, касающиеся планирования, подготовки и оценки программного продукта и связанных с этим результатов работ с целью определить, что они соответствуют описанным требованиям, показать, что они подходят для заявленных целей и определения дефектов.
[ГОСТ ISO 9000-2011; Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2).
Менеджмент качества (quality management) - скоординированная деятельность по руководству и управлению организацией, применительно к качеству.
Примечание - Руководство и управление применительно к качеству обычно включает в себя разработку политики в области качества и целей в области качества, планирование качества, управление качеством, обеспечения качества и улучшение качества. ]
4. Основные виды тестирования.
· Функциональное тестирование
· Нефункциональное тестирование
· Тестирование структуры/архитектуры программного обеспечения (Структурное тестирование)
· Тестирование изменений: подтверждающее и регрессионное тестирование.
[Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)]
Классификация видов Тестирования: по знанию внутренностей системы, по объекту тестирования, по субъекту тестирования, по времени проведения тестирования, по критерию "позитивности" сценариев, по степени изолированности тестируемых компонентов, по степени автоматизированности тестирования и по степени подготовки к тестированию.
[Тестирование Дот Ком, Савин]
Важное Дополнение: По каким атрибутам характеристик качества мы тестируем? (благодарю SALar за формулировку данного дополнения)
[В соответствии с ГОСТ Р ИСО/МЭК 9126-93 у ПО есть 6 характеристик качества: Функциональные возможности (Functionality), Надёжность (Reliability), Практичность (Usability), Эффективность (Efficiencies), Сопровождаемость (Maintainability) и Мобильность (Portability). У каждой характеристики есть атрибуты.]
5. Load and performance testing различия.
Нагрузочное тестирование (load testing) - вид тестирования производительности, проводимый с целью оценить поведение компонента или системы под увеличивающейся нагрузкой (число одновременно работающих пользователей и/или число транзакций) для определения максимального уровня нагрузки компонента или системы.)
Тестирование производительности (performance testing): Процесс тестирования с целью определить производительность программного продукта.
[Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)]
Load vs Performance Testing
Нам показалось, что Load и Performance Testing преследуют все же одну и ту же цель: проверка производительности (времени отклика) на разных нагрузках. Собственно поэтому мы и не стали разделять их. В то же время кто то может разделить. Главное все таки понимать цели того или иного вида тестирования и постараться их достигнуть.
(Автор: Андрей Широбоков. Ответ взят отсюда.)
Интересная статья о цели нагрузочного тестирования: Читать. Благодарю, SALar за ссылку.
6. Не функциональные виды тестирования.
· Нефункциональное тестирование - включает, но не ограничивается, нагрузочное тестирование, тестирование производительности, стресс-тестирование, тестирование удобства использования, тестирование восстановления, тестирование надежности и тестирование переносимости. Это тестирование того, “как” система работает.
· Тестирование структуры/архитектуры программного обеспечения (Структурное тестирование)
· Тестирование изменений: подтверждающее и регрессионное тестирование.
[Примечание: Регрессионное тестирование может выполняться на всех уровнях тестирования и включает функциональное, нефункциональное и структурное тестирование.]
[Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)]
7. Тестирование инсталляции.
Тестирование установки (installation testing) - Проверяет работоспособность методов установки программы на всех поддерживаемых платформах.
[Искусство тестирования программ, Гленфорд Майерс, 3 издание]
8. Тестирование документации основные принципы.
Проверка точности пользовательской документации (documentation testing) - Проверяет точность всей пользовательской документации.
Системное тестирование включает проверку точности пользовательской документации. Для этого с помощью документации проверяют способ представления описанных ранее системных тестов. Например, если запланирован некий нагрузочный тест, то следует использовать документацию для подбора конкретных вариантов. Кроме того, путем непосредственной инспекции (в духе инспекции кода) необходимо проверить точность и ясность изложения пользовательской документации. Любые процедуры, фигурирующие в документации, должны кодироваться и пропускаться через программу.
[Искусство тестирования программ, Гленфорд Майерс, 3 издание]
Читая и анализируя документацию, следует прежде всего уделить внимание её точности, полноте, ясности, простоте использования и тому, насколько она соответствует духу программного продукта.
[Тестирование программного обеспечения, Канер, Фолк, Нгуен, 2 издание]
9. Основные принципы Usability testing.
Оптимально, когда удобство использования тестируют конечные пользователи, а не тестировщики. Задача тестировщика может состоять в подготовке набора практических значений, связанных с реальной деятельностью, повторяющихся тестовых заданий, которые должен будет выполнить каждый пользователь. Проектируйте эти тестовые сценарии так, чтобы в процессе их выполнения пользователь столкнулся со всеми аспектами программного обеспечения, знакомясь с ними в каком-то определенном или случайном порядке.
Важную роль играет сбор и анализ подробных, точных данных. Реальным началом процесса сбора данных является разработка детальных пользовательских инструкций и списка задач. Заканчивается же этот процесс сведением в воедино результатов наблюдений, сделанных пользователями, или ответов пользователей на анкеты после проведения тестов.
Наконец, результаты тестирования должны быть правильно интерпретированы, и на основе полученных выводов разработчики должны внести в ПО соответствующие изменения.
[Искусство тестирования программ, Гленфорд Майерс, 3 издание]
10. Артефакты тестирования.
Основными понятиями RUP являются артефакт (artifact) и прецедент (precedent). Артефакты — это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным продуктом. Прецеденты — это последовательности действий, выполняемых системой для получения наблюдаемого результата.
(Автор: Сергей Трофимов. Ответ взят отсюда.)
2 вариант ответа на вопрос:
В соответствие с процессами или методологиями разработки ПО, во время проведения тестирования создается и используется определенное количество тестовых артефактов (документы, модели и т.д.). Наиболее распространенными тестовыми артефактами являются:
План тестирования (Test Plan) - это документ описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Набор тест кейсов и тестов (Test Case & Test suite) - это последовательность действий, по которой можно проверить соответствует ли тестируемая функция установленным требованиям.
Дефекты / Баг Репорты (Bug Reports / Defects) - это документы, описывающие ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Интересный факт: На Сайт «Про Тестинг» ссылается и "Учебно-методический комплекс по дисциплине «Тестирование программного обеспечения»" для студентов специальности «ПРИКЛАДНАЯ ИНФОРМАТИКА (В УПРАВЛЕНИИ)» - ИНСТИТУТ УПРАВЛЕНИЯ, БИЗНЕСА И ПРАВА.
11. Тест план и check-list.
План тестирования (Test Plan) - это документ описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
Чек-лист - это документ, описывающий что должно быть протестировано. При этом чек-лист может быть абсолютно разного уровня детализации. На сколько детальным будет чек-лист зависит от требований к отчётности, уровня знания продукта сотрудниками и сложности продукта.
Чек-лист нужен для
· Не забыть требуемые тесты
· Для деления задач по уровню квалификации
· Для сохранения отчётности и результатов тестирования
Что должно быть в Чек-Листе:
· Список проверок (с требуемой степенью детализации)
· Статус проверок:
сборка, на которой проводилось тестирование
тестовое окружение (если применимо)
тестировщик
· Результат проверки
12. Tracebility matrix, а нарисуйте
Блок-схема, показывающая основные статусы и возможные переходы от статуса к статусу в процессе его существования:
Описание данной схемы.
Допустим вы нашли баг и зарегистрировали его в баг трекинг системе. Согласно нашей блок-схеме он получит статус “Новый”. Тестировщик, ответственный за валидацию новых баг репортов, или координатор проекта (в зависимости от распределения ролей в вашей команде) может перевести его в один из следующих статусов:
· “Отклонен”, если данный баг невалидный или повторный, или же его просто не смогли воспроизвести
· “Отсрочен”, если данный баг не нужно исправлять в данной итерации
· “Открыт”, если исправление бага необходимо
Рассмотрим теперь по порядку каждый из вариантов.
1. Отклонен. В этом случае вы можете либо поспорить о судьбе вашего багрепорта, изменив статус на “Переоткрыт” либо закрыть его - статус “Закрыт”
2. Отсрочен. Баг репорт в статусе “Отсрочен” можно перевести в статус “Открыт”, когда потребуется исправление либо в статус “Закрыт”, если уже не потребуется.
3. Открыт. Именно в таком состоянии разработчик получает баг репорт для исправления. Он может отклонить (дальнейшие действия смотрите в пункте 1) или исправить баг. Баг репорт в статусе “Исправлен” переводится на тестировщика для проверки. В случае если проблема все еще воспроизводится, выставляется статус “Переоткрыт” и баг репорт направляется назад на доработку к разработчику. Если же исправление было успешным, то баг репорт переводится в статус “Закрыт”.
* * *
Хотим отметить, что данная схема сильно упрощена. Для большей наглядности и, возможно, удобства работы на проекте, вы можете добавить дополнительные статусы и переходы, тем более, что современные баг трекинговые системы позволяют это делать. Правда имейте ввиду, что излишне запутанные схемы переходов и лишние статусы могут значительно усложнить жизнь.
Примечание 1: в некоторых системах баг трекинга созданный баг репорт сразу получает статус “Открыт” без дополнительной валидации
Примечание 2: многие баг трекинговые системы позволяют переоткрывать закрытые баги, однако лично я против такой практики, поэтому и не описывал подобный переход в выше представленном жизненном цикле
Примечание 3: Рассмотренный выше жизненный цикл основан на том, что в команде есть кто-то, ответственный за назначение баг репортов. В случае, если такой роли на проекте нет, то баги назначаются разработчиками самостоятельно, и тогда во избежании путанницы, есть смысл ввести еще один промежуточный статус “В разработке” (In progress), показывающий, что данный баг репорт уже назначен и находится на стадии исправления.
[Сайт «Про Тестинг»]
15. Bug report, Основные поля bug report.
16. Приоритет и Серьезность
Серьезность (Severity) - это атрибут, характеризующий влияние дефекта на работоспособность приложения.
Приоритет (Priority) - это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект.
Градация Серьезности дефекта (Severity)
S1 Блокирующая (Blocker)
Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы.
S2 Критическая (Critical)
Критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой.
S3 Значительная (Major)
Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки.
S4 Незначительная (Minor)
Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса.
S5 Тривиальная (Trivial)
Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная посредством пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.
P1 Высокий (High)
Ошибка должна быть исправлена как можно быстрее, т.к.ее наличие является критической для проекта.
P2 Средний (Medium)
Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения.
P3 Низкий (Low)
Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения.
Порядок исправления ошибок по их приоритетам:
High -> Medium -> Low
17. Назовите баг с высшим приоритетом и низкой серьезностью и наоборот
Например, если на главной странице вместо "Сделать Яндекс стартовой страницей" была бы надпись с орфографической ошибкой: "Сделать Япдекс стартовой страницей" (высший приоритет - низкая серьёзность)
Например, ошибка на уровне архитектуры, исправление которой на текущий момент дороже, чем существование с ней (низкий приоритет - высокая серьезность)
18. Use case отличие от test case
Сценарий использования системы (use case): Последовательность операций во взаимодействии актера и компонента или системы со значимым результатом, при которой актером может быть как пользователь, так и все, что может обмениваться информацией с системой.
Верификация (verification): Подтверждение посредством представления объективных свидетельств того, что установленные требования были выполнены.
Примечания
1. Термин “верифицирован” используют для обозначения соответствующего статуса.
2. Деятельность по подтверждения требования может включать в себя:
· Осуществления альтернативных расчетов;
· Сравнение спецификации на новый проект с аналогичной документацией н апробированный проект;
· Проведение испытаний и демонстраций;
· Анализ документов до их выпуска.
Валидация (validation): Подтверждение посредством представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены.
Примечания
1. Термин “валидация” используют для обозначения соответствующего статуса.
2. Условия применения могут быть реальными или смоделированными.
[ГОСТ ISO 9000-2011.
Объективное свидетельство (objective evidence): Данные, подтверждающие наличие или истинность чего-либо.
Требование (requirement): Потребность или ожидание, которое установлено, обычно предполагается или является обязательным
Спецификация (specification): Документ, устанавливающий требования.
Испытание (test): Определение одной или нескольких характеристик согласно установленной процедуре.]
20. Граничные условия, классы эквивалентности.
Граничное значение (boundary value): Входное значение или выходные данные, которое находится на грани эквивалентной области или на наименьшем расстоянии от обеих сторон грани, например, минимальное или максимальное значение области.
В некоторых источниках ошибочно полагают, что санитарное и дымовое тестирование - это одно и тоже. Мы же полагаем, что эти виды тестирования имеют "вектора движения", направления в разные стороны. В отличии от дымового (Smoke testing), санитарное тестирование (Sanity testing) направлено вглубь проверяемой функции, в то время как дымовое направлено вширь, для покрытия тестами как можно большего функционала в кратчайшие сроки.
Какая система разработки используется у вас - вам лучше знать.Приоритет литературы: Стандарты (ГОСТ ISO 9000-2011 (аналог ISO 9000:2005) и IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004) > ISTQB (Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2) и Сертифицированный тестировщик. Программа обучения Базового уровня. Версия 2011.) > книги по тестированию (Искусство тестирования программ, Тестирование программного обеспечения, Тестирование Дот Ком) > ссылки (в случае ссылки указан источник).
