Ранее я уже писала о своем опыте собеседования людей на позицию тестировщиков. Так сложилось, что я в основном собеседовала людей без опыта работы.
Относительно недавно мне самой пришлось искать работу. На этот раз я была по другую сторону баррикад. И как кандидату одни собеседования мне понравились, а другие - совсем наоборот. На основе этого опыта я сделала выводы о том, как нужно и как не нужно проводить собеседования.
1. Практика, а не теория!
БОльшая часть пройденных мной собеседований была посвящена проверке моих теоретических знаний
Спрашивали все подряд - отличия тестирования белого ящика от черного, классы эквивалентности, анализ граничных значений, уровни тестирования, понимание разных методологий разработки, знание SQL, отличие приват и протектед методов или переменных от паблик и так далее. Часто такие собеседования длились больше часа, что очень и очень изматывало обе стороны.
Смысла в таких собеседованиях мало, когда приходит человек с опытом работы больше полутора-двух лет. Существует большая разница между "знаю как" и "умею". Если приходит человек с опытом работы, то непродуктивно тратить время обоих, спрашивая основы теории тестирования. Если нужна теория - можно нанимать и джуниоров, но ведь человек пришел на позицию Middle\Senior и платить ему нужно намного больше,чем джуниору. Так почему бы не узнать, за что именно ему нужно будет платить деньги, за какой опыт, какие практические знания? Более того, кандидат выходит с собеседования, так и не поняв, какие
именно его умения интересовали работодателя, с чем нужно будет иметь
дело в случае успеха и на каком уровне.
Я сторонник той мысли, что для проверки знаний теории нужно давать практические задания. Если тестовое задание на знание этой теории придумать сложно, то стоит задуматься, действительно ли нужна эта теория.
Нужна проверка написания тестов? Просим привести пример тест кейса. Хотим проверить полноту? Можно поросить набросать небольшой список кейсов. Автоматизация? Просим написать простой код автотеста на любом языке (в крайнем случае, псевдокод) - тут как раз и проверим знание модификаторов видимости (доступа). Нужна проверка внимательности? Даем спецификацию и скриншоты готового приложения или даже даем компьютер с открытым тестовым приложением, в котором "заложены" баги.
Безусловно, теоретические знания тоже важны, но гораздо важнее понять, подходит ли кандидат для выполнения того объема работ, который от него будет требоваться, или нет. Время собеседования, как правило, ограничено, поэтому стоит потратить его на то,чтобы понять,что представляет из себя человек, как мыслит и что умеет делать, ведь гуглить и заучивать все научились еще в институте.
2. Техническое собеседование должен вести человек, который работает на том же проекте, на который проходит собеседование
Иногда техническое собеседование проводит просто "специалист по тестированию", "qa manager\lead", который работает в другой команде. Просто так сложилось,что в команде, в которую проходит собеседование, нет компетентных людей.
Итого получаем ,во-первых, скорее всего основную массу вопросов по теории, о чем говорилось выше. Во-вторых, кандидат не может задать технические вопросы, которые его интересуют, потому что собеседующий знает только поверхностно о том, какие технологии используются и как организован процесс.
Собеседование проводится для обеих сторон, и кандидату тоже интересно,что предлагает ему работодатель. Даже если в команде нет человека, который мог бы провести собеседование кандидата с опытом работы, можно попросить и более опытного сотрудника другой команды, но при условии, что он будет "в паре" с представителем той команды, в которую ищут пополнение. И представителем должен быть не один из менеджеров, а именно тестировщик любого уровня.
3. Качество связи должно быть таким, чтобы не отвлекать от главного
Если собеседование происходит по телефону\скайпу, нужно иметь лучшие телефоны, лучшую гарнитуру и лучшие звукоизолированные комнаты. Когда что-то фонит, когда слышишь собственный голос эхом, когда в соседней комнате громко смеются, когда шум автомобилей заглушает звук голоса собеседника - это сильно отвлекает и заставляет вслушиваться в слова, потом уже собирая их вместе и понимая смысл. Частые "повторите,пожалуйста, вопрос" с обеих сторон говорят о том, что собеседование можно считать неудавшимся.
Как правило,негативные впечатления после таких собеседований остаются у обеих сторон.
Подводя итог, хочется еще раз сказать,что собеседование проводится и для работодателя, и для кандидата - так что каждая из сторон может остаться недовольной. Для проведения эффективных и успешных собеседований нужно уважать время, потраченное обеими сторонами, соответственно, пытаться узнать максимум об опыте и интересах кандидата \ процессах, практиках и технологиях проекта.
October 10, 2012
Сказка о двух ящиках и одной тестировщице
Жила-была маленькая тестировщица, и по неопытности своей считала, что белый ящик - для программистов, а черный - Мекка для тестировщиков.
Но однажды наступил момент, когда ей в Jira подключили FishEye, и она смогла видеть то, каким образом был пофикшен тот или иной баг, или каким образом был заимплеменчен тот или иной функционал. По началу все изменения выглядели как наскальная живопись - было понятно о чем речь лишь по мутным и примитивным очертаниям. Тогда она стянула себе из системы контроля версий репозиторий, и очертания стали больше напоминать то,что они значили, ибо в IDE можно было перемещаться по классам и методам, чтобы понимать, что происходит. И тогда коммиты стали понятней, и несмотря на практику код ревью, принятую в команде, маленькая тестировщица все равно заглядывала в новый код посредством FishEye.
Это привело к тому, что отныне делать impact анализ можно было основываясь не только на словах разработчика и собственных предположениях, но и на том, что она сама видела. И оказалось, что, как правило, изменения затрагивали гораздо больше того, что было сказано разработчиком, и тестов нужно было сделать гораздо больше, чтобы убедиться в правильности имплементации. Чек листы стали более полными, что позволяло отловить больше багов.
А маленькая тестировщица теперь при получении тикета в Jira первым делом открывает вкладку Source и смотрит изменения в файлах, а уж потом приступает к тестированию. А в случае, если на нее ассайнят тикет, где такая вкладка для нее отсутствует, она брезгливо морщится и тяжело вздыхает.
Не стоит брезговать выпрашивать открыть код любыми доступными способами и смотреть реализацию методов. Это поможет лучше понимать, у каких кейсов реально есть шанс отловить ошибки, а какие делаются просто для того, чтобы "погладить кота по шерсти" и убедиться, что все работает в тепличных условиях. Можно сколько угодно долго рассуждать о классах эквивалентности, граничных значениях и тому подобных вещах,
но это не имеет никакого смысла до тех пор, пока нет доступа к коду.
October 4, 2012
Lessons learned in SCRUM. Lesson 2 - Add new person to help или "Ой ли?"
Никогда не верила в тот постулат, что добавление нового человека в скрам команду по началу влечет за собой потерю производительности. Ведь человека добавили, дополнительный мозговой центр и обладатель рук может только помочь!
Но на практике оказалось,что есть большая разница между тем, кого именно добавляют. И речь идет не столько о скиле (что тоже немаловажно), сколько о персональных качествах нового члена команды.
Итак, к примерам из жизни, но в этот раз без графиков, к сожалению.
Пример 1. В команду добавили не очень опытного человека. Он хочет учиться, у него горят глаза, ему нравиться работать в команде опытных людей. В нашем случае это привело к тому, что производительность команды не упала, а незначительно увеличилась. Безусловно, часть времени тратилась на помощь новичку в освоении новых знаний, в то же время порученную ему работу он делал добросовестно, давая более опытным товарищам время на работу с более сложными задачами.
Пример 2. В команду добавили опытного человека. Он мыслит рационально, спокоен и рассудителен. Первый спринт производительность незначительно увеличилась, но после первого спринта начался рост и стабильный прирост к производительности команды, которую она показывала ранее.
Пример 3. В команду добавили опытного человека. Он реформатор, стремится улучшать качество продукта и процессов, но делает это слишком настойчиво и рьяно, его трудно убедить, даже если он просто явно не понимает еще всех внутренних процессов и условий работы.
Первый спринт производительность немного просела, потом вернулась к прежнему значению. По мере вливания нового человека в процесс производительность команды повышалась, и остановилась примерно на той же отметке, что и при добавлении человека из второго примера. Несмотря на то,что потенциал человека из примера 3 значительно выше, ожидаемого эффекта улучшения не получилось по той причине, что в команде возникло некоторое напряжение, связанное с непривычной для команды манерой обсуждения спорных моментов и невозможностью положиться на опыт друг друга - новичок не может положиться на опыт команды, так как еще не доверяет ей, а команда не может еще положиться на опыт новичка, так как привыкла решать проблемы сообща и приходя к компромиссу на основании выбора лучшего варианта на данный момент.
Подытоживая, хочу отметить, что к выбору нового человека в сложившуюся скрам команду нужно подходить с большой серьезностью и оценивать не только профессиональные качества кандидата, но и личностные. То, насколько быстро и безболезненно он вольется в команду, и вольется ли, напрямую влияет на отношения внутри команды и ее производительность. Не гонитесь за скилами кандидата - сначала прикиньте, сколько времени и сил займет у обоих сторон сгладить углы во взаимодействии.
Но на практике оказалось,что есть большая разница между тем, кого именно добавляют. И речь идет не столько о скиле (что тоже немаловажно), сколько о персональных качествах нового члена команды.
Итак, к примерам из жизни, но в этот раз без графиков, к сожалению.
Пример 1. В команду добавили не очень опытного человека. Он хочет учиться, у него горят глаза, ему нравиться работать в команде опытных людей. В нашем случае это привело к тому, что производительность команды не упала, а незначительно увеличилась. Безусловно, часть времени тратилась на помощь новичку в освоении новых знаний, в то же время порученную ему работу он делал добросовестно, давая более опытным товарищам время на работу с более сложными задачами.
Пример 2. В команду добавили опытного человека. Он мыслит рационально, спокоен и рассудителен. Первый спринт производительность незначительно увеличилась, но после первого спринта начался рост и стабильный прирост к производительности команды, которую она показывала ранее.
Пример 3. В команду добавили опытного человека. Он реформатор, стремится улучшать качество продукта и процессов, но делает это слишком настойчиво и рьяно, его трудно убедить, даже если он просто явно не понимает еще всех внутренних процессов и условий работы.
Первый спринт производительность немного просела, потом вернулась к прежнему значению. По мере вливания нового человека в процесс производительность команды повышалась, и остановилась примерно на той же отметке, что и при добавлении человека из второго примера. Несмотря на то,что потенциал человека из примера 3 значительно выше, ожидаемого эффекта улучшения не получилось по той причине, что в команде возникло некоторое напряжение, связанное с непривычной для команды манерой обсуждения спорных моментов и невозможностью положиться на опыт друг друга - новичок не может положиться на опыт команды, так как еще не доверяет ей, а команда не может еще положиться на опыт новичка, так как привыкла решать проблемы сообща и приходя к компромиссу на основании выбора лучшего варианта на данный момент.
Подытоживая, хочу отметить, что к выбору нового человека в сложившуюся скрам команду нужно подходить с большой серьезностью и оценивать не только профессиональные качества кандидата, но и личностные. То, насколько быстро и безболезненно он вольется в команду, и вольется ли, напрямую влияет на отношения внутри команды и ее производительность. Не гонитесь за скилами кандидата - сначала прикиньте, сколько времени и сил займет у обоих сторон сгладить углы во взаимодействии.
August 13, 2012
Lessons learned in SCRUM. Lesson 1 - Commitment или "Не откусывайте больше, чем можете проглотить"
Scrum является довольно новым направлением в моей практике, если говорить о более-менее толковом Scrum, а не его тени.
О некоторых уроках, полученных мной во время работы по этой методологии, я буду писать в блоге.
Итак,
Урок 1 - Commitment или "Не откусывайте больше, чем можете проглотить"
Понятие commitment в скраме обозначает объем работ, который команда обязуется выполнить за спринт.
Чем плохо невыполнение обещанного объема работ:
- невозможно спланировать конечную дату релиза продукта
- недовольство стейкхолдеров всех уровней
- недовольство собой команды, что в конечном итоге ведет к понижению производительности ее труда ("Мы снова сфейлили спринт. Но мы всегда фейлим, так что все в нормально и так.")
- конфликты внутри команды ("Я успел сделать, что от меня требовалось, а из-за этих лентяев мы снова сфейлили.")
- стресс и усталость.
Вот статистика работы реальной команды, вернее, только часть статистики. Для удобства столбцы обозначены цифрами 1-7, но это не обозначает номер спринта. Из графика видно, что команда все время "почти" выполняла коммитмент. Ну вот еще чуть - полдня или день - и все бы было красиво и хорошо. Но этих полдня всегда не хватает (кроме 3 столбца, когда сделали все).
После многих спринтов, когда запланированная работа превышала реально сделанную (столбики 1-5), решили-таки коммититься на меньший объем. Результат поразил - в первый такой спринт команда выполнила почти на 5% больше,чем в предыдущий, а на второй - на 10% больше! (столбики 6 и 7) При этом реально потраченное на выполнение задач время практически не изменилось.
Плюсы:
- удачно законченные спринты улучшают микроклимат в команде
- повышается производительность труда
- заинтересованные лица тоже довольны
- со временем команда учится более точно соизмерять свои силы и возможности.
О некоторых уроках, полученных мной во время работы по этой методологии, я буду писать в блоге.
Итак,
Урок 1 - Commitment или "Не откусывайте больше, чем можете проглотить"
Понятие commitment в скраме обозначает объем работ, который команда обязуется выполнить за спринт.
Чем плохо невыполнение обещанного объема работ:
- невозможно спланировать конечную дату релиза продукта
- недовольство стейкхолдеров всех уровней
- недовольство собой команды, что в конечном итоге ведет к понижению производительности ее труда ("Мы снова сфейлили спринт. Но мы всегда фейлим, так что все в нормально и так.")
- конфликты внутри команды ("Я успел сделать, что от меня требовалось, а из-за этих лентяев мы снова сфейлили.")
- стресс и усталость.
Вот статистика работы реальной команды, вернее, только часть статистики. Для удобства столбцы обозначены цифрами 1-7, но это не обозначает номер спринта. Из графика видно, что команда все время "почти" выполняла коммитмент. Ну вот еще чуть - полдня или день - и все бы было красиво и хорошо. Но этих полдня всегда не хватает (кроме 3 столбца, когда сделали все).
Лучше откусить кусок поменьше и добрать задачи. В конечном итоге, команда может сделать бОльший объем работы в более комфортных условиях.
Плюсы:
- удачно законченные спринты улучшают микроклимат в команде
- повышается производительность труда
- заинтересованные лица тоже довольны
- со временем команда учится более точно соизмерять свои силы и возможности.
April 19, 2012
Стратоконф: «Использование public clouds для нагрузочного тестирования web-сайтов»
Вот и закончилась первая встреча конференции Стратоконф.
Доклад был посвящен нагрузочному тестированию и назывался он «Использование public clouds для нагрузочного тестирования web-сайтов» (докладчик - Александр Балабанов).
Я редко сталкивалась с нагрузочным тестированием, поэтому тема была мне интересной и довольно новой. Очень порадовала именно практическая направленность - рассказали об инструментах и показали их работу практически в live-режиме (Chief, Tsung, Amazon Cloud). Из демонстрации стало ясно,что нагрузочное тестирование не так страшно, как мне о нем думалось ранее (во всяком случае, когда речь идет о вебе).
И все же чего-то не хватило. Возможно, краткого обзора "поставщиков" клаудов, существующих на сегодняшний день, или объяснения, почему же выбран именно амазон.
April 16, 2012
Не пропустить: Software Testing Virtual Conference от EuroSTAR
16 мая состоится Software Testing Virtual Conference от EuroSTAR. Конференция бесплатная, но требует предварительной регистрации. "Встреча" обещает быть интересной - хорошие темы, мега опытные докладчики... В общем, регистрируемся и ждем 16 мая!А здесь регистрация и более детальная информация о докладчиках.
На повестке дня:
Model Driven Development and its Impact on Testing. A Nanotech Case Study with Bryan Bakker, Sioux Embedded Systems B.V.Bryan discusses how Sioux has developed several projects with a Model Driven Development approach. He talks through the problems they found, and details information they have used for follow-up projects.Many Ways to Manage Exploratory Testing with James Lyndsay, Workroom Productions Ltd.Where (Testing) Ideas Come From with Alan Page, MicrosoftThis talk will be a swift spin through the pros and cons of typical ways that teams manage exploratory testing. James will dip into some possible alternatives, taking inspiration from machine learning, lean approaches, and from other industries who find value in exploration.
Alan discusses where new test ideas come from, and how anyone can use learning, creativity, pattern recognition and pragmatism to discover and apply new ideas anywhere - especially in software testing.Thinking Visually in Software Testing with Alan Richardson, Compendium DevelopmentsAlan shares his experience of using models and diagrams to help his test planning and communication of testing. He will cover "Not Thinking Visually" - what this looks like, why it is the norm, and traps your readers will fall into.
April 10, 2012
Боевое крещение (Pairwise testing)
Впервые предоставилась возможность использовать pairwise testing в реальных условиях! До этого много читала и безусловно соглашалась с эфективностью этого подхода, однако,шанса все не выпадало. И вот свершилось!
Напомню,что
О самом алгоритме подробнее можно прочитать здесь
Для генерации я использовала PICT от Майкрософт. Консольная утилитка на входе принимает файл модели (описание параметров и их значения), а на выходе выдает готовые комбинации, даже умеет в эксельку красиво выводить, что не может не радовать.
При необходимости можно создавать "подмодели", учитывать зависимые параметры и перебирать не парами, а,например, тройками параметров.
Результаты реально впечатляющие - из 150+ возможных комбинаций (потом надоело считать) было оставлено 14!
Напомню,что
All-pairs testing"" or pairwise testing is a combinatorial software testing method that, for each pair of input parameters to a system (typically, a software algorithm), tests all possible discrete combinations of those parameters. Using carefully chosen test vectors, this can be done much faster than an exhaustive search of all combinations of all parameters, by "parallelizing" the tests of parameter pairs. The number of tests is typically O(nm), where n and m are the number of possibilities for each of the two parameters with the most choices.
(c) Wiki
О самом алгоритме подробнее можно прочитать здесь
Для генерации я использовала PICT от Майкрософт. Консольная утилитка на входе принимает файл модели (описание параметров и их значения), а на выходе выдает готовые комбинации, даже умеет в эксельку красиво выводить, что не может не радовать.
При необходимости можно создавать "подмодели", учитывать зависимые параметры и перебирать не парами, а,например, тройками параметров.
Результаты реально впечатляющие - из 150+ возможных комбинаций (потом надоело считать) было оставлено 14!
January 17, 2012
Re: Testing-by-contract VS defensive testing
Начала писать ответ на статью в комменте, но вышло много буков - пришлось перенести к себе в блог.
Testing-by-contract и Defensive testing - это два разных подхода к тестированию. Как и любую методологию, каждый из этих подходов будет эффективен при соблюдении каких-то условий. Соответственно, и какой подход применять, решается для каждого КОНКРЕТНОГО проекта.
1. Что мы знаем о пользователях?
Пример 1.
Многопользовательская система
Ориентировочное количество пользователей - 1000
Характеристика пользователя:
возраст - от 10 и до 55-60 лет
навык владения компьютером - от базового до продвинутого
Личности целевой аудитории: неизвестны
Какой подход использовать в этом случае?
Конечно, второй - Defensive testing - и никаких сомнений!
Мы не знаем и не можем предположить, что взбредет в голову нашим пользователям - как они будут использовать нашу систему и для каких целей.
Пример 2.
Многопользовательская система
Ориентировочное количество пользователей - 35
Характеристика пользователя:
возраст - от 25 до 45 лет
навык владения компьютером - продвинутый
Личности целевой аудитории: известны - это работники предприятия, которое заказало разработку продукта
Какой подход использовать?
Обговорите с заказчиком,узнайте,чего он хочет. Я бы предлагала ему testing-by-contract, возможно,с некоторыми исключениями. Список исключений можно выяснить при разговоре с представителем будущих пользователей, назовем его бизнес-специалистом. Это человек, который знает о том, для чего предназначена разрабатываемая система и который будет сталкиваться с ней в ежедневной работе.
2. Особенности заказной разработки "для себя"
а) Направленность пользователей на результат
Как правило, когда разработка заказывается "для себя",а не для продажи, то и требования к ней уникальны. Люди бизнеса отлично понимают язык цифр и если им предоставить примерный расчет затрат на тестирование негативных сценариев и их исправление, многие решат сократить их количество. Почему? Потому что некоторые из сценариев не придут в голову тому, кто использует систему не для того,чтобы сломать,а чтобы РАБОТАТЬ с ней и получить от системы то,ЧТО ОНА ДОЛЖНА ВЫПОЛНЯТЬ. Зачем тратить время и умышленно делать разработку продукта дороже, если проверяемые нами сценарии ни разу не будут задействованы при эксплуатации системы? Зачем тратить время на их исправление?
Не ставится,выдает непонятное сообщение об ошибке. И что?! Пусть и дальше не ставится, "сам дурак"...
б) Превентивные меры
В некоторых случаях дешевле научить персонал вводить только корректные данные в формочки, чем включать в скоуп разработки развернутую обработку ошибок. Как превентивная мера может использоваться внутренняя документация предприятия - формы заполнения бланков, инструкции по работе с инструментами, описание принятия необходимых мер при возникновении той или иной проблемы...
в) Прибыль - уже сейчас
Обратите внимание на системы учета чего угодно в государственных учреждениях или маленьких коммерческих структурах. Эти системы тормозят, зависают, могут выдавать некорректные данные или не выдавать вообще, да и выглядят отвратительно,в конце концов. Одним словом - сырые, недоработанные и совсем не user-friendly.
Так почему же их используют? Потому что уже СЕЙЧАС эта система, такая сырая и некрасивая, может приносить прибыль - и ее берут в эксплуатацию, по ходу получаю апдейты и патчи. Заказная разработка стоит дорого, чем раньше она начнет окупаться- тем лучше.
г) Исключения
Безусловно,следует понимать последствия фейлов и специфику системы. Если речь идет о коррапте базы данных при попытке заимпортить в нее файл не того формата,что определен в требованиях - это нужно проверять. Если ранее Вами было выяснено у бизнес специалиста\заказчика,что эта ситуация реальна и узнали у программиста(\из кода\совершенно случайно\...), что это действительно может привести к серьезным последствиям.
Такие исключения никто не запретит добавлять в тест план. Конечно, после обсуждения с заказчиком,если разработка все же заказная и было условлено тестировать систему только позитивными сценариями.
Итог:
Testing-by-contract имеет право на жизнь для заказных систем с известным кругом пользователей. Принятие решения по использованию именно этого подхода должно быть обговорено с заказчиком. Бенефит для заказчика - удешевляет разработку. Бенефит для компании-разработчика - клиент не уходит к другому заказчику, который обещает сделать все тоже самое, но в 3 раза быстрее и дешевле (мы-то знаем,что он просто будет делать только defense testing,иначе эта цель недостижима). В "умелых руках" и при соблюдении должных условий этот подход к тестированию может принести большую пользу. Однако,использовать нужно осторожно, возможно, придется добавить гибкости и все же описать и обработать какие-то негативные сценарии - зависит от контекста (сложность системы, критичность дефектов, пользователи).
Defensive testing рекомендуется использовать во всех остальных случаях.
Testing-by-contract и Defensive testing - это два разных подхода к тестированию. Как и любую методологию, каждый из этих подходов будет эффективен при соблюдении каких-то условий. Соответственно, и какой подход применять, решается для каждого КОНКРЕТНОГО проекта.
1. Что мы знаем о пользователях?
Пример 1.
Многопользовательская система
Ориентировочное количество пользователей - 1000
Характеристика пользователя:
возраст - от 10 и до 55-60 лет
навык владения компьютером - от базового до продвинутого
Личности целевой аудитории: неизвестны
Какой подход использовать в этом случае?
Конечно, второй - Defensive testing - и никаких сомнений!
Мы не знаем и не можем предположить, что взбредет в голову нашим пользователям - как они будут использовать нашу систему и для каких целей.
Пример 2.
Многопользовательская система
Ориентировочное количество пользователей - 35
Характеристика пользователя:
возраст - от 25 до 45 лет
навык владения компьютером - продвинутый
Личности целевой аудитории: известны - это работники предприятия, которое заказало разработку продукта
Какой подход использовать?
Обговорите с заказчиком,узнайте,чего он хочет. Я бы предлагала ему testing-by-contract, возможно,с некоторыми исключениями. Список исключений можно выяснить при разговоре с представителем будущих пользователей, назовем его бизнес-специалистом. Это человек, который знает о том, для чего предназначена разрабатываемая система и который будет сталкиваться с ней в ежедневной работе.
2. Особенности заказной разработки "для себя"
а) Направленность пользователей на результат
Как правило, когда разработка заказывается "для себя",а не для продажи, то и требования к ней уникальны. Люди бизнеса отлично понимают язык цифр и если им предоставить примерный расчет затрат на тестирование негативных сценариев и их исправление, многие решат сократить их количество. Почему? Потому что некоторые из сценариев не придут в голову тому, кто использует систему не для того,чтобы сломать,а чтобы РАБОТАТЬ с ней и получить от системы то,ЧТО ОНА ДОЛЖНА ВЫПОЛНЯТЬ. Зачем тратить время и умышленно делать разработку продукта дороже, если проверяемые нами сценарии ни разу не будут задействованы при эксплуатации системы? Зачем тратить время на их исправление?
Пример - установка десктопного приложения в папку с максимальным уровнем вложенности для ОС.
Не ставится,выдает непонятное сообщение об ошибке. И что?! Пусть и дальше не ставится, "сам дурак"...
б) Превентивные меры
В некоторых случаях дешевле научить персонал вводить только корректные данные в формочки, чем включать в скоуп разработки развернутую обработку ошибок. Как превентивная мера может использоваться внутренняя документация предприятия - формы заполнения бланков, инструкции по работе с инструментами, описание принятия необходимых мер при возникновении той или иной проблемы...
в) Прибыль - уже сейчас
Обратите внимание на системы учета чего угодно в государственных учреждениях или маленьких коммерческих структурах. Эти системы тормозят, зависают, могут выдавать некорректные данные или не выдавать вообще, да и выглядят отвратительно,в конце концов. Одним словом - сырые, недоработанные и совсем не user-friendly.
Так почему же их используют? Потому что уже СЕЙЧАС эта система, такая сырая и некрасивая, может приносить прибыль - и ее берут в эксплуатацию, по ходу получаю апдейты и патчи. Заказная разработка стоит дорого, чем раньше она начнет окупаться- тем лучше.
г) Исключения
Безусловно,следует понимать последствия фейлов и специфику системы. Если речь идет о коррапте базы данных при попытке заимпортить в нее файл не того формата,что определен в требованиях - это нужно проверять. Если ранее Вами было выяснено у бизнес специалиста\заказчика,что эта ситуация реальна и узнали у программиста(\из кода\совершенно случайно\...), что это действительно может привести к серьезным последствиям.
Такие исключения никто не запретит добавлять в тест план. Конечно, после обсуждения с заказчиком,если разработка все же заказная и было условлено тестировать систему только позитивными сценариями.
Итог:
Testing-by-contract имеет право на жизнь для заказных систем с известным кругом пользователей. Принятие решения по использованию именно этого подхода должно быть обговорено с заказчиком. Бенефит для заказчика - удешевляет разработку. Бенефит для компании-разработчика - клиент не уходит к другому заказчику, который обещает сделать все тоже самое, но в 3 раза быстрее и дешевле (мы-то знаем,что он просто будет делать только defense testing,иначе эта цель недостижима). В "умелых руках" и при соблюдении должных условий этот подход к тестированию может принести большую пользу. Однако,использовать нужно осторожно, возможно, придется добавить гибкости и все же описать и обработать какие-то негативные сценарии - зависит от контекста (сложность системы, критичность дефектов, пользователи).
Defensive testing рекомендуется использовать во всех остальных случаях.
Гремучая смесь - толковый технический специалист и слабый командный игрок
Принято считать,что ИТ-шники довольно замкнутые люди с низким уровнем социализации, и что открытые общительные люди в нашей отрасли скорее исключение из правил. На самом деле, речь идет о профессиональном искажении,присущем каждой из профессий в том или ином виде, но этот пост не о том. И даже не в том, как с ним борются или пытаются минимизировать в рамках компании.
Представим ситуацию, что есть очень толковый технический специалист, но с небольшим (?) минусом - он слабый командный игрок. Я встречала два типа такой гремучей смеси:
1. Одиночка
Такой тип специалистов встречается преимущественно среди разработчиков.
Зачастую малообщителен и очень замкнут. Никому не доверяет (ведь он "очень толковый", а остальные просто "толковые"), но это обычно оправдано. В силу особенностей поведения может доводить тестировщиков до белого каления. Однако,ему никто не нужен - он сам способен выполнять весь спектр работ на проекте.
Идеально работает в проектах на одного человека, где никто не мешает ему и где никому не мешает он. Со временем может найти друга и позволить ему работать с собой. При этом личностные качества друга будут важнее профессиональных.
2. Альфа-самец
Может быть как "душой компании", так и просто уважаемым человеком. Имеет авторитет в технических вопросах. Однако использует его не всегда во благо компании - свой авторитет ревностно оберегает и подавляет "инакомыслящих", что приводит к тому,что мнение команды является мнением одного человека. Возникают проблемы и вопросы - поставить его на руководящую должность значит официально дать разрешение на авторитарность в принятии решений. Не поставить на руководящую должность - значит все время заставлять соперничать формального (менеджера) и неформального (альфа-самца) лидеров.
А в Вашей практике встречались еще какие-то виды такой гремучей смеси?
"Гремучей" такая смесь является потому, что и отпускать сильного технического специалиста не хочется, и танцевать с бубном, пытаясь сделать его работу и работу с ним эффективной, не каждому по силам и "по нервам".
Представим ситуацию, что есть очень толковый технический специалист, но с небольшим (?) минусом - он слабый командный игрок. Я встречала два типа такой гремучей смеси:
1. Одиночка
Такой тип специалистов встречается преимущественно среди разработчиков.
Зачастую малообщителен и очень замкнут. Никому не доверяет (ведь он "очень толковый", а остальные просто "толковые"), но это обычно оправдано. В силу особенностей поведения может доводить тестировщиков до белого каления. Однако,ему никто не нужен - он сам способен выполнять весь спектр работ на проекте.
Идеально работает в проектах на одного человека, где никто не мешает ему и где никому не мешает он. Со временем может найти друга и позволить ему работать с собой. При этом личностные качества друга будут важнее профессиональных.
2. Альфа-самец
Может быть как "душой компании", так и просто уважаемым человеком. Имеет авторитет в технических вопросах. Однако использует его не всегда во благо компании - свой авторитет ревностно оберегает и подавляет "инакомыслящих", что приводит к тому,что мнение команды является мнением одного человека. Возникают проблемы и вопросы - поставить его на руководящую должность значит официально дать разрешение на авторитарность в принятии решений. Не поставить на руководящую должность - значит все время заставлять соперничать формального (менеджера) и неформального (альфа-самца) лидеров.
А в Вашей практике встречались еще какие-то виды такой гремучей смеси?
"Гремучей" такая смесь является потому, что и отпускать сильного технического специалиста не хочется, и танцевать с бубном, пытаясь сделать его работу и работу с ним эффективной, не каждому по силам и "по нервам".
January 10, 2012
Интересный факт - Эффект Даннинга-Крюгера
Некоторые вещи ставит на свои места, о других заставляет задуматься:
Описание взято с вики.
Эффект Даннинга-Крюгера — когнитивное искажение, которое заключается в том, что «люди, имеющие низкий уровень квалификации, делают ошибочные выводы и принимают неудачные решения, но не способны осознавать свои ошибки в силу своего низкого уровня квалификации». Это приводит к возникновению у них завышенных представлений о собственных способностях, в то время как действительно высококвалифицированные люди, наоборот, склонны занижать свои способности и страдать недостаточной уверенностью в своих силах, считая других более компетентными. Таким образом, менее компетентные люди в целом имеют более высокое мнение о собственных способностях, чем это свойственно людям компетентным, которые к тому же склонны предполагать, что окружающие оценивают их способности так же низко, как и они сами.
Ими была выдвинута гипотеза, что для людей с низкой квалификацией в любом виде деятельности характерно следующее:
- они склонны переоценивать собственные умения;
- они не способны адекватно оценивать действительно высокий уровень умений у других;
- они не способны осознавать всю глубину своей некомпетентности;
- в случае, если уровень этих умений удаётся значительно повысить, у них появляется способность осознать уровень своей прежней некомпетентности.
Описание взято с вики.
October 7, 2011
Помните о своей команде
Не в первый раз слышу о том, что работой людей "засветившихся" с докладами на конференциях или собраниях сообществ, постоянных посетителей этих сообществ и т.д. не очень-то довольна их команда, с которой они живут рядом изо дня в день, дышат одним воздухом и делают общее дело.
Товарищи профессионалы, в погоне за узнаваемостью своего имени, за повышением зарплаты вследствие этой узнаваемости, за ощущением собственной "значимости и офигенности" - не забывайте о своих командах - продолжайте работать в полную силу, не считайте их глупее вас только потому, что они не светятся в развивающейся у нас сфере тестирования, и не забывайте просить их давать вам фидбек, ведь он будет самым честным и полезным.
Товарищи профессионалы, в погоне за узнаваемостью своего имени, за повышением зарплаты вследствие этой узнаваемости, за ощущением собственной "значимости и офигенности" - не забывайте о своих командах - продолжайте работать в полную силу, не считайте их глупее вас только потому, что они не светятся в развивающейся у нас сфере тестирования, и не забывайте просить их давать вам фидбек, ведь он будет самым честным и полезным.
September 8, 2011
И пришел Аврал...
Ситуация часто встречающаяся и всем известная - "восемь девок, один я" - много разработчиков и мало тестировщиков. Что делать, куда бежать?
Вариант 1. Самый простой, очевидный, никого не напрягающий.
- "Останусь-ка я подольше".
Но потом зачастую выясняется, что и это не спасает.
Вариант 2. Иногда не дающий положительного эффекта.
Привлекаем тестировщиков с других проектов или из других команд. Хоть на день, хоть по два часа в день в течение недели. И то будет помощь в разгружке наших плечей.
Как правило, работает для важных и приоритетных тасок.
Вариант 3. Часто вызывающий сопротивление со стороны разработчиков.
Привлекаем разработчиков для помощи в тестировании. Создание тестовых данных, регистрация аккаунтов, настройка системы, иногда даже непосредственно тестирование - может быть переложено на сильные плечи наших добрых программистов.
Вариант 4. Почти сказочный.
Договариваемся о переносе сроков в связи с тем, что функционал не будет как следует протестирован к назначенному сроку.
Мини-памятка:
Когда происходит частое изменение условий работы (например, на тестирование в процессе работы над уже оговоренным скоупом в него добавляются новые таски) - следует не забывать
- каждый день мониторить изменения
- заново оценивать необходимое на тестирование время, исходя из изменений
- не стесняться просить о помощи
- пытаться подключать к работе всех, кого только можно (безусловно, если таска достаточно важная).
Вариант 1. Самый простой, очевидный, никого не напрягающий.
- "Останусь-ка я подольше".
Но потом зачастую выясняется, что и это не спасает.
Вариант 2. Иногда не дающий положительного эффекта.
Привлекаем тестировщиков с других проектов или из других команд. Хоть на день, хоть по два часа в день в течение недели. И то будет помощь в разгружке наших плечей.
Как правило, работает для важных и приоритетных тасок.
Вариант 3. Часто вызывающий сопротивление со стороны разработчиков.
Привлекаем разработчиков для помощи в тестировании. Создание тестовых данных, регистрация аккаунтов, настройка системы, иногда даже непосредственно тестирование - может быть переложено на сильные плечи наших добрых программистов.
Вариант 4. Почти сказочный.
Договариваемся о переносе сроков в связи с тем, что функционал не будет как следует протестирован к назначенному сроку.
Мини-памятка:
Когда происходит частое изменение условий работы (например, на тестирование в процессе работы над уже оговоренным скоупом в него добавляются новые таски) - следует не забывать
- каждый день мониторить изменения
- заново оценивать необходимое на тестирование время, исходя из изменений
- не стесняться просить о помощи
- пытаться подключать к работе всех, кого только можно (безусловно, если таска достаточно важная).
June 8, 2011
Элияху М. Голдрат, Джефф Кокс: Цель. Процесс непрерывного совершенствования
Замечательная книга "Цель. Процесс непрерывного совершенствования" написана в форме новеллы, что само по себе является необычным для подобного рода литературы. Однако, это делает ее более увлекательной и быстро читаемой.
Главный герой - Алекс Рого - руководитель убыточного завода, которому руководство дает 3 месяца на изменение ситуации, после чего, в случае недостаточных изменений, обещает закрыть завод. Книга описывает трехмесячный период непрерывной работы над улучшением процесса производства. В итоге Алекс и его помощники-коллеги приходят к выводу, что цель компании - зарабатывать деньги, а также определяют алгоритм работы на заводах объединения:
Шаг 1. Найти узкие звенья системы.
Узкое звено в реалиях завода - это это все то, что не позволяет компании производить столько продукции, сколько ей требуется. Это может быть не только материалы, оборудование или люди, это также может быть продажи, например.
Шаг 2. Решить, как использовать узкое звено.
Узкое звено должно задавать ритм работы всей системы.Оно используется для контроля, чтобы избежать перегрузки системы или создания нежелательных запасов (например, горы материалов перед узким звеном или большое количество материалов\готовое продукции на складе, которые никому не нужны).
Шаг 3. Согласовать все остальные действия с этим решением.
Нет смысла производить много больше,чем может обработать узкое звено - продукция либо будет создавать завалы перед узким звеном в ожидании обработки, либо будет пылиться на складе.
Шаг 4. Повысить пропускную способность узкого звена.
Создание "буфера" перед узким звеном для обеспечения его непрерывной работы (при этом в буфере должно храниться разумное количество материала, чтобы буфер не превратился в склад). Также можно "разгрузить" звено и выдавать ему на обработку только качественные детали, тем самым экономя время работы звена.
Шаг 5. Если на предыдущем этапе узкое звено было устранено, то перейти к шагу 1.
Итого, что полезного можно вынести для управления разработкой ПО:
1. Цель компании - зарабатывать деньги.
Качество продукта само по себе не может быть целью. Как и выпуск продукта. Целью должна быть именно прибыль. Если наш продукт никто не покупает - зачем его писать? И уж тем более зачем тщательно тестировать, заставляя исправлять сценарии "с подвыподвертом", тем самым увеличивая конечную стоимость продукта. Тестирование ни в коем случае нельзя рассматривать отдельно от процесса производства продукта.
2. Алгоритм не меняется!
Шаг 1. Найти узкими звенья - почему нет? Например, на стадии жестокого багфикса с ежедневными билдами программисты исправляют по 100 багов в день, а отдел тестирования в день проверяет только 60.
Шаг 2. Тогда тестировщики будут узким звеном, под которое и нужно будет подстраивать всю работу.
Шаг 3. Голдрат на заводе в таких случаях рекомендует позволять людям ничего не делать, чтобы не собирать тонны работы перед узкими звеньями. В разработке ПО же все будет проще - достаточно занять людей, производящих "на склад" другой работой - например, переключить на другой проект или другую задачку, которая пока не будет проходить через тестировщиков. Это не требует перехода в другой цех и не требует знаний другого производственного оборудования, поэтому мы более везучие, чем рабочие завода :)
Шаг 4. Временно снимем с тестировщиков другие задачи, отложим их или передадим другому отделу. Сделаем небольшой буфер в определенное разумное количество тикетов для любителей поработать ночью и на случай задержки утреннего билда. Введем обязательную проверку разработчиками своих исправлений. Ну и автоматизированное тестирование сборки программистами.
Шаг 5. Ищем новое узкое звено.
3. Производство ПО практически ничем не отличается от любого другого производства.
4. Другие более мелкие выводы.
Рекомендую книгу к прочтению всеми работниками, вовлеченными в разработку ПО.
May 10, 2011
Размер бонуса
В своей пока еще короткой профессиональной жизни я встречалась с бонусной системой, и пока ни в одной компании она не была совершенной. :) Можно выделить несколько типов квартальных бонусов:
1. Отсутствие бонуса.
Плюсы:
+ Человек работает "за идею" и зарплату. В большинстве случаев он выносит на рассмотрение уже хорошо обдуманные идеи, которе реально могут пригодиться.
+ Избавлен от переживаний о том, дадут ли бонус вообще.
Минусы:
- Нужно найти идейных людей.
- Нужно хорошо продумывать политику поддержания уровня мотивации.
- Нужна прозрачная система повышения зарплаты.
2. "Слишком маленький бонус"
Плюсы:
+ Минимальные затраты со стороны предприятия.
+ Возможность написать "бонусная система" в описании вакансии.
+ Возможность небольшой мотивации материально-ориентированных сотрудников.
Минусы:
- Не всякий работник захочет "работать лучше", развиваться-обучаться и думать об усовершенствовании процессов в компании за небольшой бонус.
3. "Слишком большой бонус"
Плюсы:
+ Сотрудники крепко держатся за свое место на работе, соответсвенно, состав команд часто не меняется длительное время, что приводит к более сплоченой работе.
+ Материально-ориентированные сотрудники высоко мотивированы.
+ Придумывается много идей для улучшения процесса и повышения эффективности работы.
Минусы:
- Желание получить большой бонус заставляет некоторых людей генерировать по сто идей в неделю, большинство из которых очень сырые и непродуманные. Много не самых лучших идей внедряется очень быстро, без детального и основательного обдумывания - генераторы идей просто "продавливают" их для получения прибыли. Конечно, часть таких нововведений в скором времени сама собой перестает использоваться, но не стоит забывать,что внедрение и отказ от использования того или иного подхода-метода-инструмента стоит времени, а значит, денег.
- Нужна хорошо проработанная система оценивания персонала (либо менеджер, близко и внимательно наблюдающий за работой команды) - нужно успеть вовремя определить момент, когда человек начинает работать только за деньги, отсиживая оговоренные в трудовом договоре 8 часов в день.
4. Нормальный бонус
Плюсы:
+ Полная гармония.
Нормальный бонус вызывает у работников желание побороться за него, но не становится основной целью. Получение такого бонуса приятно, а неполучение не очень-то влияет на самооценку и\или материальное благосостояние.
После раздумий о размере "нормального" бонуса, я пришла к цифре 15%. Сначала я думала о 10 процентах, но это не подходит для компаний, где работает много джуниор сотрудников с низкой зарплатой. Во всяком случае, если бы в моей первой компании, где я стала работать тестировщиком, был бонус в 10% - вряд ли я бы стала пытаться его получить - слишком маленькая сумма получалась.
1. Отсутствие бонуса.
Плюсы:
+ Человек работает "за идею" и зарплату. В большинстве случаев он выносит на рассмотрение уже хорошо обдуманные идеи, которе реально могут пригодиться.
+ Избавлен от переживаний о том, дадут ли бонус вообще.
Минусы:
- Нужно найти идейных людей.
- Нужно хорошо продумывать политику поддержания уровня мотивации.
- Нужна прозрачная система повышения зарплаты.
2. "Слишком маленький бонус"
Плюсы:
+ Минимальные затраты со стороны предприятия.
+ Возможность написать "бонусная система" в описании вакансии.
+ Возможность небольшой мотивации материально-ориентированных сотрудников.
Минусы:
- Не всякий работник захочет "работать лучше", развиваться-обучаться и думать об усовершенствовании процессов в компании за небольшой бонус.
3. "Слишком большой бонус"
Плюсы:
+ Сотрудники крепко держатся за свое место на работе, соответсвенно, состав команд часто не меняется длительное время, что приводит к более сплоченой работе.
+ Материально-ориентированные сотрудники высоко мотивированы.
+ Придумывается много идей для улучшения процесса и повышения эффективности работы.
Минусы:
- Желание получить большой бонус заставляет некоторых людей генерировать по сто идей в неделю, большинство из которых очень сырые и непродуманные. Много не самых лучших идей внедряется очень быстро, без детального и основательного обдумывания - генераторы идей просто "продавливают" их для получения прибыли. Конечно, часть таких нововведений в скором времени сама собой перестает использоваться, но не стоит забывать,что внедрение и отказ от использования того или иного подхода-метода-инструмента стоит времени, а значит, денег.
- Нужна хорошо проработанная система оценивания персонала (либо менеджер, близко и внимательно наблюдающий за работой команды) - нужно успеть вовремя определить момент, когда человек начинает работать только за деньги, отсиживая оговоренные в трудовом договоре 8 часов в день.
4. Нормальный бонус
Плюсы:
+ Полная гармония.
Нормальный бонус вызывает у работников желание побороться за него, но не становится основной целью. Получение такого бонуса приятно, а неполучение не очень-то влияет на самооценку и\или материальное благосостояние.
После раздумий о размере "нормального" бонуса, я пришла к цифре 15%. Сначала я думала о 10 процентах, но это не подходит для компаний, где работает много джуниор сотрудников с низкой зарплатой. Во всяком случае, если бы в моей первой компании, где я стала работать тестировщиком, был бонус в 10% - вряд ли я бы стала пытаться его получить - слишком маленькая сумма получалась.
January 27, 2011
Мысли о workaround'ах
Второй день голова занята мыслями о workaround'ах и позволительности иметь их в программе независимо от их критичности.
Дело в том, что вчера я ехала на работу в маршрутном такси, в котором снаружи не было...ручки :). Изнутри мне открыл водитель, как и всем, кто садился после меня.
Проводя аналогию, я бы назвала отсуствие ручки проблемой в запуске программы традиционным способом, и приоритет был бы как минимум Critical и подпись "ASAP!!!", а то и Release Blocker. Однако, в реальной жизни был обнаружен (предложен) воркэраунд, позволяющий-таки ее запустить и использовать, хоть и...не вполне удобным способом. Преимущества на лицо:
1. Бизнес-пользователь (водитель) не потерял ни копейки своей ожидаемой прибыли.
2. Пользователи (люди) достигли цели, то есть вовремя добрались туда, куда хотели.
В общем-то, кроме некоего удивления UI'ем "программы", никто из пользователей и не заметил сбоя в работе!
Конечно, я не призываю не чинить такое вовсе. Я задалась вопросом - так ли критичны те баги, которые мы считаем критичными? Не тестируем ли мы программу в совершенно тепличных условиях и не смотрим ли мы на нее, как на то,чему суждено быть тепличным? Часто бывает, что наши юзкейсы отличаются от тех юзкейсов, которые нам потом дает бизнес, а иногда и от тех, которые потом приходят от пользователей в суппорт. Насколько наши испытания программы попадают в цель и сколько процентов от всех написанных нами тестов будут выполнять пользователи в реальной жизни, просто работая с программой, а не тестируя ее. Правильно говорят, что для успешного тестирования программы нужно научиться с ней жить.
Я часто встречала утверждение, что тестировщик должен смотреть на программу с точки зрения пользователей. Но мне кажется, нужно учиться смотреть еще и с точки зрения бизнеса.
Практика разделения Severity и Priority (о внедрении которой я как-то писала) получает еще один плюс в разрезе этой ситуации. Особенно, если выставлением приоритетов занимается представитель бизнеса, который чуть шире видит проблему и чей взгляд не зашорен мыслями о "страдающих пользователях" :)
Дело в том, что вчера я ехала на работу в маршрутном такси, в котором снаружи не было...ручки :). Изнутри мне открыл водитель, как и всем, кто садился после меня.
Проводя аналогию, я бы назвала отсуствие ручки проблемой в запуске программы традиционным способом, и приоритет был бы как минимум Critical и подпись "ASAP!!!", а то и Release Blocker. Однако, в реальной жизни был обнаружен (предложен) воркэраунд, позволяющий-таки ее запустить и использовать, хоть и...не вполне удобным способом. Преимущества на лицо:
1. Бизнес-пользователь (водитель) не потерял ни копейки своей ожидаемой прибыли.
2. Пользователи (люди) достигли цели, то есть вовремя добрались туда, куда хотели.
В общем-то, кроме некоего удивления UI'ем "программы", никто из пользователей и не заметил сбоя в работе!
Конечно, я не призываю не чинить такое вовсе. Я задалась вопросом - так ли критичны те баги, которые мы считаем критичными? Не тестируем ли мы программу в совершенно тепличных условиях и не смотрим ли мы на нее, как на то,чему суждено быть тепличным? Часто бывает, что наши юзкейсы отличаются от тех юзкейсов, которые нам потом дает бизнес, а иногда и от тех, которые потом приходят от пользователей в суппорт. Насколько наши испытания программы попадают в цель и сколько процентов от всех написанных нами тестов будут выполнять пользователи в реальной жизни, просто работая с программой, а не тестируя ее. Правильно говорят, что для успешного тестирования программы нужно научиться с ней жить.
Я часто встречала утверждение, что тестировщик должен смотреть на программу с точки зрения пользователей. Но мне кажется, нужно учиться смотреть еще и с точки зрения бизнеса.
Практика разделения Severity и Priority (о внедрении которой я как-то писала) получает еще один плюс в разрезе этой ситуации. Особенно, если выставлением приоритетов занимается представитель бизнеса, который чуть шире видит проблему и чей взгляд не зашорен мыслями о "страдающих пользователях" :)
January 9, 2011
Exploratory testing: плюсы и минусы
Исследовательское тестирование как вид не так давно вошло в мою жизнь, однако, это произошло довольно стремительно и неожиданно.
Я работала в условиях постоянного тестирования функционала по тест плану, и тут внезапно стали добавлять время на так называемое "wild testing". В моем понимании суть этого вида тестирования была в том, чтобы просто поклацать, что "ничего не падает", и я не находила никаких багов вне тест плана. Возможно, это было связано с недостатоком опыта на тот момент,а, возможно, неправильным настроем на работу :) Баги имеют интересное свойство: когда ждешь,что их нет - они умело маскируются. Но если подходить к тестированию с мыслью, что "там ТОЧНО что-то есть" - только успевай записывать и фотографировать :)
Но потом условия несколько изменились и на тест планы уже не было времени (хоть я очень скептически отношусь к таким утверждениям). На помощь пришло тестирование методом свободного поиска, благо, к тому времени я уже достаточно прочитала и имела побольше опыта нахождения ошибок. Так я работала примерно с полгода, тестируя все проекты именно методом свободного поиска.
В чем была выгода его использования?
1. Тестирование методом свободного поиска меньше утомляет,чем тестирование по заранее написанному тест плану по всем правилам.
2. Приветствуется полет мысли. В тестировании строго по тест плану нет места возможности применения своего опыта или смекалки. Заранее написано куда ткнуть, сколько раз и в каком порядке. Не будешь следовать инструкциям - не сможешь сказать,что прошел именно этот тест кейс. Исследовательское тестирование, наоборот, позволяет тестировать, используя свой мозг и свой опыт, а не просто читать и повторять сценарий на другом билде. А творческая немонотонная работа, как правило, мотивирует людей. А уж сколько радости приносит обнаружение бага в сложном сценарии, который, вероятнее всего, не был бы внесен в тест план!
3. Время. Написание, поддержание и прохождение тест кейсов по тест плану занимает ощутимо больше времени ввиду понятных факторов - тест план нужно писать, поддерживать и затем читать каждый тест кейс пере прохождением :) Тестирование методом свободного поиска позволяет сэкономить время на тестирование. Однако, есть некоторые риски, с которыми придется мирится, используя этот вид тестирования.
Минусы\риски
1. Отсутствие внятной статистики. Учитывая, что тест плана как такового нет - единственный способ понять состояние продукта - это открытые баги в багтрекере. Возможности просчитать статистику изменения состояния продукта мининмальны. К тому же, можно ли будет верить статистике, основанной на количестве открытых\закрытых багов, если невозможно понять, какие именно тесты проводил тестировщик над продуктом? Все ли необходимые тесты были выполнены? Были ли результаты всех тестов интерпретированы верно, или есть шанс, что часть багов были приняты за нормальное поведение системы?
2. Из первого пункта выходит вывод - исследовательское тестирование следует поручать людям, у которых уже есть опыт тестирования подобных приложений, да и вообще, есть опыт нахождения заковыристых багов. Как правило, тестировщик анализирует найденные когда-либо баги и далее, встречая подобные ситуации и части программы, может предположить, где ему искать баги в новой программе, учитывая старый опыт. То же самое с программистами - некоторые из них делают похожие ошибки довольно часто, и, зная программиста, можно сразу начинать искать в его "зонах невнимательности и безответственности". Так что, по причине разного опыта в случае, если дать двум экспертам тестирование одного и того же модуля, они найдут разные ошибки. То есть мы снова рискуем пропустить какие-то ошибки в программе.
3. Высокие уровень субъективизма при оценке результатов. Все вышесказанное ведет к тому, что нельзя вполне верить отчету тестировщиков, основанному на результатах исследовательского тестирования. :) Такой отчет значит лишь "Мы выполнили все тесты, которые пришли нам в голову, и нашли вот это. Анализируя то, что мы нашли (или не нашли?), мы полагаем, что билд хороший для текущей стадии разработки". Конечно, это мало отличается от тестирования по тест плану - там тоже результаты основаны на наборе тестов, только этот набор может быть дополнен более опытными сотрудниками, к примеру.
У меня вышло одинаковое количество плюсов и минусов, что означает "хорошая практика, если применять в меру".
Иногда я думаю, что в тестирование можно представить в виде равностороннего треугольника со сторонами 1 - время, 2 - количество найденных ошибок, 3 - достоверность и возможность использования результатов. Если пытаешься сделать одну из сторон короче - неизменно уменьшатся и остальные стороны. Пытаешься сэкономить время - теряешь в количестве найденных ошибок и результатах. Хочешь больше статистики - нужно увеличивать время на тестирование, что (возможно) повысит количество найденных ошибок.
Следуя этой, пока не вполне обдуманной, теории, исследовательское тестирование может занять следующее место в тестировании программы вцелом:
Этим рисунком я все же хочу подчеркнуть, что не все области могут быть протестированы с помощью этого метода и не всегда плюсы будут значить для нас больше,чем минусы.
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]
Как правило, Сэмпаев помнят и уважают еще долго, если обучение проходило правильно и гладко. Поэтому, когда Ученик заканчивает обучение или переходит в другой проект, Сэмпай не должен рвать сразу все связи со своим учеником. Еще какое-то время (а,может, и долго) следует поддерживать его морально и быть советчиком в сложных для него вопросах, чтобы ученик не чувствовал себя брошенным в новую пучину неизведанных знаний.
Вывод
В заключение хочу сказать, что быть Наставником – очень ответственная часть работы, которая требует как глубоких профессиональных знаний, так и знаний в области психологии. В большинстве случаев именно от наставника зависит успех Ученика в данной компании. Подходите к обучению с умом, и пусть Ваши Ученики радуют Вас!
Я очень нервничала, и чем ближе,тем больше проклинала тот день,когда решилась это сделать. Да, выступать очень-очень страшно.
Но,к счастью, все прошло довольно хорошо. :)
Ниже презенташка моего доклада и его текст.
«Девять правил Семпая, или Как стать успешным наставником?»
[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. А Питер - да, как всегда прекрасен.
В общем впечатление о конференции весьма положительное. Такого рода мероприятия мне нравятся не только тем, что есть возможность получить новые знания, но и тем, что там я часто нахожу подтверждение каким-то своим мыслям.
Из докладов хотелось бы отметить следующие:
1. Михаил Павлов "Отвечает ли тестировщик за качество?"
К великому сожалению Михаила, частично об этом говорил Майкл Болтон буквально перед ним. Тем не менее, Михаил раскыл тему более полно и детально и я совершенно с ним согласна - тестировщик отвечать за качество не может. Странно было слышать, когда люди вставали и говорили, что тестировщик может это делать и некоторые из них это делают. Бежать, бежать из такой компании :) Как можно отвечать за то,что ты не можешь контроллировать? Можно отвечать за качество СВОЕЙ работы, за качество работы отдела тестирования - почти можно, если есть достаточно полномочий, но за качество продукта... Нет, увольте.
2. Александр Александров "Дефектные дефекты"
Слышла много негативных отзывов, мол, доклад скучный. Имхо, это просто манера изложения Александра. Или преподавателей УЦ Люксов. Или просто взрослых и мудрых людей. Доклады Александрова мне всегда нравятся тем, что в них толково раскладывается по полочкам все то,что постепенно во время работы превращается в кашу. Вроде думаешь - да и так все понятно, а нет, со временем не так уж и понятно становится :) После прослушивания его докладов знания становятся более систематизированными,что ли.
3. Денис Бесков "Послание аналитиков тестировщикам"
Интресен был взгляд со стороны аналитиков на работу тестировщиков. Учитывая, что до конференции я никогда не видела живого аналитика - было занимательно. :)
Глобальные идеи, которые я вынесла с этой конференции:
1. Автоматизация
Нужно автоматизировать рутинную работу, оставляя тестировщикам время именно на полет мысли и фантазии :) Конечно, при условии нестабильного функционала, краткосрочных продуктов и т.п. автоматизация остается в стороне.
2. Метрики
Жаль,что на предыдущей работе руки так и не дошли до введения метрик,хоть я и думала об этом. Все-таки нужно было потратить (не?)много времени и ввести парочку самых необходимых нам на тот момент.
3. Место работы, компания
Не позволять себя засасывать болоту :) И в то же время никогда не сдаваться.
4. Тулзы
Доклады о самописных тулзах гигантов индустрии меня мало интересуют ввиду их максимальной заточенности под конкретные условия работы\практики и стоимости.
5. Люди
Некоторые люди не настолько плохи, как казались.
Некоторые люди не настолько круты, как казались.
P.S. А Питер - да, как всегда прекрасен.
November 3, 2010
"Менеджер и программист"
Взято отсюда
Как-то очень жизненно :)
"Человек, летящий на воздушном шаре, обнаружил, что потерялся. Он спустился немного ниже и заметил на земле женщину. Спустившись ещё чуть ниже, он обратился к ней:
— Простите, не могли бы вы помочь? Я договорился с другом встретиться час назад, но не знаю, где сейчас нахожусь.
— Вы находитесь на воздушном шаре в 30 футах от поверхности Земли, между 40 и 41 градусом северной широты и между 59 и 60 градусом западной долготы, - ответила женщина.
— Вы, должно быть, программист?
— Да, а как вы догадались?
— Вы мне дали абсолютно точный ответ, но я совершено не представляю, что делать с этой информацией, и я всё ещё потерян. Откровенно говоря, вы мне совершенно ничем не помогли.
— А вы, наверное, менеджер?
— Да. А вы как догадались?
— Вы не знаете, где находитесь и куда направляетесь. Поднялись вы туда, благодаря воздуху. Вы дали обещание, которое не представляете, как выполнять, и ожидаете, что люди, которые находятся ниже вас, решат ваши проблемы. И, наконец, сейчас вы в том же самом положении, в котором находились до встречи со мной, но почему-то теперь в этом оказалась виновата я."
Как-то очень жизненно :)
"Человек, летящий на воздушном шаре, обнаружил, что потерялся. Он спустился немного ниже и заметил на земле женщину. Спустившись ещё чуть ниже, он обратился к ней:
— Простите, не могли бы вы помочь? Я договорился с другом встретиться час назад, но не знаю, где сейчас нахожусь.
— Вы находитесь на воздушном шаре в 30 футах от поверхности Земли, между 40 и 41 градусом северной широты и между 59 и 60 градусом западной долготы, - ответила женщина.
— Вы, должно быть, программист?
— Да, а как вы догадались?
— Вы мне дали абсолютно точный ответ, но я совершено не представляю, что делать с этой информацией, и я всё ещё потерян. Откровенно говоря, вы мне совершенно ничем не помогли.
— А вы, наверное, менеджер?
— Да. А вы как догадались?
— Вы не знаете, где находитесь и куда направляетесь. Поднялись вы туда, благодаря воздуху. Вы дали обещание, которое не представляете, как выполнять, и ожидаете, что люди, которые находятся ниже вас, решат ваши проблемы. И, наконец, сейчас вы в том же самом положении, в котором находились до встречи со мной, но почему-то теперь в этом оказалась виновата я."
October 28, 2010
Monkey Habits
Когда я была джуниор тестировщиком, мне как-то дали ссылку на статью Monkey Habits , которая взорвала мне мозг. С тех пор эта статья всегда висит на одной из вкладок моего браузера и стала моей "настольной книгой". По-моему, она гениальна. Рекомендуется к прочтению всеми и заучиванию отдельных предложений наизусть :)
Subscribe to:
Posts (Atom)