Книга «How Google Tests Software» теперь на русском!

Полтора года назад, когда вышла книга «How Google Tests Software», я загорелась перевести ее на русский язык. Я давно восхищаюсь Уиттакером, я переводила его статьи, слушала мастер-классы и считаю его самым крутым чуваком в мировом тестировании. Тогда я еще работала руководителем отдела тестирования в «Иннове», и компания поддержала мой проект.

С тех пор многое поменялось: я перестала заниматься тестированием, выпускала приложения для iOS, сейчас работаю продакт-менеджером большого веб-проекта. Уиттакер же еще в 2012 году ушел из Google в Microsoft, громко хлопнув дверью. 

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

И вот, в январе издательство «Питер» выпустило книгу на русском языке с нашим переводом и дизайном:

Книга уже продается на на Озоне, а еще ее можно скачать в электронном виде за 99 рублей (спасибо издательству Питер, что оно пошло нам навстречу с ценой).

Я хотела сделать книгу такой, чтобы мне самой захотелось прочитать ее. Обложку нарисовал Макс Дегтярев — его иллюстрации всегда хочется рассматривать. (Большинство книг про тестирование оформлены битами и байтами, автоматизация изображена в виде робота, а баги — в виде жуков. Рассматривать не хочется.) 

Мы не стали придумывать мифические аналоги словам «фреймворк», «коммит», «баг» и «фича». Как говорим — так и пишем. В книге разработчики и тестировщики Google рассказывают о своей работе так, как будто сидят напротив. Мы постарались сохранить это ощущение.

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

Этот проект очень личный для меня. Я считаю его своей лебединой песней в тестировании. Спасибо «Иннове», что проект состоялся. Лучшим результатом для меня будет, если в как можно большем количестве команд разработки начнут «тестировать, как в Google», грамотно применяя принципы к своему контексту.

Небольшой анонс: мы подарим книгу всем участникам конференции Agile Days. Читайте, загорайтесь и делайте свою разработку круче! 
Читать далее...

Why Whittaker joined Microsoft? - перевод

Когда 3 февраля Джеймс Виттакер написал в Твиттере, что он уходит из Google, у всех возник миллион вопросов. Потом он написал пост о том, почему он так поступил (оригинал и перевод). И вот теперь Джеймс объясняет, почему выбрал именно Microsoft.

Оригинал
Перевод: Тимур Хайруллин

Похоже, что намеки на то, что переходы из Google в Microsoft не так уж редки, не послужили достаточным объяснением, поэтому вот вам более развесистый отчет. Для тех, кому неинтересны подробности в деталях, приведу короткую версию. Я думаю, что происходящее в мобильном и веб-ориентированном мире - неправильно, и со временем становится все более неправильным. Пользователи в опасности: они теряют контроль над персональными данными и над своей сетевой индивидуальностью. Независимые разработчики вынуждены стучаться в закрытые двери в попытках двигать веб вперед. Решение этих проблем потребует больших запасов интеллектуальной собственности, технических и информационных возможностей и дружелюбного отношения к производителям ПО. Мне кажется, что Microsoft - одна из лучших компаний, способных возглавить такое направление.

Да, я знаю, ваши комменты говорят, что вы сомневаетесь в этом, поэтому вот вам длинная версия.

Большие компании - это не круто, так почему вы ушли из одной в другую?

Я был в стартапах дважды: один раз как ведущий разработчик и еще раз как основатель. Десять лет я был профессором, с удовольствием занимаясь исследованиями и консультациями. В молодости я даже был админом в ФБР! Так что я повидал альтернативы большим компаниям - и я выбираю большие компании.

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

Компании становятся большими не просто так. Они вырастают из питательного бульона видений, идей, талантов, инноваций, успеха, инвестиций и свершений. Заставь этот бульон кипеть - и компания станет большой и будет оставаться большой. Ошибись с рецептом - и твой суп убежит. Выкипит достаточно много - и многие самые успешные на сегодня компании рано или поздно будут списаны со счетов с пустой кастрюлей в руках. Если хотите - угостите меня кофе в Starbucks и я расскажу вам, что могло бы произойти с Apple.

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

