В нашу эру центрального отопления и повальной распространённости веб-сервисов многие люди, даже мэтры тестирования, предлагают рассматривать нагрузочное тестирование и тестирование производительности лишь в связке. Причина проста: тестируем веб, вот и смотрим скорость отклика (производительность) под разной нагрузкой: от одного до N клиентов.
В результате такого восприятия теряется понимание тестирования производительности, которое является НУ ОЧЕНЬ важным, потому что:
1) Вы любите, когда что-то тормозит? Клиенты тоже не любят, обычно баги производительности являются критичными.
2) Чаще всего проблемы с производительностью являются архитектурными. Когда клиенты их репортят, исправлять их уже поздно.
3) Локализовать ошибки производительности - это сложно, это действительно искусство.
4) Неграмотное тестирование производительности ("здесь что-то тормозит") почти всегда ведёт к тому, что критичный баг переходит в разряд KNOWN ISSUES. Чтобы этот баг мог быть исправленным, тестировщику придётся потрудиться!
Если не находить проблемы с производительностью, мы получаем большой удар по качеству продукта. Находить неправильно - аналогично, "здесь что-то тормозит" не поддаётся исправлению.
Чтобы разобраться с тем, как тестировать производительность, да ещё и чтобы повысить вероятность исправления дефектов, я перечислю основные подходы к тестированию производительности. Для удобства восприятия, все подходы будут разбираться на примере архиватора файлов.
1) Отлавливаем "провалы" в производительности.
Разработчики могут вносить ошибки, связанные с производительностью, в любой момент. Чем раньше они узнают о проблеме - тем лучше.
Берём некий набор файлов и на каждой сборке измеряем скорость его архивации. Таким образом мы смотрим, не отразились ли изменения в продукте на скорости работы.
Что важно:
- автоматизация. КАЖДЫЙ билд значит КАЖДЫЙ, это важно и чтобы вовремя заметить проблему, и чтобы чётче локализовать причины для разработчиков. Тесты на скорость работы - первые кандидаты в автоматизацию.
- "правильный" набор файлов. Это должны быть наиболее часто используемые пользователями размеры и типы файлов, чтобы наши тесты были наиболее приближены к жизни.
Поиск провалов - единственный тип тестов производительности, которые достаточно часто реализуются. С остальными хуже.
2) Сравниваем себя с конкурентами. В то время как маркетологи всё ещё гоняются за "фичез-листами", пользователи уже давно ищут телефоны без фотокамер. Пользователям важно ПРОСТО и БЫСТРО. Ну, и ещё 5-10% от функционала Вашего ПО. Поэтому, нам надо проверять, насколько наша скорость сопоставима со скоростью конкурентов. И если мы в 2, 3, 5 раз медленнее - бить в колокол.
Что важно:
- обеспечить абсолютно одинаковые условия. Окружения, файлы, последовательность действий.
- проводить замеры несколько раз. Если в показателях большая дисперсия, то, возможно, мы что-то делаем неправильно.
3) Ищем "провалы" производительности, зависящие от внешних факторов.
Часто бывает такое, что пользователи жалуются "медленно", а мы вроде бы (по своим замерам) в несколько раз быстрее конкурентов. Поддельные тестировщики в ответ на такие жалобы в support отвечают "у нас всё хорошо". Настоящие тестировщики уже знают, в чём причина!
Узнаём всё, что может влиять на скорость работы. Типы файлов? Размеры архива? Файловая система? Операционка? Размер кластера? День недели? Расположение звёзд? И проводим тесты, сравнивающие производительность в зависимости от этих факторов. Зачастую бывает такое, что из-за использования неграмотного драйвера сохранение архива на фат может занимать в 30 раз больше времени, чем на нтфс, который входит в Вашу "стандартную" конфигурацию. Пользователи просто не дождутся результата!!
ОДНИМ из параметров тестов МОЖЕТ БЫТЬ количество подключений в клиент-серверном ПО. Все остальные тесты НЕ имеют отношения к нагрузочному тестированию.
Что важно:
- провести грамотный анализ входных влиющих значений. Оперируем собственным опытом, логикой, интуицией и ходим к гадалке. Иногда причины провалов абсолютно неочевидны, поэтому пробовать надо всё. При грамотной параметризированной автоматизации это всё равно не потратит Ваше время.
- исследовать архитектуру продукта, делать тестирование производительности grey-box техникой. Поговорите с разработчиками. Они конечно же скажут, что ничто не может влиять на результат - у них работа такая :) Узнайте, какие ветви кода вызываются в зависимости от каких условий. Подумайте, как Вы можете вызвать не проверенные ветки кода, как задействовать эти условия?
4) Ищем узкие горлышки aka bottleneck'и. Если наш продукт неэффективно использует ресурсы компьютера, то мы либо теряем огромный запас в скорости работы, либо становимся почти неработоспособными на конкретных "железках". Свой продукт надо знать в лицо! Что ограничивает его скорость?
При проведении тестов, обязательно включаем все возможные мониторы. Какой ресурс занят на 100%?
Никакой, и до 100% всем далеко? Проблема алгоритма, мы написали немасштабируемый софт!
Один, а остальные близки к нулю? Очень велика вероятность того, что мы не используем огромный запас скорости!
В любом случае, сообщая в дефекте сразу, в чём проблема, сеть является "боттлнеком", база или память, мы значительно помогаем разработчикам в исправлении - они сразу будут знать, "куда копать".
5) Общие советы.
Чтобы сделать тестирование производительности эффективным:
- убедите аналитиков и маркетологов или кто-там-у-вас-определяет-что-нужно-пользователям, что производительность - это ВАЖНО! Во-первых, это действительно важно. Во-вторых, к счастью, почти все и так это понимают.
- привлекайте к тест-анализу разработчиков. Они могут помочь как никто другой.
- сделайте ОЧЕНЬ понятный отчёт. Если вывести в текстовый лог результаты операций, то есть шанс, что вы не поймёте результатов вообще. Где бага, где всё хорошо?
Грамотно сгруппируйте результаты замеров, чтобы результат был понятен и очевиден.
no pasaran!
понедельник, 1 ноября 2010 г.
воскресенье, 17 октября 2010 г.
Магия дедлайна
Согласно закону Паркинсона задача прибавляет в значимости и сложности соразмерно времени, которое на неё отпущено. В этом заключается магия дедлайна - крайнего срока выполнения. Если я дам вам на выполнение задания 24 часа, цейтнот застиавит вас сосредоточиться на работе, и у вас уже не будет другой альтернативы, кроме как делать самое важное. Но если на ту же самую задачу я дам вам неделю, за шесть дней вы успеете сделать из мухи слона. Если, боже упаси, вместо одного дня вы получите два месяца, то задача разрастётся у вас в воображении до размеров монстра. Конечный продукт при близком дедлайне почти всегда будет более качественным или, по крайней мере, равнозначным тому, что рождается долго и мучительно.Тимоти Феррис
Каждый день, каждый час я вижу подтверждение этому закону. Не пытайтесь, как все, работать больше: сутки не резиновые. Работайте лучше! Для этого не нужно пахать по 15 часов. Для этого важно только отсекать лишнее и ставить дерзкие дедлайны.
пятница, 15 октября 2010 г.
Почему тестирование - это тупо и скучно?
Последние дни всё чаще натыкаюсь на сообщения в блогах и форумах про то, что тестирование - это либо очень скучно, либо тупая работа и т.д.
Что все эти люди делают в тестировании??
Позавчера я тестировала свой небольшой веб-проект.
За 4 часа я завела 25 дефектов.
Я очень радовалась каждой "находке", особенно если в поиске она была нетривиальной. Ещё больше радовалась каждый раз, когда удавалось точно локализовать дефект. Мне действительно нравилось их заводить, стараясь это сделать наиболее понятным способом.
"А что, если?...", "А как проверить?...", "А как бы?..." и т.д. заполняют мозг, который включается на полную мощность.
Если бы мне кто-то предложил в этот момент посмотреть фильм, поиграть в компьютерную игру или сходить в клуб, я бы ему ответила, что занята значительно более интересным занятием! Потому что это действительно очень интересно!
Это захватывает, и время пролетает очень быстро. Это творческая, непростая, ответственная работа, которая увлекает на 100%!
И я задумалась. Кто пишет про "скучно", "рутина" и "тупая работа"? Почему не всем нравится? Постаралась выписать всё, что пришло в голову.
1. "Не моё". Я обожаю тестировать и проводить тренинги, но я ненавижу звонить по телефону. НЕ МОЁ! Тестирование - это набор конкретных действий, которые мы выполняем. Кому-то нравится этот процесс, кому-то нет. Если это не ваше - ищите своё! Явно есть вещи, которые увлекут так же, как тестирование - меня.
2. "Не умею". Тестировать - это навык. Я помню, как я тестировала в начале карьеры. Тынканье на кнопки, просмотр UI... нудно и скучно. Тогда я не использовала на лету интересные техники тест-дизайна, тогда я не понимала как правильно локализовывать дефекты и вообще не понимала насколько важно (и обычно сложно) их точно локализовать. Это была и впрямь тупая работа, это было скучно. Знание методологии меняет всё! Тестирование становится творческим и значительно более интересным!
3. "Не понимаю зачем". Когда я тестирую свой собственный проект, мне это важно и я понимаю, зачем я это делаю. Когда я участвовала в выпуске продуктов с мировым именем, которыми я гордилась и горжусь, я понимала важность тестирования для миллионов (МИЛЛИОНОВ!) пользователей. Это добавляет работе значимость и интерес. Работая в компании, в которой качество не ценится, испытывать удовольствие от тестирования сложно - оно же никому не нужно!
Работаете в такой компании? Бегите!
4. Неоправданно жёсткие процессы. Тестировать по 100 лет назад созданным тест-кейсам, повторяющимся каждый день, не просто скучно, но и бесполезно. В итоге и интереса нет, и ответственность не чувствуется. Надо уметь выбирать оптимальное соотношения исследования к документированию. Да, документы нужны. Иногда чек-листы, иногда даже тест-кейсы, иногда они даже необходимы. Но НЕ ВСЕГДА!
Может, есть ещё какие-то причины неинтереса.
Но мне кажется, что если у вас
* оптимальный процесс
* достойный продукт
* существенный багаж знаний в области методологии тестирования и вы умеете их пременять,
то либо тестирование - это мега-супер-пупер-аж-захватывает-дух интересно, либо НЕ ВАШЕ!
Что все эти люди делают в тестировании??
Позавчера я тестировала свой небольшой веб-проект.
За 4 часа я завела 25 дефектов.
Я очень радовалась каждой "находке", особенно если в поиске она была нетривиальной. Ещё больше радовалась каждый раз, когда удавалось точно локализовать дефект. Мне действительно нравилось их заводить, стараясь это сделать наиболее понятным способом.
"А что, если?...", "А как проверить?...", "А как бы?..." и т.д. заполняют мозг, который включается на полную мощность.
Если бы мне кто-то предложил в этот момент посмотреть фильм, поиграть в компьютерную игру или сходить в клуб, я бы ему ответила, что занята значительно более интересным занятием! Потому что это действительно очень интересно!
Это захватывает, и время пролетает очень быстро. Это творческая, непростая, ответственная работа, которая увлекает на 100%!
И я задумалась. Кто пишет про "скучно", "рутина" и "тупая работа"? Почему не всем нравится? Постаралась выписать всё, что пришло в голову.
1. "Не моё". Я обожаю тестировать и проводить тренинги, но я ненавижу звонить по телефону. НЕ МОЁ! Тестирование - это набор конкретных действий, которые мы выполняем. Кому-то нравится этот процесс, кому-то нет. Если это не ваше - ищите своё! Явно есть вещи, которые увлекут так же, как тестирование - меня.
2. "Не умею". Тестировать - это навык. Я помню, как я тестировала в начале карьеры. Тынканье на кнопки, просмотр UI... нудно и скучно. Тогда я не использовала на лету интересные техники тест-дизайна, тогда я не понимала как правильно локализовывать дефекты и вообще не понимала насколько важно (и обычно сложно) их точно локализовать. Это была и впрямь тупая работа, это было скучно. Знание методологии меняет всё! Тестирование становится творческим и значительно более интересным!
3. "Не понимаю зачем". Когда я тестирую свой собственный проект, мне это важно и я понимаю, зачем я это делаю. Когда я участвовала в выпуске продуктов с мировым именем, которыми я гордилась и горжусь, я понимала важность тестирования для миллионов (МИЛЛИОНОВ!) пользователей. Это добавляет работе значимость и интерес. Работая в компании, в которой качество не ценится, испытывать удовольствие от тестирования сложно - оно же никому не нужно!
Работаете в такой компании? Бегите!
4. Неоправданно жёсткие процессы. Тестировать по 100 лет назад созданным тест-кейсам, повторяющимся каждый день, не просто скучно, но и бесполезно. В итоге и интереса нет, и ответственность не чувствуется. Надо уметь выбирать оптимальное соотношения исследования к документированию. Да, документы нужны. Иногда чек-листы, иногда даже тест-кейсы, иногда они даже необходимы. Но НЕ ВСЕГДА!
Может, есть ещё какие-то причины неинтереса.
Но мне кажется, что если у вас
* оптимальный процесс
* достойный продукт
* существенный багаж знаний в области методологии тестирования и вы умеете их пременять,
то либо тестирование - это мега-супер-пупер-аж-захватывает-дух интересно, либо НЕ ВАШЕ!
вторник, 12 октября 2010 г.
Что вы будете на завтрак: яичницу или рецепт?
Как вы думаете, какой повар лучше – тот, который умеет готовить 10 простых, вкусных, сочных блюд – или тот, который прочитал 10 больших кулинарных книг, но ни разу не стоял у плиты?
С каким водителем вы без проблем поедете – с тем, кто прочитал правила дорожного движения и впервые учится переключать передачи – или с тем, кто уже 10 лет безаварийно «таксует», не удосужившись пролистать ПДД?
С каким менеджером вы предпочтёте работать – опытным и доказавшим свою репутацию хорошего руководителя – или с новичком, но прочитавшим 5 книг по управлению?
И допустимо ли быть теоретиком в сфере тестирования?
В чём разница между знанием, навыком и опытом?
Вы можете прочитать об аэродинамике птиц и получить представление о том, как они летают. Сможете ли вы летать? Врядли. Это – знание.
Вы можете пойти на курсы вождения. Там вас научат крутить баранку, переключать передачи и даже парковаться задним ходом. Неуверенно и с каплей пота на лбу вы сможете передвигаться по улицам, судорожно вглядываясь в светофоры и пытаясь прочуствовать габариты. Но навык уже есть, едем!
Через год вы разговариваете по мобильному за рулём, засматриваетесь на особей противоположного пола и рекламу, а светофоры замечаете боковым зрением. Это – опыт.
Теория и практика – в поисках золотого сечения
Практиковаться без базовых знаний опасно. Прежде чем выезжать на улицу, надо знать, что красный свет светофора означает «СТОП», а зелёный – «Welcome!». Перед первой операцией хирургу не помешает ознакомиться с анатомией. Теория важна и даже необходима – хотя, увы и ах, без практики она ничего не даст.
Исходя из моих наблюдений, 90% тестировщиков НЕ УМЕЮТ использовать классы эквивалентности и граничные значения. Это простые (читай: элементарные), эффективные и необходимые техники. Про них все слышали. Про них все знают. Почти все знают что это. И почти никто НЕ УМЕЕТ их использовать (считая, что умеют :-) ). Хотя это – фундамент!
Зато, эти люди гонятся за новыми и новыми знаниями, которые они не смогут применять.
Китайский вопрос: «А нахуа?».
Почему так много тестировщиков – теоретики?
1. Потому что делать что-то новое страшно – а вдруг не получится?
2. Потому что в СНГ тестирование в зачаточной стадии и в 90% случаев «тестированием» называют мартышкины кликанья. Так принято!
3. Потому что вокруг полно теоретиков. С кого брать пример?
Почему надо становиться практиком?
1. Тестирование – это очень интересная и увлекательная область деятельности. Но только если вы не стоите на месте. Только если вы всё время пробуете новое. Только если вы всё время растёте. Иначе – скучные и нудные задачи с тыканьем на кнопочки.
2. Чтобы обеспечить себе быстрый карьерный рост. Почему у некоторых людей карьера стремительная и успешная, а некоторые годами работают младшими тестировщиками? Обычно, знания тут ни при чём…
3. Чтобы приносить реальную пользу. Знания, складируемые в голове, не помогут продукту успешно выйти в срок.
Уболтала, чертяка языкастая. Что делать?
1. Не ждать приглашений что-то сделать. Не вините в отсутствии роста компанию или работодателя. Начните ДЕЛАТЬ сами. Не читать, не учить. ДЕЛАТЬ.
2. Выпишите конкретные, понятные, небольшие шаги. Нарисуйте свой первый майнд меп по продукту, если вы этого ещё не делали. Напишите тест-план. Поиспользуйте Pairwise. Попробуйте новый софт.
3. Отставить бояться! Первый раз не получится – это нормально. Не надо думать, что используемый подход или инструмент не эффективны. Негативный результат – это новые знания о том, что стоит улучшить. Но не опыт! Добейтесь результата!
4. Читая книгу или посещая тренинг, проецируйте теорию на свою работу и выписывайте: что из новой информации я могу попробовать? Как я могу это сделать? Когда это будет полезно? Если после книги или тренинга вы не определили план действий – значит, вы совсем не получили пользы!
5. Если во время решения каких-либо задачек в области тестирования у вас возникнут сложности или вопросы – обращайтесь. Во имя искусства я помогу абсолютно безкоштовно, то есть даром. Условие простое: не спрашивать про сферических коней в вакууме. Конкретные примеры, задачи, проблемы. Вопросы «КАК… ?», а не «расскажи мне что-нибудь про Мадагаскар».
Не уболтала, ерунда это всё.
Ну и ладно. В мире были, есть и будут люди, которые закрываются от нового опыта. Которые боятся что-то делать и считают, что теоретические знания без применения приносят им пользу. Которые много знают и ничего не умеют. Но прежде чем войти в число таких людей, подумайте: Что вы хотите на завтрак? Яичницу или рецепт её приготовления?
С каким водителем вы без проблем поедете – с тем, кто прочитал правила дорожного движения и впервые учится переключать передачи – или с тем, кто уже 10 лет безаварийно «таксует», не удосужившись пролистать ПДД?
С каким менеджером вы предпочтёте работать – опытным и доказавшим свою репутацию хорошего руководителя – или с новичком, но прочитавшим 5 книг по управлению?
И допустимо ли быть теоретиком в сфере тестирования?
В чём разница между знанием, навыком и опытом?
Вы можете прочитать об аэродинамике птиц и получить представление о том, как они летают. Сможете ли вы летать? Врядли. Это – знание.
Вы можете пойти на курсы вождения. Там вас научат крутить баранку, переключать передачи и даже парковаться задним ходом. Неуверенно и с каплей пота на лбу вы сможете передвигаться по улицам, судорожно вглядываясь в светофоры и пытаясь прочуствовать габариты. Но навык уже есть, едем!
Через год вы разговариваете по мобильному за рулём, засматриваетесь на особей противоположного пола и рекламу, а светофоры замечаете боковым зрением. Это – опыт.
Теория и практика – в поисках золотого сечения
Практиковаться без базовых знаний опасно. Прежде чем выезжать на улицу, надо знать, что красный свет светофора означает «СТОП», а зелёный – «Welcome!». Перед первой операцией хирургу не помешает ознакомиться с анатомией. Теория важна и даже необходима – хотя, увы и ах, без практики она ничего не даст.
Исходя из моих наблюдений, 90% тестировщиков НЕ УМЕЮТ использовать классы эквивалентности и граничные значения. Это простые (читай: элементарные), эффективные и необходимые техники. Про них все слышали. Про них все знают. Почти все знают что это. И почти никто НЕ УМЕЕТ их использовать (считая, что умеют :-) ). Хотя это – фундамент!
Зато, эти люди гонятся за новыми и новыми знаниями, которые они не смогут применять.
Китайский вопрос: «А нахуа?».
Почему так много тестировщиков – теоретики?
1. Потому что делать что-то новое страшно – а вдруг не получится?
2. Потому что в СНГ тестирование в зачаточной стадии и в 90% случаев «тестированием» называют мартышкины кликанья. Так принято!
3. Потому что вокруг полно теоретиков. С кого брать пример?
Почему надо становиться практиком?
1. Тестирование – это очень интересная и увлекательная область деятельности. Но только если вы не стоите на месте. Только если вы всё время пробуете новое. Только если вы всё время растёте. Иначе – скучные и нудные задачи с тыканьем на кнопочки.
2. Чтобы обеспечить себе быстрый карьерный рост. Почему у некоторых людей карьера стремительная и успешная, а некоторые годами работают младшими тестировщиками? Обычно, знания тут ни при чём…
3. Чтобы приносить реальную пользу. Знания, складируемые в голове, не помогут продукту успешно выйти в срок.
Уболтала, чертяка языкастая. Что делать?
1. Не ждать приглашений что-то сделать. Не вините в отсутствии роста компанию или работодателя. Начните ДЕЛАТЬ сами. Не читать, не учить. ДЕЛАТЬ.
2. Выпишите конкретные, понятные, небольшие шаги. Нарисуйте свой первый майнд меп по продукту, если вы этого ещё не делали. Напишите тест-план. Поиспользуйте Pairwise. Попробуйте новый софт.
3. Отставить бояться! Первый раз не получится – это нормально. Не надо думать, что используемый подход или инструмент не эффективны. Негативный результат – это новые знания о том, что стоит улучшить. Но не опыт! Добейтесь результата!
4. Читая книгу или посещая тренинг, проецируйте теорию на свою работу и выписывайте: что из новой информации я могу попробовать? Как я могу это сделать? Когда это будет полезно? Если после книги или тренинга вы не определили план действий – значит, вы совсем не получили пользы!
5. Если во время решения каких-либо задачек в области тестирования у вас возникнут сложности или вопросы – обращайтесь. Во имя искусства я помогу абсолютно безкоштовно, то есть даром. Условие простое: не спрашивать про сферических коней в вакууме. Конкретные примеры, задачи, проблемы. Вопросы «КАК… ?», а не «расскажи мне что-нибудь про Мадагаскар».
Не уболтала, ерунда это всё.
Ну и ладно. В мире были, есть и будут люди, которые закрываются от нового опыта. Которые боятся что-то делать и считают, что теоретические знания без применения приносят им пользу. Которые много знают и ничего не умеют. Но прежде чем войти в число таких людей, подумайте: Что вы хотите на завтрак? Яичницу или рецепт её приготовления?
среда, 29 сентября 2010 г.
Результаты московских тренингов
Всем привет!
Три тренинга в Москве позади, гастроли и много новых тренингов впереди.
23, 24 и 25 сентября я провела в Москве три тренинга для тест-менеджеров.
Команда все три дня была очень интересная. У всех было что узнать, со всеми было что обсудить - и это здорово!
В первый день, на тренинге "Управление командой тестировщиков", который проходил в офисе Билайна, удалось даже собрать видеоотзывы. Эта штука для меня новая, но теперь я знаю, что смотреть в пасмурные зимние вечера, если заблокируют торрент :) Средняя оценка по анкетам 4,7 по 5-балльной шкале. Единственный "трояк" поставил мой бывший руководитель - но ему можно, на то он и руководитель :)
Во второй день, на тренинге "Управление тест-дизайном", видеоотзывы собрать забыли. А жаль! Средняя оценка по анкетам - 4,85 по 5-балльной шкале!!! Для меня это новый рекорд :) Правда, одна тройка опять была - Игорь, я всё учту! :)
Зато, вместо отзывов получилось классное фото:
На третий день, на тренинге "Управление автоматизацией", который проходил в офисе "Акрониса", было пожарче. Этот тренинг я проводила впервые, и несколько сложных моментов в объяснении давались с трудом. К огромному счастью, опытные участники не только внимательно слушали и участвовали в групповой работе, но даже помогли с объяснениями, породив идеи "как это можно нарисовать ещё нагляднее". За что им отдельное спасибо!Видеоотзывы получились длиннее и насыщеннее, но моя квалификации в видеомонтаже не позволяет их выложить :( Обещаю исправиться до конца недели. На этом тренинге средняя оценка составила 4,6, а троек было аж две!
Выводы:
1) Всем большое спасибо, было очень интересно и надеюсь ещё неоднократно встретиться!
2) Видеоотзывы - это круто. Смотрю и радуюсь! :)
3) Никто не знает тренингов по видеомонтажу?
Три тренинга в Москве позади, гастроли и много новых тренингов впереди.
23, 24 и 25 сентября я провела в Москве три тренинга для тест-менеджеров.
Команда все три дня была очень интересная. У всех было что узнать, со всеми было что обсудить - и это здорово!
В первый день, на тренинге "Управление командой тестировщиков", который проходил в офисе Билайна, удалось даже собрать видеоотзывы. Эта штука для меня новая, но теперь я знаю, что смотреть в пасмурные зимние вечера, если заблокируют торрент :) Средняя оценка по анкетам 4,7 по 5-балльной шкале. Единственный "трояк" поставил мой бывший руководитель - но ему можно, на то он и руководитель :)
Во второй день, на тренинге "Управление тест-дизайном", видеоотзывы собрать забыли. А жаль! Средняя оценка по анкетам - 4,85 по 5-балльной шкале!!! Для меня это новый рекорд :) Правда, одна тройка опять была - Игорь, я всё учту! :)
Зато, вместо отзывов получилось классное фото:
На третий день, на тренинге "Управление автоматизацией", который проходил в офисе "Акрониса", было пожарче. Этот тренинг я проводила впервые, и несколько сложных моментов в объяснении давались с трудом. К огромному счастью, опытные участники не только внимательно слушали и участвовали в групповой работе, но даже помогли с объяснениями, породив идеи "как это можно нарисовать ещё нагляднее". За что им отдельное спасибо!Видеоотзывы получились длиннее и насыщеннее, но моя квалификации в видеомонтаже не позволяет их выложить :( Обещаю исправиться до конца недели. На этом тренинге средняя оценка составила 4,6, а троек было аж две!
Выводы:
1) Всем большое спасибо, было очень интересно и надеюсь ещё неоднократно встретиться!
2) Видеоотзывы - это круто. Смотрю и радуюсь! :)
3) Никто не знает тренингов по видеомонтажу?
воскресенье, 8 августа 2010 г.
Осенний тренинг-марафон для тест-менеджеров
Этой осенью я провожу какое-то сумасшедшее количество тренингов:
1) Управление командой тестировщиков
- Москва: 23 сентября
- Санкт-Петербург: 2 октября
- Минск: 14 октября
Это мой любимый тренинг :) Сейчас он полностью переработан и нашпигован секретной информацией тайных спецагентов тест-менеджмента. Этот тренинг - о людях, потому что тестировщики - это в первую очередь люди, и умение формировать команду мотивированных рыцарей-джедаев - самое важное, что Вы можете сделать для своего проекта :) На этом тренинге Вас ждут непрерывные упражнения в группах, которые позволят не просто узнать теорию, а прочувствовать все темы на практике! А тем, кто и так всё знает - понаблюдать за своим менеджментом со стороны и получить массу полезной обратной связи!
2) Тест-дизайн для менеджеров
- Москва: 24 сентября
- Санкт-Петербург: 3 октября
- Минск: 15 октября
Этот тренинг тоже существенно переработан на основании последних отзывов. Половину тренинга мы проведём, занимаясь коллективным творчеством и знакомясь с различными инструментами тест-дизайна, которые созданы для сокращения трудозатрат на тестирование в разы. Это будут основы, которые позволят Вам сориентироваться в существующих подходах к тест-дизайну и научиться выбирать оптимальные варианты. Помимо этого, мы уделим массу времени таким темам, как создание "работающего" тест-плана, формирование команды тест-дизайна, выбор подходящего инструментария. Внимание! Тренинг настолько насыщен мозговзрывающей информацией, что перед ним необходимо хорошенько выспаться! :)
3) Управление автоматизацией тестирования
- Москва: 25 сентября
- Санкт-Петербург: 1 октября
- Минск: 16 октября
Этот тренинг будет проводиться впервые. Его цель - помочь тест-менеджерам построить эффективную автоматизацию даже в случае, если Вы сами не являетесь продвинутым техническим специалистом. Мы расшифруем все те страшные слова, которыми обычно ругаются автоматизаторы-разработчики и поизучаем, как это устроено внутри, а главное - что с этим делать?? Как сделать автоматизацию не чем-то "для галочки", а полезной проектной активностью, которая позволяет экономить затраты ручных тестировщиков? В чём разница автоматизации в маленьких и больших командах? Как отбирать тесты? Как измерять их эффективность? К концу этого тренинга Вы самостоятельно развеете массу широкораспростренённых мифов, которые препятстсвуют результативному взаимодействию миров автоматизированного и ручного тестирования ;)
В общем, готовьтесь к тренингам, запасайтесь вопросами и отличным настроением!
1) Управление командой тестировщиков
- Москва: 23 сентября
- Санкт-Петербург: 2 октября
- Минск: 14 октября
Это мой любимый тренинг :) Сейчас он полностью переработан и нашпигован секретной информацией тайных спецагентов тест-менеджмента. Этот тренинг - о людях, потому что тестировщики - это в первую очередь люди, и умение формировать команду мотивированных рыцарей-джедаев - самое важное, что Вы можете сделать для своего проекта :) На этом тренинге Вас ждут непрерывные упражнения в группах, которые позволят не просто узнать теорию, а прочувствовать все темы на практике! А тем, кто и так всё знает - понаблюдать за своим менеджментом со стороны и получить массу полезной обратной связи!
2) Тест-дизайн для менеджеров
- Москва: 24 сентября
- Санкт-Петербург: 3 октября
- Минск: 15 октября
Этот тренинг тоже существенно переработан на основании последних отзывов. Половину тренинга мы проведём, занимаясь коллективным творчеством и знакомясь с различными инструментами тест-дизайна, которые созданы для сокращения трудозатрат на тестирование в разы. Это будут основы, которые позволят Вам сориентироваться в существующих подходах к тест-дизайну и научиться выбирать оптимальные варианты. Помимо этого, мы уделим массу времени таким темам, как создание "работающего" тест-плана, формирование команды тест-дизайна, выбор подходящего инструментария. Внимание! Тренинг настолько насыщен мозговзрывающей информацией, что перед ним необходимо хорошенько выспаться! :)
3) Управление автоматизацией тестирования
- Москва: 25 сентября
- Санкт-Петербург: 1 октября
- Минск: 16 октября
Этот тренинг будет проводиться впервые. Его цель - помочь тест-менеджерам построить эффективную автоматизацию даже в случае, если Вы сами не являетесь продвинутым техническим специалистом. Мы расшифруем все те страшные слова, которыми обычно ругаются автоматизаторы-разработчики и поизучаем, как это устроено внутри, а главное - что с этим делать?? Как сделать автоматизацию не чем-то "для галочки", а полезной проектной активностью, которая позволяет экономить затраты ручных тестировщиков? В чём разница автоматизации в маленьких и больших командах? Как отбирать тесты? Как измерять их эффективность? К концу этого тренинга Вы самостоятельно развеете массу широкораспростренённых мифов, которые препятстсвуют результативному взаимодействию миров автоматизированного и ручного тестирования ;)
В общем, готовьтесь к тренингам, запасайтесь вопросами и отличным настроением!
пятница, 9 июля 2010 г.
Балдеющие от адреналина или зомбированные шаблонами
Большое спасибо Борису - подкинул книжку, которая заставила задуматься :)
Книга описывает стандартные поведенческие паттерны проектных команд. Наверное, в Орловско-Панкратовских "Играх в ИТ" нечно подобное. Смотришь на них со стороны и думаешь "вот жеж идиоты, так обычно и бывает"... и где-то внутри что-то начинает назойливо почёсывыть, постукивать, поскрёбывать... и тут ты понимаешь: "О! Я же вчера так сделала!"...
Советую всем прочитать эту книжку, будучи максимально искренним с собой и проанализировав, а не делаете ли вы сами все эти глупости? :)
Больше всего понравилась глава про менеджеров-нянь. Как минимум приятно, что звёдный состав авторов меня понимает :))) Как максимум - видно направление роста. Вот он, свет в конце тоннеля!
И ещё одна важная, важная, важная мысль. Понимать, что такое хорошо и что такое плохо и даже уметь делать всё хорошо - этого недостаточно, если работаешь в компании, где нереально что-то поменять. Понимать недостаточно - надо делать.
Книга описывает стандартные поведенческие паттерны проектных команд. Наверное, в Орловско-Панкратовских "Играх в ИТ" нечно подобное. Смотришь на них со стороны и думаешь "вот жеж идиоты, так обычно и бывает"... и где-то внутри что-то начинает назойливо почёсывыть, постукивать, поскрёбывать... и тут ты понимаешь: "О! Я же вчера так сделала!"...
Советую всем прочитать эту книжку, будучи максимально искренним с собой и проанализировав, а не делаете ли вы сами все эти глупости? :)
Больше всего понравилась глава про менеджеров-нянь. Как минимум приятно, что звёдный состав авторов меня понимает :))) Как максимум - видно направление роста. Вот он, свет в конце тоннеля!
И ещё одна важная, важная, важная мысль. Понимать, что такое хорошо и что такое плохо и даже уметь делать всё хорошо - этого недостаточно, если работаешь в компании, где нереально что-то поменять. Понимать недостаточно - надо делать.
Подписаться на:
Комментарии (Atom)