@RichardGears

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

оименно отчет по тестированию? Какие кейзы пройдены, что найдено, ну и рекомендации от отдела куа.

оименно отчет по тестированию? Какие кейзы пройдены, что найдено, ну и рекомендации от отдела куа.

да, именно отчет. краткий надо писать каждый день, на 2-3 минуты чтения (для заказчика) и подробный раз в две недели для меня после апдейта

тогда вот то что выше написал.

отчет должен содержать нужную и полезную информацию

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

спросите того, для кого вы пишете отчеты — что ему нужно и полезно знать

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

спросите того, для кого вы пишете отчеты — что ему нужно и полезно знать

нет пока таких))

эээ... а зачем тогда отчеты? для кого?

эээ... а зачем тогда отчеты? для кого?

ааа, не так прочитала, сорри

всем привет, кто может подсказать - может ли в oracle существовать нормально пользователь без пароля? создаться создался с нужными правами и привелегиями, без пароля, но при попытке подключиться пишет: An error was encountered performing the requested operation: ORA-01005: null password given; logon denied 01005. 00000 - "null password given; logon denied" *Cause: *Action: Vendor code 1005

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

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

http://dahlan.unimal.ac.id/files/ebooks/2004%20A%20Practitioner's%20Guide%20to%20Software%20Test%20Design_Good.pdf

Ли Копланд+курс Алексея Баранцева "Практикум по тест-дизайну" Вам в помощь

Всем привет! Есть те, кто юзает ScalaTest? Переодически отваливается драйвер (Chrome node not reachable) Пытаюсь завернуть его в eventually или future Подскажите, как лучше сделать, чтобы оно ретраило попытки создать драйвер игнорируя эксепшены до тех пор, пока не упадет по таймауту?

@Gorbushina Anton спасибо :)

Кинул в личку, кому еще интересно пишите

а можно тоже информацию по burp wireshark charles

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

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

Важнее себя и коллег спрашивать "Какую задачу мы можем этим решить?"

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

необходимость состоит только в том, чтобы показать заказчику, мол, 60% того сего было выполнено и подобное

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

https://habr.com/post/141671/ вот здесь неплохо расписано про метрики, зачем они и нужны ли они именно вам

https://habr.com/post/141671/ вот здесь неплохо расписано про метрики, зачем они и нужны ли они именно вам

мерси

Статья Натальи мегаполезная, да. Но я все же предлагаю для начала мух от котлет отделить

Анна, ваш вопрос был про "метрики в тестировании"

Т.е. не оценка проекта, а оценка процесса тестирования

Статья по ссылке же - это оценка именно проекта

И по хорошему такую информацию заказчику должен предоставлять ПМ

Т.е. не оценка проекта, а оценка процесса тестирования

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

в статье в самом начале есть отсылка на другую статью, про оценку эффективности тестирования - посмотрите ее

заказчик не верит, что вы работаете? :) или вы заранее боитесь, что он вдруг перестанет верить — а у вас хоп! и доказательства на руках

заказчик не верит, что вы работаете? :) или вы заранее боитесь, что он вдруг перестанет верить — а у вас хоп! и доказательства на руках

не верит :D скоро придется каждый день им отчеты делать, вот такие они недоверчивые =з=

вангую потом от "мало багов, вы вообще работаете??" до "чего так много багов, программисты что, такие криворукие?"

Примите мои соболезнования, такого формата рабочие процессы обычно заканчиваются плачевно. KPI ради KPI и т.п.

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

ERROR: S client not available

А что, у кого-то не ежедневные отчёты? Так можно? Завидую

вангую потом от "мало багов, вы вообще работаете??" до "чего так много багов, программисты что, такие криворукие?"

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

тем более метрики не помогут :)

какую метрику ни сделай — вы же все равно крайними будете, если что

вот тут интересные размышления на тему прозрачности и отчётов )

http://blog.stratoplan.ru/management-tools-reports/

Только хотел спросить про эджайл, а тут и тема подъехала... Вопрос: Занимаюсь ручным тестированием в небольшой компании (~50 человек) отдел тестирования состоит из 6 человек, есть ли смысл переводить его (да, только его) на скрам или канбан?

вот разработчики удивятся....

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

когда вы будете работать по agile, а они нет :)

К сожалению, техлид против эджайл, но за улучшение рабочего процесса тестирования. Как понимаю, "частично" эджайл не работает?)

Только хотел спросить про эджайл, а тут и тема подъехала... Вопрос: Занимаюсь ручным тестированием в небольшой компании (~50 человек) отдел тестирования состоит из 6 человек, есть ли смысл переводить его (да, только его) на скрам или канбан?

Что вам это даст, если разрабам пофиг?)

а кто вам мешает проводить аудит требований до передачи в разработку? мы и без аджайла когда-то так делали и было успешно

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

Не претендую на светоч истины, но вставлю свои 5 копеек: Желание руководства видеть метрики возникает обычно в тот момент, когда руководство не понимает чем занят отдел тестирования. Руководство не понимает чем занят отдел тестирования в тот момент, когда пролезают на прод какие-то баги или когда оно видит что народ нифига не делает и алюёт в потолок. В первом случае мысль идёт по пути "что идёт не так давайте разберемся", во втором — "нафига они нам, не многовато ли их". Есть ещё третий вариант самый частый — "потому что у всех есть" Поэтому надо понять какая проблема будет решаться метриками и подбирать для её решения.

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

Что вам это даст, если разрабам пофиг?)

Хотелось бы больше времени уделять работе и меньше - составлению всяческих отчётов

а скрам тестировщикам отдельно от разработчиков нафиг не сдался

Хотелось бы больше времени уделять работе и меньше - составлению всяческих отчётов

Глобально проблему не решить без участия всез команд