Вот о чем я говорю. Большие компании изобилуют талантами. Этой причины достаточно, чтобы объяснить чей угодно выбор - работать в большой компании. Кто не хочет все время быть среди умных людей? Вот почему стартапы пытаются сманить талантливых ребят из больших компаний. Вот почему большие компании воюют за лучших из лучших: в каждой компании есть такие. Microsoft построена на спинах IBM, DEC и прочих, и в свою очередь подогревает рост Google и возрождение Apple, которые в свою очередь являются каналом поставок для Twitter и Facebook. Догадались, где берут свои таланты новые стартапы? Догадались, где тут IBM, фундамент этого великого древа талантов? Булькает суп? Еще бы. Куда ни плюнь - попадешь в смышленого инженера. Умные ребята идут вверх, ага.

Однако таланты - это не единственный актив большой компании. Ум - необходимое качество, чтобы стать большим, но как только компания вырастает, у нее появляются два крыла с подвесными для оружия, недоступного братьям меньшим. Масштаб - это первое. Большие компании работают над большими проблемами. Размах - второе. Большие компании поставляют свои продукты в каждый уголок земного шара. И если вам хочется работать с умными людьми над проблемами планетарного масштаба, большие компании - ваш выбор.

Масштаб и размах означают, что большие компании способны взорвать сегмент индустрии или даже несколько индустрий - махом. И вот мы пришли к настоящему предназначению больших компаний: способности массированного подрыва индустрий. Microsoft взорвал экосистему персональных компьютеров, Google взорвал веб, Amazon взорвал продажи, Apple взорвал мобильный мир... Эти взрывы изменили направление будущего. И круче всего то, что любая из этих компаний за счет тройки "талант-масштаб-размах" способна сделать это еще раз.

И вашего неверия недостаточно, чтобы их остановить.

Ладно, но какая компания?

Давайте развеем иллюзии о больших компаниях. Вроде везде одно и то же, и многие могут выбрать компанию за сладкие плюшки. Я думаю, что гоняться за плюшками и прочими льготами - ошибка. Кормит ли вас компания обедами или платите вы за обед сами - это игра с нулевой суммой. Офис, засыпанный дорогими игрушками настолько, что начинает напоминать детскую имени Пэрис Хилтон, кажется неуместным. Игрушки не останавливали Пэрис от ее капризов, и они не сделают вас счастливым, если вам перестанет нравиться ваша работа. Плюшки - это пыль, дым, через который мудрые люди видят настоящую компанию, это низменные желания. Кофепойнты в Facebook не делают его умнее Apple. Хотите получать счастье от РАБОТЫ? Найдите новую.

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

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

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

И Microsoft - правильная большая компания?

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

Что ж, перейдем истокам моего выбора.

Почему Microsoft? Потому что моя страсть отлично сочетается с их желанием и способностью взрывать мир. Единственная проблема, над которой мне, похоже, придется поработать - чтобы компания сосредоточилась на заполнении команды лучшими талантами.

Почему Microsoft? Потому что большинство крупных игроков не заинтересованы в революциях. Когда вы живете за счет статус кво, вы заинтересованы двигаться медленно или не двигаться вообще.

Почему Microsoft? Потому что они попросили меня не содействовать, а помогать лидировать.

Почему Microsoft? Потому что каждый раз, когда я рассказываю людям, пользующимся интернетом с мобильника, над чем я работаю и что из этого получится, они хотят этого прямо сейчас. Когда я рассказываю разработчикам, что я строю, они начинают требовать API и SDK прямо сейчас. И если люди подгоняют вас в том, что вы делаете - это хороший знак: то что вы делаете - важно.

