И снова привет, Хабр!
На протяжении 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 дня, Карл!) перед выкладкой билда, потому что, как ранее говорила, заказчик использует гибкую методологию проекта, где в каждом спринте разрабатывается функционал.
И в конце хотелось бы сказать: возможно, когда наберусь еще больше опыта, ко мне в голову придет новое решение такой проблемы.
Спасибо, что прочитали эту статью до конца. Буду благодарна, если не будете кидать помидорами.
Комментарии (12)
Zyuzi
01.06.2022 11:29+1Спасибо за статью :) Вселяет веру в себя.
А у меня на работе было круче: "Нам надо ставить обновление, срочно, проверь его за 1 час". А тестов основной функциональности - 300. И через 20 минут вопрос от тим - лида: " Ну, что работает? Обновляем?" :)
AliyaTokareva Автор
01.06.2022 11:38Ахаха :D Обалдеть :О
И еще в таких моментах появляются зачатки мыслей "Это я виноват в том, что не успеваю", "Это из-за меня будут ошибки на проде". Но на деле нет, поставили задачу в невыполнимые сроки.
Хочется обладать магией вне Хогвартса (или "замедления времени") :D
Интересно было бы узнать: чем закончилась ваша история? :)
Zyuzi
01.06.2022 12:15+1Я сказала, что мне нужно время, обозначила срок. Уже точно не помню какой, и что если выпустят в прод - я ответственность не несу, ждали пока проверю. Разработчик фиксил баги, по сообщениям в телеграмме. :)
Про магию вне Хогвартса очень точно сказано :)
AliyaTokareva Автор
01.06.2022 12:32Вы счастливый специалист, к вам пошли на встречу :)
даже можно позавидовать :D
Это шикарно, когда команда слушает своих участников.
К сожалению есть и такие проекты, где не слушают тестировщиков Т_Т
"Мы дали вам срок и всё. Тестируйте."
А потом ночи не спишь, тестируешь Т_Т
Zyuzi
02.06.2022 06:23+1Я один тестировщик, меня любят ^_^
Но, иногда по ночам тоже тестируешь, чтобы помочь команде, они же тебя любят)
AliyaTokareva Автор
02.06.2022 11:40А после со слезами на глазах под утро идешь спать. И это слезы не только от недосыпа и боли, но и слезы счастья :D
lxsmkv
Все правильно, если было запланировано недостаточно ресурсов, то как ни крути проблему эту можно исправить только добавлением необходимых ресурсов, а еще лучше правильной оценкой трудозатрат еще до тендера. А то все кричат "мы дешевле", "мы еще дешевле", а потом вот такая котовасия получается, эх.
Можно конечно сказать, давайте тестировать столько за сколько платят. Берем 800 кейсов, берем 7 дней. У нас только 2 дня, значит проходить мы будем скажем около 225 кейсов. Теперь задача в том чтобы из 800 "наиважнейших" тестов, выбрать 225 "самых наиважнейших". T.e. те с наивысшим фактором риска. (см. Risk Based Testing) и те которые вероятно затронут изменившииеся компоненты. Выбрать "самые важные" тесты можно спрашивая себя, "если бы я мог провести только один тест, то какой бы тест я выбрал", а если два, а если три, и так далее. Или также смотреть какие из сценариев в прошлом выдавали чаще всего баги. Такое ревью тестовой базы нужно провести обязательно и выбить себе под это время. Это называется оптимизация процесса тестирования. (Вообще это работа тестменеджера но его у вас видимо нет. Ну значит в следующий раз на годовой беседе по развитию не забудьте напомнить работодателю что по факту выполняли две роли, одну из них синиор.)
Ну и нужно просмотреть тестовые сценарии отсортировать по сложности выполнения и по информационной пользе. Расставить на самые простые сценарии метки "нужно автоматизировать". Может сценарии их можно подсократить. Самые простые сценарии это те которые автомат не завалит по непонятной причине, потому что времени разбираться не будет.
Если все сценарии сложные для автомата, то можно сначала перейти на полуавтоматический режим, т.е. часть сценария проходит автомат под наблюдением а часть - человек.
Возьмите для автоматизации нормальный инструмент. Для десктопа есть например Ranorex, он не такой страшно дорогой как скажем Tricentis, Там триал на 30 дней, хватит чтобы опробовать пригодность. И документация нормальная. Потом все это распихивается по виртуальным машины и гоняется на VMWare параллельно. Katalon вроде тоже умеет десктоп. Лицензию можно выпросить у заказчика. Вообще надо знать какой у приложения технологический стек чтобы рекомендовать инструмент для автоматизации.
Третий вопрос, что делают разработчики во время 7 дней регресса? Может им тоже тестировать? Или помогать писать автоматизацию. А то как-то все это не похоже на аджайл и скрам. Должно же быть один за всех и все за одного. Что мы еще делали это спринт ревью, перед сдачей функции ее разработчики или разработчитцы демонстрировали ее всем участникам команды. Это тоже такое замаскированое тестирование, на котором часто выявлялись баги и вопросы. Потом мы ввели обязательное планирование юнит тестов, т.е. не "захочет напишет, не захочет не напишет" а прямо сабтаск. И закрывался он без написания теста только при достаточной аргументации задокументированой в нем.
Качество оно не только от регрессионного тестирования, оно от культуры разработки идет, ее нужно воспитывать. Конечно молодому специалисту-тестировщику может не хватать авторитета для этого, тогда стоит попытаться найти союзников у которых этот авторитет есть.
Вобщем это так, общие мысли. Авось что пригодится, а так, спрашивайте, рад буду поделиться опытом.
AliyaTokareva Автор
Спасибо вам большое, что прочитали статью и за советы, обязательно возьму их на вооружение.
Но на деле там не все так просто: Из выбора по критичности теста - такое да, делали совместно с аналитиками, и как раз вот эти 800 кейсов и есть критичные. Самих тестов на самом деле около 1500-2000.
Отличная идея с метками - мне это понравилось. И тут тоже есть проблема, самый первый простой и важный авто-тест провалился разными фреймворками (на входе в ПО), одинаковыми названиями атрибутов и вовсе не видеть эти GUI-объекты
Что по поводу Ranorex - в этом у меня опыт есть, и у заказчиков даже был TestComplete. И даже какие-то тесты были. Ходила к руководителю тестировщиков заказчика, чтобы увидеть эти тесты. И получила ответ, что от TestComplete отказались, и больше им пользоваться не будут в пользу бесплатных Pywinauto и\или Winium.
И последний вопрос с разработчиками. Тестировщики (я и мой коллега) с ними не общались :( и я этот вопрос поднимала, что мне "нужны" разработчики, мне нужно с ними общаться. Получила ответ: "Только через аналитика"
lxsmkv
Это они называют аджайл ????????
Я думаю вам пора поискать себе нормальное место работы, где к тестированию относятся так как надо. Да и в конце концов, если для работодателя вы все время были просто тестировщиком то он найдет себе еще одного такого просто-тестировщика, а вам пора расти.
Впомним слова Джимми о Губке Бобе, из второй серии пятого сезона: "Парень неплохой шеф-повар, но шикарным шеф-поваром он станет тогда, когда уволится из этой дыры."
Я со своего первого проекта ушел потому что по уму и по аджайлу эту работу (автоматизацию) должны делать команды, но пока для этого есть выделеный человек - ничего не поменяется. Значит мне нужно уйти, чтобы проект вынужденно поменял режим работы. Так что я передал командам знания и ушел. И все сработало, теперь команды разработки делают автоматизацию.
Так что подумайте, не сделаете ли вы проекту благо если уйдете с него. Найти работу хорошему специалисту со стажем в тестировании проще чем пытаться натянуть сову на глобус. Тем более сейчас удаленка кругом.
Да может это крамола, но иногда люди совершенно упускают из виду, что пытаются решить не имеющую решения задачу, а годики-то идут.
AliyaTokareva Автор
Спешу вас обрадовать. Из этого проекта я ушла недавно, поняла, что выросла, что хочется уже смотреть в сторону тест-менеджера. И знания свои передала тоже (как это сделала, написала тут :D https://habr.com/ru/company/icl_services/blog/660871/)