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

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

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

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

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

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

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

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

X = User*100/All

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

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

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

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

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

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

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

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

Как автоматизатор я только начинающий и вот столкнулся с проблемой, что не знаю как реализовать ожидание окончания поиска. Помогите, пожалуйста =)

В общем, каталог. До поиска отображается весь список, при поиске запрос отправляется на сервер, с сервера приходит ответ. Список корректируется. Проблема заключается в том, что при:

1. Положительном поиске  - после возврата ответа страница может и не измениться никак.

2. Отрицательном поиске(ничего не найдено) - все элементы скрываются и тупо ничего не отображается.

Так вот, подскажите пожалуйста, как можно реализовать это самое ожидание окончания поиска? Может есть у кого готовые, привычные ожидалки? 

Буду рад любой наводке! 

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

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

Да, есть индикатор ожидания, а как его можно использовать? Совсем не имею представления =(

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

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

 

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

 

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

 

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

 

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

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

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

Как-то так.

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

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

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

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

Возник тут вопрос, в ходе очередной дискуссии =)

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

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

Рассудите нас, пожалуйста, так кто же прав? =)
И как процесс тестирования в данном разрезе выглядит у вас?

 

 

 

А серверную часть, нижний уровень, предполагается проверять также, вручную, или речь про автотесты? Или просмотр кода? Или про что?

Да любым из способов. Все же здесь от времени зависит, ведь так?

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

https://bz.apache.or...ug.cgi?id=59386
Поставил ошибку в результате...

Да, предложенный вариант помогает, спасибо!

Доброго дня!

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

Так вот.

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

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

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

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

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

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

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

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

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

 

 

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

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