Я думаю, что Microsoft - правильная компания: я семь недель на новом месте, и мне нравится то, что я вижу вокруг. Когда я пришел в 2006 году, компания была сосредоточена вокруг Windows и Office. Теперь в Редмонде новая главная улица, и на ней студии (не офисы, а студии!) команд Xbox. Изменения отнюдь не символические. Windows и Office, ныне далекие от священных коров, явно подверглись генетическому инжинирингу. Я еще не совсем осознал, что они сделали и как, но их магия несомненна. Bing завершил перемешивание программирования и тестирования - они называют это "комбинированной разработкой", которую Google пытается сделать до сих пор, после года реорганизаций. И дальше больше, я вижу перемены каждый день. Наверное когда у меня будет больше данных, я напишу еще один пост.

Остались у Microsoft проблемы? Да. Буду ли я избегать тыкать в них пальцем, если они мне теперь платят? Нет. Есть улучшения, которые нужны Microsoft. Митинги собираются слишком часто и длятся слишком долго. Когда я объявил, что все мои менеджеры должны кодить, не могу сказать, что их счастье захлестнуло меня с головой. Дальше больше, я только начал собирать проблемы.

Что мне действительно нравится в Microsoft - если показать им зеркало, они будут в него смотреть. Дайте им время, и они изменятся.





Читать далее...

Если вы стали QA-менеджером

Представляю перевод статьи Джеймса Виттакера "Если вы стали QA менеджером". Оригинальному тексту почти год, я прочла его первый раз как раз, когда сама оказалась на месте героя поста. За это время у меня появились комментарии к мнению Джеймса, поэтому, можно сказать, что мы соавторы получившейся статьи.

Оговорюсь сразу, что под "QA менеджером", как я понимаю, здесь нарисован тест-менеджер, но с большим влиянием на процесс и на качество. Такое очень часто встречается в командах и компаниях, которые выпускают на рынок свой собственный продукт. Так что, я оставлю оригинальную терминологию Джеймса.

________________________

Начните жить своим продуктом!

Джеймс:
Итак, вы оказались новым QA менеджером. Первое, что вам нужно сделать, это начать жить своим продуктов, загореться им.

Полностью растворитесь в вашем продукте, запоминайте рекламные речи, поймите его конкурентные преимущества, но сохраните при этом ваш скептицизм.

QA-менеджер должен быть также увлечен своим продуктом, как и менеджер разработки, но нам нужно сдерживать нашу страсть доказательствами. Будьте уверены, что команда тестирования не прекратит тестировать функциональность, стоящую за жарким рекламным спичем.

Более того, частью жизни с вашим продуктом является быть его пользователем.

К примеру, я сейчас живу без лаптопа и использую в своей повседневной работе только Chrome OS Netbook. Так как люди видят меня с ним в коридорах, мне доводится произносить рекламные спичи по многу раз каждый день. Великолепная практика, скажу я вам! Мне же доводится жить и с огрехами, и записывать штуки, которые ещё надо доделывать. Это хворост для пламени спора между разработчиками и другими стейкхолдерами, и это тоже заставляет меня взвешивать конкурирующие продукты. Когда у меня не получается сделать что-нибудь, что мне нужно, на моем Chrome OS Netbook и я вынужден использовать конкурирующий продукт, это порождает здоровую дискуссию о том, как пользователи воспринимают недостатки наших продуктов, и о том, как мы можем правильно преподнести плюсы и минусы нашего продукта потребителям.

И это прекрасный путь для начинания нового продукта, кстати ;-)

Юля:
Если вы приходите не просто в продукт, выпускаемый вашей компанией, а в новую компанию, начните жить вашей компанией. Её культурой. Поймите, почему она выпускает именно такие продукты. Чтобы приносить людям пользу, чтобы отвечать на их вопросы, чтобы решать их проблемы? Чтобы веселить их? Чтобы что?

Побудьте пользователем других продуктов вашей компании, чтобы понять, как они относятся к вашей продукции. Чего им не хватает: внимания, скорости, скидок? Что они не могут сделать с продуктами вашей компании, и как компания реагирует на это?

