Bugsclock

Интересный баг

2011-04-22T11:39:00.001+04:00

Негодующий пользователь считает его блокером и ожидает патча :)

Трудности перевода

2010-10-24T02:51:00.002+04:00

См. строку над общим прогрессом. Что-то похожее ещё встречается у них вроде бы при установке FlashPlayer, про другие продукты не знаю.
Аутсорсятся в Китае?

Легким движением руки глюки превращаются...

2010-10-14T23:45:00.001+04:00

..глюки превращаются...
...превращаются глюки...

Тестировщик:
- В элегантные баги!
Программист:
- В элегантные фичи!

Что такое команда?

2010-07-09T01:31:00.002+04:00

Открытый вопрос. Попробуйте уместиться в 2 предложения.

Вредные советы: Как составить плохое резюме

2010-04-09T01:27:00.000+04:00

У нас в компании недавно была открыта вакансия тестировщика. Мне в очередной раз посчастливилось этим процессом заниматься. Если честно, я сам вызвался, поскольку и опыт есть и, главное, желание. Самое первое, с чем сталкиваешься - это разгребание входящих резюме. Надеюсь, нет смысла объяснять, почему резюме должно быть грамотно составленным, а резюме тестировщика, и вовсе, должно быть безупречным? Начиная с прошлого предложения все написанное считайте сугубо субъективным. Хотя, думаю, многие со мной согласятся. В данной заметке я опишу наиболее распространенные проблемы, которые встречаются в резюме (и не только) и которые могут стать причиной отказа от рассмотрения кандидата. Некоторая информация, на первый взгляд безобидная, может сыграть с вами злую шутку. Надеюсь, эта заметка кому-то поможет в будущем.

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

Прежде чем отправлять кому-то свое резюме, приведите в порядок свои вконтактики, фейсбуки, линкедины, моикруги, одноклассники и где вы там ещё зарегистрированы. Несомненно, это классно, что вам нечего скрывать, но некоторые вещи могут не понравится людям, которые рассматривают ваше резюме. Например, группы, в которых вы состоите или какие-нибудь фотографии, комментарии и т.п. Если вы делаете ваш профиль публичным, то лучше чтобы он был нейтральным, чтобы нельзя было сделать о вас никаких негативных выводов. Вы же не знаете заранее, кто его увидит - религиозный фанатик, алкаш, социофоб или вовсе какой-нибудь эротоман? :)
Адрес электронной почты, с которого вы отсылаете резюме должен быть специально зарегистрирован для этих целей и не должен быть нигде засвечен. Вы удивитесь, что Яндекс или Гугл могут рассказать только по адресу электронной почты.
В строке От Кого в заголовке письма должны стоять ваши фамилия и отчество, а не чужие.
Если вы подготовили документ в Word (или аналоге), проверьте свойства документа (автора), Word обычно запихивает туда имя владельца лицензии и оно потом может вылезти в самых неожиданных местах - при печати документа, при его импорте в систему рецензирования резюме и т.д.
Фотография. Если вы решились вставить фото в ваше резюме, подыщите как можно более нейтральное, очень хорошо подойдет фото на паспорт. И лучше, чтобы оно сразу было черно-белое.
Если у вас есть профили в профессиональных соцсетях (МойКруг, LinkedIn и т.п.), возможно, есть смысл обновить информацию, добавить что-нибудь, что не помещается в рамки резюме, а в самом резюме дать ссылку
Не стоит расписывать опыт работы, который не коррелирует с вакансией. Вряд ли кому-то интересно, как вы продавали дискеты в Компьютерном Мире или меняли картриджи в принтерах. Нет, это совсем не позорно, это просто дополнительная информация, а как известно, дополнительная информация имеет свойство отбирать внимание у основной. Потом вас так и будут вспоминать: "Ну тот, который флаеры раздавал".
Не пишите навыки в разделе опыт работы. Сделайте для навыков (skills) отдельный раздел и там их все соберите. В опыт работы надо писать то, чем вы занимались. Разработка тест-кейсов это навык. Создание и поддержание тестовой документации в актуальном состоянии это опыт работы. Программирование на JavaScript - навык, разработка скриптов для нагрузочного тестирования - опыт. И так далее.
Не копипастайте опыт работы! Зачем вы меняли работу? Из-за денег получается? Фи.
Ожидаемая зарплата. Не думаю, что её стоит писать в резюме. Скудное резюме и скромная сумма могут плохо вас охарактеризовать, что может быть верно и для обратной ситуации.
Хобби, качества, личная информация. Ну если вам действительно хочется этим поделиться, то пишите это в самом конце резюме. Телефона и емейла потенциальному работодателю должно хватить, остальное его не должно касаться. А в описанные вами личные качества сомневаюсь что кто-то поверит.
Не стоит указывать в резюме сертификаты которые никак не пересекаются с вакансией.
Знание MS Office, навыки сборки компьютера, HTML, электронная почта, интернет и т.д. - уберите, не позорьтесь :)
Избегайте использования общих фраз в резюме. Вы же хотите, чтобы ваше резюме выделялось?
Знание английского. Не пишите fluent, если не уверены, особенно если отсылаете резюме на английском. Upper-intermediate это тоже очень хороший уровень.

Краткость - сестра таланта

2010-03-22T18:44:00.005+03:00

Не багохульствуй!

2010-03-18T18:47:00.003+03:00

Внезапно обнаружился целый набор слов, который можно использовать в разговоре с коллегами:
- не багохульствуй
- багоборец
- багодельня
- баголюбец
- баговидец
- багоматерь
- багоненавистник
- багородица
- багопротивный
- багословие
- багослужение
- багоугодное дело, багоугодник
- багоубийство
- багоявление
- ...

По этому поводу появится серия сувениров :)

Сувениры для тестировщиков

2009-12-23T14:24:00.003+03:00

Братья и сестры по разуму! Я тут на досуге реализовал некоторые из своих идей по поводу сувениров для тестировщиков (ну и разработчиков тоже) и разместил их в созданном для этого случая магазине по адресу http://clauster.prostoprint.com/. Многие идеи ещё не реализованы и требуют погружения в азы векторной графики, поэтому следите за обновлениями, новинки будут появляться по мере погружения в эти самые азы. К слову, там много всевозможных видов оплаты, а доставка невозможна разве что в Антарктиду или на остров Пасхи :). Я догадываюсь, что там не все идеально, поэтому всяческая критика приветствуется в комментариях. У кого, как не у тестировщиков попросить критики :)

Больное воображение: Комбобокс в периоде

2009-12-23T14:17:00.002+03:00

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

Больное воображение: Возможен ли реверс инжиниринг "Войны и мира"?

2009-12-18T23:59:00.003+03:00

Коллега на работе поделился интересной ссылкой. Кому неохота читать "слишком многа буков", поясняю: эти страшные люди научились генерировать исполняемый shellcode таким образом, что на выходе в ascii получается чистый английский язык. В конце, там, есть картинки поясняющие. Больное воображение сразу же подсказало use case: сделать reverse engineering, например, "Войны и мира" и потом посмотреть по коду, как там мозг у Толстого работал... (да, я в курсе что "Война и мир" написана на русском и там ещё полкниги по-французски :))

Компромисс 2: Важно не количество ошибок, а их качество

