Сообщений в теме: 29

[Dananas]

Доброго дня!

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

Так вот.

Дано: неограниченный бюджет и достаточно гигантский продукт.

Задача: выбрать по какому пути развиваться дальше.

 

Проблема: нет никакого представления что будет наиболее эффективнее. Если делать уклон в сторону автоматизации, то вопрос: веб интерфейса или апи интерфейса? Или делать уклон в сторону ручной проверки, хоть продукт и активно развивается, но это активное развитие будет еще года 3. Или вовсе идти посередки между автоматизацией и ручным, но тут тогда возникает вопрос: а какого уровня тогда эффективнее будет искать специалистов?

Направьте, пожалуйста, на путь истинный, что лучше взять за основу решения сия задачи?

 

П.С. В одном из скайп-чате большинство советов было в сторону "идти по середке", но останавливает то, что текущий апи интерфейс будет через какое-то время (~через год) переносится частично на сокетный интерфейс и в сявзи с чем будет переписываться архитектура ядра. Как много времени нужно автоматизатору, что бы он начал приносить пользу?

[Vasiliy]

Пригласите для начала консультанта, который сможет подсказать насколько удобно/просто/дорого будет идти автоматизация. После таких данных выбирать путь будет проще, имхо.

[Dananas]

Что-то мне кажется что это на данном этапе будет тупиковый шаг, не? Скажет он, что да, документация на апи есть, поставить тесты будет не проблема, первые тесты будут через 3 месяца. Язык берите джава, ибо продукт написан на джава+JS. Достаточно будет одного архитектора и перевести пару ручных в подчинение к нему, что кодить умеют.

Но это же в целом не ответит на вопрос развивать процесс через ручное или через автотесты. Чего именно от консультанта в конечном итоге добиться то можно?

[Little_CJIOH]

Работа консультанта: задать глупые вопросы, ответы на которые очевидны и из этих очевидных ответов сделать очевидный вывод до которого почему-то до сих пор никто не додумался.

Я у жены так консультируюсь, она в IT не понимает ничего, но находит все засады, все недоделки. все тонкие места. "Просто" методично расспрашивая, кто, что, как и зачем делает.

[BadMF]

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

 

Хотите я приму решение за вас, если, что, потом будете на меня пинять, и говорить, что вот в этих бесполезных тратах на много миллионов виноват чувак с форума?

 

Консультант выполняет, кстати, точно такую же функцию, что я описал предложением выше, но только вы ему доверяете, потому, что заплатили денег =).

 

Не в состоянии принять решение, наймите собутыльника и всё с ним обсудите за литрушкой-другой, он вам обязательно поможет =)

[Freiman]

Есть API - автоматизируйте API. Даже если оно будет переписываться через некоторое время, у вас будет документация "как оно работало раньше", что тоже может быть полезно.

Если какую-то логику не получается автоматизировать через API, то можно тестировать и через веб-интерфейс (хотя уже слегка извращение)

Остальное - руками.

 

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

[Little_CJIOH]

Если при автоматизации тестирования правильно выбрать уровни абстракции, то при смене ядра с сохранением бизнес логики сами тесты переписывать не приходится, только адаптировать их реализацию

[Сергей]

С этого надо и начинать)

[Dananas]

http://software-test...who-is-a-tester смотрел кто выступление Алексея? Меня очень зацепил этот доклад (особенно вторая его половина) и как-то он во-время оказался для меня.

И для себя я из него вынес две фундаментальные мысли:

1. Гораздо полезнее демонстрировать работоспособность продукта (в сфере моего типа тестирования) в целом, чем этого делать только для выпускающегося в релиз функционала (основная мысль поставленного мной процесса была в том, что зачем тестировать то, что никак не менялось. В результате этого, отдельные модули не проверялись по пол года, в результате чего общая картина работоспособности продукта как-то размазывалась).

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

И оба эти пункта без автоматизации не решить. По этому да, автоматизации быть =)
Осталось только понять какой и в какой степени...

 

 

 

 

От нас то вы чего хотите? 

Наверное хотел какого-то аргумента или пинка, что направил бы мои размышления в "нужное" русло =)

[DmitriyQA]

На ваш вопрос давно существует ответ. Следуйте пирамиде автоматизации:

У нас в компании соотношение тестов примерно такое:

20% UI или E2E тестов

30% Integration тестов - в вашем случае это будут API тесты

50% Unit тестов

 

Существует 2 принципиальных модели развития любого предприятия - экстенсивное и интенсивное. В вашем случае наращивание шата является экстенсивным развитием а следственно тупиковой ветвью

