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

Грустненько, в общем, но жить как-то надо и ЗП вы еще хотите получать, я думаю :) Поэтому в текущих обстоятельствах кроме ненавистных "Покрытие такого-то функционала тестами n%", "Покрытие регрессии m%", "Найдено х багов, из них по критичности:", "Количество переоткрытых багов" вариантов не вижу. Мб более опытные коллеги подскажут вариант лучше.

Коллеги стоит такая задача: Дано: CI который выплевывает наружу на Pull Request три артефакта, нативный бинарник для osx,linux,windows Мой вопрос: какие есть средства автоматизации что бы запустить этот бинарник в windows,osx,linux (слейвы есть в jenkins) что бы автоматизировать следующий тест: запустить бинарник на платформе (osx,windows,linux) бинарник отрисует GUI морду с единственным полем ввода в единственное поле ввода ввести текст и нажать enter. все тест окончен.

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

Грустненько, в общем, но жить как-то надо и ЗП вы еще хотите получать, я думаю :) Поэтому в текущих обстоятельствах кроме ненавистных "Покрытие такого-то функционала тестами n%", "Покрытие регрессии m%", "Найдено х багов, из них по критичности:", "Количество переоткрытых багов" вариантов не вижу. Мб более опытные коллеги подскажут вариант лучше.

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

снимайте на камеру, как вы работаете

отлично все будет документироваться!

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

Заказчик хочет видеть на что он тратит деньги при отсутствии проблем?

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

А вы не поможете найти изъян в логике? Слова техлида: "Вас 6 человек. Если вы тратите 15 минут на ежедневное собрание - это 1,5 человеко-часа. Гораздо лучше делать так: старший QA за эти же 15 минут формирует задачи на команду, за минуту каждому объясняет. В итоге команда тратит 20 минут, т.е. 1/3 человеко-часа." Чувствую, что что-то не так...

Заказчик хочет видеть на что он тратит деньги при отсутствии проблем?

Ну так ясно написали же, заказчик хочет тратить деньги на отчеты :)

Заказчик хочет видеть на что он тратит деньги при отсутствии проблем?

?

А вы не поможете найти изъян в логике? Слова техлида: "Вас 6 человек. Если вы тратите 15 минут на ежедневное собрание - это 1,5 человеко-часа. Гораздо лучше делать так: старший QA за эти же 15 минут формирует задачи на команду, за минуту каждому объясняет. В итоге команда тратит 20 минут, т.е. 1/3 человеко-часа." Чувствую, что что-то не так...

Как из 15 минут собрания 6 человек вместе получается 1.5 человекочаса? Каждый поодиночке "собирается"?

Ну, мол время каждого тестера тратится

А так - только одного

Ну так и в первом случае от времени каждого тестера тратится 15 минут

Как из 15 минут собрания 6 человек вместе получается 1.5 человекочаса? Каждый поодиночке "собирается"?

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

в теории

А вы не поможете найти изъян в логике? Слова техлида: "Вас 6 человек. Если вы тратите 15 минут на ежедневное собрание - это 1,5 человеко-часа. Гораздо лучше делать так: старший QA за эти же 15 минут формирует задачи на команду, за минуту каждому объясняет. В итоге команда тратит 20 минут, т.е. 1/3 человеко-часа." Чувствую, что что-то не так...

Похоже на экономию на спичках.

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

Похоже на экономию на спичках.

Поясните?

и, да, "объяснит за минуту" — не верю

Поясните?

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

"что вы делали 10 минут в туалете?"

извините

Поясните?

Дейлик в 15 минут - это 1/32 всего дня. Не верю, что за 1/32 вы сделаете что-то настолько полезное, что можно променять на это синхронизацию команды.

Имхо, в предложенном случае иерахия даст больший минус. Вместо одного командного, например, созвона в 15 минут будет 6 созвонов по минуте (присоединяюсь к Алексею, не верю).

Имхо, в предложенном случае иерахия даст больший минус. Вместо одного командного, например, созвона в 15 минут будет 6 созвонов по минуте (присоединяюсь к Алексею, не верю).

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

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

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

Ну они же зачем-то сейчас собираются :)

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

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

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

потому что они люди и им надо общаться

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

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

Только время пребывания там не регламентировать (если вы не на галере)

и вообще, вы так минуты считаете, как будто верите, что в течение 8 часового рабочего дня человек работает 8 часов :)

Считаю не я(( Политика компании такая. Да и галерность чувствуется, вот только думаю, нужно ли пытаться улучшать рабочий процесс? Или работать по зарекомендованной схеме "не трожь - и так работает"

и вообще, вы так минуты считаете, как будто верите, что в течение 8 часового рабочего дня человек работает 8 часов :)

а сколько надо трекать часов?)

сколько НАДО? откуда я знаю. KPI они такие, сказано 8 — затрекают 8

У нас планируется условно 80% рабочего времени

вы ещё думать нерабочие мысли запретите во время работы. а то отвлекает :)

