Инструкция по выживанию при построении отдела тестирования с нуля

Доклад с весенней кофнеренции ConfetQA
Инструкция по выживанию при построении отдела тестирования с нуля.

Потихоньку собираю свои видеозаписи.

Как избежать ссор в команде тестировщиков и разрешить имеющиеся. Осень 2012

Откопал свой старый доклад с Осенней 2012 ConfetQA

Потихоньку собираю свои видеозаписи.

Праздничная скидка на тренинги 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.
Самое время пересмотреть ваши модусы.

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

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

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

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

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

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

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

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

Тест-кейз?

А дайте ваше определение тест-кейза? Своими словами.
А то после прочтения этой статьи у нас с коллегами разгорелась дискуссия.
Отдельно в тред приглашается Лёша Лупан, как эксперт и человек, делавший доклад на тему тест-кейзов на Львовской SQA Days. 

Мы начинаем завоёвывать мир. HQA.CC

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

И вот эта идея осуществилась. 

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

http://www.hqa.cc/

Наш девиз: от эскиза до релиза.

Хозяйке на заметку.

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

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

Брограммист.

Кажется, только что придумал новый термин.
"Брограммист". Это такой программист, это который почти не делает ошибок в коде, а если и делает, то после их обнаружения говорит "Извини, бро, я накосячил. Давай вечерком по пиву? Я ставлю!".

Методики обучения сотрудников.

Давным-давно я тут писал пост про МОПС.
Сейчас хочу поделиться наблюдениями о том,
как происходит обучение в большинстве компаний.
На самом деле.
Я выявил три основных методики и назвал их соответственно.

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

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

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

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


Вот те методики с которыми я сталкивался.
Мне кажется, что они основные и на их базе строятся остальные.

А какие встречали вы?
Расскажите как обучали вас и как обучаете вы?

Недосмарт.

Не умеем ставить задачи.
До S.M.A.R.T. далеко ещё, его внедрять надо долго и упорно.
Главная проблема - это проецирование и путаница в признаках.
Спросишь человека "что делать"? А он тебе начинает пространно объяснять "как делать".
Даже через "5 почему" выходит что человек и сам не до конца понимает зачем это нужно.
Почему? Потому что ему не объяснили.

Вот три кита, на которых зиждится постановка задачи хотя бы на раннем и примерном уровне:
ЗАЧЕМ?
ЧТО?
КАК?

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

Хроники Отдела Тестирования. Часть 4: На недельку, до второго.

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

Там или тут?

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

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

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

А как считаете вы?

Рубрика "Хозяйке на заметку".

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

Я не знаю что происходит и как это работает, но атмосфера становится более дружелюбной.

Люди начинают говорить тише и более конструктивно.

Градус накала реально снижается. Народ начинает давать реальный конструктив.

Креатив прет, да.

Приятное открытие. Может и велосипед, но я прочувствовал.

Холиварчик.

"Личный героизм сотрудников и менеджеров — всегда следствие недоработки в планировании и управлении" (с)

А вы согласны с этим утверждением?

Back to basics.

По следам поста Оли Киселевой
В принципе, базовая вещь, которую должен знать каждый тестер.
Оля всё правильно пишет. Красиво и с примерами.
Вот моя выжимка:

1. Тестирование на позитивных значениях.
Обычно используются пользовательские сценарии с корректными значениями.
Проверяем работоспособность заявленного функционала.

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

3. Тестирование в невозможных конфигурациях.
Своеобразный эд-хок. Проверка того, что система корректно обрабатывает нештатные ситуации и эксепшны.

В принципе, две последних парадигмы некоторые объединяют в одну, но я бы не стал этого делать. 

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

Иногда полезно вспомнить основы.

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

Музыкальный холл.
Оркестр. Играет под палочку дирижера.
Зрители слышат чудесную музыку. Ни одной фальшивой ноты.
А перед тем как все начали хорошо играть по нотам их долго рассаживали по секциям с учетом акустики и инструментов. Вот секция скрипки - тут скрипачки сидят, рядом флейты. Тарелки - в жопе, чтобы никого не глушили.
Они сыгрывались и подбирали вместе с дирижером мелодию на слух. Записывали. Фиксировали.
Потом как-то раз тапёр пришел на репетицию в спортивных штанах и пьяный.
Так появились правила.
И вот они ВИА! Они сыгрались, у них есть четкие инструкции когда какую нотку сыграть, где затянуть, какой фрак одеть и во сколько приходить на репетицию и на концерт, в какой тональности настраивать инструмент.
Публика рада.
И тут один виолончелист вскакивает и говорит "Ну вашу мать! Ну сколько можно! По нотам играем же! Не интересно же! У меня мозг не работает! Никакого, блин, развития!"

Ищу тестера со знанием польского.

Коллеги, а есть у кого тестеры? Можно даже довольно таки джуниоры.
Ключевое условие - сносное знание польского языка.
Мы его не обидим )
Кстати, русским владеть не обязательно. Главное знать английский и польский.

4 заповеди аналитика.

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

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

Вторая заповедь аналитика.
Сначала - варианты использования. Потом - постановки задач.

Третья заповедь аналитика
Проверки требований (How to demo) пишутся одновременно с требованиями.

(с) Наталья Желнова