Showing posts with label развитие. Show all posts
Showing posts with label развитие. Show all posts

October 10, 2012

Сказка о двух ящиках и одной тестировщице

Жила-была маленькая тестировщица, и по неопытности своей считала, что белый ящик - для программистов, а черный - Мекка для тестировщиков.
Но однажды наступил момент, когда ей в Jira подключили FishEye, и она смогла видеть то, каким образом был пофикшен тот или иной баг, или каким образом был заимплеменчен тот или иной функционал. По началу все изменения выглядели как наскальная живопись - было понятно о чем речь лишь по мутным и примитивным очертаниям. Тогда она стянула себе из системы контроля версий репозиторий, и очертания стали больше напоминать то,что они значили, ибо в IDE можно было перемещаться по классам и методам, чтобы понимать, что происходит. И тогда коммиты стали понятней, и несмотря на практику код ревью, принятую в команде, маленькая тестировщица все равно заглядывала в новый код посредством FishEye.
Это привело к тому, что отныне делать impact анализ можно было основываясь не только на словах разработчика и собственных предположениях, но и на том, что она сама видела. И оказалось, что, как правило, изменения затрагивали гораздо больше того, что было сказано разработчиком, и тестов нужно было сделать гораздо больше, чтобы убедиться в правильности имплементации. Чек листы стали более полными, что позволяло отловить больше багов.
А маленькая тестировщица теперь при получении тикета в Jira первым делом открывает вкладку Source и смотрит изменения в файлах, а уж потом приступает к тестированию. А в случае, если на нее ассайнят тикет, где такая вкладка для нее отсутствует, она брезгливо морщится и тяжело вздыхает.

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

но это не имеет никакого смысла до тех пор, пока нет доступа к коду.

January 10, 2012

Интересный факт - Эффект Даннинга-Крюгера

Некоторые вещи ставит на свои места, о других заставляет задуматься:

Эффект Даннинга-Крюгера — когнитивное искажение, которое заключается в том, что «люди, имеющие низкий уровень квалификации, делают ошибочные выводы и принимают неудачные решения, но не способны осознавать свои ошибки в силу своего низкого уровня квалификации». Это приводит к возникновению у них завышенных представлений о собственных способностях, в то время как действительно высококвалифицированные люди, наоборот, склонны занижать свои способности и страдать недостаточной уверенностью в своих силах, считая других более компетентными. Таким образом, менее компетентные люди в целом имеют более высокое мнение о собственных способностях, чем это свойственно людям компетентным, которые к тому же склонны предполагать, что окружающие оценивают их способности так же низко, как и они сами.

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


Описание взято с вики.

December 16, 2010

Мой доклад на SQA Days-8

На эту конференцию я решилась-таки написать доклад. И он был принят программной комиссией.
Я очень нервничала, и чем ближе,тем больше проклинала тот день,когда решилась это сделать. Да, выступать очень-очень страшно.
Но,к счастью, все прошло довольно хорошо. :)

Ниже презенташка моего доклада и его текст.


«Девять правил Семпая, или Как стать успешным наставником?»
[1]
Каждый из нас, поступая на работу, был новичком. Период обучения каждого конкретного человека занимает разное время и зависит от опыта работы и коммуникаций с людьми, личностных качеств, технической базы и...наставника. К этому выводу я пришла,проанализировав успехи новичков и зависимость их от принципов работы наставников. В данный момент я сама являюсь наставником и хочу поделиться с вами основными правилами,которыми я руководствуюсь при работе со своими учениками.
Идея наставничества как метода обучения пришла из древних времен, когда мастера обучали учеников, которые смогли бы заменить их или просто помочь в работе. В восточной культуре существует понятие Сэмпая – так называют человека, у которого больше опыта в той или иной области. При этом возраст не имеет значения
Этот термин я и буду использовать в докладе, потому что японцы – наиболее уважающий друг друга народ, а именно к взаимному уважению и должены стремиться Наставник и Ученик.