Считаю не я(( Политика компании такая. Да и галерность чувствуется, вот только думаю, нужно ли пытаться улучшать рабочий процесс? Или работать по зарекомендованной схеме "не трожь - и так работает"

По возможности улучшать конечно стоит, но в ваших обстоятельствах я сильно сомневаюсь, что это реально. Между вами и ЛПР (лицо, принимающее решения) сколько людей в иерархии?

люди хорошо работают тогда, когда их штырит, а не когда им надо 8 часов затрекать каждый день

Генеральный->Техлид->старшийQA->я

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

А вы не поможете найти изъян в логике? Слова техлида: "Вас 6 человек. Если вы тратите 15 минут на ежедневное собрание - это 1,5 человеко-часа. Гораздо лучше делать так: старший QA за эти же 15 минут формирует задачи на команду, за минуту каждому объясняет. В итоге команда тратит 20 минут, т.е. 1/3 человеко-часа." Чувствую, что что-то не так...

А общие новости по проекту рассказывать лиду 5 раз подряд?

Если конечный результат на ваш взгляд стоит всех этих мытарств, то дерзайте :)

это был риторический вопрос

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

либо у них были слабые сязи в задачах.

Есть хорошее правило: не посещать те встречи, где ты молчишь

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

Есть хорошее правило: не посещать те встречи, где ты молчишь

курсы оракулов у меня только с ледующем году =)

а как до встречи понять что на ней у меня не возникнет вопросов к тому что делают другие?

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

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

Ну зачем Васе знать, что Петя тестирует новую функциональность А, если Васина задача по тестированию функциональности Б никак не пересекается с Петеной задачей?

если не пересекается, то на стендапе они не потратят на обсуждение этих задач много времени. Петя скажет, что он сегодня тестирует А, а Вася скажет, что он тестирует Б, вот и все

Ну зачем Васе знать, что Петя тестирует новую функциональность А, если Васина задача по тестированию функциональности Б никак не пересекается с Петеной задачей?

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

если не пересекается, то на стендапе они не потратят на обсуждение этих задач много времени. Петя скажет, что он сегодня тестирует А, а Вася скажет, что он тестирует Б, вот и все

Но и ходить на стендап для них смысла нет

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

разве это не задача тимлида, знать, что делает каждый человек в команде?

задача каждого человека в команде знать что делает команда.

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

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

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

а если Вася не узнает про это — он ничего Пете не скажет

разве это не задача тимлида, знать, что делает каждый человек в команде?

Благодарю за ответ. Неожиданно понял в чём дело

не относитесь к любям как к биороботам, "вот тебе задача, сиди делай"

ERROR: S client not available

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

Это если скрам и т.п. Опять же, с вероятностью 95%, если в команде иерархия, то задача по тестированию функционала А в следующем релизе/спринте опять лажет на Васю (т.к. он его уже тестил).

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

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

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

Я видел людей, которых вы описываете, но так же видел и в обратную сторону, когда люди спокойно делали свои задачи и были мало вовлечены в судьбу проекта (при этом делали задачи лучше тех, кто был сильно вовлечён в проект)

есть пункт "степень готовности продукта к релизу", это какой-то философский вопрос или все-таки можно как-то его выразить?))

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

Конечно полезно, но тяжелореализуемо

есть пункт "степень готовности продукта к релизу", это какой-то философский вопрос или все-таки можно как-то его выразить?))

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

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

тест-плана?

Нет

проекта

Конечно полезно, но тяжелореализуемо

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

Нет

а если нет плана проекта?)

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

Да это конечно так

а если нет плана проекта?)

Тогда беда =)

Если нет плана проекта, как вы знаете финальный скоуп на релиз?

если конечно у вас не скрам

Если нет плана проекта, как вы знаете финальный скоуп на релиз?

???

если конечно у вас не скрам

он самый

тогда откуда у вас тестплан?

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

есть пункт "степень готовности продукта к релизу", это какой-то философский вопрос или все-таки можно как-то его выразить?))

Опять разбираемся - вы как тестировщик каким боком отвечаете за степень готовности продукта? ПМ в команде есть?

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

Опять разбираемся - вы как тестировщик каким боком отвечаете за степень готовности продукта? ПМ в команде есть?

ОТЧЕТЫ ОТЧЕТЫ

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

во, это интересно

Про отчеты я помню, но что-то мне кажется, что на вас еще чужую работу навешивают

Про отчеты я помню, но что-то мне кажется, что на вас еще чужую работу навешивают

м, вполне. команда маленькая)

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

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

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

а что такое сторипоинт?

а что такое сторипоинт?

А как вы работаете по скраму без сторипоинтов?

Вы как тестировщик можете сделать оценку вида "задача такая-то реализована со следующими багами"

А то, о чем пишет Юрий, имхо уже зона ответственности ПМ // product owner

А то, о чем пишет Юрий, имхо уже зона ответственности ПМ // product owner

Да, согласен. Но речь была о продукте к релизу, о неё и говорю