2009-12-12T15:52:00.000+03:00

А вы когда-нибудь дрючили продукт с целью обнаружения как можно большего количества ошибок? И вашему начальнику нравилось, что вы находите столько много ошибок?

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

Познакомлюсь с тестировщиком

2009-11-25T14:16:00.002+03:00

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

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

Зарплата от 50 000 рублей, обсуждается персонально, офис с удобствами на берегу Невы, на Свердловской набережной.
Полный текст вакансии
Если это объявление вас не испугало :), присылайте резюме по адресу hudoborodov at gmail.com и укажите, пожалуйста, в письме, что узнали о вакансии из моего блога.

Мифы и грабли: Цель тестирования - поиск ошибок

2009-10-13T23:38:00.003+04:00

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

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

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

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

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

Мифы и грабли: Ограниченные время и ресурсы - главная причина пропуска дефектов

2009-09-15T00:26:00.002+04:00

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

Мифы и грабли: А ты QA?

2009-09-11T02:19:00.003+04:00

Часто приходится слышать как нас называют QA (куа, куэй и т.п.). Многие даже сами себя так называют, я вроде даже видел футболки с надписью я - QA. А вы задумывались, что QA это не профессия, а название процесса? В каком-то английском блоге, уже не помню где, прочитал что кого-то бесит, когда его называют QA. Но, с оригинальными носителями языка, видимо, сложнее. А как к этому относитесь вы? Лично меня это не особо коробит, но вчера из троллинговых побуждений испытал замечание по данному поводу на разработчике, чем вогнал его в небольшой ступор (результатом удовлетворен). :)

С днем тестировщика!

2009-09-09T12:23:00.002+04:00

Уважаемые читатели!
Поздравляю всех вас с 64-й годовщиной с момента нахождения первого бага :)

Исследовательское тестирование: В поисках музыки исследования ПО

2009-08-26T12:27:00.005+04:00

Предисловие от переводчика.
Как и обещал, выкладываю перевод статьи Jonathan Kohl Exploratory Testing: Finding the Music of Software Investigation, от июля 2007. Статья была переопубликована в декабре 2007 журналом Methods and Tools (HTML-вариант). Джонатан дал свое согласие на публикацию перевода, и ему на самом деле очень лестно думать, что его статья теперь доступна и для неанглоговорящих читателей. Перевод совсем сырой, я его даже не перечитывал полностью, элементарно нет времени с ним возиться, поэтому не обессудьте. Остается добавить лишь то, что exploratory я всегда переводил как исследовательский, а если вы встречаете слова разрешение и напряжение и не можете увязать с контекстом, вернитесь к первому абзацу и постарайтесь понять их абстрактный смысл. Термин эвристика можно также трактовать как некая устоявшаяся практика (на мой взгляд это самое близкое по смыслу), но для context driven testing school этот термин достаточно устоявшийся.

Сама статья...
Мой друг Стив незаурядный игрок на классической гитаре. Наблюдение за его игрой вдохновляющее зрелище - он потратил годы на оттачивание сноровки и исключительно мастерски владеет инструментом. Также, Стив может рассказать о технике своей игры, дать несколько уроков и показать ученикам, как усовершенствовать свои умения. Он может петь под гитару и говорит что музыка это напряжение (tension) и разрешение (resolution, см. пояснения в комментариях). Если вся музыка будет напряженная, слушателю станет не по себе. Если будет только разрешаться - то это скучные, утомительные повторения. Стив расширяет эту идею до фактических физических действий, которые гитарист использует для извлечения определенных звуков. К примеру, если вы играете с большим преобладанием напряжения, вы будете ограничены в возможностях выполнить определенные действия. Чтобы играть музыку, вам необходимо найти баланс между напряжением и разрешением, а, чтобы найти этот баланс, вам необходимо сочетание знаний, навыков и творческого подхода.

Как и Стив, мой друг Джеймс Бах тоже исключительно искусен. Он не гитарист, он тестировщик. Джеймс так же вдохновляет, когда демонстрирует свою технику. Он мастер квалифицированного исследовательского тестирования: одновременного проектирования и выполнения тестов и познания (см. прошлую заметку - прим. пер.). Джеймс также может объяснить используемые им техники тестирования чтобы обучить учеников-тестировщиков. Увидев первый раз как он тестирует софт, я сразу вспомнил Стива. Но в этом случае, напряжение и разрешение не было связано с музыкой или техникой игры на музыкальном инструменте. Вместо этого, напряжение и разрешение вращались вокруг идей. Джеймс одновременно разрабатывал и выполнял тесты, основанные на любознательности по отношению к приложению. Все его тесты обладали обратной связью, посредством которой он получал познания для разработки следующего теста. Напряжение происходило от исследования характера его тестов, а разрешение проявлялось в их результатах. Это была музыка взаимодействи ума тестировщика и тестируемого приложения. И это не было неожиданностью; как тестировщик, Джеймс имеет хорошо развитое сочетание знаний, навыков и творческого подхода.

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

Западная классическая музыка обычно всегда расписана по нотам. Композиции записаны так, что исполнитель может исполнить их голосом либо сыграть на инструменте. Несмотря на детальный, широко распространенный "язык" записи музыки, очень трудно исполнить музыку точно так, как задумал композитор, особенно произведения, которым несколько веков, потому что мы не можем в любой момент получить консультацию композитора. Противоположностью игры по нотам является импровизация - исполнение неожиданной, непредписанной музыки. Между этими двумя стилями существует некоторый отрезок, потому что любое произведение открыто для интерпретации конкретным исполнителем и некоторые исполнители используют эти возможности больше других. Программное обеспечение для написания музыки очень точно повторяет все введенные ноты, но воспроизводимая музыка редко так же приятна слуху как живое исполнение. Музыка, исполняемая программой может быть скучной и утомительной и полна жизни в исполнении музыканта. Но с другой стороны, удачная импровизация требует мастерства и исполнители высокого класса очень широко и глубоко изучают музыкальную теорию и оттачивают технику исполнения на своих инструментах чтобы удачно и творчески импровизировать.
В тестировании, заранее записанные тестовые сценарии также предоставляют возможность их интерпретировать каждым исполнителем по-своему. Автоматизация гарантирует, что эти скрипты будут выполнены так, как записаны, но как и автоматическая музыка, нехватка интерпретации в выполнении может ограничить полученный результат. Машина сможет найти лишь те проблемы, которые мы можем предсказать и запрограммировать. Повторение одних и тех же тестов может стать скучным и нудным, становится "разрешением" идеи, без живого "напряжения" рождаемого любопытством. Но с другой стороны есть импровизационное тестирование: исследовательское. Чистое исследовательское тестирование означает, что мой следующий тест полностью порожден моими текущими идеями без каких-либо заготовок. Чистое сценарное тестирование и чистое сценарное - два берега одной реки.

