и в той уже папке все это барахло хранится

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

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

как то пытались использовать... ничего сильно дельного они не дают как то...

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

Общую удовлетворенность работой всей команды и клиентов

Общую удовлетворенность работой всей команды и клиентов

Как изменяли?

Итеративно количество реджектов, количество пропущенных дефектов на про, субъективные оценки работы команды тестирования РП, ВА, разработчиками... метрик много можно придумать, вопрос в нужности оных, некоторые собирают метрики чтобы собирать метрики :)

Итеративно количество реджектов, количество пропущенных дефектов на про, субъективные оценки работы команды тестирования РП, ВА, разработчиками... метрик много можно придумать, вопрос в нужности оных, некоторые собирают метрики чтобы собирать метрики :)

Спасибо, Олег :) тогда уточню. Интересны не только метрики, но и что с помощью них удалось улучшить или как полезно использовать

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

Должен возникнуть вопрос о том как понять какие проблемы надо решать. Отвечаю: Алексей выше написал лучший для этого источник )

А что удалось решить... Вот актуальные проблемы и удалось решить)) По большому счету для команды тестирования если не качество тестирования, то трудозатраты, то что-то в этом направлении... вот и решалось подобное ). Но здесь необходимо понимать, что метрика лишь информация для анализа, проблему сама по себе она не решает

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

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

А еще человека в штат добавить не вариант? А если 1 из них болеет, весь процесс по дедлайну падает?

Не, не упадёт

Как изменяли?

Измеряли? Разговорами с участниками.

есть навык распараллеливания процессов

Когда надо за двоих херачить(( грустно, тяжело, но умею

Не хотят ещё одного, денег нет, но мы держимся

Как же я разделяю твою боль

Не хотят ещё одного, денег нет, но мы держимся

всего доброго, хорошего настроения и здоровья.

Не хотят ещё одного, денег нет, но мы держимся

Б. безысходность

Пока вы не докажете менеджерам проекта, что этот +1 действительно нужен, либо +1 автоматизатор решит большую половину проблем (читай "автоматизация будет действительно очень профитной для тестирования в конкретном случае"), до тех пор вас будут футболить.

Не хотят ещё одного, денег нет, но мы держимся

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

Пока вы не докажете менеджерам проекта, что этот +1 действительно нужен, либо +1 автоматизатор решит большую половину проблем (читай "автоматизация будет действительно очень профитной для тестирования в конкретном случае"), до тех пор вас будут футболить.

скрипя зубами, в не рабочее время, покрыли тестами, порядка 75% и знаете, что ответили, (но мы-то думали, что тем самым покажем, что автоматизация хорошее подспорье) - ну, вот видите, вам не нужен ещё один, и так справляетесь

убили мотивацию напроч

скрипя зубами, в не рабочее время, покрыли тестами, порядка 75% и знаете, что ответили, (но мы-то думали, что тем самым покажем, что автоматизация хорошее подспорье) - ну, вот видите, вам не нужен ещё один, и так справляетесь

боль

2 варианта: 1. У вас интересные менеджеры :) 2. Неправильная подача информации с вашей стороны.

2 варианта: 1. У вас интересные менеджеры :) 2. Неправильная подача информации с вашей стороны.

В команду тестирования требуется "продажник" идей XD

Как бы это не звучало, но порой без этого никак )

А, воооот картинка, с каким лицом была сказана последняя фраза

Тут у мейла на универсариуме неплохой курс есть. Алексея Баранова вроде. И в одном их видосов он говорит о разделении времени тестировщиков. Типа 35% на один проект, 55% на другой и 10% на активности. Это и конфы, и скилловка. И т.д. непредвиденное

скрипя зубами, в не рабочее время, покрыли тестами, порядка 75% и знаете, что ответили, (но мы-то думали, что тем самым покажем, что автоматизация хорошее подспорье) - ну, вот видите, вам не нужен ещё один, и так справляетесь

стоило объяснить менеджерам, что это "героизм" и за этот героизм вы позже будете расплачиваться

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

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

вброс или персональное мнение?

50 на 50 ?

печально, если так :)

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

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

пфф) ваша картина "менеджера" впечатляет :)

а терки между менеджерами и инженерами всегда, в основном, из-за того, что менеджер думает нуждами бизнеса, а инженеры нуждами инженеров

И то верно, разработчики тоже небезгрешны

извечный вопрос, кто же в этой песочнице "дурак" :)

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

а в плане бизнеса - сколько неИнженеров строят успешные бизнесы? :)

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

А технологиские? ;)

У вас есть статистика?

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

Тогда это субъективное мнение, а не картина в целом.

Я и не назывался экспертом по социологии бизнеса. Но аргументы против послушал бы.

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

А технологиские? ;)

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

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

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

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

Это логика собачки с миской еды. "Если сейчас есть миска еды, то зачем заботиться о завтрашнем дне?"

Это логика собачки с миской еды. "Если сейчас есть миска еды, то зачем заботиться о завтрашнем дне?"

Вы сейчас знатно по бизнесам проехали)

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

