И снова привет, Хабр!
На протяжении 5 лет работы инженером-тестировщиком я всегда старалась найти ходы и выходы, чтобы упростить и оптимизировать процесс тестирования (рутина и монотонность – это не мое). Спойлер: у меня не получилось. В этой статье я хочу вам рассказать историю регрессионного тестирования на проекте, и о том, как у меня не получилось его оптимизировать ручным и авто-тестированием.
Маленькое отступление
Как я рассказывала ранее, проект, который мне довелось тестировать – программный продукт крупного банка. Заказчик применяет гибкую методологию и требует тестировать только прямую функциональную часть программных модулей.
Само программное приложение изучала по тест-кейсам, но не могу не выразить огромную благодарность аналитикам команды и руководителю группы тестирования заказчика, которые помогли понять тестируемое программное приложение с кучей модульной и системной интеграциями.
Первые шаги
Изучив основную часть ПО, решила, что нужно составить mind map. Но ее сплетения пересекались между собой, что заставляло путаться и ничего не понимать. После всех попыток что-то сотворить решила, что стоит для каждого модуля составить свою «умную» карту.
Взяла один модуль, начала составлять. Связывала последовательности один за другим. Ну вот и готово, теперь можно и тесты составлять. Конечно, здесь есть НО – в том, что последовательности и результаты функционала одинаковые, а формы для заполнения данными, чтобы появились эти последовательности и результаты – разные. И здесь задалась вопросом: «А стоит ли вообще составлять mind map?». Эта карта отлично подошла бы для небольшого проекта, но для проекта с кучей форм, настроек, параметров, функционала и прочих атрибутов, которые пересекаются, это вряд ли хорошая идея.
В итоге вернулась к тому, что стала обновлять устаревшие тесты, оставленные после коллеги-тестировщика давным-давно.
Второе дыхание
С бóльшим погружением в проект стала глубже понимать процесс разработки ПО. Теперь уже от аналитиков получаю требования, на основе которых начала составлять тест-кейсы (потому что другие тесты не требовались).
Процесс пошел, и вроде бы все было отлично. А вот и нет. С каждой новой правкой от программиста аналитики просили провести регрессионное тестирование приложения только по основным операциям. «Хех, только…»: насчитывалось более 800 тест-кейсов, а времени было лишь 2 дня.
Помните, где я выше писала про модульную и системную интеграции? Так вот, чтобы выполнить один тест, нужно сделать еще множество действий. Например, чтобы вы смогли открыть дверь от квартиры, нужно достать ключ из кармана, вставить ключ в замочную скважину, повернуть ключ, дернуть ручку – вот тогда дверь и откроется.
Казалось бы, нам нужно проверить, что дверь открывается, а действий, приводящих к этому тесту, много. Вот и здесь, в этом приложении, ситуация примерно такая же. Не трудно подумать, сколько на самом деле тест-кейсов нужно выполнить (*шепотом*: «Более 800»). А что по поводу времени? На один такой тест уходит 3-5 минут. Простая арифметика: 4*800 = 3200 минут (53,33 часов), 53, 33 / 8 = 6,6 дней. А протестировать программный продукт нужно за 2 дня…
Моим решением этой ситуации было то, что, раз уж нужно сделать кучу действий, чтобы выполнить один тест, то и эти действия тоже можно отныне называть тестами. И вот он ключ, приводящий, к оптимизации регресса – начать тестировать с далекого теста (достаем ключ из кармана) и далее, как по накатанной, прийти к конечному тесту. Решено! Нужно делать.
Составила диаграмму переходов от начального действия к конечному тесту. Создала сьют со вспомогательными тестами (действиями, приходящие к конечному тесту).
И все бы ничего, но столкнулась с такой проблемой, что эти действия в итоге оказались не нужны, так как система уже имеет свои неизменные настройки (которые настраивают аналитики и разработчики).
Но, если мы все равно будет стоять на своем, и действия используем в папке «Вспоминающих тестов», то при регрессионном тестировании образуется путаница. Так как наши тесты распределены по областям функций банковского ПО. И “кишмиш” будет не только в созданной папке с действиями, но и в голове самого тестировщика, ведь ему придется прыгать из папки в папку, чтобы поставить статус теста “Passed”.
Таким образом, «Второе дыхание» кануло в Лету.
А как же автоматизация?
«Проблему оптимизации регрессионного тестирования легко решит автоматизация», – подумала я… Но на самом деле – это не совсем так.
Глубоко изучив, какие инструменты использует заказчик для автоматизации Desktop-приложений, решила, что это лучик света в темной регрессии.
Авто-тесты в этом проекте пишутся исключительно вручную, рекордера тут нет. И пишутся такие тесты на языке Python в Pycharm с применением инструмента Inpector (отображающий ID объектов, их названия, координаты, типы и прочее) и Pywinauto (набор модулей, который автоматизирует взаимодействия MS Windows GUI). Так как язык Python мне пришлось изучать вот прямо сейчас на авто-тестах, я нашла авто-тестировщика в компании (большая благодарность ему), который подсказывал, какой код нужно написать в той или иной ситуации.
Первая проблема авто-тестирования
Вот и первая проблема подкатила. Тестируемый программный продукт “слеплен из заплаток”. Потому что он имеет разные не только фреймворки, но Pywinauto видеть не хочет некоторые объекты (кнопочки в тестируемом ПО), хоть и где-то фреймворк одинаковый. Это еще полбеды, проблема возникла и в одинаковых именах, ID, типов и прочих параметров в объектах. Здесь, конечно же, спасли бы координаты, но кто согласиться их применять? Их можно применить в самых безвыходных ситуациях, и то очень неохотно.
Вторая проблема авто-тестирования
Здесь можно задаться вопросом: а почему нельзя пригласить авто-тестировщика, который сможет оптимизировать ручное регрессионное тестирование?
Отвечу прямо: к сожалению, нельзя, потому что в команде подразумеваются лишь два тестировщика (не важно, ручной или авто), на которых и заложен бюджет. Пригласив третьего специалиста, финансовая составляющая команды будет выходить за рамки бюджета. И прибыль сократится пропорционально размеру заработной плате авто-тестировщика (на рынке IT зарплаты таких инженеров начинаются примерно с 250 000 рублей). И не стоит забывать, что с увеличением опыта и сложностей авто-тестирования в программном продукте, зарплата растет параллельно.
Подведение итогов
Я сдалась… да, вот такая неудача вышла на моем опыте.
И снова не забудем, что это дополнительная нагрузка на меня, как на ручного тестировщика, так как нужно успевать составлять тесты по требованиям, тестировать новые программные модули и проводить регрессионное тестирование (за 2 дня, Карл!) перед выкладкой билда, потому что, как ранее говорила, заказчик использует гибкую методологию проекта, где в каждом спринте разрабатывается функционал.
И в конце хотелось бы сказать: возможно, когда наберусь еще больше опыта, ко мне в голову придет новое решение такой проблемы.
Спасибо, что прочитали эту статью до конца. Буду благодарна, если не будете кидать помидорами.
