Home

Автор: Майкл Болтон (Michael Bolton)
Оригинальная публикация: Mission Critical: Visualize, Personalize, Humanize

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

Что значит мыслить критически? Целью критического мышления являются обоснованные, бесстрастные, тщательные и точные оценки и суждения. Эти оценки основываются на детальных наблюдениях, старательном сборе и взвешивании свидетельств, распознавании значимых сходств и различий, осведомленности о предубеждениях и «слепых пятнах»(и устранение их в максимальной возможной степени), непрерывном повторном применении полученных знаний. Критическое мышление требует от нас рассматривать объект мышления в контексте. А также необходимо изучать, подвергать сомнению и улучшать сами способы размышления и наблюдения.

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

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

Мне не раз приходилось сталкиваться с этим в реальных проектах, и меня беспокоило то, что мы рассматривали «пользователей» всех скопом, не вдаваясь в детали и не проводя различий.

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

Автор текста: Баранцев Алексей

В статьях Джеймса Баха можно встретить несколько различных определений того, что такое тестирование методом свободного поиска (exploratory testing), и одно из них звучит так: "тестирование без заранее подготовленных сценариев, выполняемых в точным соответствием с планом" (Exploratory tests, unlike scripted tests, are not defined in advance and carried out precisely according to plan).

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

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

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

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

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

Не теряйте из виду своих целей!

На первой встрече Московского клуба тестировщиков Алексей Баранцев выступил с докладом на тему "Как понять, действительно ли ваша работа для кого-то важна и нужна".

Слайдкаст доклада мы не так давно публиковали на портале.

А сегодня Алексей Лупан опубликовал в своем блоге расшифровку данного доклада, за что ему огромное спасибо.

Автор: Илья Комендантов

Оригинальная публикация

Когда встречаю объявления типа: "В связи с расширением штата сотрудников, требуется..", "Молодая развивающаяся компания ищет.. " и подобные им, сразу представляю, как маленькое село вырастает в пгт, оно, в свою очередь, в город, а тот – в мегаполис.

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

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

Такое себе – нагрузочное тестирование. Может стоит для анализа проблем фирмы нанимать перформанс инженеров? Почему бы и нет.. Интересно, были прецеденты?

Автор: Юлия Нечаева

Часто задают вопрос: как быть с тем, что программисты не любят тестировщиков, считают их работу второстепенной, пишут неряшливо – «все равно ведь проверят» либо мстят за каждый найденный баг и пытаются не признавать их за баги.
Или наоборот, программисты жалуются, что тестировщики злорадствуют, найдя баг, и считают личным достижением, если программист наделал много ошибок.

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

Автор: Gojko Adzic
Перевод: Дмитрий Дудников по заказу Software-Testing.RU
Оригинальная публикация

Я сейчас пишу новую книгу и в связи с этим опрашиваю множество команд, внедривших приемочное тестирование. Большинство из уже опрошенных не в одном, так в другом месте наступали на грабли при автоматизации тестирования пользовательского интерфейса (UI). Пообщавшись несколько недель назад на Agile Acceptance Testing Days в Бельгии с некоторыми участниками, которые как раз опасно приблизились к тому месту, где спрятаны грабли, я хочу представить вашему вниманию хорошие, на мой взгляд, подходы к автоматизации UI-тестирования.

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

Автор: Майкл Болтон
Перевод: Дмитрий Дудников по заказу Software-Testing.RU
Оригинал: http://www.developsense.com/articles/2009-07-ThreeKindsOfMeasurement.pdf

Люди часто цитируют лорда Кельвина: «Если вы можете измерить то, о чем говорите, и выразить это в цифрах – значит, вы что-то об этом предмете знаете. Но если вы не можете выразить это количественно, ваши знания крайне ограничены и неудовлетворительны. Может это начальный этап, но это не уровень подлинного научного знания, каков бы ни был предмет исследования» [1]. Однако немногие обращают внимание на предложение, которое предшествует этому высказыванию: «в естественных науках важнейший первый шаг в направлении изучения любого предмета – это нахождение принципов численного выражения и осуществимых способов измерения величин, связанных с ним». Это пропущенное предложение ставит перед нами несколько вопросов: «Применимы ли в области разработки и тестирования компьютерных программ принципы измерения, подобные тем, что мы используем в физике? Если нет, то какие виды измерений нам следует использовать? Как нам извлечь пользу из этих измерений?».

Автор: Майкл Болтон

Перевод: Дмитрий Дудников по заказу Software-Testing.RU

Оригинал: http://www.developsense.com/2009/09/when-do-we-stop-test.html

Несколько лет назад, примерно в то же время, когда я начал проводить тренинг «Быстрое тестирование ПО» (Rapid Software Testing), мой соавтор Джеймс Бах (James Bach) записал видео для демонстрации быстрого стресс-тестирования. В его примере подход заключался в подаче на вход визарда приложения огромного объема данных, по существу заставляя приложение нагружать само себя.

Видео длится почти шесть минут. Примерно на середине Джеймс спрашивает: «Вы можете поинтересоваться, почему я не хочу остановиться сейчас. Причина в том, что мы наблюдаем неуклонное ухудшение ситуации. Мы могли бы остановиться сейчас, но возможно мы увидим нечто худшее, если будем продолжать». Таким образом, он продолжил тест. А вскоре после этого Джеймс предложил эвристики для остановки: мы останавливаемся, когда: 1) мы обнаружили достаточно серьезную проблему, или 2) в поведении программы нет явных изменений – программа в целом работает стабильно, или 3) ценность от продолжения теста не оправдывает стоимость. Таковы были эвристики для остановки того теста.

Где-то через год после того, как я впервые увидел это видео, я решил более полно описать эвристики для прекращения тестирования в колонке для журнала «Better Software». По этому поводу мы с Джеймсом устроили транспективную беседу. Колонку вы можете найти здесь. Ещё год спустя колонка превратилась в неформальную лекцию, которую я прочитал в нескольких местах.

Примерно через шесть месяцев после этого мы оба нашли еще больше эвристик для остановки тестирования. Мы обсуждали их на STAR East 2009, и проходившие в тот момент мимо нас Дэйл Эмери (Dale Emery) и Джеймс Линдсей (James Lyndsay) присоединились к дискуссии. В частности, Дэйл высказал предположение, что во время сражения стрельба может быть остановлена в нескольких случаях: временное затишье, поступление команды «прекратить огонь», соглашение между сторонами о прекращении огня, отход сторон на начальные позиции, разоружение противника. Это показалось мне интересным.

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

Автор: Майкл Болтон
Оригинальная публикация: Swan Song
Перевод: Алексей Баранцев

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

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

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

Автор: Michael Bolton
Перевод: Баранцев Алексей

Оригинальная публикация:
Why Is Testing Taking So Long? (Part 1),
Why Is Testing Taking So Long? (Part 2)

Часть 1

Если вы работаете в тестировании достаточно давно, вам наверняка задавали этот вопрос - "Почему тестирование занимает так много времени?" Может быть, у вас есть заготовленный ответ на этот вопрос, а может и нет. Здесь я предлагаю модель, которая, я надеюсь, поможет вам справиться с менеджерами, которые задают подобные вопросы.

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

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