Home

Автор: Сергей Бережной

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

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

«Человек не будет переживать за качество всего проекта. Он не встанет и не скажет, что проект не готов к выходу, даже если давление (в том числе и с моей стороны) будет высоко».

С моей стороны показалось странным, почему он (опытный руководитель проектов) обращает внимание именно на это, а не на профессиональные знания и опыт. Неужели читал Спольского про «smart and get things done»? Такая тема не могла быть не обсуждена дополнительно! И мы решили обсудить, какие же проблемы кроме этой Заказчик видит в нашем тестировании.

Получился вот такой список главных разочарований в тестировании со стороны Заказчика:

Выступление Алексея Баранцева на AgileDays-2011

Идея написания спецификаций на «естественном языке» манит своей внешней красотой и простотой. Мысль о том, что не умеющий программировать product owner станет сам рисовать Fitnesse-таблички и писать Cucumber-спецификации, выглядит очень привлекательно, возникает надежда переложить на него часть работы. Более того, исполнимые спецификации можно использовать как направляющие для разработки, и наряду с test driven development возникают подходы с похожими названиями — Behavior driven development и даже acceptance test driven development.

Однако здесь есть два больших подводных камня.

Помните бородатый анекдот про морскую свинку, которая, вопреки своему названию, и не плавает, и не хрюкает? Когда я слышу про автоматизированное приёмочное тестирование в контексте agile, у меня всегда возникает ассоциация с этой морской свинкой. Автоматизированное? Да, с этим не поспоришь. Но при этом и не приёмочное, и не тестирование. Для тестирования это слишком просто, «программирование в табличках» — адская пытка, паттерн given-when-then не даёт возможности сделать хоть сколько-нибудь сложные автоматизированные тесты, а при ручном тестировании он и вовсе не нужен. Ну а идея автоматизировать приёмку вообще слабо вписывается в концепцию agile: если «приёмочные тесты» будут пройдены, а product owner недоволен — продукт будет считаться успешно сданным или нет?

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

Так стоит ли вообще вкладывать усилия в эту деятельность? Кому BDD и ATDD приносит пользу — заказчику, программистам, тестировщикам? Как разрабатывать тесты, чтобы потраченные усилия всё же не пропали даром? Я постараюсь дать свои ответы на эти вопросы, и с удовольствием выслушаю вашу точку зрения.

Видеозапись доклада можно посмотреть здесь.

Обсудить в форуме

Автор: Майкл Болтон (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) присоединились к дискуссии. В частности, Дэйл высказал предположение, что во время сражения стрельба может быть остановлена в нескольких случаях: временное затишье, поступление команды «прекратить огонь», соглашение между сторонами о прекращении огня, отход сторон на начальные позиции, разоружение противника. Это показалось мне интересным.

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