Конечно же, это предоставление информации - максимально полно, максимально быстро, эффективным путем.
Дальше должен происходить анализ информации о багах и проблемах, и выявление причин возникновения проблем.
После этого следует исследование области решений проблем, выбор лучшего и постановка задачи на решение.
И просто обязательно - владение задачами на решение проблем, помощь и требовательность, драйвинг и в конечном итоге решение проблемы. Часто не своими собственными силами.
Это разработка решений. Это переход на уровень влияния на качество и обеспечения его.
Я уверена, что обеспечение качества должно вырасти из тестирования, а не быть инициативой руководства и внедряться сверху.
Чтобы этого добиться, нужны условия:
Чтобы компания была заинтересована в повышении качества своих продуктов и была настроена на предвосхищение ожиданий пользователей. Тогда снимаются все ограничения на этом пути: инициативы поддерживаются (если они разумны), ресурсы выделяются (если они обоснованы), усилия ценятся (если они искренни).
Чтобы команда состояла из людей, которым постоянно мало текущего уровня, требовательных к самим себе, к своей работе и к другим. Это люди, которые жадно и быстро учатся, в том числе друг у друга.
Чтобы цели компании и команды совпадали. Это может быть - "стать лучшими на рынке или в отрасли", это может быть - "создавать продукты или решения, которыми пользуются люди", это может быть - "внесение инноваций в существующую отрасль".
Работая именно в таких условиях, я могу сказать, что это трудно. Очень трудно. Но это постоянное движение с командой вперед и вверх, и мы не позволяем друг другу останавливаться.
Мы ищем людей, которые горят этим же. Мы ищем людей, стремящихся влиять на качество продуктов, которыми пользуются люди, и готовых учиться для этого. Вы можете поделиться с нами своими знаниями и наработками. Вы можете прийти к нам, чтобы научиться этому. Вы можете прийти к нам, чтобы найти направление своего развития или сменить его. Единственное, пожалуй, о чем мы вас попросим, это никогда не останавливаться.
Нам сейчас нужен ведущий тестировщик-аналитик и инженер по автоматизированому тестированию.
Ждем вас, если вы думаете в эту же сторону!
Писать можно мне yulia.nechayeva AT inn.ru, можно на vacancy AT inn.ru
Читать далее...
пятница, 20 апреля 2012 г.
Повышение качества со стороны тестирования
На конференции AgileDays мы с моей коллегой Наташей Курашкиной рассказывали про то, как тестирование может влиять на качество, и почему мы думаем, что оно должно это делать.
Создавать среду, в которой ошибиться труднее, чем сделать правильно, - вот задача тестирования. Только так мы сможем двигаться вперед, освобождая себе руки для инноваций. Только так мы сможем повышать качество продуктов, которыми пользуемся и которые разрабатываем.
Читать далее...
Создавать среду, в которой ошибиться труднее, чем сделать правильно, - вот задача тестирования. Только так мы сможем двигаться вперед, освобождая себе руки для инноваций. Только так мы сможем повышать качество продуктов, которыми пользуемся и которые разрабатываем.
Читать далее...
воскресенье, 8 апреля 2012 г.
Selenium 1, bye-bye!
воскресенье, 25 марта 2012 г.
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 - если показать им зеркало, они будут в него смотреть. Дайте им время, и они изменятся.
Читать далее...
Оригинал
Перевод: Тимур Хайруллин
Похоже, что намеки на то, что переходы из 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 - если показать им зеркало, они будут в него смотреть. Дайте им время, и они изменятся.
Читать далее...
четверг, 8 декабря 2011 г.
Игра "Нереальное тестирование" на SQA Days, ИТОГИ.
На конференции SQA Days – 10 мы (Иннова) были спонсорами.
Как я уже говорила в своем интервью, мы ставили себе несколько целей. Во-первых, попробовать, каково это – быть спонсором. Во-вторых, создать людям фан, сделать крутой стенд, чтобы люди чувствовали в первую очередь внимание, а не рекламу. В третьих, создать эмоцию вокруг Инновы, впечатление и понимание, что мы умеем работать круто и весело!
Судя по отзывам в твиттере и тому, что по просьбам посетителей мы продлили стенд ещё на один день, это удалось!
Фотографии здесь (при клике по фоткам откроются альбомы в ФБ):
Специально для конференции мы придумали игру: Нереальное тестирование (ТМ).
Правила:
Два на первый взгляд одинаковых сайта. Но только не для зоркого глаза тестировщика!
Задача игроков была - найти максимальное количество отличий в двух сайтах за игровую сессию.
У игрока было 10 минут, которые начинались по нажатию на кнопку Старт на первом сайте.
У сайтов были отличия 3х типов:
-- Статические (k=1) – можно обнаружить, на странице не действуя, как пользователь;
-- Динамические (k=2) – могут быть найдены только в ходе «использования» сайтов,
-- Сложные (k=5) – без специальных инструментов не найти!
И были Пасхальные яйца (win, k=7):
Мы заложили в Подвиги несколько пасхальных яиц, нахождение каждого давало 7 очков!
Появление на экране сообщения WIN свидетельствовало о нахождении игроком пасхального яйца.
Фиксировать найденные игроками отличия помогали девочки-модераторы, они же вносили результаты в админку, которая пересчитывала финальный результат.
Счет игрока складывался исходя из количества найденных отличий с учетом коэффициента категории. Общий рейтинг составлялся на основании заработанных игроками очков за одну сессию.
Мы не ограничивали количество сессий для каждого игрока. Но все отличия, которые игрок запоминал с прошлого раза, он показывал модератору, чтобы она могла его зафиксировать. Таким образом, фора у повторных участников была небольшая. Зато давала возможность изменить стратегию поиска и пойти более эффективным путем.
В рейтинг засчитывался максимальный результат из всех сессий. Очки не суммировались.
Для усложнения задачи мы решили, что игрокам нужно создать нереальные для работы условия. Профессиональные массажистки делали массаж шейно-воротниковой зоны первые 5 минут игры. Продуктивность в последующие 5 минут возрастала просто на глазах!
По результатам первого дня поиграть удалось пятидесяти участникам. Легендой стенда стал Петр Родин, который несколько раз отвоевывал первое место, но в итоге занял 4е.
Второй день был менее динамичен, да и длилась игра на 2 часа меньше. Поиграло 33 человека, два призовых места взяли Катя и Вика, выбрав стратегию объединения.
Очень было интересно наблюдать, как люди с разным опытом по-разному подходили к задаче.
Одни сразу же открывали исходники двух «главных» страниц, даже не авторизуясь, проводили в сравнении 6-7 минут, потом заходили внутрь сайтов и тут только понимали, что исследовали лишь малую часть.
Другие первым делом оценивали объем страниц и функциональности сайтов, и лишь потом приступали к поиску.
Одни делали упор на отличия в верстке, другие – в функциональности.
Одни старались найти как можно больше простых отличий, другие выбирали стратегию «мало, но WIN’ов».
Многие меняли стратегию после первого раза.
Отличная иллюстрация для исследовательского тестирования, на самом деле!
Мы оставили сайты в открытом доступе ещё на неделю, до 15 числа можно поиграть вот здесь:
http://inn.webumka.ru/test1/
http://inn.webumka.ru/test2/
На любые вопросы я отвечу в этой ветке форума, здесь же можно меряться результатами. Единственное правило – не спойлить!
15 декабря я опубликую список тех отличий, которые были внесены в приложения санкционированно, то есть – по ТЗ. Интересно сравнить с вашими списками.
Удачи!
Читать далее...
 |  |
