На совещаниях группы аналитиков специалистам по тестированию лучше всего быть пассивными участниками и высказываться только в случае необходимости.
А ты, чукча, покорми собак и ничего не трогай, ага.
Читать далее...
вторник, 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 тестировщиков и разработчиков, но такие компании есть. И они позволяют себе это. Мы не можем назвать ни причин сложившейся ситуации, ни условий её возникновения, это факт.
| | Природа знает, что делает. Именно такое соотношение позволяет нашим айтишникам выигрывать в этой суровой борьбе за жизнь. Равновесие – это то, к чему стремится все в природе, и сообщества айтишников, называемые компаниями, не исключение. |
Хотелось бы добавить от нас, что все данные у нас есть и мы с удовольствием построим графики и попробуем найти корреляционные коэффициенты, если вам это интересно. Давайте делать выводы вместе, без оглядки на то, к какой стае мы принадлежим, к светлой или к темной, или являемся кусочком чего-то большего.
Читать далее...
Подписаться на:
Сообщения (Atom)
Сообщения
