Название баги
Компонент (или категория)
Критичность

Это, скорее всего,  развод.

Но меня зацепило другое -

 

 

мне сидеть минимум 4 часа шпилить в эту дебильную игру

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

Какой продукт вы используете для ежедневной/еженедельной постановки задач на тестирование регрессов?
Т.е. что вы используете, чтобы одни и те же задачи ставить на тестирование каждый день + новые фичи?

teamwork (http://www.teamworkpm.net/index.cfm)


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

http://automated-tes...o/t/soapui/2477
http://habrahabr.ru/post/111486/
http://denys-nikolay.../03/soapui.html
http://www.slideshar...soapui-28232583


Вообще гугл в помощь.)

Возможно, стоит писать, что само начало в 19:00 (хотя тогда все подойдут к 19:30 ?).

да, а то и к 20-00

Мне на почту пришло письмо, в котором было написано, что начало встречи в 18:30.
В письме не было написано, что 30 минут дается на сбор участников.
Возможно, стоит писать, что само начало в 19:00 (хотя тогда все подойдут к 19:30 ?).

Ну так начало встречи 18-30)
Первый доклад в 19-00 (на сайте в анонсах везде указано)

пол часа на сборы и познакомится. =)

По поводу ведущего тестиировщика и всего прочитанного выше.

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

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

Да вы убьете на эту летучку час - два, но ведущему тестировщику потом не придеться сидеть и перепроверять каждый чек лист.(это ж с ума сойти)
На майнд карте будут отмечаться пункты проверки. И ведущему тестировщику наглядно будет видно, что происходит с тестами ПО.
Судя по описанию у ведущего тестировщика нет времени обучать команду.
Мне вообще не понять как так могут работать люди. Если они не могут написать тесты, то как они тестируют в целом? Это же 90% что будут пропущены баги.

Ну или отправьте их на тренинги что-ли. Благо их даже в онлайне куча.

У нас все в точности так-же. Проблема сохраняется - под конец кто-то находит баг в проверенном модуле. При чем зачастую баг из серии "решили сейчас вот немного по другому проверить и ..."

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

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

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

Но вообще это все проблема коммуникаций. В тот же скайп /вики / подойти сказать / что вот мы еще вот это изменили вроде как не сложно. Но все почему-то об этом забывают.
Последнее время я сразу пытаю разработчика о чем в очередной раз они говорили с пм-ом.
а перед сдачей билда спрашиваю и ПМ-а, что они вносили новенького кроме ... перечисляю.
Обычно что-то всплывает.
Но это тоже не всегда выход.
Поэтому, что не описано в задачке на тестирование (в вики) - если ушло на боевой - сам ПМ и бьется головой. Или убивает разработчиков что не внесли.
как -то так.

Что не понравилось:
Начало задержали на 40 минут.

Начало не задержали. Начало практически всегда в 19-00.
пол часа дается на сбор всех участников.
Большинство не такие оперативные как вы, к сожалению

Обрати внимание на задания.
отказ от задания - повторно взять можно?
если задание одноразовое на персонажа, то нельзя ли его взять на сл. день или после того как персонаж получит новый уровень
проверь мобов
режим боя
получение плюшек за него
получение опыта
отображение предметов
что будет если в режиме боя персонажа выкинет из игры (разрыв инета)
что будет если закинуть денег и купить что-то что нельзя одеть на твоем уровне.
по поводу покрышек - что будет если купить их раньше чем взят квест? "увидит" ли квест что предметы для его завершения уже есть
что будет если купить покрышки -взять квест- увидеть что квест готов к завершению и выкинуть/продать/отправить другому игроку покрышки? завершится ли квест без них?
что будет если сделать тоже самое но не со всеми 5 покрышками а с 4. (избавится от одной)
что будет если взять квест и выйти из игры. При повторном заходе останется ли квест активным.
если по квесту надо убить Х кого-то чего-то , проверить обнулится ли квест если перезайти/вылететь/отказаться
проверить карту.
передвижение, указание маппоинтов на место для выполнения квестов, отображение врагов_друзей
включение выключение разных настроек.
проверить все комбинации с настройками игры.
проверить установку игры.( если требуется не только геймплей описать)
маппоинты кстати обычно пропадают при перезаходе игрока, тоже проверьте
проверьте альянсы (группы, кланы)
проверьте все описания, сроки годности, время действия бафов.
вобщем, игры такая штука, все что видишь - проверяй. и по Х раз.)
ну и корректность получение параметров от новой "экипировки" также проверьте.
можно еще долго продолжать список.)

Вчера прошла последняя встреча тестировщиков в этом году.
Тема встречи: «Гибкость – как правильно жить и работать?».
Были прослушаны такие доклады:

Михаил Заборов (Зам. директора по стратегическим проектам, Custis)
Очень часто и очень многие понимают SCRUM догматично: «Только использование канонических процессов SCRUM дает действительно существенный позитивный результат».

На самом деле, это часто вредит процессу. Можно и нужно периодически отходить от «правил» SCRUM, не отходя при этом от принципов agile.
Из доклада вы узнаете о случаях из реальной практики, когда следование “канонам” не помогает, а иногда и существенно вредит процессу, а также варианты ослабления требований к процессу или его альтернативная организация.


Андрей Дзыня (Software Testing Consultant / Technical Test Lead @ Kuoni)
HOW TO MANAGE TESTING IN DYNAMIC WORLD?

Случившиеся за последнее пятилетие изменения в процессах существенно повлияли на распределение задач разработчиков и тестировщиков. Многие начали задаваться вопросами тестирования, некоторые попытались найти ответы у Agile-евангелистов и получили совет: применяйте автоматизацию тестирования и Exploratory Testing.
Однако, мало кто может рассказать, как разные практики связать воедино и держать под контролем. В динамичных условиях создания продуктов придерживаться классических процессов тестирования крайне сложно.
Этот доклад будет интересен как тем участникам, которые работают по старинке, со значительным разделением функций разработчиков и тестировщиков, так и членов стартап-команд, у которых «нет времени» ни на документацию, ни на автоматизацию, ни на отчетность. В докладе я постараюсь показать сбалансированный подход к управлению тестированием в контексте гибких проектов, а также дать ответы на ряд практических вопросов.

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

Тем не менее, хотелось бы услышать ваши отзывы о встрече. Что понравилось, что нет.

Ждем комментариев.
Заранее спасибо.

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

№ бага, описание бага, критичность, время нахождения/номер билда. дополнение. статус. № билда с фиксом. регресс тест. (дальше статус и регресс повторяется до фикса)

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

Время расчитать можно исходя из сложности самого билда, из просчета времени на тестирование со стороны отдела тестирования, и видя баги программист может сказать сколько времени ушло на фиксы. Добавляем предыдущий опыт с похожими билдами и примерно на 90% знаем точное время окончания выполнения задачки.
Удобство в том что и тестировщики и программисты в данной задачке не ограничеы.
Добавляется графа с тестировщик/програмист где указывается ФИО автора.

у меня только одна мысль -
НАФИГА?