Первое правило Сэмпая. «Вижу цель, иду к ней»
[2]
Роберт Кийосаки
Один из принципов наставничества состоит в том, что ученик почти все время находится или в непосредственной близости от Учителя, или выполняет его задания. Эта практика была перенесена в сферу Информацинных технологий, и, на мой взгляд, отлично прижилась среди тестировщиков. Причин этому очень много, основные,на мой взгляд, заключаются в том,что возможность получить образование по этому профилю практически отсутствует, и большинство людей,как ни крути, попадает в тестирование случайно.
Наставничество преследует несколько целей:
• Помочь человеку усвоить большой объем знаний за короткое время
• Облегчить адаптацию человека в коллективе
Это общие цели, преследуемые как для новичков в тестировании, так и для опытных сотрудников, сменивших компанию. Более развернутые цели при обучении новичков, выглядят так:
• введение в проект
• введение в коллектив
• обучение инструментам и шаблонам
• обучение с нуля тестированию
Для сотрудников же с опытом работы целей преследуется никак не меньше:
• введение в проект
• введение в коллектив
• обучение инструментам и шаблонам, принятым в данной компании
• перенятие опыта
(перенятие опыта подразумевает под собой осмысленные попытки «разговорить» человека, чтобы знать, чем отличались принципы или методы работы человека на предыдущей работе. Возможно, есть что-то, что стоило бы начать использовать и в компании наставника :) )
[3]
Поставленные цели должны быть достижимы. Например, цель «обучение тестированию за 2 месяца» является недостижимой по причине того, что она неизмерима. Такие цели следует разбивать на более мелкие – например, на умение писать баг-репорты, проходить тест-кейсы, писать тест-кейсы и тест-планы.
Для достижения поставленных целей нужно создавать условия Ученику. В идеале занятия Ученика должны одновременно служить и развивать несколько навыков ученика, а не один.

Второе правило Сэмпая. Желание учить и помогать КОНКРЕТНОМУ человеку
[4]
Л. Берне
Вторым правилом наставничества является желание Сэмпая помогать конкретному человеку, с его достоинствами и футболкой супермена, и учить его. Если между Сэмпаем и Учеником нет связи или взаимоуважения – ни один из них никогда не будет работать эффективно в паре и они не добьются хорошего результата.
[5]
Таким образом приходим к выводу, что Сэмпай должен сам выбирать себе Ученика. Будущих наставников нужно обязательно брать на собеседования кандидатов и советоваться с ними,принимая решение о найме. Ведь никто не будет так близко общаться с новым человеком в ближайшее время, как его Сэмпай.


Третье правило Сэмпая. Стратегия
[6]
Брайан Трейси
При обучении сотрудников хорошей является следующая стратегия:
1. «Я расскажу, ты послушай»
На этом этапе следует максимально полно дать необходимую информацию о предмете.
2. «Я покажу, ты посмотри»
Показать, что делать и как, лично нажимая на кнопки и комментируя.
3. «Сделаем вместе»
4. «Сделай сам, я подскажу»
5. «Сделай сам, расскажи, что сделал».
На этом этапе важно понять, правильно ли мыслит Ученик. Для этого можно использовать зрительный контакт или просить продолжить за вас фразу.
Иногда ребята очень быстро пролетают первые 3 этапа . Могут возникнуть непонятки с результатом выполнения задачи. Их лучше всегда формализировать, и ,в некоторых случаях, даже записывать. В то же время особо вдаваться в подробности тоже не стоит – нужно всегда оставлять человеку свободу для творчества в работе.
Сэмпай всегда должен знать:
• Чем в данный момент занимается его Ученик
• Каких целей позволяет достичь текущая задача Ученика
• Каков ожидаемый результат выполнения конкретной задачи
• Чем по плану он будет заниматься дальше
Это позволяет максимально быстро при необходимости скорректировать действия при внесении поправок в курс обучения.

[7]
Также я бы рекомендовала Сэмпаю вести дневник, особенно, если у него несколько Учеников. В такой дневник следует заносить свое отношение к сделанной работе ученика или общее удовлетворение\неудовлетворение, обязательно с пояснениями. Например,
«16.05.2010
В простых отчетах об ошибках делает много ошибок. Грамматика, структура.
Исправление ошибок в одном месте не переносит в другие.»
Также можно отмечать и положительные моменты в работе ученика :)

Четвертое правило Сэмпая. Право на свою точку зрения
[8]
Т. Питере, Р. Уотермен
Не стоит давить на корню желание Ученика отличаться. Задача Сэмпая – мягко направить индивидуальность в полезное русло. Если заставлять делать все «как я», то можно получить в итоге «напичканного» шаблонами ученика, который будет бояться ступить шаг в сторону, вместо самостоятельно мыслящего креативного специалиста, коего мы хотим воспитать. Это касается таких мелочей, как написание баг-репортов или тест-кейсов, к примеру. Не стоит заставлять человека использовать Ваши любимые слова или времена, вместо его любимых, если, конечно, это не обусловлено терминологией проекта, корпоративной политикой или желанием высших сил. На слайде показана идеальная команда – они все, вроде,и одинаковые – но в каждом есть неповторимая изюминка, которая делает его неповторимым и от этого особенно ценным. Ведь никто не будет отрицать,что у каждого человека есть свои слабые и сильные стороны. Правильное их развитие и делает человека специалистом.

