Bugsclock

125(всего?) замечательных тестировщиков?

2018-01-18T01:01:00.002+03:00

Блог давно не обновлялся поэтому перейду сразу к делу, уважаемые русскоязычные тестировщики. Давайте-ка, друзья мои, разыщем всех тестировщиц, которые вносят свой непосильный вклад в развитие сообщества тестирования (не обязательно на международном уровне) и расширим их именами этот список https://agiletestingdays.com/blog/125-awesome-testers-you-should-keep-your-eye-on-always/

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

Если ты проигнорировал этот пост, то будешь проклят ровно через неделю :)

Черный тестер

2013-03-19T02:49:00.000+04:00

Это очень старая история. В одной девелоперской конторе под Киевом работал один тестер. И оставалось ему до релиза три дня и три ночи. Очень тестер любил свой продукт. Должны были успешный релиз выпустить. А в конторе ещё работал один менеджер. Гад редкий. Он тоже на успешный продукт глаз положил. И как то ночью, когда тестер уснул, менеджер подкрался к нему с красным пожарным топором и отрубил голову. Послали тестера в гробу с пришитой головой домой. Написали, мол, погиб ваш сынок за качество — со стула упал на топор.

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

Третья аксиома тестирования

2013-01-16T04:28:00.002+04:00

Вторая аксиома тестирования

2012-12-07T14:45:00.001+04:00

Первая аксиома тестирования

2012-11-09T01:47:00.002+04:00

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

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

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

JQuery Bug Tracker

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

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