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

не соответствовать критериям, а освоить профессию тестировщика, а не какую либо другую

я говорю это

Ну так "освоить профессию тестировщика" - это соответствовать некоторым критериям этой профессии)

намекают только новичкам ?

ну правда есть же флуд для таких рассуждений, тут вроде по делу в основном пишут

ну правда есть же флуд для таких рассуждений, тут вроде по делу в основном пишут

Ладно, все, молчу. Спасибо)

Ну так "освоить профессию тестировщика" - это соответствовать некоторым критериям этой профессии)

вот сча у меня глза на лоб

ну правда есть же флуд для таких рассуждений, тут вроде по делу в основном пишут

по делу - это о чём?

пойдем в личку, если хочешь)

вот вы бы по ходу весь тренинг болтона во флуд записали бы

пойдем в личку, если хочешь)

можно пожже

сча я наверное накидываться либо с френдом, либо с болтоном

@RichardGears

ну правда есть же флуд для таких рассуждений, тут вроде по делу в основном пишут

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

если это флуд - я просто фигею

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

да, рассуждения не нужны

рассуждения дистрактс пипл

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

Булшит бинго собрано

Рома, иди уже пей. Я сам около космополита)

да, рассуждения не нужны

Рассуждения двух человек на 3к+ людей - не нужны, если уже несколько человек сказали, что им это некомфортно.

Рома, иди уже пей. Я сам около космополита)

го на пиво ))) (посты на эту тему удаляй легко, но ишуз, но сам тред я считаю по теме)

Рассуждения двух человек на 3к+ людей - не нужны, если уже несколько человек сказали, что им это некомфортно.

а должно быть?

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

а еще нужно контролировать загруженность памяти, процессора

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

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

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

что значит профайлерами?

https://www.google.ru/amp/s/stackify.com/java-profilers-3-types/amp/

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

задача тестировщику поставлена

Ну разработчики же могут помочь? Или у вас black box?

Может быть у вас есть доступ к логам приложения - тогда, возможно, задача сведётся к парсингу логов

Может быть у вас есть доступ к логам приложения - тогда, возможно, задача сведётся к парсингу логов

что значит параинг?

Может быть у вас есть доступ к логам приложения - тогда, возможно, задача сведётся к парсингу логов

доступ к логам есть

что значит параинг?

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

Загрузка CPU - это к админам они мониторят систему

Загрузка CPU - это к админам они мониторят систему

нет таких)

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

доступ к логам есть, но только с прода, там в реальном времени не отследишь

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

Но это лишь один из вариантов. Возможно, кто-то предложит что-то проще и эффективнее.

Коллеги, посоветуйте пожалуйста материалы по эстимированию задач

Коллеги, посоветуйте пожалуйста материалы по эстимированию задач

хм, а такое есть? )) есть в книжках по аджайл/скраму немного про это

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

программисты так и сделали :) спасибо за ответ

хм, а такое есть? )) есть в книжках по аджайл/скраму немного про это

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

но вот методики получения этих первоначальных оценок остаются за кадром

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

Из головы/опыта

если опыт ничего не подсказывает и задача новая/не типичная?

Коллеги, посоветуйте пожалуйста материалы по эстимированию задач

https://www.amazon.com/Software-Estimation-Demystifying-Developer-Practices/dp/0735605351 рекомендую

Спасибо

там не столько про "как эстимировать", сколько про "как эстимировать не надо". помогает избежать кучи ошибок

http://focusedobjective.com/ еще вот можно поизучать

весь блог или что-то конкретное?

там в целом про менеджмент, статистики, сроки. какую-то конкретную статью не выделю, годных много (и "годно" у всех разное)

https://www.amazon.com/Software-Estimation-Demystifying-Developer-Practices/dp/0735605351 рекомендую

March 1, 2006 А не устарела? Или в этой области особого прогресса за 12 лет не наблюдается

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

Коллеги, посоветуйте пожалуйста материалы по эстимированию задач

У Болтона и Гойко Адзича ечть годнота по теме и еще у Дена Кеннеди (оно у последнего больше упор в менеджмент бизнеса)

March 1, 2006 А не устарела? Или в этой области особого прогресса за 12 лет не наблюдается

Серьезно? Вопрос об устаревании фундаментальных принципов за 12 лет?

