Праздничная скидка на тренинги software-testing.ru

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

Рекламирую курсы от Software-Testing.ru
Курсы хорошие и полезные. Я сам прошел несколько из них и очень много важного и пригодившегося позднее из них вынес. Я не буду раскрывать их содержание - это не мой хлеб, всё можно подробно почитать по ссылкам. Одно могу сказать точно - они стоят каждой заплаченной за них копеечки и даже больше.
Тестирование
Тест-дизайн
Программирование для тестировщиков
Автоматизация
Юзабилити
Тест-менеджмент

Всё это и многое другое можно найти в соответствующих тренингах.
А теперь моё вам предложение:
Каждый, кто до нового года зарегистрируется и оплатит тренинг получит скидку 5%.
Пусть не много, но лучше чем ничего. Если вы давно хотели попробовать эти курсы и тренинги, но не решались - вот удачный шанс.
И, чуть не забыл. Скидку вы получите, если при регистрации укажете или упомянете промокод: "Шестерёнка". Вот именно так: "Промо-код: Шестерёнка".

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

Картинка Для Привлечения Внимания:

SQA Days 16 - Мясников.

Ура!
Друзья, наконец-то выложили мой доклад с SQA Days 16!

http://vimeo.com/114338814

Если это было вам интересно и остались вопросы, то я готов ответить на них!
Cheers!

О бедном RedMine замолвите слово.

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

Перегонка (импорт) тест-кейзов в Testlink

Наверняка, многие сталкивались с такой проблемой, что тестлинк не мог корректно впихнуть в себя ваши xml, которые вы по всем правилам получили, конвертнув xls.

Я уже давно не занимаюсь тестлинком, но вместе с вами помню эту боль.
Сегодня, Андрей Бессолицын во время беседы упомянул один волшебный инструментик, который помогает сделать это быстро, безболезненно и очень эффективно.
Знакомьтесь:
http://sourceforge.net/projects/ex-converter/

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

Долгосрочное и краткосрочное планирование.

Осознал, что я не люблю краткосрочное планирование, но обожаю долгосрочное.
Не только в работе, но и в жизни.
Краткосрочное использую, конечно, но в случаях форс-мажоров (редких) или при координации нескольких людей в сжатые сроки. Либо когда задача очень ответственная и нужна прозрачность.
Ну а так предпочитаю свободу в выборе задач. Главное, чтобы к майлстоуну всё было готово.
Майлстоуны же планирую основательно и крепко, наслаждаясь процессом и стараясь учитывать каждую мелочь приходя в восторг от структуры и расстановки приоритетов.
Планирую, кстати, в связке "гуглокалендарь + трелло".
А у вас как?

Хроники Отдела Тестирования. Часть 4-2: Мировое господство.

Эта часть напрямую связана с предыдущей, поэтому за началом сюда:

Как посчитать вклад в проект?

Мальчики и девочки, мы продолжаем рубрику "просто о сложном".
Сегодня мы поговорим с вами о KPI в применении к вкладу сотрудников в проект.
Раз уж взялся капитанить, то продолжу.

Пример будет простой и наглядный.
Допустим, вы тест-менеджер и у вас в подчинении 4 человека.
Пусть это будут А, Б, В, Г:
Андрей
Борис
Вика
Галя

Вы замечательно протестировали продукт и сдали его заказчику.
Заказчик так рад, что хочет раздать всем премии. Как делить - решать вам.
Андрей упорно работал, щелкал задачки как орехи.
Борис неделю болел, но выполнил одну оооочень важную задачу.
Вика работала упорно и много задерживалась.
Что-то не получалось, но было видно, что она очень старается.
Галя работала... ну как-то средне. Вы не обращали на неё внимания.
То есть поделить просто 25%+25%+25%+25% не получится.
Ах да! И себя же надо не обделить!

