Тестирование новой функциональности
Тестирование новой функциональности должно происходить по мере её разработки, чтобы как можно быстрее дать обратную связь команде. Это очень важно, потому как уменьшает риск появления серьезных ошибок на этапе “причесывания” нового релиза. Возможно, что и ошибки в новой функциональности будут исправляться быстрее по “горячим следам” разработки.
Обычной практикой в разработке ПО служит оценка трудозатрат на выполнение той или иной задачи. Так разработчики оценивают время или сложность разработки, а тестировщики время или сложность тестирования той или иной задачи.
Стоит заметить, что оценки разработчика и тестировщика могут быть прямо противоположными. Изменения в коде могут вноситься несколько часов, а тестирование этих изменений и их влияния в целом на ПО может продолжаться несколько дней. Так и наоборот, разработчик потратит целую неделю на реализацию, а тестировщик может справиться с проверкой за один день.
Поэтому тестировщику нужно правильно распределять время и стараться уменьшать время на тестирование сложной функциональности, например, разрабатывая тесты заранее, а не при получении функциональности на тестирование.
Проверка исправления ошибок
В рамках проверки исправления ошибок проверяется как исправление ошибок из прошлой итерации, которые нашли тестировщики или пользователи ПО, так и исправление ошибок по новой функциональности.
|
|
|
Регрессионное тестирование
Помимо тестирования новой функциональности и исправления ошибок в ПО, тестировщик проводит регрессионное тестирование и также дает оценку на его проведение.
Вспомним, что же такое регрессионное тестирование.
Регрессионное тестирование - это вид тестирования, направленный на проверку изменений, сделанных в приложении или окружающей среде (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб-сервер или сервер приложения), для подтверждения того факта, что существующая ранее функциональность работает, как и прежде.
Регрессионными могут быть как функциональные, так и нефункциональные тесты. Как правило, для регрессионного тестирования используются тест-кейсы, написанные на ранних стадиях разработки и тестирования. Это даёт гарантию того, что изменения в новой версии приложения не повредили уже существующую функциональность.
Предположим, есть продукт, состоящий из множества частей:
При изменении одной из его частей могут возникнуть проблемы в других частях:
Либо добавление нового функционала приведет к ошибкам в старом:
Разработка новой функциональности увеличивает не только количество тестов на проекте, но и количество тестов для регрессионного тестирования. Со временем растет не только количество регрессионных тестов, но и время их проведения. Поэтому время на подготовку релиза с каждой новой версией увеличивается.
|
|
|
Дата добавления: 2018-08-06; просмотров: 2938; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!