Пятое правило Сэмпая. Доверие
[9]
Китайская мудрость

Чтобы понять, чего человек стоит, нужно доверять ему задачи все более и более сложные. Если Сэмпай будет все время перепроверять Ученика, он будет высказывать этим недоверие к ученику и его способностям, в результате чего сам Ученик разуверится в своих силах.
[10]
На практике же, к сожалению, проверять все-таки приходится. Например, например,задача слишком большая и серьезная. В таких случаях по возможности проверку нужно делать скрытно, чтобы о ней не знал Ученик. Пусть считает себя суперменом, когда вы якобы случайно наталкиваете его на мысль и прикрываете его спину :) Второй вариант – наоборот предупреждать о том, что вы будете проверять. Например, «Закончи с этим и обсудим дальнейший план действий».

Шестое правило Сэмпая. Ответственность
[11]
Д. Кеннеди
На слайде приведён пример настоящего Наставника. Это генерал Панфилов, чье соединение было награждено орденом, а сам генерал – удостоен звания героя СССР.
Дело в том, что ничто так не характеризует наставника, как его Ученики. Любая, даже маленькая, победа ученика частично является заслугой Сэмпая. Сэмпаю нужно стремиться к тому, чтобы на вопрос, кто этот человек, ответом было «Это Василий из дивизии Панфилова», «Это Петр, подопечный Марии».
[12]
Любой, даже маленький, проигрыш ученика является проигрышем наставника. Сэмпаю всегда нужно помнить об этом и интересоваться развитием Ученика, иначе Сэмпай может прослыть плохим или бестолковым учителем, а Ученик – бестолковым учеником. Ни то, ни другое невыгодно компании, а, значит,этого нужно стремиться избегать. Наставнику необходимо делить со своим Учеником победы и поражения.
Если Ученик сделал что-то не так, обсуждать и критиковать его поступок должен именно Сэмпай, а не другой Сэмпай, или Тест менеджер, или Проект Менеджер. Таким образом достигается бОльшая близость между Сэмпаем и Учеником, что позволяет Ученика раскрыться.

Седьмое правило Сэмпая. Спокойствие
[13]
Как уже говорилось, между Сэмпаем и Учеником должны установиться доброжелательные, доверительные и уважительные отношения. Учитывая, что Наставник является больше учителем, нежели контроллирующим органом, Сэмпай не имеет права жестко критиковать Ученика. Все проблемы, неувязки, непонимания и разочарования должны обсуждаться спокойно и взвешенно, критика должна быть только конструктивная, и вообще такие разговоры должны быть скорее похожи на общение друзей, когда один обратился за советом, нежели на ссоры детей и родителей вроде «Ты снова поступил не так!» или «Как так можно вообще?!». Если Вы чувствуете острое желание именно отругать человека, лучше отложите разговор о его промахах на другой день, когда смежете говорить спокойно.
[14]
Во время разговора обязательно нужно
• Выяснить причины, по которым Ученик решил поступить именно так
• Определить,как он должен был поступить
• Объяснить, почему его вариант решения проблемы плох, а предложенный вами – хорош
• Подвести итог
• Написать краткое резюме и отправить ему почтой
• Для Сэмпая – определить степень своей вины и причины, по которым он допустил такой проступок
Сэмпаю следует стать своего рода фильтром между Учеником и внешним миром на некоторое время. Затем следует постепенно выводить ученика во внешний мир.

Восьмое правило Сэмпая. Постоянное стремление к знаниям
[15]
Томас Джон Уотсон-старший
Сфера тестирования программного обеспечения и сами по себе информационные технологии сейчас развиваются семимильными шагами. Хороший тестировщик должен следить за их развитием и не отставать, иначе его профессионализм и ценность будет падать с каждым днем. Поэтому Сэмпай должен прививать Ученику желание развиваться и расти, узнавая что-то новое. Сэмпай должен уметь зажечь в Ученике искру. Лучший способ для этого – собственный пример.
[16]
Например, можно рассказать о недавно прочитанной статье за чашечкой кофе и спросить, что думает Ученик об основных проблемах, затронутых в ней. Или просто делать доклады для новых сотрудников по определенным темам, заставляя ребят думать и задавать вопросы.
Также Сэмпаю следует ставить ученику все новые и новые цели, которые будут развивать его и дальше, тем самым показывая, что всегда есть куда расти практически в любых условиях.
Я думаю, что у Вас тоже есть какие-то наработки по данному вопросу. Может, кто-нибудь ими поделится? 

