вторник, 4 марта 2014 г.

Всегда ли нужна ручная регрессия? Жизнь_боль как двигатель прогресса

Всегда ли нужна ручная регрессия?

Ответ простой - да, всегда. Тестировщик - последний фланг перед передачей продукта пользователю. Ему надо убедиться, что система ведет себя так, как планировалось, что ничего нигде не сломается при нажатии на одну лишь кнопку.

Автоматизация - это круто. Но даже если все тесты проходят, это не дает 100% гарантии, что и вручную все будет работать. Поэтому и нужна такая проверка. Представляем себя пользователем и идем проверять его сценарии. Вручную!


Но в каком объеме проводить ручную регрессию?

Я сейчас читаю Как тестируют в google и там сквозь всю книжку проходит мысль - Нас мало и это здорово! Нам постоянно не хватает людей. Но зато в условиях нехватки времени отсеивается все лишнее, инженеры сосредатачиваются только на том, что действительно важно и не тратят время на ненужные тесты. Дефицит порождает оптимизацию!

А нам сейчас тоже вечно не хватает людей. А может, оно и к лучшему? Smile :)

Хочу поведать о нашей оптимизации времени, которое тратится на регрессию. Которая возникла как раз из-за нехватки ресурсов!

Немного предисловия - мы разрабатываем продукт, кастомизируемый под каждого Заказчика. То есть есть main часть проекта и есть проекты Заказчиков. Когда разработчик или тестировщик хочет собрать билд, он собирает сначала main билд, потом уже какой-то конкретный.

У нас много автоматизированных тестов на уровне API, которые покрывают (или стараются покрывать) всю основную функциональность продукта. Про наши тесты я рассказывала на SQA Days 14, там можно посмотреть подробнее.

Однако наличие автотестов не освобождает от ручной регрессии. И вот почему:
  • Автотеста на баг может не быть - когда тестировщик проверяет вручную, он исследует продукт. У нас есть на это время как раз за счет автотестов, нам не надо каждый раз выполнять одни и те же нудные операции с разными комбинациями входных данных. Все это уже покрыто в тестах. Так что достаточно пройтись по основным позитивным сценариям, а дальше искать там, куда приведет вдохновение. Бывает, что находятся ошибки, а проверка кода показывает - такого теста еще нет.
  • Автотест есть, он даже проходит. А вручную падает! Тесты на уровне API - это хорошо и практично, но они проверяют работу сервера, а сломаться может клиент.
  • Проверка GUI - вытекает из прошлого пункта. На отображение GUI автотестов как раз нет (дорого и пока того не стоит). Баги там находятся очень редко, поэтому проще прокликать 1 раз в 3 недели, чем пытаться заавтоматизировать.
Таким образом, что нам дает автоматизация - вместо того, чтобы 2 полноценных дня тестировщик сидел и начинал тихо ненавидеть повторяющиеся из раза в раз обязательные сценарии, он занимается более интересными делами. Рутину на себя берет робот, а тестировщик тратит на нее пару часов, а дальше начинает исследовать. Что, конечно, гораздо интереснее!

Подход себя полностью оправдывал... До определенного момента. Что же случилось?

Итак, у нас есть около 3 Заказчиков и примерно столько же тестировщиков. Подходит время выпуска релиза, тестировщики делят регрессию и погнали! День потестили и начались поставки. С учетом всяких рисков - 2 дня, ок.

Вроде бы нормально. Однако время не стоит на месте и количество Заказчиков только растет. А тестировщиков, увы, уменьшается. Кто-то переходит в разработку. Кто-то во внедрение... И вот мы уже тратим по 3-4 дня на ручную (!) регрессию. При этом "мы" - это два замыленных тестировщика, которые пытаются все-все-все успеть и очень сожалеют, что им не хватает времени.

Так пришел дефицит. Мучились мы, мучились. Как-то надоело. Посмотрели внимательнее на наши проекты - а ведь во многом они похожи! Конечно, везде своя специфика, но общие части есть! Ага, хорошо.

А что у нас с выхлопом? Посмотрели мы на баги, которые заводятся на регрессии - а их почти нет! Бывает, конечно, что документацию кто-то не дописал или совсем все сломалось, но это фиксится тут же и просто делается перепоставка.

А вот отдельная задача - таких очень мало. По результатам регрессии заводится мало запросов на улучшение, мало ошибок, да и те в основном с минорным приоритетом. А времени тратится все больше и больше. И это с учетом автоматизации!

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

Осталось решить, на каком билде проводить полную регрессию. Сначала мы приняли решение меняться. Сегодня на А, завтра на Б, так потихоньку и охват будет шире и глаз менее замылен!

Однако уже тогда зародилась идея о создании Демо-Заказчика. Тем более, что это нужно не только для регрессий, но и для демонстраций, так почему бы и нет? Почему бы не создать свой собственный, внутренний билд, который будет аккамулировать в себе все-все-все фичи Заказчиков?

Вот его и будем проверять! Сразу выявятся все косяки интеграции, если они есть. Сразу все фичи и проверим. А потом уже на остальный быстрый smoke + написание документации + подготовка сборки к поставке.

Конечно, воплощение идеи в реальность заняло какое-то время. Тогда еще это было примерно как "в первый раз в первый класс" и создание нового Заказчика занимало много времени. Ведь это делается не так часто. А тратить драгоценное время коллег, которые и так очень сильно загружены?

Какое-то время идея была идеей, но мы уже стремились к ней и внедрили метод "тестируем одного полностью, остальные ждут отмашки, потом приступают". Потом потихонечку-полегонечку мы начали воплощать эту идею в реальность...

А теперь Заказчиков стало еще больше и мы уже слабо представляем себе, как бы мы жили и дальше без нашего волшебного Демо-Заказчика!

Так что, как оказалось, дефицит и правда пошел нам на пользу. Хотя вначале всегда кажется наоборот, именно ситуации в стиле жизнь_боль двигают нас в правильном направлении Smile :)

Вот, например, когда я редко пишу определенную группу тестов, я молчу. Терплю и подчиняюсь всем их неудобствам. Но если я с ней работаю долго и мучительно, натыкаясь на какие-то косяки и тратя кучу времени на лишнюю работу, тогда рождаются статьи во внутренней вики "как это все грустно и печально и как бы мы могли сделать мир лучше". 

Пару таких идей мы уже внедрили и я даже не представляю уже, как мы жили без них! А если размышлять в терминах новых внедрений, то это уже столько сэкономленных сил и энергии! 

Потому что если что-то делаешь один раз, можно смириться. Но если из раза в раз ты повторяешь одно и то же, возникает желание это что-то заавтоматизировать. Или упростить. Ну хоть что-то с этим сделать! И делаем. А потом наслаждаемся результатами. Результатами оптимизации из-за дефицита!

Лень - двигатель прогреса, что ни говори!
А если вы сейчас очень страдает от дефицита тестировщиков, то задумайтесь, может, оно и к лучшему, а? Wink ;)

Комментариев нет:

Отправить комментарий