[Dananas]

 

 

Существует 2 принципиальных модели развития любого предприятия - экстенсивное и интенсивное. В вашем случае наращивание шата является экстенсивным развитием а следственно тупиковой ветвью

А где та грань, когда можно с уверенностью сказать, что интенсивное развитие уже не поможет и нужно следовать экстенсивному пути?

 

Ну и сейчас нет специалиста, смогущего поднять автоматизацию, по этому как минимум один ведущий автотестер + в команду будет точно.

[SALar]

Любой рабочий центр характеризуется производительностью на единицу операционных затрат и влиянием на общее время поставки. Совершенно нормальным является жертвовать производительностью ради сокращения времени поставки.

 

Автоматизация резко (в 3-10 раз) уменьшает производительность тестирования. Покажите, что и как вы выиграете от автоматизации. Выигрыш там вполне возможен.

[DmitriyQA]

Искать автоматизатора можно и нужно если бюджет позволяет. В идеале нужно нанять хотя бы 1 челвоека с опытом, а все остальные будут у него учиться. При минимальном бюджете можно просто отправить своих тестером на курсы. Эффективность от этого очень большая - народ перестает простаивать. Если чуть геде выкроилось время после релиза - все моугт писать автотесты.

Друго дело что курсов хороших мало, мы лично договаривались с работающим специалистам чтобы он приходил в наш филиал после работы и обучал всех желающих учиться автомтаизации

[BadMF]

 

 

Существует 2 принципиальных модели развития любого предприятия - экстенсивное и интенсивное. В вашем случае наращивание шата является экстенсивным развитием а следственно тупиковой ветвью

 

И кто вам сказал что Экстенсивное развитие является тупиковой ветвью?

[Сергей]

Вот только не надо в простое между релизами пытаться писать автотесты, особенно если чуть время выкроилось.

[Little_CJIOH]

Любой рабочий центр характеризуется производительностью на единицу операционных затрат и влиянием на общее время поставки. Совершенно нормальным является жертвовать производительностью ради сокращения времени поставки.

 

Автоматизация резко (в 3-10 раз) уменьшает производительность тестирования. Покажите, что и как вы выиграете от автоматизации. Выигрыш там вполне возможен.

Я правильно понимаю, что автоматизация в 3-10 раз увеличивает стоимость тестирования, при условии сохранения производительности, но позволяет увеличить скорость поставки?

 

 

 

 

Существует 2 принципиальных модели развития любого предприятия - экстенсивное и интенсивное. В вашем случае наращивание шата является экстенсивным развитием а следственно тупиковой ветвью

 

И кто вам сказал что Экстенсивное развитие является тупиковой ветвью?

 

Это общепринятое в России мнение, если не в атаку с шашкой наголо, то это не развитие.

 

Вот только не надо в простое между релизами пытаться писать автотесты, особенно если чуть время выкроилось.

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

[SALar]

 

Любой рабочий центр характеризуется производительностью на единицу операционных затрат и влиянием на общее время поставки. Совершенно нормальным является жертвовать производительностью ради сокращения времени поставки.

 

Автоматизация резко (в 3-10 раз) уменьшает производительность тестирования. Покажите, что и как вы выиграете от автоматизации. Выигрыш там вполне возможен.

Я правильно понимаю, что автоматизация в 3-10 раз увеличивает стоимость тестирования, при условии сохранения производительности, но позволяет увеличить скорость поставки?

 

Да, все верно. Я рассматривал этот пример в докладе на SQADays и более подробно на семинаре по стратегии тестирования. во многих проектах увеличение бюджета тестирования на пару сотен тысяч долларов элементарно покрывается одним лишним днем эксплуатации.

 

 

PS. Есть еще вариант пользы. Если код страшно плохой (сильносвязан и т.д.), то любое изменение в любом месте может аукнуться где угодно... Но эту ситуацию лучше решать рефакторингом. Вот хорошая статья: http://yakov-sirotki...com/269051.html

[Сергей]

SALar, если код страшно плохой и никто не собирается делать рефакторниг, тестирование только через интерфейс (самописный, плюс логика), автоматизация не окупается, тогда что делать?) Как тут предлагают пытаться между релизами писать автотесты?)

[BadMF]

SALar, если код страшно плохой и никто не собирается делать рефакторниг, тестирование только через интерфейс (самописный, плюс логика), автоматизация не окупается, тогда что делать?) Как тут предлагают пытаться между релизами писать автотесты?)

 

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

[Dananas]

 

 

Покажите, что и как вы выиграете от автоматизации

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