Q: Что такое регрессионное тестирование(Regression testing)?
A: Повторная проверка ПО после написания нового функционала или исправления бага (дефекта). Проводится, чтобы убедиться, что не появилось новых ошибок (ничего не было сломано), так как разработчик вносил изменения в код (либо разрабатывая новый функционал, либо исправляя существующие баги).
Q: Если Вы нашли баг, а разработчик говорит, что это “так задумано”, что Вы будете делать?
A: 1. Попытаюсь найти конкретное требование, в котором описан данный функционал, и подтвердить или опровергнуть слова разработчика. 2. Если в документации ничего об этом не сказано, но разработчик не хочет исправлять дефект, обращусь к руководителю/менеджеру группы тестирования.
Q: Из каких компонентов состоит баг-репорт? Какие поля Вы заполняете в баг-репорте?
A: 1. Номер репорта - уникальный(в рамках проекта) идентификационный номер 2. Тестируемое приложение\модуль 3. Версия\номер релиза 4. Резюме проблемы\короткое описание 5. Шаги для воспроизведения 6. Серьезность\важность(Severity) — Блокирующая(S1, Blocker), Критическая(S2, Critical), Значительная(S3, Major), Незначительная(S4, Minor), Тривиальная(S5, Trivial) 7. Приоритет(Priority) — Высокий(High), Средний(Medium), Низкий(Low) 8. Аппаратная и программная среда, на которой проводилось тестирование 9. Кто написал отчет\репорт (Reporter) 10. На кого назначен отчет\репорт (Assignee) 11. Статус — Открыт, В процессе выполнения, Решен и т.д.(Open, Pending, Fixed, Closed, Сannot reproduce, etc.) 12. Решения, принятые по отчету 13. Ключевые слова
A: 1. Название 2. Идентификационные данные программного продукта, включая версию\номер релиза\сборки 3. Историю ревизии тест-плана, включая авторов, даты создания\изменения, ответственных за согласование тест-плана 4. Содержание 5. Цели документа, целевую аудиторию(для кого пишется тест-план) 6. Объект тестирования 7. Обзор(краткое описание) тестируемого продукта 8. Соответствующий список документов, например, требования, проектные документы, другие тест-планы и т. д. 9. Соответствующие стандарты или юридические требования 10. Соответствующие соглашения об именах и условные обозначения 11. Общая организация проекта и персонал/контакт-информация/ответственность 12. Анализ рисков проекта 13. Приоритеты тестирования 14. Покрытие(объем) и ограничения тестирования 15. Используемые тестовые инструменты, включая версии, патчи и т. д. 16. Распределение обязанностей(тест-кейсов) по персоналу(тестерам) и т.д.
A: При планировании\разработке\дизайне тест-кейса: 1. Тест-кейс ID (уникальный номер\код) 2. Цели тест-кейса (название, описание и .д.) 3. Инструкции о том, как получить ожидаемый результат из текущего состояния системы\программного продукта 4. Ожидаемый результат
При выполнении тест-кейса добавляются еще две колонки: 5. Фактический результат 6. Отметка о том, пройден или провален тест-кейс
Q: Что такое “позитивное”(Positive) и “негативное”(Negative) тестирование?
A: 1. “Позитивное” тестирование направлено на выполнение тест-кейсов, при которых поведение пользователя не выходит за рамки “нормального” (нормальность как правило определяется юз-кейсами или здравым смыслом). Например — Открыли браузер, ввели логин\пароль, нажали кнопку, увидели окно Home. 2. “Негативное” тестирование направлено на то, чтобы проверить поведение продукта\системы(не зависает, а показывает информативную ошибку) при некорректных действиях пользователя. Например — Открыли браузер, ввели логин\пароль (но неверный логин\пароль, состоящий из запрещенный символов), нажали кнопку несколько раз, увидели окно Home.
ИТОГ: С помощью негативного тестирования находится наибольшее количество багов
Q: Что такое тестирование с помощью “черного\белого\серого” ящика?
A: 1. Тестирование “черного” ящика — методология, при которой тестер не имеет доступа к исходному коду (UI\UX тестирование, тестирование установки, тестирование локализации) 2. Тестирование “белого” ящика — методология, при которой тестер (чаще сам разработчик или тестер-автоматизатор) имеет доступ к исходному коду продукта(Unit тестирование). Как правило, в данном случае баг репорт отражает именно ошибки в коде, а не в функциональном поведении. 3. Тестирование “серого” ящика — это расширенная методология “черного ящика”, при которой тестер также не имеет доступ к исходному коду(или доступ сильно граничен), но представляет, как система устроена логически, может поделить её на модули и искать в них ошибки, используя специальные методики (например, взаимодействие веб-приложений по сети).
Q: Возможно ли найти и исправить все баги в программном продукте? Зачем нужно тестирование?
A: Нет, невозможно. Но тестирование необходимо, чтобы уменьшить количество ошибок. Тестирование добивается этого путем установления и соблюдения бизнес-процессов в своей области (планирование тестирования, отслеживание ошибок, отчет об ошибках, автоматизация тестирования, сертификация релиза и другие).
Q: Что такое обеспечение качества продукта (Software Quality Assurance)?
A: Это процесс отслеживания и совершенствования всех видов деятельности, связанных с разработкой программного обеспечения. Этот процесс включает в себя всё: начиная со сбора требований, дизайна, код-ревью, тестирования, имплементирования и заканчивая обслуживанием (технической поддержкой на стороне клиента).