Как я уже говорила в своем интервью, мы ставили себе несколько целей. Во-первых, попробовать, каково это – быть спонсором. Во-вторых, создать людям фан, сделать крутой стенд, чтобы люди чувствовали в первую очередь внимание, а не рекламу. В третьих, создать эмоцию вокруг Инновы, впечатление и понимание, что мы умеем работать круто и весело!
Судя по отзывам в твиттере и тому, что по просьбам посетителей мы продлили стенд ещё на один день, это удалось!
Фотографии здесь (при клике по фоткам откроются альбомы в ФБ):
 |  |
Специально для конференции мы придумали игру: Нереальное тестирование (ТМ).
Правила:
Два на первый взгляд одинаковых сайта. Но только не для зоркого глаза тестировщика!
Задача игроков была - найти максимальное количество отличий в двух сайтах за игровую сессию.
У игрока было 10 минут, которые начинались по нажатию на кнопку Старт на первом сайте.
У сайтов были отличия 3х типов:
-- Статические (k=1) – можно обнаружить, на странице не действуя, как пользователь;
-- Динамические (k=2) – могут быть найдены только в ходе «использования» сайтов,
-- Сложные (k=5) – без специальных инструментов не найти!
И были Пасхальные яйца (win, k=7):
Мы заложили в Подвиги несколько пасхальных яиц, нахождение каждого давало 7 очков!
Появление на экране сообщения WIN свидетельствовало о нахождении игроком пасхального яйца.
Фиксировать найденные игроками отличия помогали девочки-модераторы, они же вносили результаты в админку, которая пересчитывала финальный результат.
Счет игрока складывался исходя из количества найденных отличий с учетом коэффициента категории. Общий рейтинг составлялся на основании заработанных игроками очков за одну сессию.
Мы не ограничивали количество сессий для каждого игрока. Но все отличия, которые игрок запоминал с прошлого раза, он показывал модератору, чтобы она могла его зафиксировать. Таким образом, фора у повторных участников была небольшая. Зато давала возможность изменить стратегию поиска и пойти более эффективным путем.
В рейтинг засчитывался максимальный результат из всех сессий. Очки не суммировались.
Для усложнения задачи мы решили, что игрокам нужно создать нереальные для работы условия. Профессиональные массажистки делали массаж шейно-воротниковой зоны первые 5 минут игры. Продуктивность в последующие 5 минут возрастала просто на глазах!
По результатам первого дня поиграть удалось пятидесяти участникам. Легендой стенда стал Петр Родин, который несколько раз отвоевывал первое место, но в итоге занял 4е.
Второй день был менее динамичен, да и длилась игра на 2 часа меньше. Поиграло 33 человека, два призовых места взяли Катя и Вика, выбрав стратегию объединения.
Очень было интересно наблюдать, как люди с разным опытом по-разному подходили к задаче.
Одни сразу же открывали исходники двух «главных» страниц, даже не авторизуясь, проводили в сравнении 6-7 минут, потом заходили внутрь сайтов и тут только понимали, что исследовали лишь малую часть.
Другие первым делом оценивали объем страниц и функциональности сайтов, и лишь потом приступали к поиску.
Одни делали упор на отличия в верстке, другие – в функциональности.
Одни старались найти как можно больше простых отличий, другие выбирали стратегию «мало, но WIN’ов».
Многие меняли стратегию после первого раза.
Отличная иллюстрация для исследовательского тестирования, на самом деле!
Мы оставили сайты в открытом доступе ещё на неделю, до 15 числа можно поиграть вот здесь:
http://inn.webumka.ru/test1/
http://inn.webumka.ru/test2/
На любые вопросы я отвечу в этой ветке форума, здесь же можно меряться результатами. Единственное правило – не спойлить!
15 декабря я опубликую список тех отличий, которые были внесены в приложения санкционированно, то есть – по ТЗ. Интересно сравнить с вашими списками.
Удачи!
Читать далее...
понедельник, 5 декабря 2011 г.
SQA Days 10: Команда, где каждый лидер
Моя презентация с SQA-Days 10.
Хочу поделиться теми принципами, которые помогли мне построить 2 суперэффективные команды тестирования в моей компании. В двух словах: в моих командах каждый специалист является лидером.
Основная фишка в том, что у лидера есть ответственность, но нет формальных полномочий. Являясь боссом в своем направлении, он является исполнителем в направлении своего коллеги.
У такого подхода, безусловно, есть ограничения к применению и подводные камни. Но при грамотном использовании, он дает неоднократное повышение эффективности тестирования.
Читать далее...
Хочу поделиться теми принципами, которые помогли мне построить 2 суперэффективные команды тестирования в моей компании. В двух словах: в моих командах каждый специалист является лидером.
Основная фишка в том, что у лидера есть ответственность, но нет формальных полномочий. Являясь боссом в своем направлении, он является исполнителем в направлении своего коллеги.
У такого подхода, безусловно, есть ограничения к применению и подводные камни. Но при грамотном использовании, он дает неоднократное повышение эффективности тестирования.
Читать далее...
вторник, 22 ноября 2011 г.
Eurostar. Introduction. The first post of our new blog.
Привет!
Мы открыли блог команды тестирования Инновы. Подробнее про нас и про то, зачем мы это делаем, можно прочесть первом поcте: http://www.innovatesting.info/2011/11/about-us.html
Открываем блог мы трансляцией с конференции EUROSTAR 2011, будем рассказывать о том, что здесь происходит, какие мысли и инсайты у нас возникают и знакомиться с миром европейского коммьюнити тестирования.
Первый пост про вчерашнюю 8-часовую сессию Майкла Болтона: вот он.
Пост про выступление Дороти Грэхем: вот
Фотопост с доклада Гойко Адзика: вот
Читать далее...
Мы открыли блог команды тестирования Инновы. Подробнее про нас и про то, зачем мы это делаем, можно прочесть первом поcте: http://www.innovatesting.info/2011/11/about-us.html
Открываем блог мы трансляцией с конференции EUROSTAR 2011, будем рассказывать о том, что здесь происходит, какие мысли и инсайты у нас возникают и знакомиться с миром европейского коммьюнити тестирования.
Первый пост про вчерашнюю 8-часовую сессию Майкла Болтона: вот он.
Пост про выступление Дороти Грэхем: вот
Фотопост с доклада Гойко Адзика: вот
Читать далее...
понедельник, 1 августа 2011 г.
Нужен младший волшебник по тестированию веб-приложений
Привет!
Я ищу коллегу в команду веб-тестирования: молодого специалиста по ручному тестированию.
UPD: специалист найден!
Мы работаем над самыми разными проектами:
- личный кабинет пользователя Фогейм, где самое важное – это удобство и логичность сценариев пользователей;
- система биллинга (связанная с платежными шлюзами, системами рассылок SMS и mail-нотификаций), в которой сейчас более 10 млн зарегистрированных пользователей (из них более 3 млн активных), которая позволяет держать более чем 100 000 «одновременных» коннектов, где самое важное – надежность и производительность;
- внутренние проекты, которыми пользуются сотрудники различных отделов в работе;
- интеграционные проекты, которые с одной стороны являются красивой витриной для пользователей, а с другой – имеют сложную систему интеграции с игровой и биллинговыми базами;
- бесчисленное количество промо-страниц, где самое важное - это корректное отображение в различных браузерах;
В нашем тестировании несколько направлений:
- автоматизированное тестирование бэкендов (собственный фреймворк на языке Java)
- ручное тестирование (используем Mind Map для фиксации тестов)
- автоматизированное тестирование интерфейсов (Selenium + Java)
Важно: у нас нет выделенной должности тест-дизайнера, каждый сотрудник в его роли проектирует свои тесты. Мы синхронизируем их на уровне планирования и на этапе финализации.
Профиль нашего будущего коллеги:
Молодой человек (или девушка, как подсказывают мне через плечо разработчики :)) с недолгим опытом работы в тестировании. Горящий, верящий в то, что тестирование влияет на качество, которого заводит видеть, как люди пользуются его продуктами. Который считает тестируемый продукт своим и лично заинтересован в его развитии и улучшении.
Если более формально, то:
- опыт тестирования 0.5 – 1.5 года;
- опыт написания тестов (можно небольшой);
- понимание принципов тестирования (не назубок рассказывать определения, а понимать, что, где и зачем применяется);
- понимание устройства веб-приложений;
- хороший вкус к программным продуктам: быть пользователем многих сервисов, понимать как пользователь их плюсы и минусы, уметь анализировать причины такой реализации;
- неуемное желание развиваться и учиться;
- уметь обосновывать свои мысли и доказывать свою правоту.
Очень хорошо, если на текущем месте работы вам некуда расти – приходите к нам, у нас есть куда!
Мы готовы помочь вам из "ручного" тестировщика стать тест-дизайнером, тест-аналитиком и специалистом по автоматизированному тестированию в одном лице, если захотите.
Самое крутое, на мой взгляд, в работе у нас – это получение мгновенного фидбека от внедрения изменения в продукт: как по отзывам пользователей, так и по отзывам службы поддержки, по мнению проектных команд и даже по изменению в профите проектов.
Тестировщики принимают участие в обсуждениях новых фич, планировании работ, демо-показах.
Мы с удовольствием поощряем желание учиться: конференции, тренинги, книги, локальные обсуждения и семинары.
Добро пожаловать!
Принимаю резюме на yulia DOT nechayeva AT inn DOT ru
Читать далее...
Я ищу коллегу в команду веб-тестирования: молодого специалиста по ручному тестированию.
UPD: специалист найден!
Мы работаем над самыми разными проектами:
- личный кабинет пользователя Фогейм, где самое важное – это удобство и логичность сценариев пользователей;
- система биллинга (связанная с платежными шлюзами, системами рассылок SMS и mail-нотификаций), в которой сейчас более 10 млн зарегистрированных пользователей (из них более 3 млн активных), которая позволяет держать более чем 100 000 «одновременных» коннектов, где самое важное – надежность и производительность;
- внутренние проекты, которыми пользуются сотрудники различных отделов в работе;
- интеграционные проекты, которые с одной стороны являются красивой витриной для пользователей, а с другой – имеют сложную систему интеграции с игровой и биллинговыми базами;
- бесчисленное количество промо-страниц, где самое важное - это корректное отображение в различных браузерах;
В нашем тестировании несколько направлений:
- автоматизированное тестирование бэкендов (собственный фреймворк на языке Java)
- ручное тестирование (используем Mind Map для фиксации тестов)
- автоматизированное тестирование интерфейсов (Selenium + Java)
Важно: у нас нет выделенной должности тест-дизайнера, каждый сотрудник в его роли проектирует свои тесты. Мы синхронизируем их на уровне планирования и на этапе финализации.
Профиль нашего будущего коллеги:
Молодой человек (или девушка, как подсказывают мне через плечо разработчики :)) с недолгим опытом работы в тестировании. Горящий, верящий в то, что тестирование влияет на качество, которого заводит видеть, как люди пользуются его продуктами. Который считает тестируемый продукт своим и лично заинтересован в его развитии и улучшении.
Если более формально, то:
- опыт тестирования 0.5 – 1.5 года;
- опыт написания тестов (можно небольшой);
- понимание принципов тестирования (не назубок рассказывать определения, а понимать, что, где и зачем применяется);
- понимание устройства веб-приложений;
- хороший вкус к программным продуктам: быть пользователем многих сервисов, понимать как пользователь их плюсы и минусы, уметь анализировать причины такой реализации;
- неуемное желание развиваться и учиться;
- уметь обосновывать свои мысли и доказывать свою правоту.
Очень хорошо, если на текущем месте работы вам некуда расти – приходите к нам, у нас есть куда!
Мы готовы помочь вам из "ручного" тестировщика стать тест-дизайнером, тест-аналитиком и специалистом по автоматизированному тестированию в одном лице, если захотите.
Самое крутое, на мой взгляд, в работе у нас – это получение мгновенного фидбека от внедрения изменения в продукт: как по отзывам пользователей, так и по отзывам службы поддержки, по мнению проектных команд и даже по изменению в профите проектов.
Тестировщики принимают участие в обсуждениях новых фич, планировании работ, демо-показах.
Мы с удовольствием поощряем желание учиться: конференции, тренинги, книги, локальные обсуждения и семинары.
Добро пожаловать!
Принимаю резюме на yulia DOT nechayeva AT inn DOT ru
Читать далее...
вторник, 8 марта 2011 г.
как Тестированию не задерживать Разработку: часть 2
Часть 1: Постановка задачи и метод решения.
Часть 2: Обоснование. Немного про Lean. Ограничения подхода.
Часть 3: Практический пример.
Спасибо Максу Дорофееву за вдохновение.
Он писал про то, как сервисному отделу можно приблизить срок выпуска задачи. Мой рассказ получается про следующий уровень вложенности. Макс не говорит про тестирование отдельно, потому что у него тестирование внутри команды, и он работает на ускорение всего процесса.
В нашем случае на ускорение всего процесса работают другие люди, чаще всего это менеджер. Отдел тестирования вносит свою лепту тем, что оптимизирует свои процессы для того, чтобы сократить время жизни задачи на тестирование и минимизировать время ожидания задачи в очереди.
Есть известная картинка, которая показывает нам, что выгоднее заниматься задачами последовательно, нежели параллельно, так как в первом случае момент завершения первых двух задач наступает намного раньше.
Теперь представим, что каждая из задач не самодостаточна, и для того, чтобы она получила бизнес-ценность (её можно было продать, ей можно было пользоваться), нужна ещё одна активность других людей.
А теперь представим, что вторая активность не обязательно может быть начата после завершения первой задачи, а уже после выполнения небольшого её участка. Если это учитывать, то можно значительно сократить общее время жизни задачи и приблизить момент её завершения.
Теперь посмотрим на сервисный отдел тестирования. Ему поступают одновременно три задачи от разных заказчиков на тестирование.
Задача на тестирование, как мы помним, не самодостаточна, и зависит от старшей задачи. Более того, есть несколько циклов тест-фикс-ретест.
Если отдел тестирования принимается за 3 задачи последовательно и доводит каждую из них до конца, то мы получаем вот такую картинку:
Красный, зеленый и синий – это задачи на тестирование, розовый, салатовый и голубой – это исправление багов по результатам тестирования. Последний ретест самый маленький и является финальным тестированием перед выпуском задачи.
Но здесь как раз тот случай, в котором исправление багов не обязательно может начаться после завершения всего тестирования задачи. Мы же помним, что тестировщики придерживаются правил 1-5, и первым делом бьют в самые приоритетные области.
Давайте посмотрим, что будет, если тестировщики будут давать фидбек после выполнения первоприоритетных тестов, и заказчики тут же будут приступать к фиксу:
Нам удалось приблизить момент выпуска задачи, нам удалось сократить время жизни задачи на тестирование, нам удалось сократить временные лаги на ожидание заказчиком результатов.
А если мы можем выпустить задачу ДО завершения финального цикла (с известными минорными багами), то посмотрите, насколько раньше это можно сделать!
Теперь вспомним, что перед тестированием была собственно реализация задачи заказчиком, и посмотрим на картинку:
Видим, что от времени жизни задачи на тестирование зависит время жизни всей задачи.
И в такой схеме легко находится Полезное-потом время.
То есть, максимально сокращая ожидание заказчиком результатов тестирования и сокращая срок жизни задачи на тестирование, мы таким образом приближаем момент выпуска задачи в релиз. Чем непосредственно влияем на бизнес-ценность этой задачи.
Если говорить терминами Lean, то тестирование, будучи сервисом, может работать на сокращение сроков выпуска продуктов путем уменьшения потери времени из-за ожидания.
И – что очень важно – такая система позволяет сотрудникам отдела принимать решения: какую задачу взять первой, на каком этапе пора давать фидбек заказчику, какие задачи брать из пула внутренних задач. Они составляют пул внутренних задач, потому что постоянно анализируют свою работу на эффективность. Они придумывают полезные штуки, потому что это интересно и полезно. Они развиваются и от этого тестирование становится более эффективным.
Такой подход уменьшает потери из-за нереализованного творческого потенциала сотрудников, что опять же увеличивает ценность конечного продукта.
Обязательные условия для того, чтобы это работало:
- опытные высококвалифицированные специалисты в отделе тестирования
--- новички не смогут сразу принимать решения, оценивать приоритеты и проводить исследовательское тестирование
- хорошие коммуникации с заказчиками (как рабочие, так и личные)
--- нужно вырабатывать общие подходы с каждым заказчиком, договариваться о способах постановки задачи, о способе репорта о багах, о том, как действовать, если задача сверхсрочная
- небольшое количество людей и небольшой поток задач (в единицах)
--- я не уверена, будет ли это работать на отделе в десятки человек и входящем потоке десятки задач в день
- небольшое количество итераций тест-ретест
--- если оно большое, то получаем дополнительные лаги на переключение, чем, скорее всего, затрём выигрыш по времени за счет раннего фидбека
Продолжение следует...
Читать далее...
Часть 2: Обоснование. Немного про Lean. Ограничения подхода.
Часть 3: Практический пример.
Спасибо Максу Дорофееву за вдохновение.
Он писал про то, как сервисному отделу можно приблизить срок выпуска задачи. Мой рассказ получается про следующий уровень вложенности. Макс не говорит про тестирование отдельно, потому что у него тестирование внутри команды, и он работает на ускорение всего процесса.
В нашем случае на ускорение всего процесса работают другие люди, чаще всего это менеджер. Отдел тестирования вносит свою лепту тем, что оптимизирует свои процессы для того, чтобы сократить время жизни задачи на тестирование и минимизировать время ожидания задачи в очереди.
Есть известная картинка, которая показывает нам, что выгоднее заниматься задачами последовательно, нежели параллельно, так как в первом случае момент завершения первых двух задач наступает намного раньше.
Теперь представим, что каждая из задач не самодостаточна, и для того, чтобы она получила бизнес-ценность (её можно было продать, ей можно было пользоваться), нужна ещё одна активность других людей.
А теперь представим, что вторая активность не обязательно может быть начата после завершения первой задачи, а уже после выполнения небольшого её участка. Если это учитывать, то можно значительно сократить общее время жизни задачи и приблизить момент её завершения.
Теперь посмотрим на сервисный отдел тестирования. Ему поступают одновременно три задачи от разных заказчиков на тестирование.
Конечно же, в реальной жизни отдел тестирования умеет браться за несколько задач одновременно в силу распределенности умений сотрудников. Но мы же рассуждаем об абстрактном.
Задача на тестирование, как мы помним, не самодостаточна, и зависит от старшей задачи. Более того, есть несколько циклов тест-фикс-ретест.
Если отдел тестирования принимается за 3 задачи последовательно и доводит каждую из них до конца, то мы получаем вот такую картинку:
Красный, зеленый и синий – это задачи на тестирование, розовый, салатовый и голубой – это исправление багов по результатам тестирования. Последний ретест самый маленький и является финальным тестированием перед выпуском задачи.
Но здесь как раз тот случай, в котором исправление багов не обязательно может начаться после завершения всего тестирования задачи. Мы же помним, что тестировщики придерживаются правил 1-5, и первым делом бьют в самые приоритетные области.
Давайте посмотрим, что будет, если тестировщики будут давать фидбек после выполнения первоприоритетных тестов, и заказчики тут же будут приступать к фиксу:
Нам удалось приблизить момент выпуска задачи, нам удалось сократить время жизни задачи на тестирование, нам удалось сократить временные лаги на ожидание заказчиком результатов.
А если мы можем выпустить задачу ДО завершения финального цикла (с известными минорными багами), то посмотрите, насколько раньше это можно сделать!
Теперь вспомним, что перед тестированием была собственно реализация задачи заказчиком, и посмотрим на картинку:
Видим, что от времени жизни задачи на тестирование зависит время жизни всей задачи.
И в такой схеме легко находится Полезное-потом время.
То есть, максимально сокращая ожидание заказчиком результатов тестирования и сокращая срок жизни задачи на тестирование, мы таким образом приближаем момент выпуска задачи в релиз. Чем непосредственно влияем на бизнес-ценность этой задачи.
Если говорить терминами Lean, то тестирование, будучи сервисом, может работать на сокращение сроков выпуска продуктов путем уменьшения потери времени из-за ожидания.
И – что очень важно – такая система позволяет сотрудникам отдела принимать решения: какую задачу взять первой, на каком этапе пора давать фидбек заказчику, какие задачи брать из пула внутренних задач. Они составляют пул внутренних задач, потому что постоянно анализируют свою работу на эффективность. Они придумывают полезные штуки, потому что это интересно и полезно. Они развиваются и от этого тестирование становится более эффективным.
Такой подход уменьшает потери из-за нереализованного творческого потенциала сотрудников, что опять же увеличивает ценность конечного продукта.
Обязательные условия для того, чтобы это работало:
- опытные высококвалифицированные специалисты в отделе тестирования
--- новички не смогут сразу принимать решения, оценивать приоритеты и проводить исследовательское тестирование
- хорошие коммуникации с заказчиками (как рабочие, так и личные)
--- нужно вырабатывать общие подходы с каждым заказчиком, договариваться о способах постановки задачи, о способе репорта о багах, о том, как действовать, если задача сверхсрочная
- небольшое количество людей и небольшой поток задач (в единицах)
--- я не уверена, будет ли это работать на отделе в десятки человек и входящем потоке десятки задач в день
- небольшое количество итераций тест-ретест
--- если оно большое, то получаем дополнительные лаги на переключение, чем, скорее всего, затрём выигрыш по времени за счет раннего фидбека
Продолжение следует...
Читать далее...
как Тестированию не задерживать Разработку. часть 1
На конференции Agile Days рассказывала про то, как сервисному отделу не стать бутылочным горлышком на примере отдела тестирования.
Презентация вот:
Видео будет чуть позже.
В дополнение пишу посты, поясняющие мой подход к организации работы отдела тестирования.
Часть 1: Постановка задачи и метод решения.
Часть 2: Обоснование. Немного про Lean. Ограничения подхода.
Часть 3: Практический пример.
Постановка задачи и метод решения.
Начну с правды: Тестирование не самодостаточно.
Тестирование само по себе не несет для продукта никакой бизнес-ценности. (Я здесь не говорю про компании-аутсорсеры, которые этим зарабатывают, я имею ввиду тестирование в процессе разработки продукта).
Задача на тестирование – это всегда часть старшей задачи: задачи на разработку, задачи, на верстку, на архитектурное решение, на текст, на сценарий, на идею, в конце концов.
И бизнес-ценность для продукта имеет именно та, старшая задача.
Понятно, что методы и подходы к тестированию зависят от старшей задачи. И – что самое важное – процессы. Процессы тестирования зависят от процессов, по которым выполняется старшая задача.
Согласитесь, было бы странно, если бы команда разработки работала по скраму с итерацией в неделю, и, отдавая задачу на тестирование, слышала бы оценку на тестирование каждой фичи в 3 дня, в которую входит написание тест-плана, сценариев, отчетов, и т.д. Аналогично в потоковом производстве задач тестирование, которое планирует на месяц вперед, явно не приведет в восторг заказчика.
Если тестирование неотрывно от выполнения старшей задачи (как это происходит в большинстве скрам-команд), то проблемы здесь намного меньше: задача просто попадает в состояние ТЕСТИРОВАТЬ, возможно, тем же человеком, который делал старшую.
Но что, если тестирование – это сервисное подразделение в компании? Которое работает на несколько команд.
Очевидно, что сервис должен быть хорошим, иначе им просто не будут пользоваться.
Сервис должен стремиться выполнить задачи всех заказчиков соответственно их требованиям. Плюс у отдела есть общие по компании требования к выпускаемому продукту, и даже если заказчик говорит, что «да IE сейчас никто не пользуется», тестировать в нем все равно нужно.
У отдела тестирования много заказчиков, у каждого свои задачи, к которым нужны разные подходы, на их тестирование нужно разное время, у них разное первоначальное качество, у них разное качество исправления ошибок (следовательно, разное количество итераций тест-ретест). У каждого заказчика свои процессы и планы: одни выдают по 3 фичи в день на тестирование, другие – один дизайн в неделю, третьи фиксят по 10 багов в день. Всплески активности у них тоже разные, у одних зависят от маркетинговых акций, у других – от релизов, у третьих – от сроков запуска новых проектов.
Если мы говорим о задачах на тестирование длиной менее одного дня каждая, то планирование здесь практически невозможно. Я не верю в выполнение тремя заказчиками плана по постановке задачи на тестирование с точностью до часа. Если вы запланировали, что одна задача придет к вам в 11 часов, другая в 15 и третья в 17, то будьте уверены, что они все придут к вам в 17-30 =)
Время, которое старшая задача проводит в тестировании, можно условно разделить на три вида:
Полезное-сейчас время – это время, когда задачу непосредственно тестируют: выполняют тестовые сценарии, гоняют тесты. Сюда же отнесем время на оформление баг-репортов, потому что этот продукт потребляет наш заказчик.
Полезное-потом время – это время на подготовку тестирования: настройка тестовой среды, тест-планы, написание тестов, сбор и анализ метрик, анализ результатов тестирования, составление отчетов, актуализация тестов. Это то, что помогает тестированию оптимизировать работу, делать её более эффективной, и давать более полную оценку качеству продукта.
Бесполезное время – это время, когда задача в тестирование передана, но в тестировании не находится. Она ждет в очереди. Либо сейчас тестировщики заняты другой задачей, либо они не успели подготовить все к началу выполнения.
Понятно, что одно и то же время может быть одновременно Бесполезным для заказчика и Полезным-потом для тестирования.
И в целях уменьшения времени на выполнение старшей задачи, очень важно оптимизировать время на тестирование. Ключевой момент – старшая задача должно КАК МОЖНО МЕНЬШЕ ждать, пока задача вернется с тестирования. При этом экономия времени не должна влиять на качество работы тестирования.
Задача тестирования - максимально эффективно тратить Полезное-сейчас время, максимально сокращать для заказчика Бесполезное время и сделать невидимым Полезное-потом время.
Хороший сервис тестирования должен работать по трем основным принципам:
- как можно быстрее приступать к задаче (минимизировать Бесполезное время)
- как можно быстрее давать первый фидбек (оптимизировать Полезное время)
- как можно быстрее давать оценку качеству (помогать заказчику спланировать и скорректировать время на багфиксы)
Чтобы этого добиться, есть несколько инструментов:
1) максимально мелкие задачи на тестирование
Нужно приучать заказчика к постановке промежуточных задач на тестирование, и найти баланс между тестированием каждого тега, и тестирование целых модулей. Это помогает практически в любой момент времени быть готовыми взяться за новую задачу.
2) правильно расставлять приоритеты в тестировании
-- «Первым бей, где больно»: по тяжести возможных найденных ошибок.
У тестировщиков есть опыт работы в проекте, они знают, какие места наиболее уязвимы, они знают, какой разработчик чище пишет код. Они, используя практики тест-дизайна, могут составить тесты таким образом, чтобы наиболее критичные ошибки с большой вероятностью были найдены первыми
-- «Первым выталкивай, что долго»: по длине цикла исправления возможных найденных ошибок.
Тестировщики знакомы с процессами заказчиков тестирования. И знают, что, например, ошибка сценарного характера исправляется дольше, так как возможно требует обсуждений, а то и исследований. А вот ошибка в коде исправляется в течении часа, или дня. Или, например, знают, что верстальщик послезавтра уходит в отпуск, и поэтому нужно все его баги найти и оформить сегодня, а завтра провести ещё один цикл тестирования.
3) практики тест-дизайна
Для того, чтобы разбивать задачу тестирования на подзадачи и выполнять их в соответствии с приоритетами, можно использовать такие практики тест-дизайна, как составление и группировка тестов:
-- по глубине тестирования (например: смоук, акцептенс, функциональные)
-- по объектам тестирования (например: дизайн – верстка – функциональность фронт-энда – функциональность бек-энда)
-- по сценариям тестирования (позитивные-негативные)
-- по эмулируемым пользователям ( наиболее распространенное поведение, более редкое, практически невозможное)
3) разумно подбирать момент оформления багов
-- Сразу же после каждого найденного бага (оправдано, если тесты маленькие, не требуют подготовки к каждому из них и легко прерываемы, плюс время на оформление бага тоже мало).
-- Сразу же после завершения тестирования подзадачи (логически завершенный участок работы тестировщика).
4) давать предварительную оценку качеству
Работая не первый день над проектом, тестировщик всегда может оценить в сравнении качество реализации текущей задачи заказчиком от других. Это можно делать на основании метрик, например, «количество багов, найденных в результате прогона тестов приоритета 1» , или «количество багов на единицу системы (сценарий, страница, таблица)».
5) кроссфункциональность сотрудников
В идеале, все сотрудники отдела тестирования должны уметь выполнять все задачи с одинаково высокой эффективностью. Но так не бывает. У разных людей разные таланты, разные способности, они наиболее эффективны в разных областях.
Но, если каждую задачу на тестирование могут выполнить несколько человек, и если люди не закреплены за направлениями, то это дает большую гибкость и позволяет выдерживать всплески активностей по определенному типу задач.
Например, не все ребята должны постоянно заниматься ручным тестированием интерфейсов. Но если все это делать умеют, то отдел легко выдержит предновогоднюю активность по промо-сайтам и страницам, и не подведет маркетологов.
6) исследовательское тестирование
Гениальный подход, философия тестирования, позволяющая опытным тестировщикам максимально быстро приступать к тестированию и максимально быстро давать первый фидбек. Для этого нужно всего-то ничего: опытный высококвалифицированный специалист, грамотный тест-дизайнер и тестировщик в одном лице.
Ну и плюс некоторые практики:
- сессионность
-- сессия 1: тестирование + оформление багов
-- сессия 2: запись выполненных тестов
-- сессия 3: анализ выполненных тестов, расширение, приоритизация
-- сессия 4: выполнение расширенного набора тестов
- парное тестирование:
-- пилот выполняет тесты
-- штурман подсказывает и записывает
7) Полезное-потом время должно быть обязательно!
Его нужно тратить на Полезные-потом вещи. Это те внутренние задачи отдела тестирования, которые позволяют тестировщикам тестировать эффективно. Это составление планов тестирования, это составление сценариев тестирования, их анализ и приоретизация, это поддержание тестовой среды в актуальном состоянии, это анализ и постоянный апдейт тестов, это разработка и постоянная актуализация фреймворка для тестирования, это изучение новых подходов и методик, это поиск лучших путей для решения задач, это чтение книг и шаринг знаний с коллегами, это ведение базы знаний, это сбор метрик и их анализ...
Если в отделе тестирования этого не делается, значит тестирование работает как загнанная лошадь, на постоянном потоке, без остановки. И обязательно придет момент, когда отдел не справится с задачей вовремя, а то и вовсе не справится, потому что не готов. Потому что нет подходов, нет инструментов. Потому что уже нет мотивации разбираться. Загнали.
Так как задачи из серии Полезное-потом не несут непосредственной ценности для заказчика тестирования, но правильно будет сделать так, чтобы они его не задерживали. Для этого можно пойти двумя путями:
-- Проанализировать загрузку задачами по времени и найти интервалы, когда она меньше всего. Например, первую неделю каждого месяца, когда итерации по проектам только стартуют. В это время нужно планировать выполнение внутренних задач.
-- Жестко запланировать время, например: каждую пятницу с 15-00 отдел тестирования задачи у заказчиков не принимает, а занимается внутренними. Если этого правила придерживаться очень жестко, то все привыкнут и будут планировать свои задачи так, чтобы отдавать их на тестирование до пятничного утра.
продолжение следует...
Читать далее...
Презентация вот:
Agile Days on Prezi
Видео будет чуть позже.
В дополнение пишу посты, поясняющие мой подход к организации работы отдела тестирования.
Часть 1: Постановка задачи и метод решения.
Часть 2: Обоснование. Немного про Lean. Ограничения подхода.
Часть 3: Практический пример.
Постановка задачи и метод решения.
Начну с правды: Тестирование не самодостаточно.
Тестирование само по себе не несет для продукта никакой бизнес-ценности. (Я здесь не говорю про компании-аутсорсеры, которые этим зарабатывают, я имею ввиду тестирование в процессе разработки продукта).
Задача на тестирование – это всегда часть старшей задачи: задачи на разработку, задачи, на верстку, на архитектурное решение, на текст, на сценарий, на идею, в конце концов.
И бизнес-ценность для продукта имеет именно та, старшая задача.
Для простоты назовем команду, выполняющую старшую задачу, заказчиком тестирования.
Понятно, что методы и подходы к тестированию зависят от старшей задачи. И – что самое важное – процессы. Процессы тестирования зависят от процессов, по которым выполняется старшая задача.
Согласитесь, было бы странно, если бы команда разработки работала по скраму с итерацией в неделю, и, отдавая задачу на тестирование, слышала бы оценку на тестирование каждой фичи в 3 дня, в которую входит написание тест-плана, сценариев, отчетов, и т.д. Аналогично в потоковом производстве задач тестирование, которое планирует на месяц вперед, явно не приведет в восторг заказчика.
Если тестирование неотрывно от выполнения старшей задачи (как это происходит в большинстве скрам-команд), то проблемы здесь намного меньше: задача просто попадает в состояние ТЕСТИРОВАТЬ, возможно, тем же человеком, который делал старшую.
Но что, если тестирование – это сервисное подразделение в компании? Которое работает на несколько команд.
Очевидно, что сервис должен быть хорошим, иначе им просто не будут пользоваться.
Сервис должен стремиться выполнить задачи всех заказчиков соответственно их требованиям. Плюс у отдела есть общие по компании требования к выпускаемому продукту, и даже если заказчик говорит, что «да IE сейчас никто не пользуется», тестировать в нем все равно нужно.
У отдела тестирования много заказчиков, у каждого свои задачи, к которым нужны разные подходы, на их тестирование нужно разное время, у них разное первоначальное качество, у них разное качество исправления ошибок (следовательно, разное количество итераций тест-ретест). У каждого заказчика свои процессы и планы: одни выдают по 3 фичи в день на тестирование, другие – один дизайн в неделю, третьи фиксят по 10 багов в день. Всплески активности у них тоже разные, у одних зависят от маркетинговых акций, у других – от релизов, у третьих – от сроков запуска новых проектов.
Если мы говорим о задачах на тестирование длиной менее одного дня каждая, то планирование здесь практически невозможно. Я не верю в выполнение тремя заказчиками плана по постановке задачи на тестирование с точностью до часа. Если вы запланировали, что одна задача придет к вам в 11 часов, другая в 15 и третья в 17, то будьте уверены, что они все придут к вам в 17-30 =)
Время, которое старшая задача проводит в тестировании, можно условно разделить на три вида:
Полезное-сейчас время – это время, когда задачу непосредственно тестируют: выполняют тестовые сценарии, гоняют тесты. Сюда же отнесем время на оформление баг-репортов, потому что этот продукт потребляет наш заказчик.
Полезное-потом время – это время на подготовку тестирования: настройка тестовой среды, тест-планы, написание тестов, сбор и анализ метрик, анализ результатов тестирования, составление отчетов, актуализация тестов. Это то, что помогает тестированию оптимизировать работу, делать её более эффективной, и давать более полную оценку качеству продукта.
Бесполезное время – это время, когда задача в тестирование передана, но в тестировании не находится. Она ждет в очереди. Либо сейчас тестировщики заняты другой задачей, либо они не успели подготовить все к началу выполнения.
Понятно, что одно и то же время может быть одновременно Бесполезным для заказчика и Полезным-потом для тестирования.
И в целях уменьшения времени на выполнение старшей задачи, очень важно оптимизировать время на тестирование. Ключевой момент – старшая задача должно КАК МОЖНО МЕНЬШЕ ждать, пока задача вернется с тестирования. При этом экономия времени не должна влиять на качество работы тестирования.
Задача тестирования - максимально эффективно тратить Полезное-сейчас время, максимально сокращать для заказчика Бесполезное время и сделать невидимым Полезное-потом время.
Хороший сервис тестирования должен работать по трем основным принципам:
- как можно быстрее приступать к задаче (минимизировать Бесполезное время)
- как можно быстрее давать первый фидбек (оптимизировать Полезное время)
- как можно быстрее давать оценку качеству (помогать заказчику спланировать и скорректировать время на багфиксы)
Чтобы этого добиться, есть несколько инструментов:
1) максимально мелкие задачи на тестирование
Нужно приучать заказчика к постановке промежуточных задач на тестирование, и найти баланс между тестированием каждого тега, и тестирование целых модулей. Это помогает практически в любой момент времени быть готовыми взяться за новую задачу.
2) правильно расставлять приоритеты в тестировании
-- «Первым бей, где больно»: по тяжести возможных найденных ошибок.
У тестировщиков есть опыт работы в проекте, они знают, какие места наиболее уязвимы, они знают, какой разработчик чище пишет код. Они, используя практики тест-дизайна, могут составить тесты таким образом, чтобы наиболее критичные ошибки с большой вероятностью были найдены первыми
-- «Первым выталкивай, что долго»: по длине цикла исправления возможных найденных ошибок.
Тестировщики знакомы с процессами заказчиков тестирования. И знают, что, например, ошибка сценарного характера исправляется дольше, так как возможно требует обсуждений, а то и исследований. А вот ошибка в коде исправляется в течении часа, или дня. Или, например, знают, что верстальщик послезавтра уходит в отпуск, и поэтому нужно все его баги найти и оформить сегодня, а завтра провести ещё один цикл тестирования.
3) практики тест-дизайна
Для того, чтобы разбивать задачу тестирования на подзадачи и выполнять их в соответствии с приоритетами, можно использовать такие практики тест-дизайна, как составление и группировка тестов:
-- по глубине тестирования (например: смоук, акцептенс, функциональные)
-- по объектам тестирования (например: дизайн – верстка – функциональность фронт-энда – функциональность бек-энда)
-- по сценариям тестирования (позитивные-негативные)
-- по эмулируемым пользователям ( наиболее распространенное поведение, более редкое, практически невозможное)
И выполнять их нужно, разумеется, соответственно выбранным приоритетам.
3) разумно подбирать момент оформления багов
-- Сразу же после каждого найденного бага (оправдано, если тесты маленькие, не требуют подготовки к каждому из них и легко прерываемы, плюс время на оформление бага тоже мало).
-- Сразу же после завершения тестирования подзадачи (логически завершенный участок работы тестировщика).
Иногда, если баг очевиден, нужно сказать вслух, и пока разработчик его правит – оформить.
4) давать предварительную оценку качеству
Работая не первый день над проектом, тестировщик всегда может оценить в сравнении качество реализации текущей задачи заказчиком от других. Это можно делать на основании метрик, например, «количество багов, найденных в результате прогона тестов приоритета 1» , или «количество багов на единицу системы (сценарий, страница, таблица)».
В большей степени это касается ситуаций, когда качество резко хуже обычного, тогда ранний фидбек даст заказчику возможность скорректировать свои планы и выделить больше времени на исправление, возможно, отложив реализацию новых фич.
5) кроссфункциональность сотрудников
В идеале, все сотрудники отдела тестирования должны уметь выполнять все задачи с одинаково высокой эффективностью. Но так не бывает. У разных людей разные таланты, разные способности, они наиболее эффективны в разных областях.
Но, если каждую задачу на тестирование могут выполнить несколько человек, и если люди не закреплены за направлениями, то это дает большую гибкость и позволяет выдерживать всплески активностей по определенному типу задач.
Например, не все ребята должны постоянно заниматься ручным тестированием интерфейсов. Но если все это делать умеют, то отдел легко выдержит предновогоднюю активность по промо-сайтам и страницам, и не подведет маркетологов.
6) исследовательское тестирование
Гениальный подход, философия тестирования, позволяющая опытным тестировщикам максимально быстро приступать к тестированию и максимально быстро давать первый фидбек. Для этого нужно всего-то ничего: опытный высококвалифицированный специалист, грамотный тест-дизайнер и тестировщик в одном лице.
Умение без специальной подготовки сесть и выполнить задачу на тестирование, использую подходы 1, 2, 3 и 4 – вот, что значит исследовательское тестирование.
Ну и плюс некоторые практики:
- сессионность
-- сессия 1: тестирование + оформление багов
-- сессия 2: запись выполненных тестов
-- сессия 3: анализ выполненных тестов, расширение, приоритизация
-- сессия 4: выполнение расширенного набора тестов
- парное тестирование:
-- пилот выполняет тесты
-- штурман подсказывает и записывает
7) Полезное-потом время должно быть обязательно!
Его нужно тратить на Полезные-потом вещи. Это те внутренние задачи отдела тестирования, которые позволяют тестировщикам тестировать эффективно. Это составление планов тестирования, это составление сценариев тестирования, их анализ и приоретизация, это поддержание тестовой среды в актуальном состоянии, это анализ и постоянный апдейт тестов, это разработка и постоянная актуализация фреймворка для тестирования, это изучение новых подходов и методик, это поиск лучших путей для решения задач, это чтение книг и шаринг знаний с коллегами, это ведение базы знаний, это сбор метрик и их анализ...
Если в отделе тестирования этого не делается, значит тестирование работает как загнанная лошадь, на постоянном потоке, без остановки. И обязательно придет момент, когда отдел не справится с задачей вовремя, а то и вовсе не справится, потому что не готов. Потому что нет подходов, нет инструментов. Потому что уже нет мотивации разбираться. Загнали.
Так как задачи из серии Полезное-потом не несут непосредственной ценности для заказчика тестирования, но правильно будет сделать так, чтобы они его не задерживали. Для этого можно пойти двумя путями:
-- Проанализировать загрузку задачами по времени и найти интервалы, когда она меньше всего. Например, первую неделю каждого месяца, когда итерации по проектам только стартуют. В это время нужно планировать выполнение внутренних задач.
-- Жестко запланировать время, например: каждую пятницу с 15-00 отдел тестирования задачи у заказчиков не принимает, а занимается внутренними. Если этого правила придерживаться очень жестко, то все привыкнут и будут планировать свои задачи так, чтобы отдавать их на тестирование до пятничного утра.
продолжение следует...
Читать далее...
Подписаться на:
Сообщения (Atom)
Сообщения