Эта аналогия музыки и тестирования естественно не совершенна. Музыка пишется для развлекательных целей или как упражнение для других музыкантов. Конечная цель - развлечение слушателей, повышение мастерства, и удовлетворение музыкантов. Тестирование, с другой стороны, проводится не для развлечения, а для получения информации. Как говорит Кем Канер, тестирование это исследовательская деятельность которая предоставляет информацию, связанную с качеством программного обеспечения [2]. Собирая различного рода информацию, мы стремимся иметь возможность к различным интерпретациям и получить способности оценить проблему с разных сторон. В музыке, импровизация может иметь негативный эффект, если используется в неуместном месте или в несоответствующей манере (когда музыкант извлекает неверную ноту, мы замечаем это). В тестировании, исследование и импровизация, даже если выполняются неверно, часто могут привести к замечательным источникам информации. Неуместные импровизации могут быть рискованными при исполнении музыки, но в проектах разработки ПО, случайности или "взятие неверной ноты", может привести к важным открытиям. Кроме того, проекты по разработке ПО стоят лицом перед рисками, и исследовательское тестирование позволяет мгновенно адаптироваться к новым рискам.

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

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

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

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

Заглянув дальше интерфейса пользователя, я обнаружил, что приложение молча сбоило; в то время, как считалось что выполнение транзакции записи в базу данных прошло успешно, на самом деле данные удалялись. Мы каждый раз теряли данный с момента запуска первого теста. Даже если тест казался пройденным, в приложении происходил серьезный сбой. Если бы я прогонял только ручной и авто тесты, проблема оставалась бы незамеченной и привела бы к катастрофическим последствиям при поставке продукта. К тому же, если бы я тратил время, на запись тестов, а затем выполнял их, я бы, скорее всего, упустил возможность, позволившую мне найти источник проблемы. Простое выполнение записанных текстов это всего лишь "разрешение" идеи и не позволяет обнаружить что-либо интересное. С другой стороны, во взаимодействии "разрешения" и "напряжения" идей исследовательского тестирования быстро приводит к важным находкам. Благодаря подобным результатам, я не склонен использовать большое количество методичных, заранее записанных ручных тестов в своей работе.

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

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

Музыканты используют схожие техники, и могут распознать "the circle of fifth" как эвристику которой надо следовать если они заблудились в своей импровизации. (Это вовсе не гарантирует, что эвристика будет работать или нет. Когда эвристика не подходит, вы просто пробуете другую.) Музыканты стремятся иметь большой набор эвристик и в той же мере используют мнемонику. Как пример - "Every Good Boy Does Fine", который используется для запоминания нот "EGBDF" по аналогии с нотным станом. искус6ные тестировщики используют похожий инструментарий для запоминания тестовых идей и техник.

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

Чтобы начать тестирование в таких условиях, я часто использую разработанную мной мнемонику "MUTII" (РПЗИР). (Композитор Nicolo Mutii (Коля Рпзир) помогает мне вспоминать это название.) Эта мнемоника помогает мне сохранять логичность в размышлениях о тестировании. Расшифровка мнемоники:

Market (рынок) - целевая группа пользователей. Например, финансовый отдел или бухгалтерская контора среднего пошиба.

Users (пользователи) - реальные пользователи, которые будут использовать приложение. Кто они? Что делают? Какие у них мотивы использовать наш продукт?

Tasks (задачи) - Для решения каких задач пользователь будет использовать продукт? Какие его типичные рабочие задачи?

Information (информация) - Как продукт расскажет мне о задачах которые он автоматизирует и как я смогу выполнить их?

Implementation (реализация) - Легко ли использовать продукт первый раз? Он надежный? Могу ли я легко выполнить свои задачи с учетом дизайна продукта и предоставляемой им информации.

Перед началом тестирования, я собираю информацию о рынке и целевой аудитории. Это позволяет определить рамки тестов, которые я буду разрабатывать для использования продукта первый раз. Если я плохо знаком с рынком и пользователями, я изучаю типовые задачи, которые приходится выполнять пользователям.

Когда я начинаю тестировать, я раскрываю свой блокнот для записи своих наблюдений и мыслей, а также любых найденных багов (см. рисунок 1). Я начинаю планировать тест в уме, выполнять его в приложении и изучаю результат. Я постоянно повторяю это процесс, изменяя тесты, и оглядываюсь на свою MUTII-мнемонику.

Рисунок 1: Помечай объяснения тестовой сессии.

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

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

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

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

Сссылки:
1. Bach, James. (2003) Exploratory Testing Explained
http://www.satisfice.com/articles/et-article.pdf
2. Kaner, Cem. (2004). The Ongoing Revolution in Software Testing. Presented at Software Test & Performance Conference, December, 2004, Baltimore, MD
http://www.kaner.com/pdfs/TheOngoingRevolution.pdf
3. Bach, James. (1999, November) Heuristic Risk-Based Testing. Software Testing and Quality Engineering Magazine http://www.satisfice.com/articles/hrbt.pdf

Мифы и грабли: Откуда есть пошло Исследовательское Тестирование и причем тут ad hoc

2009-08-19T12:06:00.005+04:00

Вообще, изначально был только ad hoc testing, который считался несистематичным, небрежным, неспланированным и прочее. Но на самом деле, это просто импровизация тестировщика во время тестирования. Потом, где-то в начале 90-х годов прошлого века, собрались товарищи (самый яркий представитель - Канер), которые объявили себя context-driven software testing school, усовершенствовали тот самый ad hoc и чтобы не вводить никого в заблуждение, придумали термин exploratory testing (который упоминается в книге Канера Testing Computer Software), что по сути являлось всего-навсего "умудренным" подходом к ad hoc тестированию. В последующее десятилетие, тремя китами Exploratory Testing - Cem Kaner, James Bach и James Whittaker, были разработаны специальные техники и выделены навыки, которые необходимы для применения Исследовательского Подхода. Ради интереса, можно изучить данный артефакт.

Разница между ad hoc и exploratory testing в том, что теоретически, ad hoc может провести кто угодно, а для проведения exploratory необходимо мастерство и владение определенными техниками. Обратите внимание, что определенные техники это не только техники тестирования. Ну а в настоящее время, на фронтах идут битвы за разделение понимания exploratory и ad hoc.

Написано по памяти из всяких разных источников и интервью Д.Баха, ссылки лень искать

51 основное качество успешного проекта

2009-08-18T17:31:00.004+04:00

У нас в офисе, над кофе-машиной висит бумажка:
Чтобы стать успешным, проект должен сочетать в себе 51 основное качество (переводить не буду):
1. Accessibility
2. Affordability
3. Beauty
4. Build
5. Caching
6. Code Coverage
7. Compatibility
8. Complexity
9. Consistency
10. Credibility
11. Cyclomatic complexity
12. Discoverability
13. Documentation
14. Efficiency
15. Ethics
16. Extensibility
17. Honesty
18. Integration
19. Licensing
20. Logging and instrumentability
21. Maintainability
22. Marketability
23. Memorability
24. Modularity
25. Open-ness
26. Optimisibility
27. Originality
28. Parallelability
29. Performance
30. Platform versatility
31. Popularity
32. Power
33. Practicality
34. Predictability
35. Purity
36. Readability
37. Reliability
38. Remarkability
39. Responsiveness
40. Reusability
41. Robustness
42. Scalability
43. Scriptability (automatability)
44. Security
45. Simplicity
46. Testability
47. Transparency
48. Trustworthiness
49. Usability
50. User eXperience
51. Versatility

Вы можете позволить себе три.
Два из них - безопасность (44 - security) и удобство использования (49 - usability).
Выберите ещё одно.

Источник http://secretgeek.net/core51.asp