Девятое правило Сэмпая. Дальнейшая забота об Ученике
[17]
Как правило, Сэмпаев помнят и уважают еще долго, если обучение проходило правильно и гладко. Поэтому, когда Ученик заканчивает обучение или переходит в другой проект, Сэмпай не должен рвать сразу все связи со своим учеником. Еще какое-то время (а,может, и долго) следует поддерживать его морально и быть советчиком в сложных для него вопросах, чтобы ученик не чувствовал себя брошенным в новую пучину неизведанных знаний.

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

Отзыв: SQA Days-8

Вот и у меня дошли руки до своего блога и отзыва о конференции SQA Days-8, которая проходила в Санкт-Петербурге.
В общем впечатление о конференции весьма положительное. Такого рода мероприятия мне нравятся не только тем, что есть возможность получить новые знания, но и тем, что там я часто нахожу подтверждение каким-то своим мыслям.

Из докладов хотелось бы отметить следующие:

1. Михаил Павлов "Отвечает ли тестировщик за качество?"
К великому сожалению Михаила, частично об этом говорил Майкл Болтон буквально перед ним. Тем не менее, Михаил раскыл тему более полно и детально и я совершенно с ним согласна - тестировщик отвечать за качество не может. Странно было слышать, когда люди вставали и говорили, что тестировщик может это делать и некоторые из них это делают. Бежать, бежать из такой компании :) Как можно отвечать за то,что ты не можешь контроллировать? Можно отвечать за качество СВОЕЙ работы, за качество работы отдела тестирования - почти можно, если есть достаточно полномочий, но за качество продукта... Нет, увольте.

2. Александр Александров "Дефектные дефекты"
Слышла много негативных отзывов, мол, доклад скучный. Имхо, это просто манера изложения Александра. Или преподавателей УЦ Люксов. Или просто взрослых и мудрых людей. Доклады Александрова мне всегда нравятся тем, что в них толково раскладывается по полочкам все то,что постепенно во время работы превращается в кашу. Вроде думаешь - да и так все понятно, а нет, со временем не так уж и понятно становится :) После прослушивания его докладов знания становятся более систематизированными,что ли.

3. Денис Бесков "Послание аналитиков тестировщикам"
Интресен был взгляд со стороны аналитиков на работу тестировщиков. Учитывая, что до конференции я никогда не видела живого аналитика - было занимательно. :)

Глобальные идеи, которые я вынесла с этой конференции:
1. Автоматизация
Нужно автоматизировать рутинную работу, оставляя тестировщикам время именно на полет мысли и фантазии :) Конечно, при условии нестабильного функционала, краткосрочных продуктов и т.п. автоматизация остается в стороне.
2. Метрики
Жаль,что на предыдущей работе руки так и не дошли до введения метрик,хоть я и думала об этом. Все-таки нужно было потратить (не?)много времени и ввести парочку самых необходимых нам на тот момент.
3. Место работы, компания
Не позволять себя засасывать болоту :) И в то же время никогда не сдаваться.
4. Тулзы
Доклады о самописных тулзах гигантов индустрии меня мало интересуют ввиду их максимальной заточенности под конкретные условия работы\практики и стоимости.
5. Люди
Некоторые люди не настолько плохи, как казались.
Некоторые люди не настолько круты, как казались.

P.S. А Питер - да, как всегда прекрасен.

July 26, 2010

Ключевые сотрудники

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

1. рамках компании
2. в рамках отдела тестирования
?

July 14, 2010

What leads to success?


Послушала заменчательный рассказ Ричарда Джонса о 8ми секретах успеха. Согласна со всем :)

Оригинал тут.


1. Passion
Do it for love, not for money.

2. Work
"Nothing comes easily. But I have a lot of fun."

3. Good
"To be successful out your nose down in something and get damn good at it."
Practice, Practice, Practice.

4. Focus
"Focusing yourself to one thing"

5. Push
"Push yourself. Physically, mentally, you gotta push,push,push."

6. Serve
"It is a privilege to serve as a doctor."

7. Ideas
Listen, Observe, Be Curious, Ask Questions, Problem solve, Make Connections

8. Persist

June 18, 2010

"Борется за свою славу"

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