Поняв, как это происходит на уровне всей компании, гораздо легче понять, как это работает для для вашего продукта. Вы поймете, кто в команде идет in-line с компанией, а чьи цели лежат в другой плоскости. Вы поймете, кто на вашей стороне (а вы ведь – именно тот человек, который хочет сделать ваш продукт лучше для пользователя и успешнее для компании, правда же?), а кого нужно ещё переманивать. На кого-то можно махнуть рукой, а кто-то просто мешает работе над продуктом. Это шанс улучшить ситуацию. Потому что вы - новый человек со свежим взглядом, и во-вторых – потому что тестирование – это фильтр.

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

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

Фокусируйтесь на тест-плане, сделайте это высшим приоритетом

Джеймс:
Если вы заняли уже существующую роль тест-менеджера в уже существующем продукте, есть вероятность, что тест-план уже тоже существует и что этот тест-план неактуален. Я не наезжаю на вашего предшественника, я просто искренен. Большинство тест-планов являются «временными» документами.

Объясню, что я имею ввиду под этим.

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

Тестировщики очень любят жаловаться на это: «Как мы можем тестировать продукт без полного описания того, что он делает?»

Но разве не то же самое мы зачастую делаем со своими тест-планами? Мы наскоро клепаем тест-план, но как только мы начинаем писать тесты (автоматические или мануальные), как они начинают жить своей собственной жизнью. Довольно скоро тесты начинают расходиться с тест-планом, так как мы догоняем новые разработки или наш опыт подсказывает нам новый тестерский инсайт.

Тест-план стал в точности, как спецификация: Документ-Который-Был.

Юля:
Тест-план (как и все тестирование, конечно же), может работать на вас, а может на продукт. Иными словами, часто хочется применить все свои теоретические знания и накопленный опыт и отразить все предыдущие годы работы в документе под названием Тест-План-Всего.

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

Продукту нужен рабочий тест-план. И всей команде нужен рабочий тест-план. Отлично, если ваш тест-план – это список модулей на доске и написанные маркером же рядом номера задач в таск-трекере и тегов в свне. Отлично, если актуализация вашего тест-плана – это merge еженедельномитинговых фоллоу-апов. Отлично, если он отражает суть вашего подхода к тестированию продукта и понятен любому члену команды.

Если вы делаете его для того, чтобы потешить свое чувство сертифицированного тест-менеджера – будьте честными в этом признаться. Хотя бы себе.

Джеймс:
И вот вы – новый тест-менеджер, сделайте исправления этих документов вашей первоочередной задачей. Вы узнаете функциональность вашего продукта, и вы увидите пробелы в текущей структуре тестов, которые нужно закрывать. Плюс к тому, у вас будет почва для разговора с менеджерами разработки, и вы сможете показать им, что вы серьезно относитесь к качеству. Менеджеры разработки в Гугле любят хорошие тест-планы, это дает им понимание того, чем вы занимаетесь.

Разберитесь с процессом и приоритетами релиза

Поздний цикл предрелизного тестирования – это самая нервная часть всего цикла разработки. Тест-менеджеры должны поддерживать баланс между правильным тестированием и обеспечением гармоничного релиза. Я советую посещать все девелоперские совещания, но чем ближе к релизу – тем точнее вы не должны пропустить ни одного. Будьте очень внимательны к их беспокойствам и проблемам. Самые ужасные предположения имеют тенденцию претвориться в действительность. Добавляйте тесты в ваш набор проверок, чтобы убедиться, что эти сценарии не случатся.

Юля:
Будьте всегда готовы ответить себе, команде и инвесторам, почему этот баг встретился 20 процентам пользователей и породил тысячи петиций. Почему вы не наняли ещё троих тестировщиков, чтобы протестировать тщательно все области, а не только самые приоритетные? Почему вы держите именно такой баланс между знанием о качестве и затратами на его контроль? Почему вы в последний момент кинули все силы на эту область, хотя в недельной давности тест-плане она шла вторым приоритетом?

