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

[Little_CJIOH]

Подводя итог всему сказанному:

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

Если вам хочется ускорения процесса - озадачьтесь малой автоматизацией и инструментами

Если у вас есть страх, что отвалится функционал, который в текущем релизе не должны были задеть никак - прописывайте смоук тесты по основным сценариям использования

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

 

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

Эффективность считается исходя из того, какая цель и какой ценой достигается. Некоторые цели достигаются эффективнее ручным тестированием, некоторые автоматическим.

[Сергей]

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

[DmitriyQA]

 

 

 

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

 

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

 

Я сказал потому что испробовал на себе.
Т.к. компания наша вышла в IPO то в средсвах стеснения никаого нет. Дошло до того что людей в офисе садить не где. И так наняли мы аутсорсом 60 индусов, результат как понимаете очевидный - пару сорваных релизов. Мы и так все время штат наращиваем, но банально негде людей столько взять. По этому выход у нас только 1 - автоматизация. Если у кого то по другому, то это обусловлено маленьким размером. 

[DmitriyQA]

 

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

 

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

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

 

 

 

 

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

 

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

 

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

 

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

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

 

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

[Little_CJIOH]

 

 

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

 

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

Я сказал потому что испробовал на себе.
Т.к. компания наша вышла в IPO то в средсвах стеснения никаого нет. Дошло до того что людей в офисе садить не где. И так наняли мы аутсорсом 60 индусов, результат как понимаете очевидный - пару сорваных релизов. Мы и так все время штат наращиваем, но банально негде людей столько взять. По этому выход у нас только 1 - автоматизация. Если у кого то по другому, то это обусловлено маленьким размером. 

Погодите, то что вы попытались в несколько раз смасштабировать ручное тестирование и паралельно начать работать с аутсорсерами, да еще и с отличным от привычного вам менталитетом. и потерпели неудачу не показатель того. что это тупиковый путь. Нанять людей мало их еще организовать надо. Самоорганизация хороша до 5 человек и совсем перестает работать на 9. Ручное тестирование так-же как и автоматическое требует настроенного фреймворка, чтобы на конечных исполнителей падали атомарные задачи, а количество решенных атомарных задач совершало качественный переход в картину качества продукта. И это совсем не простая задача..

[Dananas]

Подводя итог всему сказанному:

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

Если вам хочется ускорения процесса - озадачьтесь малой автоматизацией и инструментами

Если у вас есть страх, что отвалится функционал, который в текущем релизе не должны были задеть никак - прописывайте смоук тесты по основным сценариям использования

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

 

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

Эффективность считается исходя из того, какая цель и какой ценой достигается. Некоторые цели достигаются эффективнее ручным тестированием, некоторые автоматическим.

Спасибо большое за подитог! Пойду еще наподумать

[DmitriyQA]

 

 

 

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

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

 

В количестве найденных багов автотестами и вручную. И в потраченном времени на каждый из багов. Тогда и увидите всю эфективность

[Vasiliy]

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

 

Это оффтопик. Можно не отвечать:) Так, крик души.

[Freiman]

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

Ваша цель - получить максимум информации о состоянии продукта за определенное время.
Для этого нужно разделить подходы к тестированию.
Некоторую часть функциональности, которую вы сейчас тестируете руками, можно автоматизировать через апи.
Эффективность:
1. насколько меньше времени вы будете тратить на проверку
2. насколько полезную информацию будете получать от автотестов.
Сейчас вы гоняете тесты ядра руками, и через D дней можете сказать, что функциональность ядра не поломалась.
Через некоторое время вы будете гонять эти тесты на каждом билде ядра за M минут, и можете в любой момент сказать, поломано ядро или нет. Очень хорошо, если так получится покрыть реально критический функционал.

Также, конечно, придется заняться тест-дизайном с ручными тестировщиками, чтобы не получилось так, что они фактически вручную перепроверяют то, что проверено автотестами :)

[Dananas]

В целом картина получилась следующая:

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

Благодаря такой "оптимизации" мы смогли проработать 2 года без увеличения штата и автотестов при постоянном росте проекта.

 

Сейчас же, если внедрить автоматизацию, то, да, будет постоянно висеть простынка о состоянии работоспособности ядра. И получается что данная информация будет даже более полезна разработке, чем нам. Нам же, в свою очередь, останется только смотреть на продукт со стороны интерфейса. Мне нравится эта перспектива! =)

 

Спасибо всем за умные мысли! Пойду теперь дальше на подумать