Затравка: Исследовательское тестирование: В поисках музыки исследования ПО

2009-08-18T00:55:00.005+04:00

Хочу представить анонс перевода очередной, в этот раз довольно большой, статьи на тему исследовательского тестирования от Jonathan Kohl, которая в оригинале называется "Exploratory Testing: Finding the Music of Software Investigation". Ссылку, как обычно, не даю, а любителям прочитать в оригинале, найти не составит труда. Может быть, среди читателей есть люди, знающие конкретный перевод для музыкальных терминов tension и resolution? Был бы весьма признателен за подсказку. Поскольку сама статья довольно длинная, слишком скоро остальную часть не ждите, надеюсь за неделю справлюсь.

************************************

Мой друг Стив незаурядный игрок на классической гитаре. Наблюдение за его игрой вдохновляющее зрелище - он потратил годы на оттачивание сноровки и исключительно мастерски владеет инструментом. Также, Стив может рассказать о технике своей игры, дать несколько уроков и показать ученикам, как усовершенствовать свои умения. Он может петь под гитару и говорит что музыка это напряженность (tension, кто знает верный перевод , подскажите - прим. пер) и разрешение (resolution, переход в консонанс - прим. пер). Если вся музыка будет напряженная, слушателю станет не по себе. Если будет только разрешаться - то это скучные, утомительные повторения. Стив расширяет эту идею до фактических физических действий, которые гитарист использует для извлечения определенных звуков. К примеру, если вы играете с большим преобладанием напряженности, вы будете ограничены в возможностях выполнить определенные действия. Чтобы играть музыку, вам необходимо найти баланс между напряженностью и разрешением, а, чтобы найти этот баланс, вам необходимо сочетание знаний, навыков и творческого подхода.

Как и Стив, мой друг Джеймс Бах тоже исключительно искусен. Он не гитарист, он тестировщик. Джеймс так же вдохновляет, когда демонстрирует свою технику. Он мастер квалифицированного исследовательского тестирования: одновременного проектирования и выполнения тестов и познания (см. прошлую заметку - прим. пер.). Джеймс также может объяснить используемые им техники тестирования чтобы обучить учеников-тестировщиков. Увидев первый раз как он тестирует софт, я сразу вспомнил Стива. Но в этом случае, напряженность и разрешение не было связано с музыкой или техникой игры на музыкальном инструменте. Вместо этого, напряженность и разрешение вращались вокруг идей. Джеймс одновременно разрабатывал и выполнял тесты, основанные на любознательности по отношению к приложению. Все его тесты обладали обратной связью, посредством которой он получал познания для разработки следующего теста. Напряженность происходила от исследования характера его тестов, а разрешение проявлялось в их результатах. Это была музыка взаимодействи ума тестировщика и тестируемого приложения. И это не было неожиданностью; как тестировщик, Джеймс имеет хорошо развитое сочетание знаний, навыков и творческого подхода.

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

Сссылки

1. Bach, James. (2003) Exploratory Testing Explained
http://www.satisfice.com/articles/et-article.pdf
2. Kaner, Cem. (2004). The Ongoing Revolution in Software Testing. Presented at Software Test & Performance Conference, December, 2004, Baltimore, MD
http://www.kaner.com/pdfs/TheOngoingRevolution.pdf
3. Bach, James. (1999, November) Heuristic Risk-Based Testing. Software Testing and Quality Engineering Magazine http://www.satisfice.com/articles/hrbt.pdf

Exploratory testing: Развитие понимания об исследовательском тестировании. Часть 3

2009-08-13T01:22:00.003+04:00

Часть 1
Часть 2

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

Как обращал наше внимание Jerry Weinberg в своей к ниге Perfect Software And Other Illusions About Testing, много важных тестов проводится без нажатий кнопок на клавиатуре или запуска автотестов. Исследовательский подход может быть применен к любому аспекту процесса разработки, а не только к выполнению тестов (т.е. конфигурация, управление, наблюдение и оценка работающего продукта). Ревью может быть проведено как исследовательским, так и сценарным методом, с учетом того, что рецензент сам определяет что наблюдать. Например, ревью может быть проведено в свободном стиле (в этом случае оно может быть весьма исследовательским); руководствуясь сводом идей, оформленных в виде чек листа (в данном случае подход немного более сценарный и менее исследовательский); или руководствуясь набором строгих условий, таких, как те, что используются статическими анализаторами кода (в этом случае подход будет совершенно сценарный).

Для разработчиков, тестирование (как мы помним "обследование продукта в целях его оценки") является естественным элементом парного программирования, и так как проектирование, исполнение, интерпретация и познание сильно переплетены, парное программирование есть исследовательский процесс. TDD (test-driven development) имеет сильно выраженные исследовательские черты по той же причине. В натуре, Elisabeth Hendrickson цитирует момент прояснения одного программиста: "Я понял! Это же разработка через тестирование! (TDD)". Меня аналогично осенило, когда я понял, что TDD весьма и весьма исследовательский стиль разработки.

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

Источник DevelopSense Blog, автор Michael Bolton

Exploratory testing: Развитие понимания об исследовательском тестировании. Часть 2

2009-08-12T01:47:00.004+04:00

Часть 1

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

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

Для тех, кто неизбежно спросит "Чем отличается исследовательское тестирование от ad hoc тестирования?" я отвечу так, что не смогу провести различия, пока вы не объясните что вы понимаете под "ad hoc". Некоторые полагают, что "ad hoc" является синонимом "небрежный" или "поспешный" (прим. пер. - у нас чаще встречаются "свободный" и "случайный"). Исследовательское тестирование, конечно же, не поспешное и не небрежное (так же, как не случайное и не свободное, прим. пер.). Когда я смотрю в словарь, я вижу, что "ad hoc" буквально значит "к случаю", и в полном понимании "специальный, устроенный для данной цели, для данного случая". Комиссия Роджерс по Челленджеру была ad hoc-комиссией (прим. пер. - чрезвычайной?), созванная для выполнения конкретных целей и распущенная после того, как цели были достигнуты. В этом смысле, ad hoc и exploratory не такие уж и разные. Почти все выполняемое тестирование, исследовательское ли, или сценарное, будет ad hoc (специальное, для данной цели); оно выполняется для обеспечения неких целей и прекращается по мере их достижения. Таким образом, я не могу быть уверенным, что вы подразумеваете под "ad hoc" пока вы мне не скажете. Я даю здесь определение исследовательскому тестированию; вы можете сравнить его со своим представлением об "ad hoc", если хотите.

Часть 3

Exploratory testing: Развитие понимания об исследовательском тестировании. Часть 1.

2009-08-11T01:23:00.005+04:00

Представляю вашему вниманию очередной перевод. На этот раз статья посвящена исследовательскому тестированию (exploratory testing). Тема эта весьма интересная, и, как я вижу, слабо освещенная в нашем русскоязычном сегменте. Поскольку статья немалая, выкладываю пока первую часть, всего планируется три. Отдельное спасибо Алексею Никулину за безвозмездный перевод первого абзаца :) Итак, поехали!