Главное, чтоб вы четко понимали это сами.

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

Я обнаружил, что в Гугле увеличение фокуса команды на мануальном тестировании искренне приветствовалось командой разработчиков. Найдите комфортную зону вашей команды разработки и удерживайте баланс между тем, чтобы всё-таки правильно тестировать, и тем, чтобы сделать финальные часы (дни) как можно безболезненнее.

Тестируйте ваш процесс тестирования

Джеймс:
Начните с чтения каждого теста-кейса и просмотра всей информации. Можно ли привязать эти тесты к тест-плану? Сколько тестов у вас есть на один компонент? А на фичу? Если баг находится за пределами процесса тестирования, создаете ли вы на него тест-кейс? Есть ли у вас процесс исправления или выбрасывания испорченных или неактуальных тест-кейсов?

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

Юля:
Чем критичнее вы относитесь к своей работе, тем больше у вас права критично относиться к чужой. Считается, что тестировщик не должен ошибаться и не должен пропускать баги. В то время, как программисту вполне позволено их делать. Чтобы изменить это мнение, нужно действительно крепко тестировать не только работу программистов, но и свою собственную. Вы должны всегда видеть ещё возможности протестировать что-то лучше, тщательнее, если представится такая возможность. И вы должны четко понимать, от чего вы осознанно отказываетесь. И уметь объяснить это всей команде.

Чем более требовательны вы к своим тестам, тем более требовательными у вас получится быть к разработчикам.

Ищите пути для инноваций

Самый легкий путь выглядеть хорошо в глазах разработчиков – это поддерживать статус-кво. Многие руководители разработчиков высоко ценят покорную и зависимую команду тестирования. Многие из них любят предсказуемые и легкопонятные практики тестирования. Эта та штука, о которой надо беспокоиться меньше всего (ведь даже перед лицом очевидной неэффективности знакомый путь часто считается самым близким).

Как новый менеджер, ваша работа – не дать им отделаться так легко! Вы должны сделать список тех частей процесса, которые вас настораживают, и тех частей, которые кажутся чересчур громоздкими или неэффективными. Это те места, где стоит применить инновации. Будьте готовы к нервозности со стороны разработчиков, но покажите, что ваши старания приносят пользу и заключите долгосрочное пари!

Юля:
Очень важно выдерживать баланс между «так у нас принято» и «я знаю, как сделать лучше». Когда вы приходите в новой роли в новую команду, у вас есть огромный плюс и страшное оружие: «свежий взгляд». Если его применять правильно – вы взорвете тестирование на проекте (в хорошем смысле). Будьте готовы столкнуться с «это не заработает, потому что…», «мы это пробовали, это фигня…», «да ну , бред какой-то, лучше делать по-старому…». Жизненно важно отличать реальные причины того, почему здесь делается именно так, от пустых отговорок, за которыми люди скрывают привычку и нежелание двигаться.

Если вы возьмете правильный опыт этой команды и дадите ему новое дыхание – будет бомба!

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

Юля:
Так что - дерзайте! И удачи вам.

Читать далее...

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 =)

Хочу сказать, что аудитория, подход к общению, подборка докладов очень сильно отличается от привычных нам конференций по тестированию.
Ну и да, я в восторге =)

Читать далее...

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. "

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

И вполне возможно попасть туда, куда очень хочется, если идти в этом направлении. Всегда нужно кричать о том, что ты хочешь, ведь вероятность того, что в зоне слышимости находится человек, который может помочь, очень велика.

И ещё – прислушивайтесь, пожалуйста, вдруг вы можете помочь тому, кто кричит неподалеку =)

Спасибо,
А я буду дальше любоваться облаками =)

Читать далее...

7 plagues of Software Testing by James Whittaker - The plague of Entropy