Трактирщик: Охотник с двумя учениками.
Король: О, так, значит, он может мне помочь! Он много охотится и многое видит. Может, он видел мою дочь?
Трактирщик: Нет, этот охотник Вам не поможет, он больше не охотится.
Король: А чем же он занимается?
Трактирщик: Борется за свою славу. Он собрал уже 50 дипломов о том, что он знаменит.
Король: Так чем занимается-то?
Трактирщик: Отдыхает. Бороться за свою славу, может быть, гораздо утомительней...


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

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

June 14, 2010

Игра в быстрые вопросы

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

Так вот, для поддержания и проверки знаний, в последнее время я начала практиковать использование быстрых вопросов своей команде. Суть такова - ни с того, ни с сего (для подопечного, конечно же, у Вас-то все давно продумано!) задаете вопрос члену команды, устно или письменно через асю - неважно. Вопрос должен быть конкретным, чтоб задать его быстро, и быстро услышать ответ. Например, назвать методики сокращения количества тестовых примеров, перечислить виды тестирования и далее в таком духе.
Задали - и наблюдаете.
Если вопрос устный, то смотрим за глазами человека и его движениями, чтобы понять степень подготовленности человека морально и степень знания вопроса. Вывод для Вас, если подопечный не справился, должен быть такой : "дать Васе на самообразование повторить этот материал".
Ни в коем случае нельзя сердиться и нервничать ("Как ты можешь не знать таких элементарных вещей!"), иначе игру можно считать законченной,а менеджера - проигравшим - ему начнут врать. Да и и игра перестанет быть игрой, превратившись в чекпоинт.
Если вопрос письменный, то нужно наблюдать за выражением лица (если это возможно) и следить,чтоб у человека не было возможности\времени открыть Гугл. Остальное все также, как и в случае с устным вопросом.

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

ОБЯЗАТЕЛЬНО необходимо объяснить команде, что это не проверка знаний и не контрольная работа, а просто такая игра, в которой можно очень быстро проверить свои знания в той или иной сфере, чтоб знать, какие знания следует освежить.

June 2, 2010

Priority & Severity

Пока в нашей компании жизнь была спокойной и налаженной,я искренне недоумевала, зачем дублировать информацию, имея, кроме поля Priority, еще и обязательное поле Severity. Но теперь, имея массу тикетов перед релизом и не имея поля Severity в кастомерском багтрекере, я понимаю, что мне его не хватает :)
Priority - это приоритет, а Severity - "строгость","жесткость". Я, наконец-то, столкнулась с такой ситуацией, когда приоритет ошибки гораздо выше, чем ее строгость, и наоброт - строгость выше, чем приоритет ошибки.
Например, ГУИ баги у нас обычно имеют низкую строгость и, зачастую, низкий приоритет, однако, перед релизом приоритет внезапно растет, в то время, как строгость остается прежней. :)

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

UPD: Сегодня добавила в багтрекер поле Severity.
Столкнулась с тем, что отличие между полями не все понимают, и мне предлагают перед релизом менять приоритет, который у нас ранее обозначал нечто среднее между строгостью и приоритетом. На мой взгляд, ошибка не может изменить свою строгость с течением времени,а вот приоритет вполне может быть изменен и будет меняться.
Поэтому отвоевала оба поля, посмотрим, что выйдет :)

March 15, 2010

Крупная компания vs Маленькая компания

Работая в большой компании (~90 человек), было весело, познавательно, и тем не менее жестко. Большая компания как Голиаф - неповоротливая и негибкая, с четко выраженными характером и наклонностями. К тому же,как правило, в больших компаниях очень много времени уходит ни на что - ненужные отчеты, совещания, снова отчеты... и жесткая иерархия. Директор становится человеком, от которого зависит твоя зп, но который по факту ничего о тебе не знает, кроме имени и проектов, над которыми работаешь. Он также далек от сотрудников, как и президент страны - всегда навиду и делает,вроде,все для нас, для своего народа. :)
В этом плане маленькая компания гораздо эффективней работает: ежедневные отчеты можно заменить планом на день\два\неделю, отмеченную в экселе, мапе или любым наглядным способом. Совещания можно заменить стенд-ап митингами, этакими 15-минутками, а то и убрать вообще. Конечно,важные вопросы все же стоит обсуждать на совещаниях, но это,как правило,бывает редко. Но, на мой взгляд, ДЕЙСТВИТЕЛЬНО ВАЖНЫЕ вопросы не решаются с участием всей тимы\копмании.
Однако, в маленькой компании очень трудно развиваться личностно и профессионально, особенно, если нет кого-то, кто был бы умнее\искусснее тебя.

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