Одним из заметных событий конференции CAST 2008 стал доклад Кема Канера "О пользе чеклистов и опасности сценариев: что предлагает традиционная система обучения тестировщикам". Большую часть доклада заняло сравнение исследовательского и сценарного процессов, в котором Кем противопоставил сценарии - готовые пошаговые инструкции, исполняемые более или менее автоматически - машиной или человеком, заменяющим её, и чеклисты - перечисление особенностей, которые могут быть интересны, и решение об их целесообразности находится во власти человека, пользующегося этим списком. Что по мне, самое ценное в докладе было развитие сюжета о природе исследования и исследовательского тестирования. Итак, по состоянию на 21 сентября 2008 года, моя (как обычно, тесно связанная с Кема и Джеймса Баха) актуальная на данный момент версия сюжета. Еще одна из целей - возможность сослаться на этот пост, чтобы не повторяться на форумах.

По определению Джеймса:

"тестирование - это обследование продукта в целях его оценки".

По Кему, современное исследовательское тестирование это (делаем глубокий вдох:

"стиль тестирования, подразумевающий определенную свободу и ответственность конкретного тестировщика в постоянной оптимизации качества его работы, воспринимающего проектирование, выполнение , оценку результатов тестов и познание (прим. пер. - изучение продукта; накопление опыта; развитие навыков; далее - познание) как взаимодополняющие активности, которые протекают параллельно на протяжении всего проекта".

Это было определение, которое он предложил на симпозиуме Heuristic and Exploratory Techniques в Palm Bay, Флорида, в марте 2006 (в котором James Bach, Jonathan Bach, Scott Barber, Tim Coulter, Rebecca Fiedler, David Gilbert, Marianne Guntow, James Lyndsay, Robert Sabourin, Adam White, Cem и я принимали участие). Короткая версия Джеймса:

"одновременное проектирование, выполнение тестов и познание".

Оба означают одно и то же. Одно более точное, другое краткое по содержанию.

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

Элементы проектирования, выполнения и оценки результатов тестов и познание выполняются одним и тем же лицом

Процессы проектирования, выполнения и оценки результатов тестов и познание протекают вместе, нежели раздельно во времени

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

Все, что познано на данный момент, включая результаты самого последнего теста, определяет какой следующий тест выберет тестировщик

Тестировщик ориентирован на выяснение новой информации, нежели подтверждение имеющейся

В целом, тестировщик предпочитает разнообразить аспекты своих тестов, нежели повторять их, если повторение теста специально не направлено на раскрытие новой информации

Часть 2
Часть 3

Вы считаете себя экспертом в тестировании?

2009-08-09T23:11:00.006+04:00

Тогда проанализируйте следующие утверждения:
1. Я должен составлять тест-план.
2. Важно, чтобы тестирование обладало свойством повторяемости.
3. Каждый тест-кейс должен иметь ожидаемый результат.
4. Автоматизация экономит деньги и время.
5. Все тесты основываются на модели того, что должно быть протестировано.
6. Достаточно хорошее качество (good enough) недостаточно хорошее.
7. Недокументированный тест не может быть улучшен.
8. Лучше использовать термин дефект нежели баг/ошибка.
9. Exploratory testing - полезная практика.
10. Неопределенность и двусмысленность должны быть исключены из требований.

Из доклада J.Bach "Becoming a Software Testing Expert"

Компромисс 1: Цель разработки не ПО без багов, а удовлетворение нужд пользователей.

2009-06-17T12:50:00.004+04:00

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

Итак, компромисс первый: Цель разработки не ПО без багов, а удовлетворение нужд пользователей.

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

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

Мифы и грабли: Пятиминутка ненависти к тестированию

2009-05-16T22:41:00.011+04:00

Например, на собеседовании можно часто услышать вопрос, почему вы стали тестировщиком и что вам нравится в тестировании. Да и вообще, об это частенько любят потрепаться на форумах и в других местах скопления инженеров по тестированию. Это все конечно интересно, но есть же и другая сторона медали. Не знаю как вас, но лично меня некоторые вещи в тестировании периодически расстраивают. Иногда даже наблюдается пар из ушей. Я немного поразмышлял, что же делает несчастным тестировщика и для начала выделил пять пунктов. Если что-то ещё придет на ум, или подскажет кто - опубликую в другой заметке. Вы можете подумать, что я тут поплакаться решил, но не дождетесь :) - это просто издержки в профессии. У всех они свои. Итак, иногда:

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

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

3. Нас учат как правильно тестировать
Чтобы вы сразу поняли, это, к примеру, когда вам какой-нибудь умник начинает менторским тоном рассказывать, как тестировать ну, допустим, граничные значения (а вы это прекрасно знаете). То есть, какие-то азы. Или, бывает, встречаются перцы, которые считают что тестирование это обезьянья работа и я-вам-тут-щас-за-час-все-протестирую. Не спорьте с такими, выслушайте и сделайте, как считаете нужным. А вообще, я никогда не упускаю возможности чему-нибудь незнакомому научиться, и вам советую.

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

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

Tools: www.websequencediagrams.com - создание диаграмм последовательностей

2009-05-04T16:54:00.009+04:00

Удобный и простой Web-сервис для быстрого создания диаграмм различных последовательностей - www.websequencediagrams.com. Вы пишете текст определенного формата, нажимаете Draw и получаете нечто подобное:

Можно очень быстро набросать модель для тестирования, например, инсталлятора.

Tools: Интересный сервис для создания макета интерфейса (mockup)

2009-04-21T19:08:00.004+04:00

Демо-версию посмотреть можно тут: http://www.balsamiq.com/demos/mockups/Mockups.html
Много различных контролок, есть даже для iPhone. Все интуитивно понятно. В-общем, что тут писать, лучше посмотреть.

Tools: Expression Web SuperPreview от Microsoft

2009-04-17T00:44:00.003+04:00

Недавно Microsoft объявила о новом продукте Expression Web SuperPreview , который позволяет через один и тот же интерфейс предпросматривать веб-страницы для любого из браузеров, установленных в системе. Также продукт содержит всяческие полезности, как, например HTML-debugger. Бета-версия уже доступна для скачивания. Однако, в ней пока поддерживается только IE - можно сравнить рендеринг между IE6 и IE7 (или 8). Внутренний билд уже поддерживает Safari и Firefox. Окончательно продукт появится как составная часть MS Expression Web Studio 3, которую обещают релизнуть в конце года.

Мифы и грабли: Что такое программа?

2009-04-09T00:21:00.002+04:00

А давайте-ка заглянем в словари (сами-знаете-на-каком-сайте) и посмотрим что такое программа.

Большая советская энциклопедия

Программа (от греч. programma — объявление, распоряжение, указ), Упорядоченная последовательность действий для ЭВМ, реализующая алгоритм решения некоторой задачи.

Экономико-математический словарь

В кибернетике (главным образом, технической) — основной элемент программного управления, строго определенная последовательность действий, предписанная объекту управления. В частности, машинная П. — алгоритм задачи, записанный таким образом, чтобы ее можно было решить на ЭВМ. Запись ведется на одном из языков программирования как последовательность команд (операторов), указывающих, в каком порядке, с какими данными и какие надо проводить элементарные операции.

ГОСТ 19781-90

Программа - согласно - данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма.

Да уж, как-то суховато и старомодно. В последнее время стало модно в качестве компетентного источника использовать Википедию. Заглянем и туда:

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

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

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