Порок энтропии.

Оригинал

Математически, энтропия – это мера неопределенности. Скажем, если есть 5 событий, то энтропия будет максимальной, если все они равновероятны, и энтропия будет минимальной, если лишь одно из событий определено, а остальные 4 – невозможны.

Чем более неопределенные события вам приходится рассматривать, тем выше карабкается мера энтропии. Люди часто думают об энтропии как о мере случайности: чем более неопределенные события рассматриваются, тем более случаен их результат.

Тестировщики привносят энтропию в разработку добавлением ряда вещей, которые следует сделать разработчику. Когда разработчики пишут код, энтропия мала. Когда мы заводим баги, мы увеличиваем энтропию. Баги отводят внимание разработчиков от кодирования. Теперь они должны работать параллельно и над созданием, и над починкой фич. Чем больше багов, тем больше параллельных задач, и это повышает энтропию. Энтропия – одна из причин, почему баги вызывают ещё больше багов: принцип энтропии обеспечивает это. Энтропия порождает энтропию! В конце концов, математика показывает нам то, что и так интуитивно понятно: предотвращение круче лечения.

Как бы там ни было, мы ничего не можем сделать, чтобы полностью предотвратить порок энтропии, кроме как создать разработчиков, которые никогда не ошибаются. А раз это маловероятно, мы должны определять, как и когда мы сталкиваемся с энтропией, и делать все, что в наших силах, чтобы ею управлять. Чем больше мы сможем сделать во время разработки, тем лучше. Помогать в code review, вводить наших разработчиков в курс тест-планов, пользовательских сценариев и окружений, чтобы они могли кодировать с меньшим количеством багов, которые нам пришлось бы рапортовать. Выкуривать баги как можно раньше, заводить их пачками и быть уверенными, что мы создаём только высококачественные баг-репорты, причесывая их самостоятельно, концентрируя тем самым мысли программистов на разработке. Написание хороших баг-репортов и быстрая проверка исправлений удержат внимание разработчиков там, где ему положено быть. Фактически это максимизирует определенность «разработчицких событий» и минимизирует количество и влияние багов. Энтропия, таким образом, сходит на минимум

Мы не можем отогнать этот порок, но мы можем определить привнесение энтропии в разработку и согласиться с неминуемым влиянием на качество кода; мы можем держать её под контролем.





Читать далее...

7 plagues of Software Testing by James Whittaker - The plague of blindness

Порок слепоты

Оригинал

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

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

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

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

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

Тестировщики могли бы многому научиться в мире компьютерных игр. Включите свои heads up дисплеи - и вы увидите информацию, к которой были слепы. Сила в знании.





Читать далее...

7 plagues of Software Testing by James Whittaker - The Plague of Homelessness

Порок бездомности

Оригинал

Есть 2 категории людей, которые регулярно находят баги: тестировщики, которым за это платят, и пользователи, которые сталкиваются с багами случайно. Вообще-то, пользователи не делают это специально, просто в процессе нормального использования ПО в ходе работы (или развлечения, или социализации, или ещё чего-то) случаются сбои. Частенько, именно магическая комбинация взаимодействия приложения с реальными данными пользователя на реальном компьютерном окружении пользователя приводит к сбою ПО. Не кажется ли вам очевидным, что тестер должен стремиться воссоздать такие данные и условия окружения в своей тестовой лаборатории, чтобы найти эти баги до выпуска продукта?

На самом деле, тестировщики усердно пытались добиться именно этого в течение десятилетий. Я называю это «привнесением пользователя в тестовую лабораторию», неважно как, телом или духом. Моя докторская диссертация была на тему статического тестирования использования, и я был далеко не первым человеком, кто думал об этой идее, как свидетельствует моя многостраничная библиография. Но здесь есть естественное ограничение на успех такого рода работы. Тестировщики просто не могут стать пользователями или имитировать их действия достаточно натурально, чтобы найти все важные баги. Вы будете пропускать важные дефекты, если только вы действительно не живете в этом продукте.