В тестировании с момента поолучения пенициллина ничего не поменялось

Болтона? Он у нас выступает на неделе

принципы не меняются. модели меняются. если мне не изменяет память, Стив Макконел это как раз тот человек, который распиарил модель Боэма (про то, что стоимость исправления ошибки растёт сильно нелинейно в зависимости от стадии разработки)

Болтона? Он у нас выступает на неделе

у вас это где? видеотрансляция будет?

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

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

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

кто бы сомневался...

Это кстати типичный факап везде, наши американцы модели иногда прикладывают тупо ибо "ну все же такие и бизнесу нужна плашка", а потом факапы лезут ибо сайд эффекты

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

опять будет минутка истории. в конце 80-х Боэм сотоварищи изучили что-то около сотни проектов, и выявили закономерность, что стоимость исправления бага от этапа к этапу разработки возрастает примерно в 10 раз, и всего таких этапов можно выделить то ли четыре, то ли пять. в конце 90-х Макконел это дело раскопал и написал в книжке. и эта модель стала популярной, её пихали потом во все учебники и доклады, мол, надо баги раньше исправлять, иначе всем конец. насколько мне известно, никто до сих пор не смог обнаружить других конкретных материалов, данных объективного наблюдения, которые бы хорошо подтверждали модель Боэма. одно исследование на сотне проектов тридцать лет назад! и все до сих пор в это верят, потому что Макконел молодец, хорошо распиарил тему

Знаем такую тему

если опыт ничего не подсказывает и задача новая/не типичная?

тогда берут пессимистичную оценку за основу

у вас это где? видеотрансляция будет?

Внутрь да, во вне - хз, врядли

Внутрь да, во вне - хз, врядли

жаль

опять будет минутка истории. в конце 80-х Боэм сотоварищи изучили что-то около сотни проектов, и выявили закономерность, что стоимость исправления бага от этапа к этапу разработки возрастает примерно в 10 раз, и всего таких этапов можно выделить то ли четыре, то ли пять. в конце 90-х Макконел это дело раскопал и написал в книжке. и эта модель стала популярной, её пихали потом во все учебники и доклады, мол, надо баги раньше исправлять, иначе всем конец. насколько мне известно, никто до сих пор не смог обнаружить других конкретных материалов, данных объективного наблюдения, которые бы хорошо подтверждали модель Боэма. одно исследование на сотне проектов тридцать лет назад! и все до сих пор в это верят, потому что Макконел молодец, хорошо распиарил тему

Вероятно потому, что эта модель хорошо ложится на (не факт что верные) интуитивные ожидания

при эстимейтах важно понимать что точно в них попасть можно только когда делаешь много однотипных задач

Вероятно потому, что эта модель хорошо ложится на (не факт что верные) интуитивные ожидания

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

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

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

при эстимейтах важно понимать что точно в них попасть можно только когда делаешь много однотипных задач

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

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

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

Второе - это консенсусное решение

задним числом всегда хорошо анализировать — "вот если бы мы исправили эту ошибку на этапе проектирования, это стоило бы нам 10 баксов, а сейчас мы попали на поллимона". да не могли мы её тогда за десять баксов исправить!

потому что — "хорошо быть таким умным до, как моя жена после"

потому и появился agile, с другими моделями

потому и появился agile, с другими моделями

Я на пиве после прошлого куафеста спорил с колей алименковым, что "ажайл, континус деливери и другие хр" в общем то были всегда, но потом на них хайпанули

Никаких "других моделей" имхо в аджайле нет, правильно продуманный гибкий процесс по эффективности не выше правильно продуманного MSF или там RAD

Хотя видел, что рад уже в аджайл тоже включают

Все работает в границах применимости

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

Ну ХР рафинировалась давно, РАД тоже, МСФ юзался мс и партнерами и имхо он до сих пор умнее и эффективнее большинства процессов, но тоже не везде

Рафинирование канбана произошло вообще тогда, когда многие из современных проповедников еще из яслей не вылезли

Я обожаю аджайл идеи и читаю о них внутри компании с 2008-го года

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

то, что хайпанули — это понятно. и заработали неплохо, не просто так же хайпанули

то, что хайпанули — это понятно. и заработали неплохо, не просто так же хайпанули

Ну, как тот же Коля написал, претензий к тренерам нет, есть вопрос к развесившим ушы