Ура-ура!!! Программы для пользователей называются прикладным программным обеспечением. Идем дальше:

Издательский словарь-справочник

ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ — совокупность программ, управляющих работой компьютера или автоматизированной системы.

Cловарь по естественным наукам. Глоссарий.ру

Программное обеспечение - комплекс программ:
- обеспечивающих обработку или передачу данных;
- предназначенных для многократного использования и применения разными пользователями.

Википедия

К прикладному программному обеспечению (application software) относятся программы, написанные для пользователей или самими пользователями, для задания компьютеру конкретной работы. Программы обработки заказов или создания списков рассылки — пример прикладного программного обеспечения. Программистов, которые пишут прикладное программное обеспечение, называют прикладными программистами.

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

7 навыков высокоэффективных тестировщиков (часть 2)

2009-03-25T01:18:00.005+03:00

Навык 4 - Мыслить Win\Win
Во многих организациях, команды разработчиков и тестировщиков переводят стрелки друг на друга, тем самым создавая напряженность между командами. Это наносит большой вред и существенно влияет на качество. У команд разработчиков и тестировщиков должна быть одна общая цель - обеспечить клиенту поставку продукта высочайшего качества. Если это становится общей целью команды, все начинают помогать и всячески поддерживать друг друга, в результате, когда счастливый клиент получает высококачественный продукт, все в команде счастливы не меньше этого самого клиента. Если вы хотите поспособствовать созданию атмосферы доверия, уважения и развить команду Win\Win, вот несколько советов:

Делитесь знаниями - не скрывайте свои знания от других, делитесь ими.
Общайтесь - обедайте с различными должностными лицами в вашей компании. Узнавайте больше о них,
Поощряйте труд остальных - хвалите и восхищайтесь великолепной работой коллег. Расскажите об этом своему (и их) начальнику. Расскажите им, как вы цените их работу.
Спасайте утопающих - если вы видите что кто-то погряз в работе, предложите ему свою помощь. Если предложили - помогайте и обеспечьте, чтобы коллега действительно получил ту помощь, которая ему необходима.

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

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

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

Об авторе
Стив Миллер является президентом Pragmatic Software. Имея 24 года опыта за спиной, Стив обладает обширными знаниями в областях управления проектами, архитектуры ПО и тест-дизайна. Стив публикует ежемесячный бюллетень для компаний - разработчиков ПО. Вы можете прочесть другие бюллетени по адресу http://www.pragmaticsw.com/Newsletters.asp

7 навыков высокоэффективных тестировщиков (часть 1)

2009-03-20T13:52:00.007+03:00

Отсебятина: Мне показалось занимательной данная статья, поэтому я решил её перевести. Нахрапом взять не удалось, поэтому разбиваю на две части. Возможно, вы не согласитесь с некоторыми утверждениями, но никто не мешает включить мозг и подогнать их под себя. Ссылка на источник будет во второй части. Скоро :)

Опубликованная в 1989 году книга Стивена Кови "7 навыков высокоэффективных людей" помогла миллионам людей повысить свою эффективность как в жизни, так и в работе. В данной статье обсуждаются 7 навыков, характерных для высокоэффективных тестировщиков. Итак, навыки:

Проактивность (упреждение)
Видеть результат работы в её начале
Начинать с самого главного
Мыслить Win\Win
Сначала понять самому, потом искать понимание
Синергизм
Точить пилу

Навык 1 - Проактивность
Цель тестировщика в любом проекте - добиться поставки ПО высокого качества. Когда проекты терпят неудачу из-за их плохого качества, вы либо упреждаете проблемы либо реагируете на последствия после анализа причин. Если вы реагируете, вы будете обвинять в проблемах и препятствиях других людей и обстоятельства. Если вы проактивны, вы берете ответственность на себя и ищете возможность предотвратить такие проблемы в будущем. На завершающей стадии каждого проекта ваша команда проводит "post mortem" или "retrospective" митинги на которых открыто обсуждается что было сделано хорошо а что плохо. Ниже представлены несколько идей, как быть проактивным:

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

Навык 2 - Видеть результат работы в её начале
Конечной целью должна быть поставка высококачественного продукта, отвечающего всем требованиям клиента. До начала кодирования необходимо составить список критериев, который позволит судить об успешности продукта. Например, таким критерием может быть то, что продукт выполняет определенные задачи, не содержит известных дефектов (или небольшое количество малокритичных), хорошо задокументирован, прост в использовании и т.д. Определяя критерии успеха наперед, вы сможете объективно оценить, удовлетворяет ли им ваш продукт или нет. Просите помощи в определении критериев у всех членов команды. Выработанные командой критерии будут лучше и более измеримыми и в итоге вы получите неплохой "прикуп" от своей команды.

Навык 3- Начинать с самого главного
Расстановка приоритетов в работе имеет огромное значение. С начала вы должны прилагать усилия к самым важным вещам, затем менее важным и т.д. Например, все согласны, что негативное тестирование очень важно чтобы гарантировать что продукт правильно отрабатывает сценарии когда пользователь выполняет непредусмотренные действия. Но при сопоставлении его с позитивным тестированием, первое является менее приоритетным. Таким образом, лучше начинать тестирование с проверки соответствия дизайну и прямому назначению и вложиться в это по полной. После этого можно переходить к тестированию негативных сценариев (граничные значения, неверные входные данные, переполнения, инъекции и т.д.).

Мифы и грабли: Цель тестирования в проверке соответствия требованиям

2009-03-13T01:23:00.007+03:00

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

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

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

Итак, вы проверяете соответствует ли ваш продукт требованиям. А задаетесь ли вы при этом такими вопросами:

Возможно ли составить полный список требований?
Если нет, можно ли считать работу выполненной проверив соответствие списку требований?
Надо ли тестировать то, что в требованиях не описано?
Верны ли требования сами по себе?
Я что, долбаный робот? :) и т.д.

Если задаетесь, то вы наверняка принимаете активное участие в формировании требований. А если кто читал "Роман об управлении проектами" Демарко наверняка помнят главу про плохую спецификацию провалившегося проекта (система для аэропорта). Да и вообще, практика подключения тестировщиков к проекту на этапе формирования требований давно себя зарекомендовала с самой лучшей стороны, особенно если вспомнить правило 1-10-100.

Что по поводу качества, мне нравится высказывание Gerald Weinberg: "Quality is value to some person", т.е. у каждого свои представления о качестве. У разработчика. у менеджера, у тестировщика, у пользователя и т.д. Поэтому тестирование осложняется тем, что тестировщикам приходится часто сталкиваться с проблемами, которые влекут за собой конфликт интересов. Тут уже надо включать голову и здравый смысл. Некоторым конечно проще перевести стрелки на менеджера или лицо более ответственное, но грамотный тестировщик обычно всегда в состоянии предложить решение и донести его до заинтересованных сторон (так называемых stakeholders). Потому что у этого тестировщика сформирована общая картина проекта и он понимает что от него хочет каждая из заинтересованных сторон. Кажется, я уже ударился в проповедование context-driven testing. :)

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

10 практик юзабилити

2009-03-04T13:37:00.016+03:00