Это как домовладение. Не имеет значения, хорошо ли построен дом. Не имеет значения, насколько старательными были строители и подрядчики во время строительства. Дом может быть тщательно проинспектирован на каждой фазе строительства подрядчиком, домовладельцем и государственным строительным инспектором. Все равно есть проблемы, которые могут быть обнаружены только спустя некоторое время после заселения дома. Дом должны использовать, в нем должны обедать, спать, принимать душ, готовить, устраивать вечеринки, отдыхать и все остальное, что домовладельцы делают в своих домах. Нельзя обнаружить дефект в системе сточных вод, пока подросток не постоит под душем в течение часа. Нельзя обнаружить оставленный кусок арматуры в бетонной плите гаража, пока не начнут парковать машину ночью. Строитель не будет (да он и не сможет) смоделировать такое.

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

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

Тестировщики бездомны. Мы можем делать лишь то, что можем, и ничего более. Нужно понимать наши ограничения и быть готовыми к спискам жалоб от наших пользователей. Претендовать на то, что как только приложение выпущено, проект завершен, - как минимум, глупо. Есть ещё гарантийный период, в который мы присматриваем за приложение, и этот период - все ёще часть фазы тестирования.






Читать далее...

7 plagues of Software Testing by James Whittaker - The Plague of Boredom

Порок скучности .

Оригинал.

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

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

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

Я считаю, что скучающие тестировщики что-то упускают. Я утверждаю, что лишь тактические аспекты тестирования становятся со временем скучными, и многие ударяются в автоматизацию дабы сгладить это. Автоматизация как зелье от скуки выполнения тест-кейсов и заполнения баг-репортов – это одно дело, но автоматизация – не замена стратегическим аспектам процесса тестирования и именно в стратегии мы находим избавление от порока скучности. Процесс тест-дизайна, принятие решения о том, что должно быть и что не должно быть протестировано, и в каком соотношении, - во всем этом автоматизация вам не поможет, и это остается интересной и побуждающей думать задачей. И ни одно из этого ещё не является стратегической задачей мониторинга тестов и определения, когда остановиться. Это и есть те тяжелые, но интересные стратегические проблемы, которые изгоняют порок скучности. Тестировщики могут поддаться пороку скучности, либо же они могут сместить свой фокус с лишь тактических задач на изящный микс из тактической работы и стратегических размышлений.

Убедитесь, что в вашей суете по выполнению мелких тактических задач тестирования вы не упускаете стратегические аспекты вашей работы, потому что именно здесь есть интересные технические задачи и высокоуровневые размышления, которые удержат ваш интерес и припрут этот порок к стене.
________________________________________________________________________________________

Скучность. Вообще-то, boredom – это скука, но скучность больше подходит для передачи именно свойства, присущего тестированию. Скука – это его следствие.





Читать далее...

7 plagues of Software Testing by James Whittaker - Plague of Amnesia

Порок амнезии.

Оригинал.

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

Тестировщики ПО подвержены двум типам порока амнезии. У нас есть командная амнезия, которая заставляет нас забывать наши прежние проекты, наши прежние баги, тесты, сбои и так далее. Требуется время для построения коллективной памяти, которая помогла бы нам остановить повторение наших ошибок. Каждый проект – это не старт с нулевой точки, это всего лишь новая цель для уже более опытной команды. Звездный корабль Enterprise сохраняет бортовой журнал. Это дневник, в котором описаны все приключения его экипажа и к которому можно обратиться за деталями, которые возможно помогут людям выбраться из текущего очередного переплета. Я не пропагандирую ведение дневников для команд тестирования, но я действительно хочу иметь механизм для сохранения знаний. Идея в том, что мы как команда основываемся на наших коллективных знаниях и успехах. Чем длиннее память экипажа Enterprise, тем лучше её можно использовать.