Что я предлагаю делать в таких случаях:
Давайте для начал будем оценивать весь объём работ как единицу.
Ну или 100%. Лучше будет даже 100 баллов.
Далее. Каждой задачке даем "вес" в определенное количество баллов.
Так, например, тест элементов главной странички сайта - это 5 баллов.
А вот тест бэкенда - это 10 баллов.
И так далее и тому подобное, пока всё не будет посчитано.
Таким образом, все наши задачки, которые выполнялись в процессе тестирования,
составят эти самые 100 баллов.

А вот, когда мы всё оценили, то получается, что Андрей хоть и щелкал задачки,
но они были простые и общий вклад у него не больше 15 баллов.
Борис сделал хорошую задачку сразу на 10 баллов и добил маленькими до 18.
Вика со всем своим сидением на работе и тщанием не заработала более 10 баллов.
А вот Галя, которая "вроде бы работала как работала",
оказывается, сделала работы аж на 30 баллов!
Не забываем и себя любимого.
В итоге получаем:

Андрей - 15
Борис - 18
Вика - 10
Галя - 30
Тест-менеджер: 27

Что это значит?
Андрей - 15% от всех денег
Борис - 18% от всех денег
Вика - 10% от всех денег
Галя - 30% от всех денег
Тест-менеджер: 27% от всех денег

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

В зависимости от ваших отношений с командой, процесс определения вклада можно
делать прозрачным или нет. Здесь ничего не посоветую. Всё зависит от вас.
Искренне ваш, Капитан Очевидность.
Оставайтесь на линии, до новых встреч!

З.ы. Отпишите, пожалуйста, в каментах, нужна ли эта капитанская рубрика или все всё и так про это знают и расписывать такие штуки нет смысла?

Метод цепных оценок простым языком.

Рассказывал молодому специалисту, решил поделиться тут.

Короче, моделируем ситуацию.
Допустим ты менеджер и у тебя есть задача протестировать что-то.
Назовем условно "Объект".
Итак.
Тебя спрашивают, к когда ты сможешь это сделать?
Ты прикидываешь.
И тут тебе приходит на помощь "метод цепной оценки".
Ты можешь выдать три дедлайна.

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

Однако ты должен учитывать риски.
Например, один из сотрудников говорит, что ему надо на учебу и он пробудет там весь день.
То есть тестить вам придётся уже полтора дня. Ибо его часть работы расползется по оставшемуся сотруднику и тебе. Логично?
Да и ты понимаешь, что тебе спокойно не дадут погрузиться, а будут дёргать.
Значит ты будешь выполнять свою работу дольше.
То есть на тесты отведится уже два дня.
Это - оранжевый дедлайн.

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

Что значат эти цвета?
Зеленый дедлайн - это выполнение задачи в идеальных условиях.
Красный - это с учетом большинства рисков и проблем.
Оранжевый - это среднее время выполнения задачи.

В среднем оранжевый дедлайн это среднее арифметическое от красного и зеленого, умноженное на 90%.
То есть О =  (З + К)/2*0.9

Последний коэффициент я выработал эмпирическим путем.
У крепко сработавшейся команды и с нормальными процессами это может быть 75%. Середнячок 90%.
Если по итогам расчетов на ретроспективе коэффициент получился больше 100% - "что-то пошло не так" (с) и где-то у вас есть узкое место и какой-то timeleak.
Самое время пересмотреть ваши модусы.

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

Дилемма заключенного

Вынес для себя очень много интересного из данной статьи.
Суть в том, что некоторые, на первый взгляд, нелогичные поведения при взаимодействии с командой могут привести к взаимовыгодному результату.
Или как минимизировать ущерб при взаимном нарушении договоров.
Чума, вобщем. Интересно!
Как оказалось, кое-какие стратегии применял раньше неосознанно.
Где-то изобрел велосипед.
Схему Рапопорта использовал на прошлой работе. Но не очень успешно.

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

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

Имхо, будет особенно полезно для тех, кто работает с краудсорсными командами.

"Тестер" или "Тестировщик"?

"Тестер" или "Тестировщик"?
Как вас называют на работе? Как вы сами себя называете? Как правильно?
Не знаю как тут сделать опрос, но интересно, какое название вам больше нравится.
Свои версии в комментарии. Холивары приветствуются.