В свежей заметке на DevelopSense Blog, где Майкл Болтон и Бен Симо совершенно справедливо склоняют глаголы над интерфейсом последней версии Skype, проскакивает несколько, как мне показалось, интересных ссылок. Текст одной из них я сподобился перевести. Многие вещи, несомненно очевидны и стали уже нормой, но пруфлинки и имена дядек на которых можно сослаться, часто бывает полезным аргументом если вы практикуете такую вещь как Bug Advocacy. Также материал может служить неплохим подспорьем для тест-планов по юзабилити. Дисклаймер: я долго сомневался при переводе слова heuristics и решил перевести его как практики. Вы можете понимать как вам удобно или предложить лучший на ваш взгляд вариант.

автор Jakob Nielsen
Оригинал http://www.useit.com/papers/heuristic/heuristic_list.html#

Ниже перечислено 10 основных принципов для проектирования пользовательского интерфейса. Они называются практики потому что они по характеру ближе к практическим методам нежели к каким либо руководствам по юзабилити (guidelines).

Очевидность статуса системы: Система должна постоянно держать пользователя в курсе происходящего путем соответствующих откликов в пределах разумных промежутков времени
Приближенность системы к реальности: Система должна "говорить" на языке пользователя, словами, фразами и понятиями близкими пользователю, а не специализированными системными терминами. Следуйте общим соглашениям, формируя появление информации в естественном и логичном порядке.
Контроль и свобода пользовательских действий: Пользователи часто ошибочно выбирают функции системы и нуждаются в четко обозначенном запасном выходе, чтобы выйти из неверного состояния без дополнительных диалогов. Поддерживайте отмену и восстановление.
Согласованность и стандарты: Пользователи не должны удивляться различным словам, состояниям или действиям обозначающим одно и то же. Следуйте стандартизированным соглашениям.
Предупреждение ошибок: Лучше хорошего сообщения об ошибке может быть только тщательно спланированный дизайн, предупреждающий пользователя об ошибочных действиях. Либо устранение способствующих ошибкам условий, либо их проверка и предоставление пользователям опции подтверждения перед тем, как они совершат действие.
Распознавание предпочтительнее вспоминания: Минимизируйте загрузку памяти пользователей отображая объекты, действия или опции. Не вынуждайте пользователя запоминать информацию когда он переходит от одной части диалога к другой. Инструкция по использованию системы должна быть доступна постоянно.
Гибкость и эффективность использования: Горячие функции - невидимые для новичков - могут ускорять работу опытных пользователей, таким образом, система в состоянии обслужить новичков и продвинутых. Позвольте пользователям настраивать частые действия.
Эстетичный и минималистичный дизайн: Диалоги не должны содержать не имеющей значения или редко используемой информации. Каждая доля лишней информации в диалоге конкурирует с полезной и уменьшает её относительную заметность.
Помогайте пользователям опознавать, выявлять и восстанавливаться после ошибок: Сообщения об ошибках должны быть написаны простым языком (без кода), точно указывать на проблему и предлагать конструктивное решение.
Помощь и документация: Даже несмотря на то что система может использоваться без документации, она должна быть обеспечена помощью и документацией. Любая подобная информация должная быть легко доступна, ориентирована на задачи пользователя, содержать перечень возможных шагов и не быть слишком большой.

Первоначально автор разработал эти практики для эвристической оценки в сотрудничестве с Rolf Molich в 1990-м [Molich and Nielsen 1990; Nielsen and Molich 1990]. С тех пор они были усовершенствованы на основе анализа факторов 249 проблем юзабилити [Nielsen 1994a] что породило набор практик с максимальной степенью пояснения, которые воплотились в этом пересмотренном перечне практик [Nielsen 1994b].

Обновленные сведения

Я буду представлять мои новейшие руководства по юзабилити на консультации Fundamental Guidelines for Web Usability в рамках Usability Week 2009 conference в Вашингтоне, Сан-Франциско, Лондоне.

Смотрите также:

Основные принципы дизайна интерфейса от Bruce "Tog" Tognazzini. Перечень длинноват для эвристической оценки, но служит хорошим чек-листом.
10 практик юзабилити для повседневной жизни (типа прикол, на англ.)

Список литературы:

Molich, R., and Nielsen, J. (1990). Improving a human-computer dialogue, Communications of the ACM 33, 3 (March), 338-348.
Nielsen, J., and Molich, R. (1990). Heuristic evaluation of user interfaces, Proc. ACM CHI'90 Conf. (Seattle, WA, 1-5 April), 249-256.
Nielsen, J. (1994a). Enhancing the explanatory power of usability heuristics. Proc. ACM CHI'94 Conf. (Boston, MA, April 24-28), 152-158.
Nielsen, J. (1994b). Heuristic evaluation. In Nielsen, J., and Mack, R.L. (Eds.), Usability Inspection Methods, John Wiley & Sons, New York, NY.

Майкрософт изменили гайдлайны для капитализации

2009-02-27T13:51:00.008+03:00

Для кого-то это не новость и, возможно, кого-то это развеселит, но на днях я был удивлен тем, что оказывается для Windows Vista стандарты капитализации изменились. Я уже привык к тому, что в названии кнопок, например, все слова пишутся с большой буквы (это грубо говоря, на самом деле там много разных условий). Такой вид капитализации называется title-style capitalization. Когда с большой буквы написано только первое слово, это sentence-style. Так вот, чтобы следовать Windows Vista tone, title-style capitalization должен использоваться только для заголовков окон, все остальные элементы UI должны быть оформлены в стиле sentence. Прочитать об этом и многом другом в оригинале можно тут. К чему этот пост? Да к тому, что все течет, все меняется, не забывайте держать руку на пульсе :)

Мифы и грабли: Вы не обеспечиваете качество тестированием

2009-02-18T22:52:00.007+03:00

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

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

Из книги "Lessons Learned in Software Testing" Kaner, Bach, Pettichord

Tools: Snipping Tool - встроенный в Windows Vista инструмент захвата изображений

2009-02-07T00:52:00.008+03:00

Наверняка я не открываю Америку, но тем не менее. Если вы работаете на Windows Vista Home Premium, Business, Enterprise или Ultimate, вы можете использовать встроенное средство для захвата изображений - Snipping Tool (Ножницы в русской локализации).

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

Произвольная форма. Обведите требуемый объект произвольной линией, например образующей круг или треугольник.
Прямоугольник. Заключите объект в прямоугольник, протащив курсор вокруг объекта.
Окно. Выберите требуемое окно (например, окно обозревателя или диалоговое окно).
Весь экран. Также можно сделать снимок всего экрана.

Готовый фрагмент автоматически копируется в окно, где доступны такие инструменты как многоцветное перо, маркер и ластик. Сохранить можно в форматах PNG, GIF, JPEG или HTML (MHT). Также есть возможность отправить картинку по почте. Если вам нужно захватить какую-либо нестатичную область, например открытое меню, сделайте следующее:

Откройте Snipping Tool.
Нажмите ESCAPE и откройте меню.
Нажмите CTRL+PRINT SCREEN.
Выбирайте тип выделения и хватайте.

Мифы и грабли: Цель тестирования - поиск ошибок

2009-02-03T00:54:00.008+03:00

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