А вы пробовали объяснить?

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

Я вас понял в таком ключе "и так работает" = приносит деньги, но код организован плохо и процессы не очень эффективны.

Я бы уточнил - "_пока_ приносит деньги"

Я бы уточнил - "_пока_ приносит деньги"

тут тоже нужны расчеты, без них любые аргументы для бизнеса будут просто "пустыми словами"

т.к. бизнес никогда не стоит на месте, он как в игре flappy bird, либо вверх, либо вниз летит.

т.к. бизнес никогда не стоит на месте, он как в игре flappy bird, либо вверх, либо вниз летит.

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

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

ERROR: S client not available

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

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

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

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

Какие метрики брать - непонятно. Их не придумали пока еще.

Какие метрики брать - непонятно. Их не придумали пока еще.

это можно не метриками мерять, а реальной пользой. Например: отрефакторив большой модуль, разделив логику и ускорив обработку процессов, что потенциально увеличит быстродействие системы на n% и скорость обработки заявок операторами на m%

По-моему это как раз пример метрик

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

тут вы говорите о проблеме непонимания менеджерами инженеров, а инженеров менеджерами.

Но сложность в том что в реальности будет: - быстродействие системы увеличилось на n% - скорость обработки заявок возросла на m% - нагрузка на админов и девопсов по поддержке нового решения возросла на p% и они начали q% задач срывать сроки - аптайм провалился на r% - разработчики стали закрывать таски медленнее на s% из-за того что в новом модуле надо теперь успевать фиксить баги - в офисе стало на t% больше паникеров, которые кричат что старая версия работала лучше и вносят напряженность в команду

И еще 42 параметра в оценочной формуле ^^

Но сложность в том что в реальности будет: - быстродействие системы увеличилось на n% - скорость обработки заявок возросла на m% - нагрузка на админов и девопсов по поддержке нового решения возросла на p% и они начали q% задач срывать сроки - аптайм провалился на r% - разработчики стали закрывать таски медленнее на s% из-за того что в новом модуле надо теперь успевать фиксить баги - в офисе стало на t% больше паникеров, которые кричат что старая версия работала лучше и вносят напряженность в команду

Абсолютно с вами согласен. С этим нужно бороться сообща с менеджером. А если с ним недопонимание, то тогда и нет смысла ругать его/их, он вас просто не понимает.

в этом вопросе я отталкиваюсь от позиции: "не они меня не понимают, а я объясняю не так".

Когда все аргументы закончились, остается только обхамить ?

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

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

какой у вас богатый арсенал манипуляций административным персоналом :)

Ой, как будто так делают не только лишь все.

Ой, как будто так делают не только лишь все.

делают, но не все)

Ребята, внесите ясность

Когда говорят о 100℅покрытии тестами, имеется ввиду лишь автоматика или же всё?

А какой контекст?

Веб приложение

яснее не стало.

Когда говорят о 100℅покрытии тестами, имеется ввиду лишь автоматика или же всё?

дык спроси че ты , тип вам что надо

Ага, я понял

СПС

Когда говорят о 100℅покрытии тестами, имеется ввиду лишь автоматика или же всё?

Есть мысля, что когда слышишь про 100% покрытие тестами, надо убигать

Когда говорят о 100℅покрытии тестами, имеется ввиду лишь автоматика или же всё?

Нет

ребят вопрос по аппиуму) Error: Command '/bin/bash Scripts/bootstrap.sh -d' exited with code 1 at ChildProcess.<anonymous> (../../lib/teen_process.js:66:19) at emitTwo (events.js:106:13) at ChildProcess.emit (events.js:191:7) at maybeClose (internal/child_process.js:877:16) at Process.ChildProcess._handle.onexit (internal/child_process.js:226:5) { Error: Command '/bin/bash Scripts/bootstrap.sh -d' exited with code 1 at ChildProcess.<anonymous> (../../lib/teen_process.js:66:19) at emitTwo (events.js:106:13) at ChildProcess.emit (events.js:191:7) at maybeClose (internal/child_process.js:877:16) at Process.ChildProcess._handle.onexit (internal/child_process.js:226:5) stdout: '\u001b[1mFetching dependencies\n*** Downloading peertalk.framework binary at "v1.0"\n', stderr: 'Failed to write to /usr/local/lib/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent/Carthage/Build/Mac: Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “Mac” in the folder “Build”." UserInfo={NSFilePath=/usr/local/lib/node_modules/appium/node_modules/appium-xcuitest-driver/WebDriverAgent/Carthage/Build/Mac, NSUnderlyingError=0x7f8fd5430cf0 {Error Domain=NSPOSIXErrorDomain Code=13 "Permission denied"}}\n', code: 1 } вот такое падает эмулятор стартует и потом я так понял при попытке поставить приложение падает такое, ставил аппиум через sudo без него нехватало прав, где то в интернетах натыкался что это может быть следствием такой установки, сталкивались с таким?

А если права на папку поменять?

Должно решить данную проблему

Или и скрип через sudo вызывать

дай права на папку sudo или chmod там

export джавы проверь или че там у тебя