Я уже очень давно думала про Business Driven Testing, и вот, наконец-то, собралась рассказать о таком подходе.
Тестирование - это не просто тестирование
View more presentations from Julia Nechaeva.
Читать далее...
понедельник, 3 мая 2010 г.
Тестирование - это не просто тестирование
Мой рассказ на Softwarepeople 2010, плавно перетекший в диалог со слушателями. Рассказываю, что тестирование может работать на успех продукта, а не только на корректность функциональности приложения.
Я уже очень давно думала про Business Driven Testing, и вот, наконец-то, собралась рассказать о таком подходе.
Читать далее...
Я уже очень давно думала про Business Driven Testing, и вот, наконец-то, собралась рассказать о таком подходе.
Читать далее...
среда, 14 апреля 2010 г.
воскресенье, 4 апреля 2010 г.
2 вебинара и 5 конференций за 3 месяца
Сегодня утром, взглянув на количество стикеров с датами на холодильнике, я ужаснулась и поняла, что пора вести ивенттрекинговую систему. С планированием, комментариями, жизненным циклом, ответственными за определенные задачи и т.п. Мой первый план на 3 месяца вот.
8 апреля – я читаю вебинар на базе Software-testing.ru на тему «Работа с требованиями: Анализ, тестирование. Версия 2.0». Посмотрев на материалы и отзывы первого вебинара, я немного переработала структуру, добавила ещё 2 метода тестирования требований (в зависимости от формата их представления) и практически убрала из вебинара работу слушателей. Она все равно неуправляема, людям неинтересно работать в одиночестве перед монитором, не советуясь с коллегами, не обмениваясь шутками :) Поэтому всю практику я покажу своими руками на одном примере, а работу слушателей всю вынесу в домашнее задание. Вот у меня и появилось место для больше методов :) И домашнее задание тоже немного видоизменю, учтя пожелания слушателей предыдущего вебинара.
Кстати, если вы читаете этот пост, то с вероятностью 100 процентов организаторы дадут вам 10 процентную скидку на оба вебинара из серии «Аналитика для тестировщиков 2.0»
17 апреля – Training Labs, здесь я презентую этот же тренинг, но уже в живом виде. Тут будет минимум теории и максимум работы с аудиторией. Все с ног на голову – работать в классе, а теорию читать дома :)
22 апреля – второй вебинар из серии «Аналитика для тестировщиков 2.0» - «Работа с требованиями: управление изменениями».
22 апреля же, сразу после окончания вебинара я бегу на SoftwarePeople, где я рассказываю про то, как тестирование может влиять на успех продукта. Хватит уже отводить нам роль проверяльщика за программистом! Мы хотим приносить больше пользы! Мы не можем видеть, как прекрасный с точки зрения надежности и устойчивости продукт, в котором исправлены все баги с важностью выше, чем «вообще-вообще-неважно», оказывается никому не нужным!
Ну, и хочу послушать, что думают об этом люди.
23 апреля я просто слушаю доклады второго дня Softwarepeople": Саша Орлов, Сурен Самарчян, Стас Фомин, Гриша Печенкин, Сергей Архипенков, Влад Балин, Макс Дорофеев, Стас Давыдов, Костя Кондратюк, Стас Калканов, Асхат с Никитой… Я правда не знаю, как тут не разорваться.
13 мая я хочу поговорить о тестировании на Dev-Labs у Славы Панкратова в Киеве. Вот как раз думаю, о чем бы рассказать. Скорее всего, поделюсь своими мыслями о значимости тестирования на уровне всего продукта и с киевскими коллегами. Разумеется, уже учитывая опыт общения с московскими.
14-15 мая я в своем родном городе Харькове провожу 2 дня на SQA Days. Расскажу о том, чем работа в тестировании игр отличается от работы в тестировании «обычного» софта. И отличается ли вообще? ;-) Конечно же, буду присутствовать на таком значимом событии, как встреча организаторов Харьковского QA Club’a с питерскими активистами Ромой Твердохлебовым и Лешей Лянгузовым. Обмен опытом организации сообщества в своем городе – это что-то уникальное. Хочу также пригласить туда некоторых из своих бывших студентов, чтобы они посмотрели на все многообразие подходов и методик, проблем и задач, решений и озарений в тестировании.
И как член программного комитета совершенно официально заявляю, срок подачи докладов продлен до 15 апреля. Подача докладов приветствуется, благо – форматы разные, на любой вкус. А аудитория в Украине благодарная, ребята интересные, вы уж мне поверьте.
Май богат на события, 14-16 мая в Москве пройдет Конференция разработчиков игр 2010. Куда я не попадаю из-за моей верности профессии, а не отрасли =) Хотя, интересно безумно. Но туда пойдет мое Дневное Лицо большая умница Степа Корчагин, которому будет всучен диктофон и список докладов, которые надо записать.
5 июня я буду в Черновцах «тормошить IT-сообщество» города, по выражению пригласивших меня организаторов =) Зарождение профессионального сообщества – это всегда маленькое чудо и колоссальная работа. Надо поддержать ребят, которые задумали эту конференцию.
Насыщенно получилось, ага. Зато интересно, держит в тонусе и позволяет систематизировать свои мысли и наработки, поделиться ими с другими, получить фидбек. Ведь без обратной связи любая работа становится ненужной. Также и со знаниями. Если не может применить – зачем тогда знать? А чтобы применить, нужно увидеть много аспектов, много разных сторон, услышать много мнений. Конференции – это сила. Но чтобы получить от них желаемое, надо знать, что хочешь получить.
Читать далее...
8 апреля – я читаю вебинар на базе Software-testing.ru на тему «Работа с требованиями: Анализ, тестирование. Версия 2.0». Посмотрев на материалы и отзывы первого вебинара, я немного переработала структуру, добавила ещё 2 метода тестирования требований (в зависимости от формата их представления) и практически убрала из вебинара работу слушателей. Она все равно неуправляема, людям неинтересно работать в одиночестве перед монитором, не советуясь с коллегами, не обмениваясь шутками :) Поэтому всю практику я покажу своими руками на одном примере, а работу слушателей всю вынесу в домашнее задание. Вот у меня и появилось место для больше методов :) И домашнее задание тоже немного видоизменю, учтя пожелания слушателей предыдущего вебинара.
Кстати, если вы читаете этот пост, то с вероятностью 100 процентов организаторы дадут вам 10 процентную скидку на оба вебинара из серии «Аналитика для тестировщиков 2.0»
17 апреля – Training Labs, здесь я презентую этот же тренинг, но уже в живом виде. Тут будет минимум теории и максимум работы с аудиторией. Все с ног на голову – работать в классе, а теорию читать дома :)
22 апреля – второй вебинар из серии «Аналитика для тестировщиков 2.0» - «Работа с требованиями: управление изменениями».
22 апреля же, сразу после окончания вебинара я бегу на SoftwarePeople, где я рассказываю про то, как тестирование может влиять на успех продукта. Хватит уже отводить нам роль проверяльщика за программистом! Мы хотим приносить больше пользы! Мы не можем видеть, как прекрасный с точки зрения надежности и устойчивости продукт, в котором исправлены все баги с важностью выше, чем «вообще-вообще-неважно», оказывается никому не нужным!
Ну, и хочу послушать, что думают об этом люди.
23 апреля я просто слушаю доклады второго дня Softwarepeople": Саша Орлов, Сурен Самарчян, Стас Фомин, Гриша Печенкин, Сергей Архипенков, Влад Балин, Макс Дорофеев, Стас Давыдов, Костя Кондратюк, Стас Калканов, Асхат с Никитой… Я правда не знаю, как тут не разорваться.
13 мая я хочу поговорить о тестировании на Dev-Labs у Славы Панкратова в Киеве. Вот как раз думаю, о чем бы рассказать. Скорее всего, поделюсь своими мыслями о значимости тестирования на уровне всего продукта и с киевскими коллегами. Разумеется, уже учитывая опыт общения с московскими.
14-15 мая я в своем родном городе Харькове провожу 2 дня на SQA Days. Расскажу о том, чем работа в тестировании игр отличается от работы в тестировании «обычного» софта. И отличается ли вообще? ;-) Конечно же, буду присутствовать на таком значимом событии, как встреча организаторов Харьковского QA Club’a с питерскими активистами Ромой Твердохлебовым и Лешей Лянгузовым. Обмен опытом организации сообщества в своем городе – это что-то уникальное. Хочу также пригласить туда некоторых из своих бывших студентов, чтобы они посмотрели на все многообразие подходов и методик, проблем и задач, решений и озарений в тестировании.
И как член программного комитета совершенно официально заявляю, срок подачи докладов продлен до 15 апреля. Подача докладов приветствуется, благо – форматы разные, на любой вкус. А аудитория в Украине благодарная, ребята интересные, вы уж мне поверьте.
Май богат на события, 14-16 мая в Москве пройдет Конференция разработчиков игр 2010. Куда я не попадаю из-за моей верности профессии, а не отрасли =) Хотя, интересно безумно. Но туда пойдет мое Дневное Лицо большая умница Степа Корчагин, которому будет всучен диктофон и список докладов, которые надо записать.
5 июня я буду в Черновцах «тормошить IT-сообщество» города, по выражению пригласивших меня организаторов =) Зарождение профессионального сообщества – это всегда маленькое чудо и колоссальная работа. Надо поддержать ребят, которые задумали эту конференцию.
Насыщенно получилось, ага. Зато интересно, держит в тонусе и позволяет систематизировать свои мысли и наработки, поделиться ими с другими, получить фидбек. Ведь без обратной связи любая работа становится ненужной. Также и со знаниями. Если не может применить – зачем тогда знать? А чтобы применить, нужно увидеть много аспектов, много разных сторон, услышать много мнений. Конференции – это сила. Но чтобы получить от них желаемое, надо знать, что хочешь получить.
Читать далее...
среда, 31 марта 2010 г.
Swiss Testing Day отчет
Конференция Swiss Testing Day проходила в Цюрихе, в здании Конгрессхауса, что сродни московскому Дому союзов, только современнный. Зайдя туда, я, если честно, удивилась. Мне показалось, что я попала на тусовку по случаю защиты докторской. Или, на крайний случай, прием по случаю назначения нового директора банка. Множество людей в костюмах, средний возраст где-то около 40.
Регистрация открывается в 8 утра, открытие конференции в 9. В 8-05 уже полно народу, который активно между собой общается.
Выставка спонсорских стендов. Это именно что выставка. Не стенд со скучающим человечком рядом, а ряд 2х2 секторов, в каждом из которых по несколько человек, монитор, материалы и конфеты-кепки-футболки =)
Открыл конференцию главный организатор Адриан Звингли, открыл на немецком языке, поэтому при всем желании, оценить его приветственное слово не могу. Но зал реагировал живо.
В 9-10 начал говорить Джеймс Виттакер. В течение почти часа Джеймс, размахивая руками и приводя примеры из области медицины, рассказывал о том, как они в Гугле подходят к тестированию. Он вообще непревзойден, на мой взгляд, в способности приводить жизненные примеры к тестировщицким ситуациям и проблемам. Задумываешься.
Доклад Building a Successful QA Organisation проводился в довольно необычной форме: парный доклад от руководителя подразделения компании, предоставляющей услуги по тестированию и контролю качества, и представителя компании-вендора, которая пользуется их услугами на протяжении 7 лет. Такой себе, двухсторонний взгляд на вещи. Докладчики рассказали об эволюции их отношений по цепочке: need based – reliability - trust - partnership.
Проработав в аутсорсинговой компании 4 года, я много знаю о построении отношений между командой тестирования и заказчиком. Но как-то очень мало задумывалась о стратегическом пласте аутсорсинга тестирования. О том, как найти заказчика, как понять его потребность, какие решения выбрать для него, что ему предложить, какому заказчику отказать, потому что «мы так не работаем» и как выбрать это самое «как мы работаем». Ещё миллион вопросов, от решения которых высшее руководство обычно заботливо укрывает тест-менеджеров. И тест-менеджерам лишь остается не подводить свое руководство =)
А тут рассказали именно о том уровне. О том, как однажды стало понятно, что нельзя продавать ресурсы, надо предоставлять услугу. О том, что принимать ключевые решения они оставляют вендору, давая ему все на то вводные. О том, как перейти от resource based модели к service based модели отношений с заказчиком.
И, все-таки, для того, чтобы построить успешные отношения в любой отрасли – нужна любовь =) (Егор Егоров, привет!)
Worldwide Testing - Join the Crowd. Это как раз то, что я сейчас внедряю у себя в компании. Бета-тестирование. Правда, у нас с Эвальдом немного неравные позиции =) У меня уже есть сотни тысяч пользователей наших продуктов, из которых можно найти нужное количество лояльных и готовых помогать. Но, тем не менее, у него эта практика достаточно успешна.
Не соглашусь с подходом докладчика, где во главе угла такого подхода он ставит дешевость такого метода.
Обратите внимание, что левый угол у него пустой. В то время как такой подход наоборот, главным своим профитом содержит именно ранний допуск пользователей к продукту, что для них очень ценно. Создатели продукта получают заранее лояльных пользователей – что может быть дороже?
То есть, это опять же, про любовь =)
Полуторачасовой перерыв на ланч, при условии, что Конгрессхаус находится в 150 метрах от озера… мммм =)
Ну и да, по возвращению почти к концу ланчу, обратила внимание на то, что еда ещё в доступе и неостывшая.
How we Test Software at Microsoft – Биджей менее эмоционален, чем Джеймс, да и вообще, Гугловцы кажутся более бесшабашными, чем Майкрософт. В плане новаторства и всяких интересных плюшек. Всегда интересно послушать,как это делают монстры. Применять ли - другой вопрос.
Why not use the Fast Lane to reach a higher Test Maturity Level? – про Model Based Testing и про тул, который разработали в Сименсе и успешно используют. Надо сказать, что это не первый доклад, который я слушаю про Model Based Testing, но это первый, который заставил меня об этом задуматься.
Четвертый доклад меня не порадовал, но скорее потому, что тема мне оказалась неинтересной, поэтому и писать ничего про него не буду.
Ну а потом, как вы уже знаете, было St. Patrick’s Day Party =)
Хочу сказать, что аудитория, подход к общению, подборка докладов очень сильно отличается от привычных нам конференций по тестированию.
Ну и да, я в восторге =)
Читать далее...
Регистрация открывается в 8 утра, открытие конференции в 9. В 8-05 уже полно народу, который активно между собой общается.
Выставка спонсорских стендов. Это именно что выставка. Не стенд со скучающим человечком рядом, а ряд 2х2 секторов, в каждом из которых по несколько человек, монитор, материалы и конфеты-кепки-футболки =)
Открыл конференцию главный организатор Адриан Звингли, открыл на немецком языке, поэтому при всем желании, оценить его приветственное слово не могу. Но зал реагировал живо.
В 9-10 начал говорить Джеймс Виттакер. В течение почти часа Джеймс, размахивая руками и приводя примеры из области медицины, рассказывал о том, как они в Гугле подходят к тестированию. Он вообще непревзойден, на мой взгляд, в способности приводить жизненные примеры к тестировщицким ситуациям и проблемам. Задумываешься.
Доклад Building a Successful QA Organisation проводился в довольно необычной форме: парный доклад от руководителя подразделения компании, предоставляющей услуги по тестированию и контролю качества, и представителя компании-вендора, которая пользуется их услугами на протяжении 7 лет. Такой себе, двухсторонний взгляд на вещи. Докладчики рассказали об эволюции их отношений по цепочке: need based – reliability - trust - partnership.
Проработав в аутсорсинговой компании 4 года, я много знаю о построении отношений между командой тестирования и заказчиком. Но как-то очень мало задумывалась о стратегическом пласте аутсорсинга тестирования. О том, как найти заказчика, как понять его потребность, какие решения выбрать для него, что ему предложить, какому заказчику отказать, потому что «мы так не работаем» и как выбрать это самое «как мы работаем». Ещё миллион вопросов, от решения которых высшее руководство обычно заботливо укрывает тест-менеджеров. И тест-менеджерам лишь остается не подводить свое руководство =)
А тут рассказали именно о том уровне. О том, как однажды стало понятно, что нельзя продавать ресурсы, надо предоставлять услугу. О том, что принимать ключевые решения они оставляют вендору, давая ему все на то вводные. О том, как перейти от resource based модели к service based модели отношений с заказчиком.
И, все-таки, для того, чтобы построить успешные отношения в любой отрасли – нужна любовь =) (Егор Егоров, привет!)
Worldwide Testing - Join the Crowd. Это как раз то, что я сейчас внедряю у себя в компании. Бета-тестирование. Правда, у нас с Эвальдом немного неравные позиции =) У меня уже есть сотни тысяч пользователей наших продуктов, из которых можно найти нужное количество лояльных и готовых помогать. Но, тем не менее, у него эта практика достаточно успешна.
Не соглашусь с подходом докладчика, где во главе угла такого подхода он ставит дешевость такого метода.
Обратите внимание, что левый угол у него пустой. В то время как такой подход наоборот, главным своим профитом содержит именно ранний допуск пользователей к продукту, что для них очень ценно. Создатели продукта получают заранее лояльных пользователей – что может быть дороже?
То есть, это опять же, про любовь =)
Полуторачасовой перерыв на ланч, при условии, что Конгрессхаус находится в 150 метрах от озера… мммм =)
Ну и да, по возвращению почти к концу ланчу, обратила внимание на то, что еда ещё в доступе и неостывшая.
How we Test Software at Microsoft – Биджей менее эмоционален, чем Джеймс, да и вообще, Гугловцы кажутся более бесшабашными, чем Майкрософт. В плане новаторства и всяких интересных плюшек. Всегда интересно послушать,как это делают монстры. Применять ли - другой вопрос.
Why not use the Fast Lane to reach a higher Test Maturity Level? – про Model Based Testing и про тул, который разработали в Сименсе и успешно используют. Надо сказать, что это не первый доклад, который я слушаю про Model Based Testing, но это первый, который заставил меня об этом задуматься.
Четвертый доклад меня не порадовал, но скорее потому, что тема мне оказалась неинтересной, поэтому и писать ничего про него не буду.
Ну а потом, как вы уже знаете, было St. Patrick’s Day Party =)
Хочу сказать, что аудитория, подход к общению, подборка докладов очень сильно отличается от привычных нам конференций по тестированию.
Ну и да, я в восторге =)
Читать далее...
четверг, 18 марта 2010 г.
St Patrick's Day in Zurich with celebrities in Testing
Это жизнеутверждающий пост, которым я хочу сказать: не сдавайтесь, если чего-то очень хотите. Идите к цели, работайте в нужном направлении, показывайте миру, что вам это важно, и он откликнется.
Пишу этот пост на борту самолета Москва-Цюрих, в 16:40, 16 марта 2010 года. Лечу навстречу событию, которое должно было случиться больше 4 месяцев назад.
Днем позже, 17 марта, мне доведется посетить конференцию Swiss Testing Day, куда я попала приглашенным гостем по ходатайству Джеймса Виттакера, известной в тестировщицкой среде специалиста, который сейчас работает в Сиэттловском Гугле на должности Test Director.
Вечером того же дня, который ко всему ещё и День Святого Патрика, будет сделано это фото, которое показывает, что тестировщики тоже люди, тоже любят пиво и тоже ценят языческие праздники =) На ней слева направо: Биджей Роллисон (Microsoft), я, Тимур Хайруллин (Яндекс) и Джеймс Виттэкер (Google)
О самой конференции отчет я напишу обязательно, как только она закончится, а сейчас, пока лечу, хочу рассказать о том, как это все произошло. Такая себе, простая тестировщицкая сказка =)
А началось все в августе 2009. Когда Тимсон рассказал мне о конференции GTAC и дал линк на выступление Джеймса Виттакера на GTAC 09, тогда ещё он работал в майкрософте. Ну, мои отношения с конференциями вы знаете, да? (Начиная с 2008 года я побывала на 9 конференциях в области тестирования и разработки софта, выступила на 7, дважды была в оргкомитете и вот уже третий раз вхожу в программный комитет). Я очень ценю то, что на конференциях можно пообщаться с людьми, которые делают что-то, что меня интересует. Они делают это хорошо, и они готовы рассказать, как они это делают. А тут – Гугл, Виттакер, Цюрих, АААААААААА…...
По правилам GTAC 09, регистрация происходила в течение августа, принимались заявки до 28 августа, затем в течение нескольких дней оргкомитет рассматривал их и, начиная с 3 сентября, рассылались утвержденные приглашения и отказы.
Я была просто уверена в том, что получу подтверждение, ведь при подаче заявки я расписала свою активность в русскоязычном сообществе тестировщиков в графе «Why do you think you should get the GTAC conference».
И вот, 4 cентября я получаю письмо с текстом «Thank you very much for applying to attend GTAC 2009. Unfortunately due to an overwhelming response we do not have a place for you this year». Это, правда, было очень неожиданно. Хорошо, что у меня большой монитор, который скрыл мои эмоции от коллег.
Подуспокоившись, я начала думать, почему же мне пришел отказ. Али я не хороша =) Может быть, организаторы не дочитали мои комментарии? Или я мало в них написала. И я начала писать апелляцию.
Письмо получилось, на мой взгляд, достаточно эмоциональным и при этом содержало достаточно фактов.
Процитирую некоторые моменты из него:
«Let me explain why I’m striving to get GTAC……………………………………………
The main purpose of GTAC is to give people an opportunity to share their experience and knowledge on testing field. You really do a great job. Thanks for this.
I do the same for Russian-speaking testers. I often speak at different conferences and seminars because I do see a lack of lore in testing community. I am sure that we should communicate more with each other, speak about our problems and ideas and get common solutions…………………
My contribution in it is organizing a conference for Russian-speaking testers. I am a member of Organizing Committee of ‘Software Quality Assurance Days’ conference that is the biggest event for QA and QC engineers all over ex-USSR area………………….
We give a chance to our testers to find people who are also hands-on with testing and to swap their knowledge……………………………………………………
So we are working in the same field with you. I do believe that there are a lot of things I can learn from you. Also I’m sure that you are happy with such events and communities existing. We work hard to let people work easier…………………………………………………
So I’d like to ask you to review my request for getting GTAC one more time. I hope that you let me participate it because grain of knowledge I’ll get there will be planted into fertile ground. I promise.»
Однако же через 2 дня я получаю отрицательный, но, надо отметить, достаточно человечный ответ от организаторов:
«Julia - thank you for your enthusiastic plea for re-consideration - unfortunately, we decided on the participants and waiting list, have informed all of them, and will have to see what level of cancellation there will be - so far, very very few have declined the invites.»
Ненене, ребята из гугла. Вы, наверное, не понимаете, как я хочу попасть на эту конференцию =)
Но я знаю, кто может понять.
Джеймс Виттакер. Ну конечно! Не может такой клевый и здоровский дядька не отреагировать на мое желание. Тем более что он к этому времени уже стал Test Director в Google. Тем более что он наверняка будет там выступать. Раздобываю его контакт, и мое следующее письмо летит к нему. Виттакер ответил на следующий день. В достаточно дружеском тоне он написал, что
«I am sorry you didn't get accepted to GTAC, but I understand that the number of applicants this year was exceptionally high. As it turns out, I am not going either as I have a product release I have to attend to here in Seattle.
Thanks for the note. I enjoyed reading is and am glad to see the passion you have for this discipline. I hope we'll meet in person some day.»
Я отвечаю спасибо, поздравляю его с Днем тестировщика (дело-то происходит 9 сентября) и уже складываю оружие, как вдруг получаю письмо от Джеймса, в котором он пишет 2 вещи:
1 – «The closest I will get is Norway in February where I'll be speaking. As that conference gets closer I will be sure and update you.»
2 – «My new book is out now and I'd love to get it translated. (Речь идет о его книге Exploratory Software Testing.) Any chance you can make it to Norway in February? I'll forward details of the conference when I get them. I'll also be visiting our Google office in Switzerland on that trip as well.»
Тут уже монитор меня не спас =) Да и зачем было скрывать мои эмоции =)
Забегая вперед, скажу, что с переводом книги ничего не вышло, так как правообладатель, с которым меня свел Джеймс, в довольно сухой форме проинформировал меня, что они не работают с переводчиками, а лишь передают права на издание книги локальному издательству, и те уже сами решают вопрос с переводом. На мою просьбу порекомендовать меня в качестве переводчика издательству, с которым они будут сотрудничать на предмет издания книги в России, менеджер издательства-правообладателя посоветовал мне поискать предложения по работе переводчика на сайтах российских издательств =)
Тут Виттакер был бессилен. Но зато наше общение вылилось в перевод цикла его статей «7 пороков тестирования», которые опубликованы в моем блоге и на software-testing.ru. Кстати, перевод первой статьи я выложила как раз в первый день GTAC 09, как бы в отместку =)
Вяло обмениваясь письмами в режиме 1 письмо в неделею с темой «ещё одна статья переведена и выложена» - «Oh, great, thank you», я полностью успокоилась, и меня греет финальная фраза в последнем письме от организаторов GTAC «we're looking forward to hopefully seeing you in one of the upcoming GTACs in the next years!»
И вот, 23 ноября, я получаю письмо от Джеймса :
"
It's looking likely that I will be a keynote at the Swiss Testing Days in Zurich on March 17. I am sure I can pull some strings and get you involved in the Zurich event. "
Не буду рассказывать о том, как пришлось переносить самолет, потому что не успевали доставить мой паспорт с визой из Киева в Москву. Не буду здесь говорить спасибо людям, которые мне очень сильно помогли, я сказала и ещё скажу им лично.
Не буду рассказывать о трудностях получения визы в Швейцарию в украинском посольстве, скажу лишь, что это вполне себе возможно.
И вполне возможно попасть туда, куда очень хочется, если идти в этом направлении. Всегда нужно кричать о том, что ты хочешь, ведь вероятность того, что в зоне слышимости находится человек, который может помочь, очень велика.
И ещё – прислушивайтесь, пожалуйста, вдруг вы можете помочь тому, кто кричит неподалеку =)
Спасибо,
А я буду дальше любоваться облаками =)
Читать далее...
Пишу этот пост на борту самолета Москва-Цюрих, в 16:40, 16 марта 2010 года. Лечу навстречу событию, которое должно было случиться больше 4 месяцев назад.
Днем позже, 17 марта, мне доведется посетить конференцию Swiss Testing Day, куда я попала приглашенным гостем по ходатайству Джеймса Виттакера, известной в тестировщицкой среде специалиста, который сейчас работает в Сиэттловском Гугле на должности Test Director.
Вечером того же дня, который ко всему ещё и День Святого Патрика, будет сделано это фото, которое показывает, что тестировщики тоже люди, тоже любят пиво и тоже ценят языческие праздники =) На ней слева направо: Биджей Роллисон (Microsoft), я, Тимур Хайруллин (Яндекс) и Джеймс Виттэкер (Google)
О самой конференции отчет я напишу обязательно, как только она закончится, а сейчас, пока лечу, хочу рассказать о том, как это все произошло. Такая себе, простая тестировщицкая сказка =)
А началось все в августе 2009. Когда Тимсон рассказал мне о конференции GTAC и дал линк на выступление Джеймса Виттакера на GTAC 09, тогда ещё он работал в майкрософте. Ну, мои отношения с конференциями вы знаете, да? (Начиная с 2008 года я побывала на 9 конференциях в области тестирования и разработки софта, выступила на 7, дважды была в оргкомитете и вот уже третий раз вхожу в программный комитет). Я очень ценю то, что на конференциях можно пообщаться с людьми, которые делают что-то, что меня интересует. Они делают это хорошо, и они готовы рассказать, как они это делают. А тут – Гугл, Виттакер, Цюрих, АААААААААА…...
По правилам GTAC 09, регистрация происходила в течение августа, принимались заявки до 28 августа, затем в течение нескольких дней оргкомитет рассматривал их и, начиная с 3 сентября, рассылались утвержденные приглашения и отказы.
Я была просто уверена в том, что получу подтверждение, ведь при подаче заявки я расписала свою активность в русскоязычном сообществе тестировщиков в графе «Why do you think you should get the GTAC conference».
И вот, 4 cентября я получаю письмо с текстом «Thank you very much for applying to attend GTAC 2009. Unfortunately due to an overwhelming response we do not have a place for you this year». Это, правда, было очень неожиданно. Хорошо, что у меня большой монитор, который скрыл мои эмоции от коллег.
Подуспокоившись, я начала думать, почему же мне пришел отказ. Али я не хороша =) Может быть, организаторы не дочитали мои комментарии? Или я мало в них написала. И я начала писать апелляцию.
Письмо получилось, на мой взгляд, достаточно эмоциональным и при этом содержало достаточно фактов.
Процитирую некоторые моменты из него:
«Let me explain why I’m striving to get GTAC……………………………………………
The main purpose of GTAC is to give people an opportunity to share their experience and knowledge on testing field. You really do a great job. Thanks for this.
I do the same for Russian-speaking testers. I often speak at different conferences and seminars because I do see a lack of lore in testing community. I am sure that we should communicate more with each other, speak about our problems and ideas and get common solutions…………………
My contribution in it is organizing a conference for Russian-speaking testers. I am a member of Organizing Committee of ‘Software Quality Assurance Days’ conference that is the biggest event for QA and QC engineers all over ex-USSR area………………….
We give a chance to our testers to find people who are also hands-on with testing and to swap their knowledge……………………………………………………
So we are working in the same field with you. I do believe that there are a lot of things I can learn from you. Also I’m sure that you are happy with such events and communities existing. We work hard to let people work easier…………………………………………………
So I’d like to ask you to review my request for getting GTAC one more time. I hope that you let me participate it because grain of knowledge I’ll get there will be planted into fertile ground. I promise.»
Однако же через 2 дня я получаю отрицательный, но, надо отметить, достаточно человечный ответ от организаторов:
«Julia - thank you for your enthusiastic plea for re-consideration - unfortunately, we decided on the participants and waiting list, have informed all of them, and will have to see what level of cancellation there will be - so far, very very few have declined the invites.»
Ненене, ребята из гугла. Вы, наверное, не понимаете, как я хочу попасть на эту конференцию =)
Но я знаю, кто может понять.
Джеймс Виттакер. Ну конечно! Не может такой клевый и здоровский дядька не отреагировать на мое желание. Тем более что он к этому времени уже стал Test Director в Google. Тем более что он наверняка будет там выступать. Раздобываю его контакт, и мое следующее письмо летит к нему. Виттакер ответил на следующий день. В достаточно дружеском тоне он написал, что
«I am sorry you didn't get accepted to GTAC, but I understand that the number of applicants this year was exceptionally high. As it turns out, I am not going either as I have a product release I have to attend to here in Seattle.
Thanks for the note. I enjoyed reading is and am glad to see the passion you have for this discipline. I hope we'll meet in person some day.»
Я отвечаю спасибо, поздравляю его с Днем тестировщика (дело-то происходит 9 сентября) и уже складываю оружие, как вдруг получаю письмо от Джеймса, в котором он пишет 2 вещи:
1 – «The closest I will get is Norway in February where I'll be speaking. As that conference gets closer I will be sure and update you.»
2 – «My new book is out now and I'd love to get it translated. (Речь идет о его книге Exploratory Software Testing.) Any chance you can make it to Norway in February? I'll forward details of the conference when I get them. I'll also be visiting our Google office in Switzerland on that trip as well.»
Тут уже монитор меня не спас =) Да и зачем было скрывать мои эмоции =)
Забегая вперед, скажу, что с переводом книги ничего не вышло, так как правообладатель, с которым меня свел Джеймс, в довольно сухой форме проинформировал меня, что они не работают с переводчиками, а лишь передают права на издание книги локальному издательству, и те уже сами решают вопрос с переводом. На мою просьбу порекомендовать меня в качестве переводчика издательству, с которым они будут сотрудничать на предмет издания книги в России, менеджер издательства-правообладателя посоветовал мне поискать предложения по работе переводчика на сайтах российских издательств =)
Тут Виттакер был бессилен. Но зато наше общение вылилось в перевод цикла его статей «7 пороков тестирования», которые опубликованы в моем блоге и на software-testing.ru. Кстати, перевод первой статьи я выложила как раз в первый день GTAC 09, как бы в отместку =)
Вяло обмениваясь письмами в режиме 1 письмо в неделею с темой «ещё одна статья переведена и выложена» - «Oh, great, thank you», я полностью успокоилась, и меня греет финальная фраза в последнем письме от организаторов GTAC «we're looking forward to hopefully seeing you in one of the upcoming GTACs in the next years!»
И вот, 23 ноября, я получаю письмо от Джеймса :
"
It's looking likely that I will be a keynote at the Swiss Testing Days in Zurich on March 17. I am sure I can pull some strings and get you involved in the Zurich event. "
Не буду рассказывать о том, как пришлось переносить самолет, потому что не успевали доставить мой паспорт с визой из Киева в Москву. Не буду здесь говорить спасибо людям, которые мне очень сильно помогли, я сказала и ещё скажу им лично.
Не буду рассказывать о трудностях получения визы в Швейцарию в украинском посольстве, скажу лишь, что это вполне себе возможно.
И вполне возможно попасть туда, куда очень хочется, если идти в этом направлении. Всегда нужно кричать о том, что ты хочешь, ведь вероятность того, что в зоне слышимости находится человек, который может помочь, очень велика.
И ещё – прислушивайтесь, пожалуйста, вдруг вы можете помочь тому, кто кричит неподалеку =)
Спасибо,
А я буду дальше любоваться облаками =)
Читать далее...
понедельник, 8 марта 2010 г.
День знаний от Лаборатории качества - отзыв злого полицейского.
20 февраля посетила День знаний от Лаборатории Качества. Попала туда по приглашению, с предложением послушать, оценить и написать отзыв. С опозданием, но все-таки пишу.
Дальше, понимая, что учить организаторы хотели все-таки больше «молодежь», старалась оценивать каждый доклад с позиции: «Что было бы, если бы я начала учиться этому на этом конкретном докладе?»
Сразу вопрос к ребятам-организаторам: на кого были рассчитаны доклады? Целевая аудитория хотя и была объявлена, но, боюсь, не понималась самими тренерами. Попытка сделать как можно обобщеннее сыграла злую, хотя весьма предсказуемую шутку.
Саша Федоров рассказал про поддержание тестов в актуальном состоянии, про внесение (или не-внесение) изменений в тесты в случае изменений в требованиях, в ситуации, в целях, в приоритетах и т.п. При этом уровень выше – то есть тестирование «запросов» на изменения в тестах - не был затронут вообще. Из чего делаем вывод, что тест-дизайнеру уже поступают протестированные, причесанные и вылизанные изменения в требованиях. А тест-дизайнер нас всего лишь исполнитель и знай, тесты расширяет да сужает по указке.
При этом совершенно очевидно, что докладчик тему знает, на вопросы, которые я задавала с целью расширения scope доклада, отвечал хорошо, правдиво и интересно.
В итоге получилось непонятно, на кого этот рассказ был рассчитан:
- На тест-менеджеров, принимающих решения? Тогда им нужно было в первую очередь рассказывать об активностях предшествующих изменениям в тестах – менеджменте изменений и тестировании изменений, о принятии решений в области тестового покрытия, на задачи в области оценивания времени и перераспределения сил на тестирование и тест-дизайн.
- На тестировщиков-извините-обезьянок, которые попутно ещё и тесты поддерживают, а не только их проходят? Так им этого и знать не нужно, им ставь задачу – расширяй здесь, они и расширяют. Ну и, я не думаю, что ребята из ЛК рассчитывали увидеть таких на своем мероприятии.
- На тест-дизайнеров? Так любому тест-дизайнеру (неважно, выделенная это должность или просто одна из исполняемых ролей) все сказанное и так известно. Если же не известно и он пришел этому учиться – то В ПЕРВУЮ ОЧЕРЕДЬ нужно было рассказать, откуда эти изменения берутся и как их обрабатывать.
Я бы поняла, если б Саша хотел ПОКАЗАТЬ ребятам, как поддерживать и улучшать тесты, но тогда нужно было бы проводить реальный тренинг и учить их делать это руками. Выдавать тесты, выдавать условия, показывать, как надо, а потом предлагать делать самим и советовать. Голая же лекция, я ещё раз повторюсь, непонятно, кому предназначалась.
Павел Трубников… Человек явно не из тестирования, потому что с причинно-следственными связями в докладе (а это опять же был доклад, а не тренинг) было туго. Доклад для менеджеров почему-то все время сводился к тому, как найти работу.
Тем более, что это ну никак не соответствовало заявленной теме доклада. Если же Вы рассказываете для тех, кто только собирается стать профессионалом, то НЕЛЬЗЯ в голом виде подать за 30 минут всю сложность поддержания мотивации у сотрудников, которой им придется заниматься в будущем. Превратное мнение о том, что менеджер ДОЛЖЕН ДЛЯ ВСЕХ делать задачи интересными вырождается в неправильное поведение будущих менеджеров с их командой.
Ввиду моей теплой дружбы с Сашей Орловым и присутствия на множестве его тренингов по мотивации людей, мне есть с чем сравнить.
Павел начал свой доклад с того, что «я не пророк, и моё мнение не единственно верное», закончил же проповедями «забудьте о материальной мотивации», за что и был пойман аудиторией и окончательно запутан =) Уважаемый Павел! Как раз люди, которые отвечают лишь за сроки своей работы, никогда не смогут сделать продукт лучше, они смогут лишь сделать его так, как им сказали.
В общем, здесь все наоборот, слишком широкий замах, попытка смешать как минимум 4 серьезные темы в одну, при этом, не показав пути айтишника как такового.
Ну и в компетентности в области человеческой мотивации заподозрить тренера не могу.
Наташа Руколь – интересный докладчик. Если бы можно было разделить её харизму на всех – всем бы хватило и было бы веселее =) Озвучен прекрасный менеджерский подход «показывать общую картинку и место конкретной задачи в ней».
Судя по всему, тренера доклады друг друга не тестировали, иначе Наташа нашла бы критический баг в докладе Саши Федорова – несоответствие этому требованию.
Но к заявленной теме доклада все, рассказанное Наташей, относилось опять же слабо. Очень размытые понятия никак не ложились на тест-дизайн. Либо это рассказ о том, как повысить личную эффективность (непонятно, кстати, зачем), либо это заявленная тема о том, как этот скачок поможет лучше управлять тестированием. Под каждый пример можно было нарисовать конкретную задачу из тест-менеджмента и наглядно показать профит.
Доклад Михаила Давыдова послушать не получилось - убегала собираться на самолет.
Совет ребятам на будущее – четко определяйте целевую аудиторию, которую вы хотите учить, и понимайте, что она уже знает, а о чем ей нужно ещё рассказать. И обязательно приподнимайте завесу уровня (а то и нескольких уровней) выше. Ведь тестировщику, которого учат правильно описывать баги, нужно знать, как тот или иной баг повлияет на конечное качество продукта; тест-дизайнеру, пишущему тест, нужно понимать цели тестирования на каждом этапе; тест-менеджеру, принимающему решение о расширении тестового покрытия, нужно понимать, откуда взялось это дополнительное время на тестирование в проекте и что рассчитывает этим выгадать менеджер проекта. Если этот менеджер, конечно, заинтересован в успехе проекта, а не работает лишь за «сдать в срок» =)
А если в докладах ещё и будут раскрываться заявленные темы – то цены такому обучению не будет.
Ведь качество продукта – это соответствие ожиданиям пользователя, так давайте делать обучение качественным.
И нельзя забывать о том, что пользователь не всегда знает, чего же ему ждать. Тем более – неподготовленный. Берясь учить людей, нужно понимать, какую ответственность берете на себя.
Жду отзыва от Ромы, который скрасил мне галерку =) Кстати, Рома готовит презентацию про классификацию тренеров, coming soon.
Ага, вот ещё, что. Нашла Очень Положительный Отзыв (тм). Хочется задать вопрос очень простой вопрос автору: чему Вы научились на тренинге?
Собственно, вот.
Читать далее...
Претензия номер раз – ни одного тренинга не было. Были доклады, были рассказы, но единственное, чему здесь тренировали пришедших, - это слушать.
Дальше, понимая, что учить организаторы хотели все-таки больше «молодежь», старалась оценивать каждый доклад с позиции: «Что было бы, если бы я начала учиться этому на этом конкретном докладе?»
Сразу вопрос к ребятам-организаторам: на кого были рассчитаны доклады? Целевая аудитория хотя и была объявлена, но, боюсь, не понималась самими тренерами. Попытка сделать как можно обобщеннее сыграла злую, хотя весьма предсказуемую шутку.
Саша Федоров рассказал про поддержание тестов в актуальном состоянии, про внесение (или не-внесение) изменений в тесты в случае изменений в требованиях, в ситуации, в целях, в приоритетах и т.п. При этом уровень выше – то есть тестирование «запросов» на изменения в тестах - не был затронут вообще. Из чего делаем вывод, что тест-дизайнеру уже поступают протестированные, причесанные и вылизанные изменения в требованиях. А тест-дизайнер нас всего лишь исполнитель и знай, тесты расширяет да сужает по указке.
При этом совершенно очевидно, что докладчик тему знает, на вопросы, которые я задавала с целью расширения scope доклада, отвечал хорошо, правдиво и интересно.
Претензия номер два – не к опыту и знаниям докладчика, а к очень уж узко очерченной описанной области.
В итоге получилось непонятно, на кого этот рассказ был рассчитан:
- На тест-менеджеров, принимающих решения? Тогда им нужно было в первую очередь рассказывать об активностях предшествующих изменениям в тестах – менеджменте изменений и тестировании изменений, о принятии решений в области тестового покрытия, на задачи в области оценивания времени и перераспределения сил на тестирование и тест-дизайн.
- На тестировщиков-извините-обезьянок, которые попутно ещё и тесты поддерживают, а не только их проходят? Так им этого и знать не нужно, им ставь задачу – расширяй здесь, они и расширяют. Ну и, я не думаю, что ребята из ЛК рассчитывали увидеть таких на своем мероприятии.
- На тест-дизайнеров? Так любому тест-дизайнеру (неважно, выделенная это должность или просто одна из исполняемых ролей) все сказанное и так известно. Если же не известно и он пришел этому учиться – то В ПЕРВУЮ ОЧЕРЕДЬ нужно было рассказать, откуда эти изменения берутся и как их обрабатывать.
Я бы поняла, если б Саша хотел ПОКАЗАТЬ ребятам, как поддерживать и улучшать тесты, но тогда нужно было бы проводить реальный тренинг и учить их делать это руками. Выдавать тесты, выдавать условия, показывать, как надо, а потом предлагать делать самим и советовать. Голая же лекция, я ещё раз повторюсь, непонятно, кому предназначалась.
Страшно, товарищи, что вы рассказываете слушателям лишь о каком-то выделенном куске, не объясняя места этого куска в общей картине. Ведь таким образом, вы готовите роботов, которые не способны принять решение в ситуации, которую им не описывали.
Павел Трубников… Человек явно не из тестирования, потому что с причинно-следственными связями в докладе (а это опять же был доклад, а не тренинг) было туго. Доклад для менеджеров почему-то все время сводился к тому, как найти работу.
Уважаемый тренер, если Вы позиционируете свою аудиторию как людей состоявшихся в своей профессии, то, поверьте, им не нужно рассказывать о том, как подавать себя на собеседовании.
Тем более, что это ну никак не соответствовало заявленной теме доклада. Если же Вы рассказываете для тех, кто только собирается стать профессионалом, то НЕЛЬЗЯ в голом виде подать за 30 минут всю сложность поддержания мотивации у сотрудников, которой им придется заниматься в будущем. Превратное мнение о том, что менеджер ДОЛЖЕН ДЛЯ ВСЕХ делать задачи интересными вырождается в неправильное поведение будущих менеджеров с их командой.
Ввиду моей теплой дружбы с Сашей Орловым и присутствия на множестве его тренингов по мотивации людей, мне есть с чем сравнить.
Павел начал свой доклад с того, что «я не пророк, и моё мнение не единственно верное», закончил же проповедями «забудьте о материальной мотивации», за что и был пойман аудиторией и окончательно запутан =) Уважаемый Павел! Как раз люди, которые отвечают лишь за сроки своей работы, никогда не смогут сделать продукт лучше, они смогут лишь сделать его так, как им сказали.
В общем, здесь все наоборот, слишком широкий замах, попытка смешать как минимум 4 серьезные темы в одну, при этом, не показав пути айтишника как такового.
Ну и в компетентности в области человеческой мотивации заподозрить тренера не могу.
Наташа Руколь – интересный докладчик. Если бы можно было разделить её харизму на всех – всем бы хватило и было бы веселее =) Озвучен прекрасный менеджерский подход «показывать общую картинку и место конкретной задачи в ней».
Судя по всему, тренера доклады друг друга не тестировали, иначе Наташа нашла бы критический баг в докладе Саши Федорова – несоответствие этому требованию.
Но к заявленной теме доклада все, рассказанное Наташей, относилось опять же слабо. Очень размытые понятия никак не ложились на тест-дизайн. Либо это рассказ о том, как повысить личную эффективность (непонятно, кстати, зачем), либо это заявленная тема о том, как этот скачок поможет лучше управлять тестированием. Под каждый пример можно было нарисовать конкретную задачу из тест-менеджмента и наглядно показать профит.
Доклад Михаила Давыдова послушать не получилось - убегала собираться на самолет.
Совет ребятам на будущее – четко определяйте целевую аудиторию, которую вы хотите учить, и понимайте, что она уже знает, а о чем ей нужно ещё рассказать. И обязательно приподнимайте завесу уровня (а то и нескольких уровней) выше. Ведь тестировщику, которого учат правильно описывать баги, нужно знать, как тот или иной баг повлияет на конечное качество продукта; тест-дизайнеру, пишущему тест, нужно понимать цели тестирования на каждом этапе; тест-менеджеру, принимающему решение о расширении тестового покрытия, нужно понимать, откуда взялось это дополнительное время на тестирование в проекте и что рассчитывает этим выгадать менеджер проекта. Если этот менеджер, конечно, заинтересован в успехе проекта, а не работает лишь за «сдать в срок» =)
А если в докладах ещё и будут раскрываться заявленные темы – то цены такому обучению не будет.
Ведь качество продукта – это соответствие ожиданиям пользователя, так давайте делать обучение качественным.
И нельзя забывать о том, что пользователь не всегда знает, чего же ему ждать. Тем более – неподготовленный. Берясь учить людей, нужно понимать, какую ответственность берете на себя.
Жду отзыва от Ромы, который скрасил мне галерку =) Кстати, Рома готовит презентацию про классификацию тренеров, coming soon.
Ага, вот ещё, что. Нашла Очень Положительный Отзыв (тм). Хочется задать вопрос очень простой вопрос автору: чему Вы научились на тренинге?
Собственно, вот.
Читать далее...
четверг, 24 декабря 2009 г.
Тестирование для не-тестировщиков
Чуть больше месяца назад, 19 ноября, ещё находясь в Харькове, я провела вебинар, организованный УЦ Люксофт, "Тестирование для не-тестировщиков". Вебинар совершенно нетехнический и очень философский. Моей целью было не передать знания и не научить, и лишь поделиться мыслями и подтолкнуть слушателей к размышлениям. Выводы каждый сделал свои.
Расшифровку выкладывать отдельно не буду, а хочу сделать цикл постов на основе материалов этого вебинара. Будет, чем заняться на каникулах :)
Описание вебинара под слайдкастом.
Приятного прослушивания.
1.1 Вид сверху.
Общепринятые определения и что за ними стоит на самом деле. Анализируем.
Делаем выводы, чем чревато следование определениям.
1.2. Вид с разных сторон.
Взгляд программиста. Взгляд менеджера. Взгляд руководителя. Взгляд
тестировщика. Взгляд программного продукта :)
Анализируем. Находим общее видение.
1.3. Каким может видеться тестирование с разных сторон.
Плохим. Хорошим. Полным. Недостаточным.
Анализируем. Делаем выводы, что одного эпитета мало.
1.4. Делаем вывод, что тестирование – это часть процесса разработки программного обеспечения, которое в совокупности с действиями остальной проектной команды помогает повысить качество программного продукта.
1.5. А только ли повысить?
Измерить. Подтвердить. Опровергнуть предположение. Да практически все, что угодно.
Различные цели тестирования.
Вывод: Цели тестирования нужно ставить. О них должны быть осведомлены все участники процесса разработки программного обеспечения.
2.1. Что нам нужно проверить?
Что работает правильно? Что работает быстро? Что такое правильно? Что такое быстро?
В итоге понимаем, на основании чего ставить цели тестирования.
2.2. Виды тестирования в разрезе постановки целей.
В итоге понимаем, как определять, какие виды тестирования нам нужны, с какой степенью покрытия и детализации.
3.1. Ну, разумеется, тестировщики.
У них есть умение, навыки, знания, окружения, в конце концов, им за это платят.
3.2. Почему не программисты? - «Мы и так пишем хороший код, давайте покажу, что все работает».
Плюсы выделенного тестирования.
Программисты должны программировать!
3.3. Почему не менеджер? – «Я же лучше всех знаю, чего хочет заказчик»
Плюсы выделенного тестирования.
Оставьте менеджеру менеджерово!
3.4. Так почему же все-таки программисты? «Зачем нам тестировать перед сдачей кода? Пусть тестируют тестировщики»
Плюсы пре-тестирования разработчиками.
3.5 Так почему же все-таки менеджер? «Зачем мне прогонять аксептенс, если тестировщики уже все протестировали?»
Плюсы пост-тестирования менеджером.
Выводы:
Главное в тестировании (если это не просто поиск ошибок) – это определить его цель и сообщить о ней всей проектной команде. Тогда каждый сотрудник будет вносить свой вклад в качество программного продукта.
- руководители, которые «слышали где-то» о тестировании и хотят узнать подробнее, что это, что это может им принести и принять решении о внедрении либо не-внедрении тестирования на своих проектах;
- менеджеры, которым «навязали» тестирование, но не объяснили, зачем это, что это и что должно получиться на выходе, какого результата от них ждут. И это действительно «мертвый груз» в проекте, потому что тестировщикам также не объяснили;
- программисты, которых начальство «заставляет» тестировать, в то время как всем давно известно, что «тестировать должны тестировщики»;
- руководители и менеджеры, которые хотят объяснить:
---- программистам, что им тоже нужно тестировать;
---- программистам, что тестировщики – их соратники;
---- тестировщикам, что они – соратники программистов;
---- менеджерам, что им делать и чего ждать от отдела тестирования;
---- новоиспеченному отделу тестирования, что их задача не «воевать с программистами» и не «просто находить ошибки»;
- тестировщики, на которых возложили «обеспечивать качество продукта» и с них за это качество и спрашивают, не объяснив, что они должны для этого делать;
- программисты, тестировщики, менеджеры и руководители, которые столкнулись с проблемой вражды между тестировщиками и программистами, эту проблему осознали и хотят научиться объяснять команде, что все её члены делают одно дело, а не борются друг с другом.
Читать далее...
Расшифровку выкладывать отдельно не буду, а хочу сделать цикл постов на основе материалов этого вебинара. Будет, чем заняться на каникулах :)
Описание вебинара под слайдкастом.
Приятного прослушивания.
Тестирование для не-тестировщиков
View more presentations from jnechaeva.
Тестирование
1.1 Вид сверху.
Общепринятые определения и что за ними стоит на самом деле. Анализируем.
Делаем выводы, чем чревато следование определениям.
1.2. Вид с разных сторон.
Взгляд программиста. Взгляд менеджера. Взгляд руководителя. Взгляд
тестировщика. Взгляд программного продукта :)
Анализируем. Находим общее видение.
1.3. Каким может видеться тестирование с разных сторон.
Плохим. Хорошим. Полным. Недостаточным.
Анализируем. Делаем выводы, что одного эпитета мало.
1.4. Делаем вывод, что тестирование – это часть процесса разработки программного обеспечения, которое в совокупности с действиями остальной проектной команды помогает повысить качество программного продукта.
1.5. А только ли повысить?
Измерить. Подтвердить. Опровергнуть предположение. Да практически все, что угодно.
Различные цели тестирования.
Вывод: Цели тестирования нужно ставить. О них должны быть осведомлены все участники процесса разработки программного обеспечения.
2. Какое тестирование нужно.
2.1. Что нам нужно проверить?
Что работает правильно? Что работает быстро? Что такое правильно? Что такое быстро?
В итоге понимаем, на основании чего ставить цели тестирования.
2.2. Виды тестирования в разрезе постановки целей.
В итоге понимаем, как определять, какие виды тестирования нам нужны, с какой степенью покрытия и детализации.
3. Кто должен тестировать?
3.1. Ну, разумеется, тестировщики.
У них есть умение, навыки, знания, окружения, в конце концов, им за это платят.
3.2. Почему не программисты? - «Мы и так пишем хороший код, давайте покажу, что все работает».
Плюсы выделенного тестирования.
Программисты должны программировать!
3.3. Почему не менеджер? – «Я же лучше всех знаю, чего хочет заказчик»
Плюсы выделенного тестирования.
Оставьте менеджеру менеджерово!
3.4. Так почему же все-таки программисты? «Зачем нам тестировать перед сдачей кода? Пусть тестируют тестировщики»
Плюсы пре-тестирования разработчиками.
3.5 Так почему же все-таки менеджер? «Зачем мне прогонять аксептенс, если тестировщики уже все протестировали?»
Плюсы пост-тестирования менеджером.
Выводы:
Главное в тестировании (если это не просто поиск ошибок) – это определить его цель и сообщить о ней всей проектной команде. Тогда каждый сотрудник будет вносить свой вклад в качество программного продукта.
Целевая аудитория
- руководители, которые «слышали где-то» о тестировании и хотят узнать подробнее, что это, что это может им принести и принять решении о внедрении либо не-внедрении тестирования на своих проектах;
- менеджеры, которым «навязали» тестирование, но не объяснили, зачем это, что это и что должно получиться на выходе, какого результата от них ждут. И это действительно «мертвый груз» в проекте, потому что тестировщикам также не объяснили;
- программисты, которых начальство «заставляет» тестировать, в то время как всем давно известно, что «тестировать должны тестировщики»;
- руководители и менеджеры, которые хотят объяснить:
---- программистам, что им тоже нужно тестировать;
---- программистам, что тестировщики – их соратники;
---- тестировщикам, что они – соратники программистов;
---- менеджерам, что им делать и чего ждать от отдела тестирования;
---- новоиспеченному отделу тестирования, что их задача не «воевать с программистами» и не «просто находить ошибки»;
- тестировщики, на которых возложили «обеспечивать качество продукта» и с них за это качество и спрашивают, не объяснив, что они должны для этого делать;
- программисты, тестировщики, менеджеры и руководители, которые столкнулись с проблемой вражды между тестировщиками и программистами, эту проблему осознали и хотят научиться объяснять команде, что все её члены делают одно дело, а не борются друг с другом.
Читать далее...
понедельник, 21 декабря 2009 г.
Конференция Agile Days - отчет
Недавно (9 декабря) посетила конференцию AgileDays, которую делали ребята из ScrumTrek. По этому поводу хочу немного отчитаться :)
Никита Филиппов рассказал про базовое - Обзор Agile . Нужно всем конференциям перенять фишку: делать 1-2 доклада про азы. Потому что часть людей приходит затем, чтобы посмотреть, что такое аджайл (в других случаях – что такое тестирование, что такое анализ требований и пр.), и им нужно это дать, им нужно об этом рассказывать. Потому что им рано и зачастую опасно слушать про техники и инструменты, не понимая общего смысла и цели подхода, не зная основных определений, не понимая исторических особенностей возникновения той или иной техники. Задавать же вопрос «почему вы сделали так?» на докладе, который предполагает базовые знания в этой отрасли – вроде как некомильфо. Так что Никита полностью угодил своей целевой аудитории.
А вот Андрей Бибичев учел разброс в слушателях и сделал экскурс в историю возникновения описываемых им техник FDD и DDD, и рассказал как о причинах их рождения, и о проблемах, которые решили с их помощью их авторы, так и о том, какие проблемы решает он сам использованием этих методик. Здесь можно было как узнать для себя новое, так и сравнить свой подход с подходом команды Андрея. И все это на фоне завсегдашнего бибичевского юмора, когда непонятно, над кем же он сейчас на самом деле смеется: над слушателем, над методикой или над собой.
Женя Курышев покорил меня (и зал, судя по отзывам) очень легкой подачей experience report’а о том, как яндексоиды внедряли скрам в Моем Круге. Как и все, что делает Яндекс, это делалось для людей и облегчения их работы. То есть, самый правильный подход: процесс для работы, а не работа для процесса. Нужна доска – пожалуйста, сорвали 6 пробковых плиток с потолка – получили доску стоимостью 48 рублей. Распределенные команды – не вопрос, давайте юзать виртуальную доску. Не можем прийти к соглашению – давайте позовем стороннего эксперта, но тогда уже его мнение будет финальным. Вобщем, интересная история на фоне картинок про бакланов – зачет!
Сурен Самарчян (не посчитайте меня подлизой за хороший отзыв о докладе моего руководителя :)) поднял всех на крышу и предложил решать проблемы на уровне компании или проекта, а не задачи. Вообще, все доклады Сурена, - они про стратегическое решение. Нанять инженера, который будет каждый раз перезапускать сервер при падении сайта – это затыкание дыры, а не решение проблемы. Нужно смотреть глубже. Сверху. Ведь проблема-то для компании не в том, что сайт падает, а в том, что из-за ухода пользователей теряется прибыль. В этом контексте любая проблема становится проблемой руководителя компании, и решаться должна на высшем уровне с оглядкой на цели.
Очень хотелось попасть на доклады Максима Гапонова, Леши Кривицкого и Наташи Трениной, Стаса Фомина, Артема Марченко. Жду видео.
Что касается организации – то кроме кривоватого сайта (за что команда организации уже выслушала немало :)) и отсутствия внятных указателей на первом этаже, куда людям идти, я даже знаю, что ещё мне не понравилось. Ну да, иногда не хватало стульев, но аншлаг в зале – это признак качественного доклада. Ну да, далековато добираться, но зато – хорошее помещение и близко от метро. Ну да, не дарили кресла-мешки от mail.ru, но зато на них можно было валяться и работать. Пароль от вайфая ybrjveytcrf;e – это вообще, шедевр :)
Как и любую конференцию, я, в первую очередь, оцениваю по тому, вынесла ли я с неё что-то новое? Знакомство с Артемом Марченко, Светой Топольской, Димой Лобасевым (наконец-то), Женей Курышевым, штук 20 различных идей и мыслей в блокнотике, доделанный на кресле-мешке вебинар, я считаю – хороший результат.
Плюс общение с уже знакомыми мне интересными людьми. Компания подобралась хорошая. Асхат, Ира и Никита умеют собирать людей :)
И это все несмотря на то, что на месте конференции я была уже в 7 утра, так как вызвалась помогать на регистрации.
Читать далее...
Никита Филиппов рассказал про базовое - Обзор Agile . Нужно всем конференциям перенять фишку: делать 1-2 доклада про азы. Потому что часть людей приходит затем, чтобы посмотреть, что такое аджайл (в других случаях – что такое тестирование, что такое анализ требований и пр.), и им нужно это дать, им нужно об этом рассказывать. Потому что им рано и зачастую опасно слушать про техники и инструменты, не понимая общего смысла и цели подхода, не зная основных определений, не понимая исторических особенностей возникновения той или иной техники. Задавать же вопрос «почему вы сделали так?» на докладе, который предполагает базовые знания в этой отрасли – вроде как некомильфо. Так что Никита полностью угодил своей целевой аудитории.
А вот Андрей Бибичев учел разброс в слушателях и сделал экскурс в историю возникновения описываемых им техник FDD и DDD, и рассказал как о причинах их рождения, и о проблемах, которые решили с их помощью их авторы, так и о том, какие проблемы решает он сам использованием этих методик. Здесь можно было как узнать для себя новое, так и сравнить свой подход с подходом команды Андрея. И все это на фоне завсегдашнего бибичевского юмора, когда непонятно, над кем же он сейчас на самом деле смеется: над слушателем, над методикой или над собой.
Женя Курышев покорил меня (и зал, судя по отзывам) очень легкой подачей experience report’а о том, как яндексоиды внедряли скрам в Моем Круге. Как и все, что делает Яндекс, это делалось для людей и облегчения их работы. То есть, самый правильный подход: процесс для работы, а не работа для процесса. Нужна доска – пожалуйста, сорвали 6 пробковых плиток с потолка – получили доску стоимостью 48 рублей. Распределенные команды – не вопрос, давайте юзать виртуальную доску. Не можем прийти к соглашению – давайте позовем стороннего эксперта, но тогда уже его мнение будет финальным. Вобщем, интересная история на фоне картинок про бакланов – зачет!
Сурен Самарчян (не посчитайте меня подлизой за хороший отзыв о докладе моего руководителя :)) поднял всех на крышу и предложил решать проблемы на уровне компании или проекта, а не задачи. Вообще, все доклады Сурена, - они про стратегическое решение. Нанять инженера, который будет каждый раз перезапускать сервер при падении сайта – это затыкание дыры, а не решение проблемы. Нужно смотреть глубже. Сверху. Ведь проблема-то для компании не в том, что сайт падает, а в том, что из-за ухода пользователей теряется прибыль. В этом контексте любая проблема становится проблемой руководителя компании, и решаться должна на высшем уровне с оглядкой на цели.
Очень хотелось попасть на доклады Максима Гапонова, Леши Кривицкого и Наташи Трениной, Стаса Фомина, Артема Марченко. Жду видео.
Что касается организации – то кроме кривоватого сайта (за что команда организации уже выслушала немало :)) и отсутствия внятных указателей на первом этаже, куда людям идти, я даже знаю, что ещё мне не понравилось. Ну да, иногда не хватало стульев, но аншлаг в зале – это признак качественного доклада. Ну да, далековато добираться, но зато – хорошее помещение и близко от метро. Ну да, не дарили кресла-мешки от mail.ru, но зато на них можно было валяться и работать. Пароль от вайфая ybrjveytcrf;e – это вообще, шедевр :)
Как и любую конференцию, я, в первую очередь, оцениваю по тому, вынесла ли я с неё что-то новое? Знакомство с Артемом Марченко, Светой Топольской, Димой Лобасевым (наконец-то), Женей Курышевым, штук 20 различных идей и мыслей в блокнотике, доделанный на кресле-мешке вебинар, я считаю – хороший результат.
Плюс общение с уже знакомыми мне интересными людьми. Компания подобралась хорошая. Асхат, Ира и Никита умеют собирать людей :)
И это все несмотря на то, что на месте конференции я была уже в 7 утра, так как вызвалась помогать на регистрации.
Читать далее...
четверг, 10 декабря 2009 г.
Вебинар "Работа с требованиями: анализ, тестирование" состоялся. Отчет.
Вчера я провела свой первый вебинар на тему тестирования требований. Мне понравилось, как прошло. Теперь жду отзывов с подтверждениями и с критикой.
Группа хорошая, ребята активные, решали задания, задавали вопросы, просили говорить помедленнее :)
Структуру я построила таким образом, чтоб индукторам было легко сразу, а дедукторам не пришлось долго ждать, чтоб включиться. Поясню. Есть такое понятие в методиках обучения взрослых людей, как Цикл Колба. Для того, чтобы взрослому человеку обучиться какому-либо сложному навыку максимально эффективно, то он должен пройти по четырем стадиям:
При этом разным людям удобно включаться на разных стадиях. Кому-то нужно сначала выслушать теорию, а кому-то - сразу пощупать, а потом понять, почему оно на ощупь такое.
Напомню, что индукторами (к коим и я отношусь) я называю вторых, а дедукторами - первых.
Сначала мы вовлеклись в процесс выявления потребности бизнеса, предложения ему решения его бизнес-задачи и выявления требований к этому решению.
В двух словах: владелец компании "Вакуумная сфера" заметил, что его программисты проводят в кофейне напротив много рабочего времени. Некоторые - по полтора часа в день. Решил это дело прекратить, тем самым рассчитывая повысить производительность программистов и свою прибыль. Решение - кофемат в офисе. Не помогло. Через месяц опять все заседают в кофейне.
Оставив нашего героя чесать репу над тем, что же он сделал не так, мы обратились к теории.
Второй этап был теоретический:
1. Что такое требования. Методы их фиксации.
2. Какие бывают требования
3. Что с ними можно делать.
4. Где здесь тестирование. Зачем нам это?
5. На что тестировать? Критерии хороших, качественных требований.
6. Методы тестирования требований
7. Заключение
Затем мы, уже обладая знанием теории, приступили к разбору ситуации с кофематом, протестировали требования, нашли несоответствия критериям, поняли, какие проблемы могли бы предотвратить.
И получили домашнее задание.
Все это я старалась сопровождать веселыми слайдами, отражающими суть процесса.
Например вот здесь заказчик объясняет аналитикам, что ему нужно:
А здесь я сравниваю, кто должен бы по-хорошему участвовать в процессе тестирования требований, а кто на самом деле участвует :) Символ одиночества.
Читать далее...
Группа хорошая, ребята активные, решали задания, задавали вопросы, просили говорить помедленнее :)
Структуру я построила таким образом, чтоб индукторам было легко сразу, а дедукторам не пришлось долго ждать, чтоб включиться. Поясню. Есть такое понятие в методиках обучения взрослых людей, как Цикл Колба. Для того, чтобы взрослому человеку обучиться какому-либо сложному навыку максимально эффективно, то он должен пройти по четырем стадиям:
При этом разным людям удобно включаться на разных стадиях. Кому-то нужно сначала выслушать теорию, а кому-то - сразу пощупать, а потом понять, почему оно на ощупь такое.
Напомню, что индукторами (к коим и я отношусь) я называю вторых, а дедукторами - первых.
Сначала мы вовлеклись в процесс выявления потребности бизнеса, предложения ему решения его бизнес-задачи и выявления требований к этому решению.
В двух словах: владелец компании "Вакуумная сфера" заметил, что его программисты проводят в кофейне напротив много рабочего времени. Некоторые - по полтора часа в день. Решил это дело прекратить, тем самым рассчитывая повысить производительность программистов и свою прибыль. Решение - кофемат в офисе. Не помогло. Через месяц опять все заседают в кофейне.
Оставив нашего героя чесать репу над тем, что же он сделал не так, мы обратились к теории.
Второй этап был теоретический:
1. Что такое требования. Методы их фиксации.
2. Какие бывают требования
3. Что с ними можно делать.
4. Где здесь тестирование. Зачем нам это?
5. На что тестировать? Критерии хороших, качественных требований.
6. Методы тестирования требований
7. Заключение
Затем мы, уже обладая знанием теории, приступили к разбору ситуации с кофематом, протестировали требования, нашли несоответствия критериям, поняли, какие проблемы могли бы предотвратить.
И получили домашнее задание.
Все это я старалась сопровождать веселыми слайдами, отражающими суть процесса.
Например вот здесь заказчик объясняет аналитикам, что ему нужно:
А здесь я сравниваю, кто должен бы по-хорошему участвовать в процессе тестирования требований, а кто на самом деле участвует :) Символ одиночества.
Читать далее...
воскресенье, 6 декабря 2009 г.
7 plagues of Software Testing by James Whittaker - The plague of Entropy
Порок энтропии.
Математически, энтропия – это мера неопределенности. Скажем, если есть 5 событий, то энтропия будет максимальной, если все они равновероятны, и энтропия будет минимальной, если лишь одно из событий определено, а остальные 4 – невозможны.
Чем более неопределенные события вам приходится рассматривать, тем выше карабкается мера энтропии. Люди часто думают об энтропии как о мере случайности: чем более неопределенные события рассматриваются, тем более случаен их результат.
Тестировщики привносят энтропию в разработку добавлением ряда вещей, которые следует сделать разработчику. Когда разработчики пишут код, энтропия мала. Когда мы заводим баги, мы увеличиваем энтропию. Баги отводят внимание разработчиков от кодирования. Теперь они должны работать параллельно и над созданием, и над починкой фич. Чем больше багов, тем больше параллельных задач, и это повышает энтропию. Энтропия – одна из причин, почему баги вызывают ещё больше багов: принцип энтропии обеспечивает это. Энтропия порождает энтропию! В конце концов, математика показывает нам то, что и так интуитивно понятно: предотвращение круче лечения.
Как бы там ни было, мы ничего не можем сделать, чтобы полностью предотвратить порок энтропии, кроме как создать разработчиков, которые никогда не ошибаются. А раз это маловероятно, мы должны определять, как и когда мы сталкиваемся с энтропией, и делать все, что в наших силах, чтобы ею управлять. Чем больше мы сможем сделать во время разработки, тем лучше. Помогать в code review, вводить наших разработчиков в курс тест-планов, пользовательских сценариев и окружений, чтобы они могли кодировать с меньшим количеством багов, которые нам пришлось бы рапортовать. Выкуривать баги как можно раньше, заводить их пачками и быть уверенными, что мы создаём только высококачественные баг-репорты, причесывая их самостоятельно, концентрируя тем самым мысли программистов на разработке. Написание хороших баг-репортов и быстрая проверка исправлений удержат внимание разработчиков там, где ему положено быть. Фактически это максимизирует определенность «разработчицких событий» и минимизирует количество и влияние багов. Энтропия, таким образом, сходит на минимум
Мы не можем отогнать этот порок, но мы можем определить привнесение энтропии в разработку и согласиться с неминуемым влиянием на качество кода; мы можем держать её под контролем.
Читать далее...
Математически, энтропия – это мера неопределенности. Скажем, если есть 5 событий, то энтропия будет максимальной, если все они равновероятны, и энтропия будет минимальной, если лишь одно из событий определено, а остальные 4 – невозможны.
Чем более неопределенные события вам приходится рассматривать, тем выше карабкается мера энтропии. Люди часто думают об энтропии как о мере случайности: чем более неопределенные события рассматриваются, тем более случаен их результат.
Тестировщики привносят энтропию в разработку добавлением ряда вещей, которые следует сделать разработчику. Когда разработчики пишут код, энтропия мала. Когда мы заводим баги, мы увеличиваем энтропию. Баги отводят внимание разработчиков от кодирования. Теперь они должны работать параллельно и над созданием, и над починкой фич. Чем больше багов, тем больше параллельных задач, и это повышает энтропию. Энтропия – одна из причин, почему баги вызывают ещё больше багов: принцип энтропии обеспечивает это. Энтропия порождает энтропию! В конце концов, математика показывает нам то, что и так интуитивно понятно: предотвращение круче лечения.
Как бы там ни было, мы ничего не можем сделать, чтобы полностью предотвратить порок энтропии, кроме как создать разработчиков, которые никогда не ошибаются. А раз это маловероятно, мы должны определять, как и когда мы сталкиваемся с энтропией, и делать все, что в наших силах, чтобы ею управлять. Чем больше мы сможем сделать во время разработки, тем лучше. Помогать в code review, вводить наших разработчиков в курс тест-планов, пользовательских сценариев и окружений, чтобы они могли кодировать с меньшим количеством багов, которые нам пришлось бы рапортовать. Выкуривать баги как можно раньше, заводить их пачками и быть уверенными, что мы создаём только высококачественные баг-репорты, причесывая их самостоятельно, концентрируя тем самым мысли программистов на разработке. Написание хороших баг-репортов и быстрая проверка исправлений удержат внимание разработчиков там, где ему положено быть. Фактически это максимизирует определенность «разработчицких событий» и минимизирует количество и влияние багов. Энтропия, таким образом, сходит на минимум
Мы не можем отогнать этот порок, но мы можем определить привнесение энтропии в разработку и согласиться с неминуемым влиянием на качество кода; мы можем держать её под контролем.
Читать далее...
Подписаться на:
Сообщения (Atom)
Сообщения
