На совещаниях группы аналитиков специалистам по тестированию лучше всего быть пассивными участниками и высказываться только в случае необходимости.
А ты, чукча, покорми собак и ничего не трогай, ага.
Читать далее...
вторник, 27 октября 2009 г.
цитаты
Канер, Фолк, Нгуен, "Тестирование программного обеспечения.":
На совещаниях группы аналитиков специалистам по тестированию лучше всего быть пассивными участниками и высказываться только в случае необходимости.
А ты, чукча, покорми собак и ничего не трогай, ага.
Читать далее...
На совещаниях группы аналитиков специалистам по тестированию лучше всего быть пассивными участниками и высказываться только в случае необходимости.
А ты, чукча, покорми собак и ничего не трогай, ага.
Читать далее...
воскресенье, 25 октября 2009 г.
7 plagues of Software Testing by James Whittaker - Plague of repetitiveness
Порок повторяемости
Если бесцельность – это результат «простоделания», то повторяемость – это результат «простеделания несколько раз». Раз за разом, билд за билдом, спринт за спринтом, версия за версией мы тестируем наш продукт. Разработчики проводят инспекции, создают юнит-тесты и запускают статистические анализаторы. Но у нас есть лишь маленькие догадки по поводу всей этой работы, и мы не можем доверять им. Разработчики тестируют, но затем перетестируем мы. Мы не можем поручиться за то, что они делают, и поэтому мы подвергаем повторному тестированию всё. Наряду с ростом нашего продукта в фичах и по мере фиксов дефектов мы продолжаем наше тестирование. Новые тесты теряют свою новизну очень быстро, и все они, в конце концов, становятся устаревшими.
Существует Бейзеровский пестицидный парадокс. Пестициды убивают жуков, но опрыскайте одно и то же поле одним и тем же ядом достаточное количество раз, и у оставшихся жуков выработается иммунитет. «Прополоскать и повторить» - это алгоритм для мытья волос, а не для тестирования ПО. Последнее, чего мы хотим добиться, -- это билд, полный супер-багов, устойчивых к нашему «тестициду». Дальше – хуже: всё, что называется «успешным тестированием» будет давать нам фальшивое видение тщательности и делать наши метрики завершенности кучей опасного вранья.
Когда вы не находите баги, это не потому, что их нет, а потому, что повторение повлекло за собой пестицидный парадокс.
Феремеры знают, как изменять формулу их пестицида время от времени, знают, как подгонять формулу под специфический тип паразитов, которых они ожидают на своих полях. Они делают это, потому что вникают в историю используемого пестицида и знают, что может случиться в случае грубого повторения того же самого старого яда. Так и тестировщики должны обращать внимание на их результаты тестирования и следить за автоматизацией, которая не прибавляет полезности. На помощь приходит здравая инспекция изменений в автоматизации. Изменяйте порядок тестов, изменяйте их данные, находите новые окружения, изменяйте входные данные, делайте что-то такое, к чему баги не готовы.
Читать далее...
Если бесцельность – это результат «простоделания», то повторяемость – это результат «простеделания несколько раз». Раз за разом, билд за билдом, спринт за спринтом, версия за версией мы тестируем наш продукт. Разработчики проводят инспекции, создают юнит-тесты и запускают статистические анализаторы. Но у нас есть лишь маленькие догадки по поводу всей этой работы, и мы не можем доверять им. Разработчики тестируют, но затем перетестируем мы. Мы не можем поручиться за то, что они делают, и поэтому мы подвергаем повторному тестированию всё. Наряду с ростом нашего продукта в фичах и по мере фиксов дефектов мы продолжаем наше тестирование. Новые тесты теряют свою новизну очень быстро, и все они, в конце концов, становятся устаревшими.
Существует Бейзеровский пестицидный парадокс. Пестициды убивают жуков, но опрыскайте одно и то же поле одним и тем же ядом достаточное количество раз, и у оставшихся жуков выработается иммунитет. «Прополоскать и повторить» - это алгоритм для мытья волос, а не для тестирования ПО. Последнее, чего мы хотим добиться, -- это билд, полный супер-багов, устойчивых к нашему «тестициду». Дальше – хуже: всё, что называется «успешным тестированием» будет давать нам фальшивое видение тщательности и делать наши метрики завершенности кучей опасного вранья.
Когда вы не находите баги, это не потому, что их нет, а потому, что повторение повлекло за собой пестицидный парадокс.
Феремеры знают, как изменять формулу их пестицида время от времени, знают, как подгонять формулу под специфический тип паразитов, которых они ожидают на своих полях. Они делают это, потому что вникают в историю используемого пестицида и знают, что может случиться в случае грубого повторения того же самого старого яда. Так и тестировщики должны обращать внимание на их результаты тестирования и следить за автоматизацией, которая не прибавляет полезности. На помощь приходит здравая инспекция изменений в автоматизации. Изменяйте порядок тестов, изменяйте их данные, находите новые окружения, изменяйте входные данные, делайте что-то такое, к чему баги не готовы.
Читать далее...
четверг, 22 октября 2009 г.
7 plagues of Software Testing by James Whittaker - Plague of Aimlessness
«7 plagues of Software Testing» - это цикл постов Джеймса Виттекера, который с мая 2009 года присоединился к команде Google в качестве Test Director. Этот цикл родился из его первого tech talk в Гугле, где его выводы, по признанию самого Джеймса, были признаны ребятами из Гугла достаточно провокационными. Все 7 статей опубликованы в блоге http://googletesting.blogspot.com/.
Перевод первого поста из этой серии я символично выкладываю именно сегодня, во второй день конференции Google Test Automation Conference, которая проходит именно сейчас в Цюрихе, и на которую я не попала. Именно она послужила поводом для моего знакомства с Джеймсом Виттекером. Джеймс разрешил мне переводить и публиковать его статьи, чем я, собственно, и занимаюсь.
Спасибо Тимуру Хайруллину за помощь и терпение :)
Цикл «Семь пороков тестирования» открывает первый пост: «Порок бесцельности».
Мудрость. Это больше, чем просто крутое словцо. Оно рисует в воображении колдовской образ древних магических книг и ученых мудрецов с их тайными, с таким риском добытыми знаниями.
И это именно то, чего нам не хватает в тестировании. Мудрость тестирования? Вы шутите? Где она? Кто же её зажал? Не подскажете?
Индустрия тестирования больна пороком бесцельности. Нам не хватает Мудрости, нам не хватает корня того знания, которое передается от мастера к подмастерьям и записано в магических книгах для прилежного изучения. Наши ученики без наставников. Мы должны заново изобретать колесо в уединении своих офисов, тем самым позволяя другим тестировщикам заново изобретать колесо в своих офисах по всему миру.
Предлагаю остановить эту бессмыслицу. Тестирование стало слишком бесцельным. Мы тестируем потому, что наши менеджеры говорит нам это делать. Мы автоматизируем потому, что мы можем, или потому, что мы знаем как, а не потому, что это часть осознаной и выстраданной стратегии, и уж точно не потому, что нам это подсказывает наша Мудрость. Существует ли где-то план или другое задокументированное знание, которое направляет наше тестирование, или мы просто барабаним по клавиатуре, надеясь, что что-то сломается? Где же наши тестировщицкие книги заклинаний? Действительно ли с трудом добытое знание наших предшественников в тестировании – это то, что нам всегда доступно в наше время быстродоступной информации?
Когда охотники убивают, они запоминают и территорию, и обстоятельства. Они передают это знание своим преемникам. Со временем они начинают понимать повадки добычи, и коллективное знание множества охотников значительно облегчает труд будущих охотников. Когда вы видите такую территорию, вы ожидаете игры по опрделенным правилам. Можем ли мы сказать то же самое о тестировании? Как хорошо мы учимся друг у друга? Разве наши моменты озарений систематизированы таким образом, чтобы избавить будущих тестировщиков от страданий в бесцельности борьбы с тем, над чем страдали мы? Можем ли мы сказать, что когда мы видим такую функциональность, мы знаем лучший способ её протестировать?
Порок бесцельности, увы, широко распространен. И нужда в Мудрости очень остра. Nike говорит нам: ‘just do it’, но что применимо к упражнениям, не подходит к тестированию ПО. В следующий раз, поймав себя на ‘just doing’ тестирование, остановитесь на мгновение и спросите себя: «Какова моя цель?» и «Каково назначение этого теста?». И если ответ не приходит к вам моментально, вы в плену бесцельности, «just doing it», положившись на удачу и грубую силу в усилиях по поимке вашей добычи.
Удаче не место в волшебстве охоты и ей нет места в тестировании. Удача – это хорошая случайность, но она не может быть нашим планом А. Следите за пороком бесцельности. Препарируйте свои успехи, исследуйте свои неудачи и будьте уверены, что вы фиксируете то, чему научились в ходе самонаблюдения, для ваших коллег.
Станьте для них Мастером. Создавайте тестировщицкую книгу заклинаний и делитесь ей с другими в своей команде. И со временем вы избавитесь от порока бесцельности.
________________________________________________________________________________________
Тестирования. Software Testing. Я осознанно не употребляю практически нигде в тексте выражение "Тестирование программного обеспечения". И так понятно, что стоит за термином "тестирование".
Порок. В оригинале plague, что переводится как чума, мучение, напасть, бедствие. Были предложения перевести plague как "беда" или "зараза". Мне больше всего нравится "порок", это что-то такое, что было в тестирование заложено изначально и от чего практически невозможно избавиться, но можно смягчить. Мне кажется, именно это имел ввиду Джеймс.
Мудрость. В оригинале lore, что означает коллективное знание в какой-либо области (в данном случае - тестирования). Это что-то такое, что собирается многими поколениями и что всегда доступно всем страждущим. Поэтому перевожу как Мудрость. Такая себе коллективная Мудрость всея тестирования.
Кто же её зажал? Джеймс использует глагол boharted, который невозможно перевести на русский, не потеряв обаяния этого слова. Сленговое словечко to bogart родом из наркоманских 60х, означает "зажать что-то, что должно быть передано другим". "Don't bohart that joint!" - "Не зажимай косяк!"". Пруфлинк. Слово это возникло благодаря актеру Хамфри Богарту, известному своей привычкой не выпускать сигарету изо рта (основную известность ему, конечно же, принес кинематограф, а не сигарета. Очень люблю его "Касабланку").
Читать далее...
Перевод первого поста из этой серии я символично выкладываю именно сегодня, во второй день конференции Google Test Automation Conference, которая проходит именно сейчас в Цюрихе, и на которую я не попала. Именно она послужила поводом для моего знакомства с Джеймсом Виттекером. Джеймс разрешил мне переводить и публиковать его статьи, чем я, собственно, и занимаюсь.
Спасибо Тимуру Хайруллину за помощь и терпение :)
Цикл «Семь пороков тестирования» открывает первый пост: «Порок бесцельности».
Мудрость. Это больше, чем просто крутое словцо. Оно рисует в воображении колдовской образ древних магических книг и ученых мудрецов с их тайными, с таким риском добытыми знаниями.
И это именно то, чего нам не хватает в тестировании. Мудрость тестирования? Вы шутите? Где она? Кто же её зажал? Не подскажете?
Индустрия тестирования больна пороком бесцельности. Нам не хватает Мудрости, нам не хватает корня того знания, которое передается от мастера к подмастерьям и записано в магических книгах для прилежного изучения. Наши ученики без наставников. Мы должны заново изобретать колесо в уединении своих офисов, тем самым позволяя другим тестировщикам заново изобретать колесо в своих офисах по всему миру.
Предлагаю остановить эту бессмыслицу. Тестирование стало слишком бесцельным. Мы тестируем потому, что наши менеджеры говорит нам это делать. Мы автоматизируем потому, что мы можем, или потому, что мы знаем как, а не потому, что это часть осознаной и выстраданной стратегии, и уж точно не потому, что нам это подсказывает наша Мудрость. Существует ли где-то план или другое задокументированное знание, которое направляет наше тестирование, или мы просто барабаним по клавиатуре, надеясь, что что-то сломается? Где же наши тестировщицкие книги заклинаний? Действительно ли с трудом добытое знание наших предшественников в тестировании – это то, что нам всегда доступно в наше время быстродоступной информации?
Когда охотники убивают, они запоминают и территорию, и обстоятельства. Они передают это знание своим преемникам. Со временем они начинают понимать повадки добычи, и коллективное знание множества охотников значительно облегчает труд будущих охотников. Когда вы видите такую территорию, вы ожидаете игры по опрделенным правилам. Можем ли мы сказать то же самое о тестировании? Как хорошо мы учимся друг у друга? Разве наши моменты озарений систематизированы таким образом, чтобы избавить будущих тестировщиков от страданий в бесцельности борьбы с тем, над чем страдали мы? Можем ли мы сказать, что когда мы видим такую функциональность, мы знаем лучший способ её протестировать?
Порок бесцельности, увы, широко распространен. И нужда в Мудрости очень остра. Nike говорит нам: ‘just do it’, но что применимо к упражнениям, не подходит к тестированию ПО. В следующий раз, поймав себя на ‘just doing’ тестирование, остановитесь на мгновение и спросите себя: «Какова моя цель?» и «Каково назначение этого теста?». И если ответ не приходит к вам моментально, вы в плену бесцельности, «just doing it», положившись на удачу и грубую силу в усилиях по поимке вашей добычи.
Удаче не место в волшебстве охоты и ей нет места в тестировании. Удача – это хорошая случайность, но она не может быть нашим планом А. Следите за пороком бесцельности. Препарируйте свои успехи, исследуйте свои неудачи и будьте уверены, что вы фиксируете то, чему научились в ходе самонаблюдения, для ваших коллег.
Станьте для них Мастером. Создавайте тестировщицкую книгу заклинаний и делитесь ей с другими в своей команде. И со временем вы избавитесь от порока бесцельности.
________________________________________________________________________________________
Тестирования. Software Testing. Я осознанно не употребляю практически нигде в тексте выражение "Тестирование программного обеспечения". И так понятно, что стоит за термином "тестирование".
Порок. В оригинале plague, что переводится как чума, мучение, напасть, бедствие. Были предложения перевести plague как "беда" или "зараза". Мне больше всего нравится "порок", это что-то такое, что было в тестирование заложено изначально и от чего практически невозможно избавиться, но можно смягчить. Мне кажется, именно это имел ввиду Джеймс.
Мудрость. В оригинале lore, что означает коллективное знание в какой-либо области (в данном случае - тестирования). Это что-то такое, что собирается многими поколениями и что всегда доступно всем страждущим. Поэтому перевожу как Мудрость. Такая себе коллективная Мудрость всея тестирования.
Кто же её зажал? Джеймс использует глагол boharted, который невозможно перевести на русский, не потеряв обаяния этого слова. Сленговое словечко to bogart родом из наркоманских 60х, означает "зажать что-то, что должно быть передано другим". "Don't bohart that joint!" - "Не зажимай косяк!"". Пруфлинк. Слово это возникло благодаря актеру Хамфри Богарту, известному своей привычкой не выпускать сигарету изо рта (основную известность ему, конечно же, принес кинематограф, а не сигарета. Очень люблю его "Касабланку").
Читать далее...
среда, 21 октября 2009 г.
Опрос "Соотношение разработчиков и тестировщиков" или "В мире айтишников"
После нашего с Тимуром Хайруллиным выступления на PM-Labs к нам подходили люди и спрашивали, откуда у нас информация о таком соотношении количества разработчиков и тестировщиков в компании? Напомню, что мы иллюстрировали наши наблюдения на примере «самой обычной компании» под названием «Вакуумная сфера», состав которой был следующий:
30 программистов (+3)
5 ПМ (+1)
5-6 тестировщиков (+1)
2 архитектора
2 аналитика
3-5 сисадминов
2 дизайнера / юзабилиста
2-3 бухгалтерия
2-3 sales
2-3 маркетинг
2-3 HR
1-2 ХО
Мы получили несколько комментариев с содержанием, что «соотношение 1 тестировщик на 5 разработчиков – весьма нездоровая ситуация», что «такая компания не может нормально работать и производить хорошие продукты», что «компании стали взрослее и понимают ценность тестирования» и проч.
Хотелось бы уточнить, что это соотношение было приведено не как среднее, а как обычное. Интуитивно мы понимаем, что это не из ряда вон выходящая ситуация, но ответить на вопрос «Откуда вы взяли, что такое соотношение является нормальным» мы не смогли.
Сильно подозреваю, что приведи мы тот же самый пример на конференции для аналитиков – началось бы что-то вроде «да где вы видели компанию с двумя аналитиками», «это какая-то нездоровая ситуация» и т.п. Ну да ладно.
Благодаря нашим коллегам Саше Орлову, Алексею Баранцеву, Славе Панкратову, Денису Бескову, Александру Байкину мы собрали информацию о количественном соотношении разработчиков и тестировщиков в почти 250 компаниях. И теперь мы можем сказать совершенно точно – такая ситуация является совершенно обычной и, более того, наиболее распространенной.
Какие из этого можно сделать выводы? Не знаю. Думаю, что данное исследование, котороое по сути не является исследованием, а являет собой просто опрос, лишь показывает картину отрасли, тенденции и тренды.
Судите сами.
Ах, да. Для придания исследованию бОльшей живости и человечности мы пригласили быть нашим экспертом признанного знатока человеков и человеческой природы:
Итак, в опросе приняли участие представители 246 компаний, так или иначе имеющих отношение к разработке программного обеспечения, из стран СНГ+ (айпишники мы не анализировали). Общий портрет участника таков:
Если не делать никаких выводов, а лишь посмотреть на картинку, то можно увидеть, что
А что же внутри этих семейств? Как у наших родовых объединений обстоят дела с ролевым распределением?
Все графики построены по следующему принципу:
По оси абсцисс у нас количество разработчиков в компании на одного тестировщика. По оси ординат – количество таких случаев.
Выводов мы, как и обещали, не делаем. Просто смотрите на картинку и понимайте ситуацию. Есть компании, которые живут и, мы верим, процветают при минимальном (а то и нулевом) количестве тестировщиков на десяток разработчиков. Компании, проходя свой жизненный цикл, проскакивают цифры 7, 8 и 9, и сразу переходят на следующий уровень с цифрой 3-5 программистов на одного тестировщика. Таких большинство. Это не плохо, и это не хорошо. Это просто так есть.
Немногие могут себе позволить соотношение 1:1 тестировщиков и разработчиков, но такие компании есть. И они позволяют себе это. Мы не можем назвать ни причин сложившейся ситуации, ни условий её возникновения, это факт.
Хотелось бы добавить от нас, что все данные у нас есть и мы с удовольствием построим графики и попробуем найти корреляционные коэффициенты, если вам это интересно. Давайте делать выводы вместе, без оглядки на то, к какой стае мы принадлежим, к светлой или к темной, или являемся кусочком чего-то большего.
Читать далее...
30 программистов (+3)
5 ПМ (+1)
5-6 тестировщиков (+1)
2 архитектора
2 аналитика
3-5 сисадминов
2 дизайнера / юзабилиста
2-3 бухгалтерия
2-3 sales
2-3 маркетинг
2-3 HR
1-2 ХО
Мы получили несколько комментариев с содержанием, что «соотношение 1 тестировщик на 5 разработчиков – весьма нездоровая ситуация», что «такая компания не может нормально работать и производить хорошие продукты», что «компании стали взрослее и понимают ценность тестирования» и проч.
Хотелось бы уточнить, что это соотношение было приведено не как среднее, а как обычное. Интуитивно мы понимаем, что это не из ряда вон выходящая ситуация, но ответить на вопрос «Откуда вы взяли, что такое соотношение является нормальным» мы не смогли.
Сильно подозреваю, что приведи мы тот же самый пример на конференции для аналитиков – началось бы что-то вроде «да где вы видели компанию с двумя аналитиками», «это какая-то нездоровая ситуация» и т.п. Ну да ладно.
Благодаря нашим коллегам Саше Орлову, Алексею Баранцеву, Славе Панкратову, Денису Бескову, Александру Байкину мы собрали информацию о количественном соотношении разработчиков и тестировщиков в почти 250 компаниях. И теперь мы можем сказать совершенно точно – такая ситуация является совершенно обычной и, более того, наиболее распространенной.
Какие из этого можно сделать выводы? Не знаю. Думаю, что данное исследование, котороое по сути не является исследованием, а являет собой просто опрос, лишь показывает картину отрасли, тенденции и тренды.
Судите сами.
Ах, да. Для придания исследованию бОльшей живости и человечности мы пригласили быть нашим экспертом признанного знатока человеков и человеческой природы:
Итак, в опросе приняли участие представители 246 компаний, так или иначе имеющих отношение к разработке программного обеспечения, из стран СНГ+ (айпишники мы не анализировали). Общий портрет участника таков:
| Тип компании | Количество респондентов | Из них: | ||||
| Маленьких (<30 человек) | Небольших (31-100 человек) | Средних (101-300 человек) | Больших (301-1000 человек) | Гигантов (>1000 человек) | ||
| Аутсорсинговая | 77 | 47 | 20 | 6 | 0 | 4 |
| Продуктовая | 83 | 47 | 16 | 9 | 5 | 6 |
| IT-отдел | 94 | 52 | 24 | 5 | 8 | 5 |
Если не делать никаких выводов, а лишь посмотреть на картинку, то можно увидеть, что
| представители семейства айтишников – очень общительные существа. На воле они предпочитают селиться небольшими группами, и лишь немногие из образовавшихся объединений со временем вырастают в мощных гигантов, способных в случае необходимости подмять под себя более мелкие образования. | |
А что же внутри этих семейств? Как у наших родовых объединений обстоят дела с ролевым распределением?
Все графики построены по следующему принципу:
По оси абсцисс у нас количество разработчиков в компании на одного тестировщика. По оси ординат – количество таких случаев.
| | Таким образом, эти картинки показывают нам тенденцию, к которой стремятся объединения айтишников, называемые айти-компаниями, для сохранения равновесия и выживания в жестоком мире разработки программного обеспечения. Интересно, осознают ли они свое стремление, или просто идут за своей природой, не призывая новых особей к себе в компанию? |
| | Давайте понаблюдаем более пристально за таким интересным подвидов компаний-разработчиков, как аутсорсеры. Из картинки видно, что наши темные собратья не отличаются от общей массы и старательно придерживаются общей тенденции. |
| Особи же дневные, так называемые светлые, продуктовые компании, как видно, не очень отличаются от своих темных, более приземленных собратьев. И, хотя летают наши друзья лишь в светлое время суток, состав сообщества они выбирают такой же, как и у остальных поселений рассматриваемой группы айтишников. Но стоит намекнуть им на схожесть с темными представителями данного вида, как гордые продуктмейкеры тут же становятся в боевую стойку и начинают защищать так тщательно создаваемый миф о принадлежности светлой стороне. | |
| | Давайте взглянем на тех представителей айтишного мира, что мирно сожительствуют с другими видами, сосуществуя в качестве небольших подгрупп более крупных сообществ, часто не имеющих ничего общего ни со средой обитания, ни с повадками айтишников. Тем не менее, им удается выжить, обеспечивая большинство своими услугами, без которых в нашем мире редко какому виду удается выживать и занимать достойное место среди своих врагов. IT-отделы, как мы видим на картинке, тоже подчиняются законам матушки-природы, и в своих, часто не очень больших и с трудом организованных стаях они соблюдают то хрупкое равновесие, которое присуще всем объединениям айтишников. |
Выводов мы, как и обещали, не делаем. Просто смотрите на картинку и понимайте ситуацию. Есть компании, которые живут и, мы верим, процветают при минимальном (а то и нулевом) количестве тестировщиков на десяток разработчиков. Компании, проходя свой жизненный цикл, проскакивают цифры 7, 8 и 9, и сразу переходят на следующий уровень с цифрой 3-5 программистов на одного тестировщика. Таких большинство. Это не плохо, и это не хорошо. Это просто так есть.
Немногие могут себе позволить соотношение 1:1 тестировщиков и разработчиков, но такие компании есть. И они позволяют себе это. Мы не можем назвать ни причин сложившейся ситуации, ни условий её возникновения, это факт.
| | Природа знает, что делает. Именно такое соотношение позволяет нашим айтишникам выигрывать в этой суровой борьбе за жизнь. Равновесие – это то, к чему стремится все в природе, и сообщества айтишников, называемые компаниями, не исключение. |
Хотелось бы добавить от нас, что все данные у нас есть и мы с удовольствием построим графики и попробуем найти корреляционные коэффициенты, если вам это интересно. Давайте делать выводы вместе, без оглядки на то, к какой стае мы принадлежим, к светлой или к темной, или являемся кусочком чего-то большего.
Читать далее...
вторник, 29 сентября 2009 г.
Test-Labs 2009
Test-Labs состоялся, ура!
Первая на моей памяти конференция для тестировщиков на территории Украины. Будучи причастной к организации Software Quality Assurance Days, а также к QA Club, я вижу нехватку профессионального общения в нашей, тестировщицкой среде. Да, есть блоги, да, есть информационные площадки. Но живое общение этим никогда не заменишь. Спасибо Славе Панкратову лично и всему учебному центру Люксофт за предоставленную возможность.
Ничего не скажу про организацию. Блокноты, ручки, одна_остановка_на_такси, мягкие стулья – что ещё нужно, если ты приехал не за этим? Мне понравилось.
Буду говорить про важное. То есть про доклады и про аудиторию.
Игорь Лужанский. Решила посетить, потому что уж очень хвалили Игоря после его выступления на PM-Labs.
Игорь – отличный докладчик. Живой и горящий. Уверена, что он такой же и в работе, а это значит, что его команде повезло :)
Хороший, четкий, структурированный доклад. Очень полезные и нужные вещи. Ничего нового для меня лично, но, вспомнив себя пару лет назад, вполне представляю, сколько информации могли почерпнуть слушатели, которые не сталкивались с тестированием требований, либо начали это делать вот только сейчас. Вобщем, требования должны быть и они должны тестироваться. По дополнению Леши Колупаева, столь формализованного процесса может в проекте и не быть, от этого проект не станет менее успешным. Важно понимать, зачем мы делаем это или не делаем.
Вторую секцию я провела в кофейне, перерисовывая графики и дорисовывая шляпы своим человечкам, символизирующим специалистов с опытом работы в тестировании :)
Юлия Нечаева. Взгляд с точки зрения докладчика. Очень отзывчивая аудитория.
Говорила о методиках набора тестировщиков, о их "покупке" и обучении, и когда что выгоднее. Рада, что технические специалисты понимают, что проекты и ПО делают люди, а не технологии и не методологии. И что самое важное для успеха проекта – это его фундамент, его команда. Когда после слов Игоря, модерировавшего эту секцию: «Есть вопросы к Юле?», - взметнулось рук 10 одновременно, стало очень тепло. Значит донесла. Значит актуально.
В итоге доклад с пост-обсуждением занял больше часа, затем кулуары. И ещё стены пивного ресторана «Сундук» до самого его закрытия внимали разговорам на тему «Нетехнические скиллы для тестировщиков».
Слушателей заинтересовала программа обучения, которую я веду в рамках сотрудничества Никсов с ВУЗами Харькова. Здорово, что такие инициативы есть не только у нас, что они развиваются и приносят свои плоды.
Привет ребятам из Молдовы и из Днепропетровска. Если у ваших команд такие менеджеры, то все у вас получится :)
Александр Александров. Человек с фамилией Ходить_на_все_его_доклады (ц).
Александр Леонидович как всегда показывает слушателям самую суть вопроса, при этом, показывая этот самый вопрос с разных уровней: проверить – выяснить – обеспечить – предсказать. Это был обзор не только теории качества, но и применения этой самой теории к различным задачам. Не очень глубоко, но таков формат.
Спасибо Тимуру Хайруллину за интересные комментарии о perceptive quality.
Ну и «Сундук». Становится традицией завершать люксофтовские конференции именно там. Пиво, колбаски и интересные собеседники. Макс, Рома и Никита, доклады ваши я, к сожалению, не слушала, но вы жгли и после :)
Возвращаясь немного назад: заполняя анкету и проставляя оценки докладам, подумалось, как их оценивать-то? По соотношению «что я ожидал – что я получил»? Или по «узнал ли я что-то новое?» А если объективно доклад отличный, но для другой аудитории, поэтому лично мне там было не очень интересно? Вопрос спорный. А перегружать анкету пунктами «понравилась ли вам прическа\бусики докладчика?» тоже глупо. Поэтому, наверное, усредненное значение в этом случае подходит. Пять.
Ещё отчет здесь. Ждем материалов.
Читать далее...
Первая на моей памяти конференция для тестировщиков на территории Украины. Будучи причастной к организации Software Quality Assurance Days, а также к QA Club, я вижу нехватку профессионального общения в нашей, тестировщицкой среде. Да, есть блоги, да, есть информационные площадки. Но живое общение этим никогда не заменишь. Спасибо Славе Панкратову лично и всему учебному центру Люксофт за предоставленную возможность.
Ничего не скажу про организацию. Блокноты, ручки, одна_остановка_на_такси, мягкие стулья – что ещё нужно, если ты приехал не за этим? Мне понравилось.
Буду говорить про важное. То есть про доклады и про аудиторию.
Игорь Лужанский. Решила посетить, потому что уж очень хвалили Игоря после его выступления на PM-Labs.
Игорь – отличный докладчик. Живой и горящий. Уверена, что он такой же и в работе, а это значит, что его команде повезло :)
Хороший, четкий, структурированный доклад. Очень полезные и нужные вещи. Ничего нового для меня лично, но, вспомнив себя пару лет назад, вполне представляю, сколько информации могли почерпнуть слушатели, которые не сталкивались с тестированием требований, либо начали это делать вот только сейчас. Вобщем, требования должны быть и они должны тестироваться. По дополнению Леши Колупаева, столь формализованного процесса может в проекте и не быть, от этого проект не станет менее успешным. Важно понимать, зачем мы делаем это или не делаем.
Вторую секцию я провела в кофейне, перерисовывая графики и дорисовывая шляпы своим человечкам, символизирующим специалистов с опытом работы в тестировании :)
Юлия Нечаева. Взгляд с точки зрения докладчика. Очень отзывчивая аудитория.
Говорила о методиках набора тестировщиков, о их "покупке" и обучении, и когда что выгоднее. Рада, что технические специалисты понимают, что проекты и ПО делают люди, а не технологии и не методологии. И что самое важное для успеха проекта – это его фундамент, его команда. Когда после слов Игоря, модерировавшего эту секцию: «Есть вопросы к Юле?», - взметнулось рук 10 одновременно, стало очень тепло. Значит донесла. Значит актуально.
В итоге доклад с пост-обсуждением занял больше часа, затем кулуары. И ещё стены пивного ресторана «Сундук» до самого его закрытия внимали разговорам на тему «Нетехнические скиллы для тестировщиков».
Слушателей заинтересовала программа обучения, которую я веду в рамках сотрудничества Никсов с ВУЗами Харькова. Здорово, что такие инициативы есть не только у нас, что они развиваются и приносят свои плоды.
Привет ребятам из Молдовы и из Днепропетровска. Если у ваших команд такие менеджеры, то все у вас получится :)
Александр Александров. Человек с фамилией Ходить_на_все_его_доклады (ц).
Александр Леонидович как всегда показывает слушателям самую суть вопроса, при этом, показывая этот самый вопрос с разных уровней: проверить – выяснить – обеспечить – предсказать. Это был обзор не только теории качества, но и применения этой самой теории к различным задачам. Не очень глубоко, но таков формат.
Спасибо Тимуру Хайруллину за интересные комментарии о perceptive quality.
Ну и «Сундук». Становится традицией завершать люксофтовские конференции именно там. Пиво, колбаски и интересные собеседники. Макс, Рома и Никита, доклады ваши я, к сожалению, не слушала, но вы жгли и после :)
Возвращаясь немного назад: заполняя анкету и проставляя оценки докладам, подумалось, как их оценивать-то? По соотношению «что я ожидал – что я получил»? Или по «узнал ли я что-то новое?» А если объективно доклад отличный, но для другой аудитории, поэтому лично мне там было не очень интересно? Вопрос спорный. А перегружать анкету пунктами «понравилась ли вам прическа\бусики докладчика?» тоже глупо. Поэтому, наверное, усредненное значение в этом случае подходит. Пять.
Ещё отчет здесь. Ждем материалов.
Читать далее...
среда, 29 апреля 2009 г.
SQA Days 2009 - фотовзгляд из первой секции
По долгу исполнения роли ведущей первой секции, вырваться из неё не удалось, посему с нетерпением жду материалов остальных двух.
Первая секция проходила, как удачно выразился Михаил Мериин, в христианском зале с пролетарским потолком :)
Ромуальд Здебский. Докладчик, после которого просто страшно было выступать, потому что такой опыт выступлений, как у Ромуальда, не затмить:)
Юрий Цыганенко. Практически опроверг теорию о "все несчастные семьи несчастны по-разному" :). Оказалось, что с похожими проблемами сталкиваются многие компании, занимающиеся софтверным аутсорсингом. Мне очень близка эта тема, и приятно было услышать чужой взгляд на те же вещи.
Саша Орлов. Блистателен и искрометен.
Практически текст для визитки :)
Михаил Мериин. Колоссальный опыт. Спасибо, что поделились!
Александр Александров. Мэтр всия тестирования. Всегда интересно слушать. Четко, структурированно, уверенно. Подкреплено практическим опытом.
Асхат Урузбаев. Асхат, с%;ко гибкий :)
Ну и по поводу часто обсуждаемой темы, зачем народ ездит на конференции? Не только слушать, но и рассказывать, не только спрашивать, но и отвечать, не только смотреть, но и показывать. Хочется отметить, что рассказывали, отвечали и показывали достаточно активно :) Общение бурлило.
Второй день был живой, новаторский, оригинальный. Круглые столы - на мой взгляд, отличный формат! Позволяет услышать сразу несколько точек зрения плюс высказаться самому.
Недостатки приняты организиторами к сведению, что-то аргументировано как политика конференции, что-то решено было корректировать в будущем. Главное, что диалог состоялся. Диалог организаторов с участниками.
Спасибо всем, кто был! :)
Читать далее...
Первая секция проходила, как удачно выразился Михаил Мериин, в христианском зале с пролетарским потолком :)
Ромуальд Здебский. Докладчик, после которого просто страшно было выступать, потому что такой опыт выступлений, как у Ромуальда, не затмить:)
Юрий Цыганенко. Практически опроверг теорию о "все несчастные семьи несчастны по-разному" :). Оказалось, что с похожими проблемами сталкиваются многие компании, занимающиеся софтверным аутсорсингом. Мне очень близка эта тема, и приятно было услышать чужой взгляд на те же вещи.
Саша Орлов. Блистателен и искрометен.
Практически текст для визитки :)
Михаил Мериин. Колоссальный опыт. Спасибо, что поделились!
Александр Александров. Мэтр всия тестирования. Всегда интересно слушать. Четко, структурированно, уверенно. Подкреплено практическим опытом.
Асхат Урузбаев. Асхат, с%;ко гибкий :)
Ну и по поводу часто обсуждаемой темы, зачем народ ездит на конференции? Не только слушать, но и рассказывать, не только спрашивать, но и отвечать, не только смотреть, но и показывать. Хочется отметить, что рассказывали, отвечали и показывали достаточно активно :) Общение бурлило.
Второй день был живой, новаторский, оригинальный. Круглые столы - на мой взгляд, отличный формат! Позволяет услышать сразу несколько точек зрения плюс высказаться самому.
Недостатки приняты организиторами к сведению, что-то аргументировано как политика конференции, что-то решено было корректировать в будущем. Главное, что диалог состоялся. Диалог организаторов с участниками.
Спасибо всем, кто был! :)
Читать далее...
вторник, 7 апреля 2009 г.
Вы - новая команда тестирования на старом проекте.
Заказчик меняет команду тестирования на Вашу. Процесс поставлен и разогнан. Что делать в первую очередь?
Перед новой командой тестирования стоят задачи:
- «меркантильные»: сделать как минимум не хуже, чем было, то есть показать, что заказчик не зря сменил аутсорсера;
- «общечеловеческие»: выпускать качественный продукт.
Для их выполнения команде нужно будет улучшить процесс (или, как минимум, не испортить :) и в дальнейшем по нему работать.
Для улучшения процесса хорошо было бы показать заказчику , что хорошо, а что можно улучшить.
Тут 2 варианта:
1) Самый лучший, если есть время на вхождение в процесс, его анализ и изменение, если это нужно, и там, где это нужно. Вхождение можно разделить на этапы: знакомство с продуктом, анализ требований, анализ тестов (покрытие, былые прохождения и пр.), исправление и улучшение.
2) В условиях недостатка времени – просто включаться в работу по налаженному процессу и тогда улучшения вносить «по ходу», если остается время.
Рассматриваем первый вариант – у команды есть время на «вход».
Первым делом - анализ требований: есть ли, в каком виде, тестируемы ли? Тут можно говорить долго и много ( В моем последнем жизненном примере проекта нет требований, есть только юзер мануал, который пришлось переводить из вида «If you want to print the document that you have received from your agent, please select File>Print» в «To print document user should be able to select File>Print». А также пришлось уточнять моменты типа «There is no limit how many files user can add to the collection.» Беспредел – это, конечно, хорошо, но проверить какую-то разумную цифру все же надо :)
В ходе работы выработалось несколько формальных правил, напишу о них отдельно.)
Затем - анализ покрытия требований тестами. Преследуем 2 цели: получить картину «как это есть сейчас», и составить план действий « что сделать, чтоб было так, как должно быть».
В ходе анализа покрытия:
- составляем матрицы прослеживаемости;
- анализируем матрицы: почему некоторые единичные требования покрыты десятками тестов, в то время как целые блоки других вообще не имеют соотвествующих тестов? Э то следствие расстановки приоритетов или уверенности в себе предыдущей команды?
- попутно анализируем тесты на предмет избыточности.
После того, как анализ проведен, картина ясна, можно приступать к написанию тестов по непокрытым требованиям.
Пока что моя команда на этапе апдейта тест-кейсов с целью достичь как можно большего покрытия с как можно меньшей избыточностью.
Так что, продолжение следует...
Читать далее...
Перед новой командой тестирования стоят задачи:
- «меркантильные»: сделать как минимум не хуже, чем было, то есть показать, что заказчик не зря сменил аутсорсера;
- «общечеловеческие»: выпускать качественный продукт.
Для их выполнения команде нужно будет улучшить процесс (или, как минимум, не испортить :) и в дальнейшем по нему работать.
Для улучшения процесса хорошо было бы показать заказчику , что хорошо, а что можно улучшить.
Тут 2 варианта:
1) Самый лучший, если есть время на вхождение в процесс, его анализ и изменение, если это нужно, и там, где это нужно. Вхождение можно разделить на этапы: знакомство с продуктом, анализ требований, анализ тестов (покрытие, былые прохождения и пр.), исправление и улучшение.
2) В условиях недостатка времени – просто включаться в работу по налаженному процессу и тогда улучшения вносить «по ходу», если остается время.
Рассматриваем первый вариант – у команды есть время на «вход».
Первым делом - анализ требований: есть ли, в каком виде, тестируемы ли? Тут можно говорить долго и много ( В моем последнем жизненном примере проекта нет требований, есть только юзер мануал, который пришлось переводить из вида «If you want to print the document that you have received from your agent, please select File>Print» в «To print document user should be able to select File>Print». А также пришлось уточнять моменты типа «There is no limit how many files user can add to the collection.» Беспредел – это, конечно, хорошо, но проверить какую-то разумную цифру все же надо :)
В ходе работы выработалось несколько формальных правил, напишу о них отдельно.)
Затем - анализ покрытия требований тестами. Преследуем 2 цели: получить картину «как это есть сейчас», и составить план действий « что сделать, чтоб было так, как должно быть».
В ходе анализа покрытия:
- составляем матрицы прослеживаемости;
- анализируем матрицы: почему некоторые единичные требования покрыты десятками тестов, в то время как целые блоки других вообще не имеют соотвествующих тестов? Э то следствие расстановки приоритетов или уверенности в себе предыдущей команды?
- попутно анализируем тесты на предмет избыточности.
После того, как анализ проведен, картина ясна, можно приступать к написанию тестов по непокрытым требованиям.
Пока что моя команда на этапе апдейта тест-кейсов с целью достичь как можно большего покрытия с как можно меньшей избыточностью.
Так что, продолжение следует...
Читать далее...
вторник, 10 февраля 2009 г.
У меня не хватает людей
Если б мне ещё одного тестировщика - качество продукта бы повысилось.
Продукт нестабилен потому, что людей не хватает.
Дайте людей - быстрее закончим.
К сожалению, многие руководители команд (и не только тестирования) искренне верят в верность этих фраз. К такому решению прибегают не только в сфере IT, как правильно заметил Саша Орлов в своей статье У меня не хватает ресурсов. Я думаю, что эта стратегия и пришла из повседневной жизни, где часто увеличивают количество лекций для улучшения знаний студентов, нанимают 2 бригады штукатуров для ускорения завершения ремонта и т.п. Хорошо хоть понимают, что с детьми так не получится :)
Есть известная фраза “Работа занимает все отведенное на неё время”. В случае вышеописанного подхода получаем, что “Работа находится для всех ресурсов, на неё выделенных”.
Случай из жизни: Мне в проект дали +1 тестировщика. Это не требовалось, я не просила, просто нужен был скилл-ап для джуниора, и решили, что проект подходящий. До этого команда справлялась со всеми поставленными тасками, но новый ресурс оказался полностью загруженным! Я стала думать, откуда же взялась для него работа?
Всем известен принцип 80\20, который в применении к работе звучит как "20 процентов задач дают 80 процентов отдачи". Под отдачей я здесь понимаю вклад в достижение цели.
И задачи для дополнительного сотрудника как раз и были из оставшихся 80 процентов, которые давали 20 процентов отдачи. То есть с его помощью мы, безусловно, повысили качество, но, по сути, это не было необходимым условием. Оговоренный критерий завершения работы ТАКОГО “вылизывания” не предполагал.
Всегда можно посадить человека на придумывание и дальнейшую поверку как можно более юзер-френдли сообщений типа “Вы конечно извините, мы все понимаем, но из-за нехороших людей, придумавших эту систему, почтовый индекс может содержать только цифры. Так что мы будем вам очень благодарны, если Вы введете правильный индекс. Только так Вы сможете продолжить регистрацию ”. Только входит ли это в цель проекта? Или все-таки целью является выпуск работающе системы платежей?
Вывод: прежде чем просить дополнительные ресурсы, нужно посмотреть, чем же заняты уже имеющиеся? Какой вклад в достижение цели проекты вносят задачи, которые на них заассайнены? Может случиться так, что не только не понадобятся дополнительные люди, но и уже имеющиеся будут чуточку разгружены :)
Читать далее...
Продукт нестабилен потому, что людей не хватает.
Дайте людей - быстрее закончим.
К сожалению, многие руководители команд (и не только тестирования) искренне верят в верность этих фраз. К такому решению прибегают не только в сфере IT, как правильно заметил Саша Орлов в своей статье У меня не хватает ресурсов. Я думаю, что эта стратегия и пришла из повседневной жизни, где часто увеличивают количество лекций для улучшения знаний студентов, нанимают 2 бригады штукатуров для ускорения завершения ремонта и т.п. Хорошо хоть понимают, что с детьми так не получится :)
Есть известная фраза “Работа занимает все отведенное на неё время”. В случае вышеописанного подхода получаем, что “Работа находится для всех ресурсов, на неё выделенных”.
Случай из жизни: Мне в проект дали +1 тестировщика. Это не требовалось, я не просила, просто нужен был скилл-ап для джуниора, и решили, что проект подходящий. До этого команда справлялась со всеми поставленными тасками, но новый ресурс оказался полностью загруженным! Я стала думать, откуда же взялась для него работа?
Всем известен принцип 80\20, который в применении к работе звучит как "20 процентов задач дают 80 процентов отдачи". Под отдачей я здесь понимаю вклад в достижение цели.
И задачи для дополнительного сотрудника как раз и были из оставшихся 80 процентов, которые давали 20 процентов отдачи. То есть с его помощью мы, безусловно, повысили качество, но, по сути, это не было необходимым условием. Оговоренный критерий завершения работы ТАКОГО “вылизывания” не предполагал.
Всегда можно посадить человека на придумывание и дальнейшую поверку как можно более юзер-френдли сообщений типа “Вы конечно извините, мы все понимаем, но из-за нехороших людей, придумавших эту систему, почтовый индекс может содержать только цифры. Так что мы будем вам очень благодарны, если Вы введете правильный индекс. Только так Вы сможете продолжить регистрацию ”. Только входит ли это в цель проекта? Или все-таки целью является выпуск работающе системы платежей?
Вывод: прежде чем просить дополнительные ресурсы, нужно посмотреть, чем же заняты уже имеющиеся? Какой вклад в достижение цели проекты вносят задачи, которые на них заассайнены? Может случиться так, что не только не понадобятся дополнительные люди, но и уже имеющиеся будут чуточку разгружены :)
Читать далее...
понедельник, 26 января 2009 г.
Kharkov QA Club - первая встреча состоялась
В честь годовщины своего существования Харьковский QA Club вышел из offline общения в мир.
23 января состоялась первая встреча его участников. На заседании присутствовало более 100 специалистов по качеству и специальный гость - Слава Панкратов.
Более подробно о прошедшем мероприятии можно почитать здесь и на форуме.
Хотелось бы узнать о подобных сообществах в других городах (я уверена, они существуют). Давайте коооперироваться :)
Читать далее...
23 января состоялась первая встреча его участников. На заседании присутствовало более 100 специалистов по качеству и специальный гость - Слава Панкратов.
Более подробно о прошедшем мероприятии можно почитать здесь и на форуме.
Хотелось бы узнать о подобных сообществах в других городах (я уверена, они существуют). Давайте коооперироваться :)
Читать далее...
вторник, 23 декабря 2008 г.
Scrum и XP: Заметки с передовой
Формальный анонс: "Благодаря инициативе Алексея Солнцева и активистов сообщества Agile Ukraine переведена популярнейшая книга Хенрика Книберга "Scrum and XP from the Trenches".
Неформальный анонс: Ну какие же молодцы, а? Вот говорят, что ПМ’ы ничего не умеют делать…А они умеют. Организовывать и даже самоорганизовываться. Ладно, пусть не все, но некоторые точно могут :-). Да не просто так, а с реальным выхлопом - так пишет об этой инициативе Серега Мовчан, на совести которого 17 переведенных и 89 отревьювленных глав из 110.
Итак, рецепт:
1 - находится группа единомышленников, причём среди них обязательно должен быть как минимум один подорванец
2 - Происходит общение на интересующие народ темы до тех пор, пока подорванец не выдаст что-то наподобие вот этого;
3 - Тут-то надо сразу же подписаться и voilà - дело в шляпе, а у тебя есть чем занять долгие вечера после работы;
4 - Далее идёт 2 месяца более-менее напряженного перевода, 1 месяц тормозов и 1 месяц нервного ожидания от вычитки - чего там филологи сделают с нашим детищем?
5 - И гордое созерцание результата (PDF)… кстати, ничуть не хуже оригинала.
Немного о книге
Книга исключительна полезна. С одной стороны она про такой хорошо (если не излишне) раскрученный термин как Scrum, на который ведутся большинство (если не все) начальников. С другой стороны, она упирает на то, что Scrum без инженерных практик не живёт. Не знаю сознательно ли Хенрик заложил этот месадж в книгу или так получилось случайно, но получилось именно то, что доктор прописал :-)
Почитайте - не пожалеете.
Читать далее...
Подписаться на:
Сообщения (Atom)
Сообщения