А ну-ка, назовите мне быстренько последний крупный сбой продукта, над которым работает ваша команда. Есть ли у вашей команды коллективная память общих багов? Делитесь ли вы хорошими тестами? Если один специалист пишет тесты для проверки какой-то функциональности, знают ли об этом остальные и тратят ли они свое время на тестирование где-то в другом месте? Документируются ли проблемы, которые ломают автоматизацию, с тем, чтобы усилия на анализ этих проблем и их решение не повторялись снова? Знает ли команда, что делает каждый, с тем, чтобы их области тестирования перекрывались как можно меньше? Достигается ли это с помощью дашбордов и постоянного общения? Или мы синхронизируем наши действия лишь митингами, крадущими наше время и прерывающими нашу работу? Ответьте честно. Первый шаг к исправлению – признание существования проблемы.

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

Амнезия индустрии – это настоящая беда. Подумайте об этом в таком ключе: проблема тестирования, которая встала перед вами прямо сейчас (вставьте сюда проблему, над которой вы работаете), уже была когда-то решена. Вы тестируете операционную систему? Кто-то уже сделал это, и не только он. Веб-приложение? Да, и это уже сделано. AJAX? Клиент-сервер? Да, да и ещё раз да. Скорее всего все, что вы сейчас делаете, уже было сделано до вас. Да, есть какие-то новые проблемы тестирования, но более чем вероятно, что ваша нынешняя проблема не одна из них. Очень плохо, что с коллективной памятью в индустрии все так запущено, иначе было бы просто дотянуться до помощи.

Позвольте мне завершить эту колонку, показав пальцем внутрь: Как же мы [Гугл] будем тестировать недавно анонсированную ОС Chrome? Сколько коллективной памяти мы сохранили после Chrome и Android? Сколько из того, чему мы научились, тестируя Android, поможет? А сколько из этого будет переиспользоваться? Как легко тестовые команды Chrome и Android адаптируются к этому новому испытанию? И, конечно же, многие наши проблемы тестирования – это те, с которыми мы уже сталкивались.

Запомним ли мы?




Читать далее...

7 plagues of Software Testing by James Whittaker - Plague of repetitiveness

Порок повторяемости

Оригинал

Если бесцельность – это результат «простоделания», то повторяемость – это результат «простеделания несколько раз». Раз за разом, билд за билдом, спринт за спринтом, версия за версией мы тестируем наш продукт. Разработчики проводят инспекции, создают юнит-тесты и запускают статистические анализаторы. Но у нас есть лишь маленькие догадки по поводу всей этой работы, и мы не можем доверять им. Разработчики тестируют, но затем перетестируем мы. Мы не можем поручиться за то, что они делают, и поэтому мы подвергаем повторному тестированию всё. Наряду с ростом нашего продукта в фичах и по мере фиксов дефектов мы продолжаем наше тестирование. Новые тесты теряют свою новизну очень быстро, и все они, в конце концов, становятся устаревшими.

Существует Бейзеровский пестицидный парадокс. Пестициды убивают жуков, но опрыскайте одно и то же поле одним и тем же ядом достаточное количество раз, и у оставшихся жуков выработается иммунитет. «Прополоскать и повторить» - это алгоритм для мытья волос, а не для тестирования ПО. Последнее, чего мы хотим добиться, -- это билд, полный супер-багов, устойчивых к нашему «тестициду». Дальше – хуже: всё, что называется «успешным тестированием» будет давать нам фальшивое видение тщательности и делать наши метрики завершенности кучей опасного вранья.

Когда вы не находите баги, это не потому, что их нет, а потому, что повторение повлекло за собой пестицидный парадокс.

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




Читать далее...

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!" - "Не зажимай косяк!"". Пруфлинк. Слово это возникло благодаря актеру Хамфри Богарту, известному своей привычкой не выпускать сигарету изо рта (основную известность ему, конечно же, принес кинематограф, а не сигарета. Очень люблю его "Касабланку").




Читать далее...