То есть, этому мифу будет посвящено несколько заметок. Тем не менее, ниже я не озвучу свое видение вопроса, а приведу вольный перевод отрывка из книги Рекса Блэка Pragmatic Software Testing, который в свою очередь цитирует Бориса Бейзера (мне очень льстит такая вложенность :) ). Мне сегодня случайно попалась эта глава на глаза, показалась весьма в тему и я решил не откладывать в долгий ящик. Это неплохая пища для ума, а свое скромное мнение я напишу как-нибудь потом, тем более что с гуру трудно не согласиться.

-------
Один из трех основателей современного тестирования ПО, Борис Бейзер, определил пять стадий становления тестировщика:

Стадия 0: Нет никакой разницы между тестированием и отладкой. Цель тестирования - помощь в поиске и исправлении ошибок;
Стадия 1: Цель тестирования - доказать что ПО работает;
Стадия 2: Цель тестирования - доказать что ПО не работает;
Стадия 3: Цель тестирования не в том, чтобы что-то доказать, а в понижении предполагаемых рисков, приводящих к неработающему ПО, до приемлемого уровня;
Стадия 4: Тестирование это не этап. Это интеллектуальная деятельность которая приводит к получению надежного и стабильного ПО без больших трудоемких затрат на тестирование.

Первые две стадии можно рассматривать как миф людей и организаций с незрелыми практиками и процессами тестирования (для исчерпывающего описания см. книгу Б.Бейзера Software Testing Techniques).

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

Однако вы можете прогрессировать до стадии 3. На этой стадии тестирование является составляющей всеобъемлющей стратегии управления рисками. Тестирование ориентировано на риски. Тестирование предоставляет информацию, имеющую отношение к рискам. Эта книга может научить вас как достичь и этого.

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

Итак, на какой стадии вы сейчас находитесь и почему? На какой стадии хотят вас видеть коллеги и начальство и почему? На какой стадии нужно вашей организации чтобы вы находились и почему?
-------

Думаю, в следующих заметках на эту тему я опять обращусь к кому-нибудь из классиков.

Tools: Locky - инструмент блокировки файлов

2009-01-21T15:11:00.005+03:00

Некий Evil Tester решил поделиться самописным инструментом, который позволяет блокировать доступ к файлам. Количество заблокированных файлов может достигать 64. Небольшая инструкция по использованию прилагается в архиве, который можно скачать здесь.

Ссылка на источник

Анонс: Мифы и грабли тестирования

2009-01-20T00:42:00.008+03:00

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

На фото: Кэри Байрон из телешоу "Разрушители легенд"

Tools: Problem Steps Recorder в Windows 7

2009-01-15T17:10:00.005+03:00

Наверное, многие уже знают о распространяемой Microsoft бесплатной бета-версии Windows 7 для тестирования.
Так вот, в данную сборку включена удобная утилита для быстрой и несложной записи последовательности действий пользователя. В результате работы программы получается ZIP-файл, в котором запакован MHTML-отчет о действиях пользователя. Пример такого отчета можно посмотреть здесь. Запускается данная утилита из Панели Управления или Start\Run\psr.exe. Небольшую видеопрезентацию можно скачать отсюда.

Как её оттуда выковырять пока не разбирался.

Update: Не работает с Qt :(

Tools: Om for software testing

2009-01-14T17:39:00.004+03:00

Простая и полезная программка для генерации текстовых строк различной длины и содержания.

Om (pronounced as "Oh m") is a free command line tool for generating stressfull text data for field testing as well as Random testing. The data generated can be copied anywhere using Ctrl + v. (e.g. It can be copied to any field of the test Application or as a Test data in Test Case file).

Features

Om can generate data in three different ways using its three different modes of Operation.

User can provide an option for generating data consisting of different character types like uppercase, lowercase, numerical, others or any combination of the above four.

Om comes with User Manual for complete guidance to its users.

Om is free software. This means that everyone may use it, redistribute it and/or modify it under the terms of the GNU General Public License, as published by the Free Software Foundation.

Downloads:
Click here to download Om1.0 for windows. (Download includes User Manual).

About Author
Sanket Vaidya is a software test engineer at Patni Computer Systems Ltd. , India

Источник: http://omfortesting.110mb.com/

Обнаруживайте серьезные проблемы быстро

2008-12-27T16:01:00.010+03:00

Вероятно, ваша цель включает в себя, помимо всего прочего, выявление серьезных проблем (на фоне незначительных) и это выявление должно быть быстрым. Если это так, то что это означает с точки зрения выполнения тестов?

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

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

Из книги Lessons Learned in Software Testing, Cem Kaner, James Bach, Bret Pettichord

7 основных принципов Context-Driven школы тестирования.

2008-12-18T01:49:00.022+03:00

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

Ценность каждого решения зависит от условий его применения.
Есть много вариантов решений, но нет лучшего.
Команда - самая важная составляющая любого проекта.
Часто проекты отнимают много времени там, где мы этого не ждем.
Продукт - это конечное решение. Если задача не решается, продукт не работает.
Грамотное тестирование это сложный интеллектуальный процесс.
Только здравый смысл и мастерство, совместно прилагаемые на протяжении всего проекта, позволят нам сделать все правильно и в срок, чтобы эффективно протестировать наши продукты.

Пояснения принципов в действии:

Группы тестирования существуют для выполнения работ связанных с тестированием. Они не участвуют в разработке; они обслуживают проект.
Тестирование выполняется от лица заинтересованных сторон - в процессе разработки, испытаний, отладки, исследования или реализации продукта. Совершенно разные стратегии тестирования могут быть применены для этих разных целей.
Совершенно нормально разным группам тестирования иметь разные цели. Методы достижения одной цели могут не подойти или быть антипродуктивными для достижения другой.
Неправильные метрики опасны.
Суть тест-кейса лежит в его возможности предоставить информацию (т.е. уменьшить неопределенность)
Все ошибаются. Даже если вам кажется что продукт проходит вашу проверку, он возможно сломается там где вы (или автотесты) этого не проверяли.
Автоматизированное тестирование это не автоматическое ручное тестирование: абсурдно подразумевать под автоматизированными тестами имитацию тестирования человеком.
Разные типы дефектов вскрываются разными типами тестов - тесты должны усложняться или нацеливаться на различные уязвимости чтобы программа становилась более стабильной.
Тестовые артефакты дают хороший результат когда они удовлетворяют соответствующим требованиям заинтересованных сторон.

Пример:

Рассмотрим два проекта:

Разработка системы управления самолетом. Корректное поведение означает высочайшую техническую и математическую точность. Соответствие требованиям Федерального авиационного агентства. Всё, что вы делаете (или не делаете) может стать основанием для суда в течение 20 лет. В команде прививается инженерная культура в которой ценятся такие качества как осторожность, точность, повторяемость и двухсторонний контроль.
Разработка текстового процессора для Веба. Корректное поведение в данном случае значит потакать огромному числу пользователей Microsoft Word для их привлечения к вашему продукту. Нет регулярных требований имеющих значение (кроме отвечающих общим потребностям). Через 20 месяцев надо выпустить продукт, хороший либо плохой. Команда не следует инженерной культуре, попытки следовать культуре из первого случая будут приводить к ущербу для окружающих.

Методы тестирования подходящие для первого проекта обречены на провал во втором.
Методы подходящие для второго будут выглядеть преступно халатными в первом.

Источник: http://www.context-driven-testing.com/