Да, кстати, и как считается количество найденных пользователями?
Каждый отчет от пользователя - +1 или каждая новая ошибка +1? 

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

Посмотрите http://blog.shumoos.com/archives/271

Не предлагаю использовать напрямую. Просто посмотрите.

Что могу ответить... Только грустный смайл =((((

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

Например, для компании1 процент пропущенных будет равняться 25% и это будет хороший показатель, ибо штат тестирования всего 1 человек, а тестирует он соц сеть ВК.

Или компания2, процент пропущенных будет 1%, но это критично, ибо тестируют самолет.

 

Хочу переубедить своего оппонента, но не хватает доводов! С его слов, нормальный показатель это 3%, все что больше - это вы отцтой тестировщики и место ваше в отстойнике.

А какова аргументация? Так-то важно "качество", а не количество, как выше отметили.

Вообще, тоже интересен метод расчёта процентов. 

 

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

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

Но все же хотелось бы увидеть статистику и понять, так 7% это норма или нет? =)

Зависит от принятых в компании норм, ПО то разное бывает.

Ну и я бы считала % только критичных ошибок или по крайней мере в разбивке по критичности, а то мелких ошибок может быть миллион, но они никак не влияют ни на что.

Согласен на приоритет. Но любая пропущенная ошибка - это же все равно по факту является ошибкой =)

Можно считать отдельно по функционалу, можно считать по релизу, а можно общую переменную. Вот по ней у меня получилось порядка 7% ошибок с боевого. При этом максимальное в релизе было порядка 40% =(

Я считаю просто как дважды два:

Общее кол-во ошибок - 100%

Найдено пользователями - Х

X = User*100/All

Ну и плюс любой параметр: релиз, функционал, человек, всего и т.д.

Да доброго дня всем! =)

Вопиющий случай!!! Семь процентов ошибок с боевого, мне тут недавно сказали, что это большой показатель!!! Разрази меня гром! Да так ли это??

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

Хочу переубедить своего оппонента, но не хватает доводов! С его слов, нормальный показатель это 3%, все что больше - это вы отцтой тестировщики и место ваше в отстойнике.

Хмм... А если менее опытного и более опытного посадить за новый проект, от кого из них тогда будет больше профита? =)
Был ли у кого подобный опыт?

А по мне так, штука в том, что более опытные пытаются подходить к работе более системно: то есть не тыкать во все куда глаза глядят, а разбирают функционал, пишут подготовительные какие-то тесты/пометки, фантазируют с тест данными итд и все это "по умному". Или говоря другими словами, более часто спускаются с проверок на уровне "бизнесс-сценарии", на уровень "функциональная-реализация". И в результате из-за этого новички выигрывают количеством и качеством (ибо нарушается логика бизнес-кейса) ошибок, чем старички, хотя старички по факту знают больше и больше смогут проверить.

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

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

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

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

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

 

 

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

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

Доброго дня!

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

Так вот.

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

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

 

 

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

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

Фига какая тема...

Я вот тут намеднях (месяца 9 назад...) задался тем же самым вопросом: не имея никакого понимания с какой стороны автоматизации держаться за палку, начал обучаться.

Мой план действий был примерно таков:
1. Понять как общаются веб-клиент с сервером.

2. Попробовать упростить жизнь рекордером (как пример, Selenium IDE).

3. Понять что такое вообще автоматизация в масштабе (форум, статьи, доклады).

4. Начать изучать язык программирования (я брал Питон, по советам от сюда http://software-test...chshe-nachat-i/ ). Начал изучать с курсов на stepic.org, ибо бесплатные. Здесь все просто, главное не лениться =)

5. Потом записался на курс ПДТПитон у Баранцева. Дорогой собака, но вник что такое автоматизация, как разбивать архитектуру и в целом уже могу как тут выше писали, автоматизировать рутину при том грамотно.
6. Углубление в понятие "селениум". Попробовал углубитсья, записался на еще один курс от Баранцева (не помню как точно называется, чтото типа разработка тестов на Питон с селениум). По факту оказался курс сложным, не осилил =)
7. И вот сейчас планирую углубиться в автоматизацию не через веб-интерфейс (еще пока не нашел подходящий курс).

Как-то так.

Если же обособить: на то, что бы на проекте начать поднимать автоматизацию у меня ушло порядка 6 месяцев учебы. Если же твоя цель устроиться джуном автоматизатором, то готовься потратить времени не меньше =)
И начни изучать любой язык, в любом случае - пригодиться!

В общем, всем спасибо за мнения! Если будут какие еще аргументы - велком =)

Доброго всем!

Возник принципиальный вопрос: искать до упора автоматизатора который полностью впишется в тематику проекта или расти своего? Подскажите у кого как по опыту было?

В итоге я сбился полностью как лучше поступить =)

В итоге буду искать автоматизатора и просить пока выделить разработчика в помощь! =)

 

Доброго всем!

 

Возник принципиальный вопрос: искать до упора автоматизатора который полностью впишется в тематику проекта или расти своего? Подскажите у кого как по опыту было?

 

Есть человек, который будет обучать автотестера ?

 

Не, такого человека нет =(
Есть как бы я, который прошел курс программирования для тестировщиков, который как бы "осознал" какая должна быть "архитектура" автотестов, но опыта как такового нет.

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

Похоже на то, что придется искать опытного, что бы он меня учил =)

Вот только по веремени это может же занять слишком много времени...

Автоматизировать нужно бекэнд через апи и ВС интерфейсы.

 

 

Пишите требования, что вам, как тестировщику, нужно от автоматизации, отдаете порграммисту. Через неделю у вас будет минимальный фреймворк, с которым можно работать, чтобы покрыть основные потребности в автоматизации через апи. Что и как улучшить поймете сами через полгода работы с этим фреймворком, сделаете вторую версию требований с улучшениями и отдайте еще на неделю программистам.
Выйдет намного дешевле, чем искать идеального человека. И код будет намного лучше и стабильнее. 

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

Идеальный диалог!..

оуууу!! Шикарно! Спасибо, сработало!