Новости

История о бесконечном регрессионном тестировании

На протяжении 5 лет работы инженером-тестировщиком я всегда старалась найти ходы и выходы, чтобы упростить и оптимизировать процесс тестирования (рутина и монотонность – это не мое). Спойлер: у меня не получилось. В этой статье я хочу вам рассказать историю регрессионного тестирования на проекте, и о том, как у меня не получилось его оптимизировать ручным и авто-тестированием.  

Маленькое отступление

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

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

Первые шаги

Изучив основную часть ПО, решила, что нужно составить mind map. Но ее сплетения пересекались между собой, что заставляло путаться и ничего не понимать. После всех попыток что-то сотворить решила, что стоит для каждого модуля составить свою «умную» карту.

Взяла один модуль, начала составлять. Связывала последовательности один за другим. Ну вот и готово, теперь можно и тесты составлять. Конечно, здесь есть НО – в том, что последовательности и результаты функционала одинаковые, а формы для заполнения данными, чтобы появились эти последовательности и результаты – разные. И здесь задалась вопросом: «А стоит ли вообще составлять mind map?». Эта карта отлично подошла бы для небольшого проекта, но для проекта с кучей форм, настроек, параметров, функционала и прочих атрибутов, которые пересекаются, это вряд ли хорошая идея.

В итоге вернулась к тому, что стала обновлять устаревшие тесты, оставленные после коллеги-тестировщика давным-давно.

Второе дыхание

 С бóльшим погружением в проект стала глубже понимать процесс разработки ПО. Теперь уже от аналитиков получаю требования, на основе которых начала составлять тест-кейсы (потому что другие тесты не требовались).

Процесс пошел, и вроде бы все было отлично. А вот и нет. С каждой новой правкой от программиста аналитики просили провести регрессионное тестирование приложения только по основным операциям. «Хех, только…»: насчитывалось более 800 тест-кейсов, а времени было лишь 2 дня.

Помните, где я выше писала про модульную и системную интеграции? Так вот, чтобы выполнить один тест, нужно сделать еще множество действий. Например, чтобы вы смогли открыть дверь от квартиры, нужно достать ключ из кармана, вставить ключ в замочную скважину, повернуть ключ, дернуть ручку – вот тогда дверь и откроется.

Казалось бы, нам нужно проверить, что дверь открывается, а действий, приводящих к этому тесту, много. Вот и здесь, в этом приложении, ситуация примерно такая же. Не трудно подумать, сколько на самом деле тест-кейсов нужно выполнить (*шепотом*: «Более 800»). А что по поводу времени? На один такой тест уходит 3-5 минут. Простая арифметика: 4*800 = 3200 минут (53,33 часов), 53, 33 / 8 = 6,6 дней. А протестировать программный продукт нужно за 2 дня…

Моим решением этой ситуации было то, что, раз уж нужно сделать кучу действий, чтобы выполнить один тест, то и эти действия тоже можно отныне называть тестами. И вот он ключ, приводящий, к оптимизации регресса – начать тестировать с далекого теста (достаем ключ из кармана) и далее, как по накатанной, прийти к конечному тесту. Решено! Нужно делать.

Составила диаграмму переходов от начального действия к конечному тесту. Создала сьют со вспомогательными тестами (действиями, приходящие к конечному тесту).

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

Но, если мы все равно будет стоять на своем, и действия используем в папке «Вспоминающих тестов», то при регрессионном тестировании образуется путаница. Так как наши тесты распределены по областям функций банковского ПО. И “кишмиш” будет не только в созданной папке с действиями, но и в голове самого тестировщика, ведь ему придется прыгать из папки в папку, чтобы поставить статус теста “Passed”.

Таким образом, «Второе дыхание» кануло в лепту.

А продолжение читайте в блоге ICL Services на Хабр.