Насколько подробными должны быть мануальные тесты?

Хороший вопрос. Я думаю, многие из нас сталкивались созданием тестовых наборов. И многие из нас будут спорить с пеной у рта: "Да не нужны нам тесты записывать, все и так знают как это работает." – "Нет! Хоть что-то должно быть. Используйте чек-листы, майнд-мапы!" – "Да, нет же! Тест-кейсы должны быть  подробными, чтобы каждый новый человек с улицы мог прийти и с первого дня проходить тестовый набор".

И единственное, что тут можно сказать: "Я согласен! Со всеми!".

Действительно, все зависит от контекста: от проекта, от команды, от квалификации, от менеджмента… 

Джастин Хантер (Justin Hunter), основатель проекта http://hexawise.com/, отвечает на этот вопрос следующей матрицей 2х2:

Visual Studio: Макрос для замены пробелов на символы подчеркивания

Имена тестов более читабельны, если написаны через подчеркивание:

При_вводе_2_плюс_2_в_результате_должно_быть_4()

Нежели если они написаны в CamelCase

ПриВводе2Плюс2ВРезультатеДолжноБыть4()

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

1. Писал строку текста в Ворде, для того чтобы не допускать тупых афрографических ашибак
2. Копировал строку в Visual Studio
3. Использовал стандартный поиск и замену по выделенному тексту. Это лишний диалог, на который я тратил лишнее время. 

При помощи макроса для Visual Studio, это действие проходит быстрее и менее раздражающе.
Теперь я нажимаю Alt+1 – и пробелы заменяются на подчеркивания.

Код макроса можно взять тут: Visual Studio Macro for BDD Naming
И видео о том, как добавить новый макрос в Visual Studio:

Confet&QA: Мой доклад про создание читабельных отчетов для автоматизации тестирования на .NET/C# + Webdriver + Gallio Icarus/MbUnit + BDDfy

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

Мой доклад посвящен инструментам, помогающим сделать результаты прогона автоматизации более наглядными. Это Gallio + MbUnit, которые позволяют не только создавать и запускать тесты, но и создавать красивые отчеты после прохода автоматизации, записывать видео встроенными средствами и много другое.

Я рассказал о BDDfy – фреймворке, позволяющим писать тесты в более понятном и читабельном аля BDD-стиле. Именно в этом фреймвоке  я нашел решение тех проблем, которые у меня возникали со Specflow.

Но, на счет Gallio Icarus не обошлось и без полезной ложки дёгтя.
Перечитайте нашу переписку на форуме автоматизаторов с товарищем apetrovskiy. Александр очень хорошо расписывает возможные проблемы с Gallio и варианты их решения.

Читабельные отчеты для автоматизации на C# / Gallio / BDDfy from Дмитрий Жарий

Ресурсы:
Gallio Icarus: http://gallio.org

BDDfy – фреймворк для БыДиДификации кода :)

Страница проекта на Github:
http://teststack.github.com/TestStack.BDDfy/

Описание на английском:
http://www.mehdi-khalili.com/bddify-in-action/introduction

И еще больше докладов с Конфетки в поиске по Ютубу.

XMLStarlet утилита для редактирования XML файлов из командной строки

Наконец-то нашел!

Зачем?

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

Например, заменить connectionString в файле web.config и подобных конфигурационных файлах. 

Иногда мне приходится отслеживать изменения в XML фалах, а для этого их необходимо привести в более удобный вид. 

Решения
Я пишу скрипты на языке Perl, если необходимы более тонкие преобразования и работа с XML файлами. Для конфигурации билда перед запуском авто-тестов, у меня также есть подобные поиски и замены в файлах конфигурации на C#. Но, все это как-то заточено под конкретные файлы, и создавать универсальное решение не хотелось, но пришлось бы…

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

xml ed -u "configuration/connectionStrings/add[@name='SqlServerDb']/@connectionString" -v "Data Source=SQL2008;Initial Catalog=testdb93;User ID=admin;Password=admin;MultipleActiveResultSets=True;" My.Database.config

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

Домашняя страница XMLStarlet
Страница загрузки

З.Ы: Внутри архива есть хорошее руководство пользователя

Given When Then в баг репортах

Не знаю как у вас, но на моем проекте баг-репорты очень часто выступают в роли требований: в роли пропущенных требований и запросов на совершенствование (enhancement request).

Кстати, интересно, а какая собственно разница между требованием, тест-кейсом и баг-репортом?

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

"У пользователя должна быть возможность сложить два числа в калькуляторе"

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

RamDisk – делаем всё быстрее!

Наверное, самый лучший практический совет, который я вынес из конференции XP Days – это совет по работе с Ram Disk'ами из доклада Crazy Talk: When 10 second builds start to make you nervous

Ram Disk – это технология не новая. Помню, как еще грузился с загрузочной дискеты Windows 95, где создавался такой диск с голым ДОСом. И в то время, при жестком дефиците оперативной памяти, навряд ли можно было использовать эту технологию каким либо другим способом.

Но, сейчас, когда 8 Гб – это уже так, средненько, а стоимость SSD как-то все еще неоправданно высока – для оптимизации процесса сборки большого проекта, особенно если он написан на С++ или Java – отлично подходят RAM-диски.

Простые тесты ввода-вывода показывают прирост производительности дисковых операций в 150 – 200 раз. Ну, а сам билд, со слов докладчика,  может собираться в 2 – 3 раза быстрее. Т.е. за 20 минут вместо 60-ти.

Для создания RAM-дисков существует множество как недорогих платных, так и бесплатных решений.

Я пока остановился на бесплатном ImDisk Virtual Disk Driver. Попробую, возможно получится оптимизировать некоторые операции backup/restore. 

Devnology Podcast 034 - Gojko Adzic

Я давно не пополнял запасы Спецификации через пример. В последнее время, по этой теме какое-то затишье, в смысле хорошых материалов и презентаций. Но, это подкаст действительно очень стоящий.

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

Ссылка на оригинальную страницу

MP3: Ссылкана аудиофайл 

О чем я расскажу на Test Automation Days

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

Только сейчас, многие из нас, автоматизаторов, пытаются как-то использовать паттерн PageObject для того, чтобы и сделать код тестов понятней, и держать "все локаторы в одном классе". Буквально только сейчас люди начинают использовать некоторые преимущества объектно-ориентированного программирования. То есть применять то, чем программисты активно пользуются уже более 20-ти лет. И если они используют эти техники такой продолжительный срок – значит в этом что-то есть!

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

Например, есть ли чего общего между страницей регистрации нового пользователя и формой обратной связи? И там и там есть некоторые ожидаемые поля. И там и там некоторые поля обязательны. Можем ли мы спросить у каждой страницы "А дай-ка мне список своих текстовых полей" и, получив список, – проверить каждое.

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

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

Хорошо. Предположим, на страницу была добавлена фича "Если форма не сохранена и пользователь закрывает страницу – приложение должно известить о несохраненных изменениях". Сколько кода нужно написать, чтобы проверить эту фичу для 50-ти страниц в приложении?

Я покажу, как добавить 50 таких тестов, произведя изменения всего лишь в одном в файле.
Если интересно – приходите на мой доклад "За пределами PageObject" на конференции Test Automation Days, которая состоится в Киеве 9-го февраля 2013-го года.

Шапка тестировщика

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

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

Кроме того, был даже отдельный пример реализации такого плагина.  И, скорее всего, для того чтобы «протестировать» функциональность, мне достаточно было убедиться в том, что код примера компилируется и работает. Но, в тот момент у меня и сомнений не возникало, что этот код плагина не работает, а в правильной работе той функциональности, которая вызывала методы плагина – сомнения были.

Шапка программиста
Я решил примерить на себя «шапку программиста»  и реализовать тестовой плагин с нуля, не копируя код примера.
Для этого, в начале, я написал модульные тесты, которые бы эмулировали функциональность Аппликейшена, и вызывали нужные методы согласно протоколу. А сами методы отдавали необходимые данные, которые читались из внешнего файла. И данные, и вызовы – все это было покрыто модульными тестами. Кроме того, я добавил логирование вызовов методов плагина в отдельный лог, и при помощи тестов, еще даже не подключая плагин к Аппликейшену, я уже был доволен тем, что все работает так, как я хочу.

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

Проверки последовательности вызовов я реализовал в самом плагине с последующим выводом ошибок в лог. А возвращаемые тестовые данные я сделал уникальными для каждого варианта.

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

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

Выводы
Я думаю, многих из нас немного злят те случаи, когда после допиливания одной функциональности, отваливается тот функционал, который стоял в паре кликов. И даже особо не напрягаясь, можно найти новую блестящую ошибку JavaScript или ошибку от сервера.
Возникают мысли «ну как же ЭТО можно было не заметить?». А можно, если вдруг программист забыл надеть «шапку тестировщика». И причин тут может быть целая масса: от личных проблем – до проблем на производстве, авралов, невнимательности.

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

WebDriver: отладка CSS селекторов в Internet Explorer

Есть такие странные сайты, которые сейчас, в 2012 году, извините за слово, поддерживают только Internet Explorer 4 и выше. (пример 1, пример2, пример3).

При автоматизации таких сайтов, возникает проблема: как можно быстро убедится в том, что новый CSS селектор работает, не запуская тесты?

Как оказалось, в Internet Explorer такая функциональность по отладке CSS селекторов – есть.
Достаточно в IE Developer Tools (F12) в поле поиска задать селектор после символа “@”:

@a[onclick*='Home/login.asp']

Цитаты про тестирование

"Я вижу резолвленные баги но не ощущаю ожидаемого результата"
© наш QA
Лежали всем офисом.
http://juick.com/MaEcTPo/1230654

Писать тесты — это как писать код. Только тесты.
http://juick.com/V1ncE/1857174

Тем кто считает, что юнит тесты не могут работать с базой: если вы тестируете связку человек+лопата, и знаете, что лопата в порядке, а тест падает. Где будете искать ошибку?
http://juick.com/korchasa/1425218

В который раз сталкиваюсь с заблуждением "тесты == автоматизированные тесты". Если вы проверяете результаты работы своих скриптов, то вы уже тестируете. А уж автоматизировать этот процесс или нет, второй вопрос.
http://juick.com/korchasa/1232004

Блин, без BDD я не знаю, что сейчас надо сделать. о_о
http://juick.com/neFormal/1857653

"Humans make mistakes; programs (if coded correctly) do not." — Rails 3 in Action.
Интересно, время подтвердит эту гипотезу?
http://juick.com/wyldrodney/1854703

Тестирование и правда облегчает жизнь. Причем невероятно сильно. =)
http://juick.com/demiazz/1450005

Меня тут спросили, как я пошучу над коллегами первого апреля. А у нас какбе релиз. Первого. А я какбе тестер. Столько клевых идей!
А как бы пошутили вы?
http://juick.com/kisinkaito/602452

Узнал сегодня в институте 3 главных правила тестирования программы: 1) Тестирование легко начать, но сложно закончить. 2) С ростом числа обнаруженных ошибок увеличивается вероятность обнаружения новых. 3) Никогда не тестируйте свою программу сами. Пусть за вас её тестирует другой программист.
До сих пор не верится, что лектор говорил это на полном серьезе. Хотя с этими пунктами тяжело поспорить.
http://juick.com/ubuntard/521783

Запомню.
Памятка по приоритетам для QA:
blocker/highest — падение игры, нерабочая основная механика, ошибки, приводящие к невозможности дальнейшего игрового прогресса
critical/high — баг основной механики, нерабочая вторичная механика, ошибки, приводящие к невозможности дальнейшего игрового прогресса без перезапуска
major/normal — баг вторичной механики, ошибки визуализации или анимации, ошибки сохранения прогресса с предыдущей сессии
minor/low — ошибки позиционирования элементов, нелогичность поведения, перепутанные картинки/звуки
trivial/lowest — орфография(её проверяют в последний момент сразу всю), пожелания/заметки
Для багтрекеров с раздельными полями "важность" и "приоритетность"(например, mantis) это всё относится только к "важности", "приоритет" выставляется дополнительно в зависимости от пожеланий менеджмента.

http://juick.com/neFormal/1745507

Потеря душевного равновесия — побочный эффект работы куа инженера.http://juick.com/estet/507684

"хомо багус" — человек тестирующий (лат.).

http://juick.com/estet/204145

Багзилла как зеркало души тестировщика...http://juick.com/estet/97844

Между (QA) Quality Assurance, (QC) Quality Control и тестировщиками – разницы нет

Нас, тестировщиков, по-прежнему продолжают называть – QA (Quality Assurance), хоть и многие из нас с пеной у рта доказывают, что QA – это не человек, а процесс. Что мы тестировщики, не пишем код, а, следовательно, не можем обеспечить его качество. Это возможно только косвенно, путем предоставления информации о текущем качестве продукта и другими, но опять же, косвенными методами.

Но, все равно нас продолжают так называть. Все говорят «отдали в QA». Нам нужен новый QA.

Не видите разницы между QA, QC и тестировщиками?

Так значит и между:
Программистами, разработчиками и кодерами;
HR’ами и рекрутерами;
Менеджерами, начальниками и руководителями;
Тимлидами и скрам мастерами;
Эникейщиками и сисадминами – разницы тоже нет!

Upd: Расшифровки QA:

• Quality Assurance
• Quality Assistant
• Quality Analyst
• Quality Auditor
• Quick Assistance (support)
• Quality A… 

Как твитнуть из Google Формы. Руководство-детектив

– Так вы говорите, что этот хомяк пришел в Твиттер из Гугл формы?

– И да,  и нет. Гугл-форма была началом его пути, но в твиттере он оказался благодаря рецепту в http://ifttt.com в котором все элементы rss ленты одного из блогов на Blogger попадают в твиттер

– Стоп, а кто тогда опубликовал этот пост с хомяком в Blogger (http://dztwitter.blogspot.com/)?

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

– Значит хомяка прислали по имейлу… Хм… странно, кто же способен на такое?
– На это способна обычная Гугл-форма, в которой есть пользовательский скрипт привязаный к событию отправки формы. Как только новая форма отправляется – запускается вся цепочка: на специальный почтовый адрес для публикации в блоггер – отправляются данные формы. Ifttt читает RSS блога – и постит новые элементы в твиттер.

Добавить новый пользовательский сценарий в Google Forms можно через Tools - Script Editor
В самом редакторе необходимо ввести следующий код, и привязать его к триггеру отправки формы. Это делается через меню Resources – Current Script Triggers.

Вот и все. Вот так хомяк случайно попал в форму, прошел по десятку серверов и оказался в твиттере.
– Но, зачем использовать гугл формы для хранения Хомяков?
– Дело в том, что Властелину Хомяков очень удобно парсить данные Google Docs для создания готового для публикации HTML с собранными ссылками. Но, Властелин очень хотел, чтобы при добавлении новой ссылки, она сразу же попадала в твиттер. А копи-пастить руками каждый раз Властелин не хотел, потому что он очень ленивый.

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

А вот сам скрипт-триггер:

function onFormSubmitted() {
  var sheet = SpreadsheetApp.getActiveSheet();
  var rows = sheet.getDataRange();
  var numRows = rows.getNumRows();
  var values = rows.getValues()[numRows-1]; // Последняя запись

  message = values[1] + ": " + values[2] + " " + values[4];
  
  MailApp.sendEmail("dzhariy.!!!SALT!!!@blogger.com", "", message);
}

Бесплатные Вебинары по Selenium Webdriver с самого начала

Tarun Kumar, автор
Вебинаров по Selenium

На сайте «No Automated Testing», Tarun Kumar проводит бесплатные вебинары по Selenium Webdriver для начинающих. Примеры рассматриваются для платформы Java, с разбором работы не только Selenium IDE и Selenium Webdriver, но и достаточных основ объектно-ориентированного программирования на языке Java, с использованием сопутствующих инструментов тестирования.

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

Инструкция для просмотра:

1. Зайдите на страницу трейнингов: http://www.seleniumtests.com/p/free-selenium-training.html Выберете интересующий вебинар – вы перейдете по ссылке на советующий пост 
2. В посте найдите ссылку на anymeeting и перейдите на этот сайт 
3. На странице ввода пароля, введите – seleniumpassword 
4. Имя и почту можно указать любые 

Выглядеть это должно так:

 На странице тренингов вы можете подписаться на следующие вебинары.
Все права на упомянутые материалы принадлежат их автору – Tarun Kumar. При возникновении вопросов – свяжитесь с ним лично.

Гик-пост непонимание. Работа в Windows

Я реально не понимаю людей, которые не пользуются Far Manager.  Работа с командной строкой для них кажется сущим адом.

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

Я не понимаю людей, которые не могут выучить те 9 программ, которые можно быстро запустить через [Windows]+R: appwiz.cpl, services.msc, winword, excel, mspaint, notepad, inetmgr, eventvwr.msc . Угадайте, что каждая из них запускает?

Я не понимаю тех людей, которые для запуска Windows Task Manager жмут Ctrl+Alt+Del и выбирают его из меню, вместо нажатия Ctrl+Shift+Esc

FFmpeg + Screen Capture Recorder мега-быстрая запись видео багов

В итоге моих экспериментов по записи видео воспроизведения багов, я нашел самый быстрый и удобный способ записи полного экрана рабочего стола с практически моментальным созданием видео высокого качества и минимального размера.
Во-первых, скачайте и установите Screen Capture Recorder (домашняя страница проекта).

Во-вторых, создайте bat-файл со следующим содержимым:
Record.bat:

@REM= FFmpeg + screen-capture-recorder Desktop recording
@ECHO OFF
@REM =============== FFmpeg Path ===================================================
set FFMPEG64="C:\Program Files (x86)\Screen Capturer Recorder\configuration_setup_utility\vendor\ffmpeg\bin\ffmpeg.exe" 
set FFMPEG32="C:\Program Files\Screen Capturer Recorder\configuration_setup_utility\vendor\ffmpeg\bin\ffmpeg.exe" 

SET FFMPEG=%FFMPEG32%
IF NOT EXIST %FFMPEG64% GOTO NEXT
SET FFMPEG=%FFMPEG64%
:NEXT

@REM ============== GET CURRENT DATE AND TIME =======================================

For /f "tokens=1-4 delims=/. " %%a in ('date /t') do (set mydate=%%c-%%a-%%b)
For /f "tokens=1-2 delims=/:" %%a in ('time /t') do (set mytime=%%a_%%b)
echo %mydate%_%mytime%

@REM =============== Output Dir and filename ========================================

md %mydate%
set output=%mydate%\%mytime%_recording.mp4

@REM =============== Delay 3 pigs. Sorry, pings======================================
TITLE : 2
ping localhost
TITLE : 1
ping localhost
TITLE Started!

@REM =============== Run FFmpeg =====================================

%FFMPEG% -f dshow -i video=screen-capture-recorder -r 12 -q 1  "%output%"
explorer /select,"%output%"

@REM =============== See also: =====================================
@REM =============== http://blog.zhariy.com   ======================
@ECHO ON

Всё! Теперь запустите файл, и наслаждайтесь записью скринкаста под Windows бесплатно open source в mp4, в один клик, привет SEO оптимизации :)

Примечание: При записи видео, я рекомендую отключить Windows Aero и установить «классическую серую» тему Windows. Размер роликов при «классической» схеме может быть в 1,5 – 2 раза меньше.

Как же все-таки люди становятся тестировщиками?

Еще с 9-го класса школы и в колледже я увлекался программированием. Вначале это был Паскаль, потом Делфи, потом Perl, потом C#... Мне было интересно писать собственные программки, в надежде на то, что я когда-нибудь напишу то, чего еще не написано. 

Согласитесь, что в конечном итоге, у программирования есть результат: программа, которая что-то делает. И согласитесь, что по своей сути, программирование очень похоже на резьбу по дереву, лепку из глины, строительство моделей самолётов. Во-первых, интересен сам процесс. Во-вторых – всегда есть вполне осязаемый и материальный результат.
Тестирование. Я не знаю ни одного человека, у которого бы хобби было тестировать софт.
Я уверен, что для программиста, такой диалог был бы волне нормален:

– Вася, выходи на улицу гулять!
– Не м-о-о-гу, мне нужно проект на nodejs переписать

Но, вы хоть когда-нибудь слышали, чтобы ответ тестировщика был:

– Не м-о-о-гу, мне нужно еще пять тесткейсов дописать

Мой путь начался именно с программирования. Так я попал в автоматизацию тестирования, а после – заинтересовался и самим тестированием. И такой путь дает свои плюсы.
Во-первых, мне до сих пор нравится ковыряться в самой системе изнутри. Зная, на чем написано приложение, используется ли база данных, какие технологии использовались; я могу предугадать баги.  И это не интуиция, а простое знание технологии и следование четкой мантре:

«Если у технологии есть сложные, запутанные или рутинные места – там точно нужно искать ошибку».

Приложение состоит на 80% из клиентского JavaScript с кучей формочек – то сто процентов не все формочки правильно инициализируются.  Только знания самой технологии позволяет мне предугадывать баги.  И изучение новых популярных технологий для дальнейшего применения их в своих целях – и есть одно из моих хобби.

Но, для меня остаётся загадкой два вопроса:

Как тестировщики без знаний в программировании могут эффективно тестировать ПО? (Ведь таки многие как раз эффективно и тестируют).

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

Четверг, 26-е Багфиксьня – Международный день *.bat файлов

День *.bat файлов –  поистине знаменательная дата для всех тестировщиков планеты.
По традиции, в этот день, счастливые тестировщики создают новые *.bat файлы, автоматизируя свои рутинные действия.

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

start winword
start outlook
start chrome

Конечно же, *.bat-файлы, или как называют их в народе – батники, сами по себе очень стары, бородаты и ограничены. Но, ведь это всего лишь контейнер для команд!
Утилиту Ffmpeg, которой было записано это видео, я запускаю при помощи файла run.bat, следующего содержания:

ffmpeg -f dshow -i video=screen-capture-recorder -r 24000/1001 -q 1 out.avi

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

1. Выкачать последнюю версию исходиников проекта из системы контроля версий 
2. Сбилдать исходники при помощи msbuild
3. Обновить SQL-скрипты в базе данных

Все это обеспечивается правильным комбинированием различных команд.

Вам необходимо каждый день выкачивать билд с сервера заказчика? – добавьте в ваш bat-файл команду xcopy (для копирования с сетевой шары) или скачайте и используйте wget или curl для копирования файлов с HTTP/FTP ресурсов.

Ага, вам нужно деинсталлировать приложение перед установкой?
Без проблем. Используйте:

MsiExec.exe /qn /x{GUID вашего приложения} 

Проинсталлировать приложение?

msiexec /I appsetup.msi /qb /log appsetup.msi.log

 Или вы хотите остановить назойливую службу Windows Update, которая так и хочет перезапустить ваш компьютер?

sc stop wuauserv

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

Ну, а автоматизированные тесты вы как запускаете? Вы уже создали отдельный *.bat-файл для этой цели? (Пользователей CI, просьба не тролить это предложение)

Sql Change Scanner – утилита для отслеживания изменений в таблицах SQL Server

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

Простого и удобного для меня средства получения такой информации не было, но, за несколько часов, я создал  инструмент при помощи Perl и двух магических SQL запросов. Тогда утилита была непереносима, потому что мне было действительно сложно убедить людей, что поставить Perl на машину – это круто. А Command Line интерфейс – это еще круче. Я говорил… но, мне не верили.

Sql Change Scanner -- окно приложения

Утилита Sql Change Scanner – как раз и выводит имена таблиц, которые были модифицированы.
Сейчас это переносимое GUI приложение. Написал я его за два вечера,  и вот, сегодня – альфа релиз. Это значит, что «все работает на моей машине».

Скачать последнюю версию, вы можете с гитхаба. Сейчас это версия SqlChangeScanner_v1.0.zip  

Краткая инструкция:
Ограничения: Работает только с SQL Server. Тестировалась на SQL Server 2008

В начале, распакуйте и запустите SqlChangeScanner.exe
Укажите валидный ConnectionString к базе данных. Эту строку соединения вы можете взять из web.config вашего приложения.

Нажмите на кнопку Connect для соединения. Если все нормально, то в логе (Output) не должно быть ошибок.

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

Теперь приложение готово к отслеживанию изменений в базе. Сделайте изменение и нажмите на кнопку Scan еще раз. После завершения процесса, в логе (Output) вы увидите те таблицы, которые были модифицированы.

В данном случае, модификация – это либо удаление, либо изменение либо добавление элемента. Работа Sql Change Scanner основана на подсчете контрольных сумм таблиц, так что сейчас приложение покажет имя модифицированной таблицы, но не скажет, какого именно типа была модификация. Для более тонкой работы, вы можете воспользоваться SQL Profiler.

Критика и баг-репорты – приветствуются.

Короткая видео-демонстрация:

Вредная терминология в тестировании

Навеяно постом Рины Ужевко
Ненавижу терминологию!

Товарищи программисты, все тестировщики думают, что и вы тоже читали эти статьи из Википедии:
http://ru.wikipedia.org/wiki/Тестирование_программного_обеспечения

Перед прочтением этого текста, я настаиваю – ознакомьтесь с материалами Википедии

• Системное тестирование – это тестирование того, как приложение работает в операционной системе. Например, в Windows XP, Windows 7
• Интеграционное тестирование – это тестирование, при помощи интеграторов, т.е. тех людей, которые будут устанавливать ваш комплекс ПО заказчику
• Функциональное тестирование – это тестирование функций. Т.е. тоже самое, что и юнит-тестирование. 
• Юнит тестирование – это тестирование юнитов, т.е. тоже самое что и функциональное тестирование
• Модульное тестирование – это тестирование модулей. Это круче чем юнит тестирование. 
• Тестирование производительности – это тестирование того, что производит приложение. В большинстве случаев, самый полезный продукт – это лог приложения. 
• Стресс-тестирование – это когда вы ощущаете дискомфорт из-за того, что продукт надо было сдать еще вчера, вы работаете сверхурочно, вам за это не оплачивают, а ваш начальник – чудак. 
• Тестирование безопасности – тестирование того, что пользователь чувствует себя безопасно, работая с приложением. 
• Тестирование совместимости – это проверка того, насколько программное обеспечение и пользователь совместимы. Нередко, такое тестирование проводится с привлечением сторонних консультантов-астрологов. 
• Позитивное тестирование – приносит радость
• Негативное тестирование – оставляет в душе осадок, как будто туда кто-то плюнул
• Приёмочное тестирование – выполняется при помощи приемника, например «Приемник престола»  или аналогичного дворянского чина
• Тестирование при сдаче – проводится в магазине, при покупке ПО. Покупатель тестирует сдачу, выданную продавцом.
• Регрессионное тестирование – метод запугивания программистов, например:–  Иванываныч, тестировщики говорят, что отрегрессили наше приложение– Будь с ними осторожен, они могут и нас словить и отрегрессить 
• Статическое тестирование – это когда тестировщик тупо сидит, пялится в монитор и ничего не делает
• Динамическое тестирование – голодные тестировщики заперты в клетке. Электрические разряды стимулируют их метаться по клетке быстрее. 

Книга: Краткие основы тестирования программного обеспечения

Это книга, которую нигде не купить (разве что по знакомству), потому что тираж печатного издания всего 100 экземпляров. Это книга, которую я бы никогда не прочитал, если бы один такой печатный экземпляр не попал мне в руки.

И после прочтения, я хочу вам настоятельно рекомендовать эту книгу к прочтению:

Автор: Артур Коробейник
Краткие основы тестирования программного обеспечения

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

Это всего лишь 100 страниц. Да вы можете прочитать ее уже сегодня вечером.
Скачать (бесплатно без смс и регистрации :)  книгу можно со страницы автора.

Юмор в тестировании

Перевод замечательного поста: TheSoftware Testing Funny Pages

Кто сказал, что у тестировщиков нет чувства юмора? Я решил сделать небольшую подборку из моих любимых юмористический постов по тестированию. Наслаждайтесь! 

Кто есть кто?

• Менеджер проекта – это человек, который считает, что 9 женщин могут сделать 1-го ребенка за 1 месяц
• Координатор проекта на стороне заказчика думает, что одна женщина может сделать 9 детей за 1 месяц
• Разработчик думает что для того чтобы сделать одного ребенка необходимо 18 месяцев
• Менеджер по маркетингу считает, что можно сделать ребенка даже если нет ни одного мужчины и ни одной женщины
• Клиент – это тот человек, который не понимает, зачем ему нужен ребенок
• Тестировщик всегда говорит своей жене, что это не правильный ребенок
  

Половина стакана

Оптимист думает, что стакан наполовину полон, пессимист - что наполовину пуст, а хороший тестировщик не понимает, почему стакан в два раза больше, чем он должен быть. 

Признаки того, что вы встречайтесь тестировщиком  (взгляд глазами девушки) 

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

Не совсем правильное парное тестирование:

Слева: (Читает книгу ISTQB Basic Level): – Не так быстро, Миша, тут написано, что ты должен написать тест кейс перед тем как выполнить его!

Тестировщики за обедом

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

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

Эффективная запись видео воспроизведения багов

Как говорится в пословице «Лучше один раз увидеть, чем не дочитать баг с 15-ю степами». 


Это действительно так.  

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

Для себя я понял, что размазывать описание бага, на более чем 5 шагов – это просто не эффективно. А лучше всего – одна-две лаконичных строчек, например:

Пользователь не может купить Биту в магазине software-testing.ru, потому что страница выдает нечитабельный текст:
«?????????, ????? ???????? ????: �?и�?а �?еал�?ного �?е�?�?и�?ов�?ик�?»

Ну, а дальше можно либо описать 15 шагов воспроизведения, либо записать видео и приатачить к багу.

Для менеджера понятно, что есть серьезная проблема: пользователь не может купить товар в магазине. И двух текстовых строчек вполне достаточно для того, чтобы назначить баг программисту, ответственному за модуль.

Программист же намного быстрее просмотрит видео, чем прочитает 15 строчек шагов воспроизведения.

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

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

Инструменты

Для записи экрана я уже давно использую два бесплатных инструмента:
Microsoft Expression Encoder 4 и FFmpeg + screencapturer.

Плюсы  Microsoft Expression Encoder 4:

1. Удобный
2. Позволяет редактировать параметры кодирования видео
3. Позволяет записывать регионы

Минусы:  

1. Ограничение: бесплатно можно записать только 10 минут, но этого вполне хватает для записи воспроизведения багов (делая паузы при записи где это необходимо)

Плюсы  FFmpeg + Screencapturer  

1. Бесплатный без ограничений
2. Потребляет (субъективно) меньше системных ресурсов
3. Преобразовывает видео в нужный формат уже во время записи видео
4. Позволяет задать множество параметров

Минусы:

1. Сложен в настройке, но используя VirtualDub или WinFF, можно упростить процесс подбора командной строки

CamStudio плюсы:

1. Пишет как полный экран, так и регионы
2. Удобен в использовании 
3. Нет ограничений. Бесплатный.

Минусы:

1. Не поддерживает расширенную настройку сжатия видео. Для сжатия вам придется использовать тот же VirtualDub/FFmpeg/WinFF либо другой софт
2. Субъективно съедает больше ресурсов системы при записи видео 

Редактирование видео и добавление аннотаций после записи: 
В данный момент, я использую Windows Movie Maker. Не все устраивает, но лучшей альтернативы я еще не нашел.

Аннотирование видео в момент записи:
Epic Pen – замечательный инструмент. Позволяет рисовать на рабочем столе прямо во время записи, так что процесс аннотирования происходит в реальном времени, и вы не тратите время на пост-обработку


Ну, и скриншоты
Greenshot – мой выбор. Простой, бесплатный инструмент со всеми необходимыми возможностями.

Демонстрация работы FFmpeg + ScreenCapturer и Epic Pen:

Бесплатный Microsoft Expression Encoder 4 для записи багов

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

Microsoft ExpressionEncoder 4 – это бесплатный инструмент, с вполне приемлемыми ограничениями этой самой бесплатности. EE4 Screen Recorder записывает видео продолжительностью до 10 минут. Но, этого времени вполне достаточно для записи шагов воспроизведения бага в приложении.

Раньше для этих целей я использовал Сamstudio для записи и WinFF для конвертации видео.

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


Я ни в коем случае не отказываюсь от дальнейшего использования Сamstudio для записи скринкастов продолжительностью более 10 мин. 

Мега полезный и интересный доклад: Advanced Web Debugging with Fiddler

Сегодня я посмотрел мега полезный доклад Mehdi Khalili:  Advanced Web Debugging with Fiddler.
Если Вы еще не с Fiddler, или использовали из всего его функционала только табу «Inspectors» – я настоятельно рекомендую посмотреть этот доклад.

Мехди делится множеством полезных советов по использованию инструмента. И говорит, что Fiddler’ом пользуются даже домохозяйки, далекие от IT и тестирования. Да, да… для накрутки рейтинга в Веселых Фермах :)

Более детально о докладе можно прочитать тут:
http://www.mehdi-khalili.com/advanced-web-debugging-with-fiddler

Видео:

Кому понравился этот доклад, давайте устроим небольшой флэшмоб, и твитним что-то следующего характера:

Спасибо / Spasibo / Thanks @MehdiKhalili for your great presentation on Advanced Web Debugging with Fiddler mehdi-khalili.com/advanced-web-d…
— dzhariy (@dzhariy) April 25, 2012

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

ATDD и Specification by Example с примерами на Java

Очень классная презентация, речь в которой идет о процессах ATDD, Specification by Example, рассматриваются примеры автоматизации, в том числе паттерн PageObject. Рассматривается инструмент отчета по тестированию Thucydides и многое другое.
Хотел бы я еще и доклад посмотреть, эхх…  

UPD: Спасибо Виталию, за ссылку на видео доклада:
http://irishdev.com/Home/Events/614-Thucydides--Web-Testing-for-Devs.html

Completing the circle - Automated web tests as a team communication tool

View more presentations from Wakaleo Consulting

Скринкаст (запись рабочего стола) при помощи ffmpeg под Windows

Наконец-то я нашел подходящий мне способ записывать скринкасты под Windows. Мне это необходимо для записи работы авто-тестов.

Такая видеозапись может рассказать больше лога + из видео можно сделать скриншоты для бага.

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

Во-первых, необходимо скачать сам 32-битный FFmpeg http://ffmpeg.zeranoe.com/builds

Затем установить Microsoft Visual C++ 2010 SP1 Redistributable Package (x86): http://www.microsoft.com/download/en/details.aspx?id=8328 И самый важный ингредиент: виртуальный драйвер устройства для захвата экрана: http://sourceforge.net/projects/screencapturer

А теперь просто запускаем команду:

ffmpeg -f dshow -i video=screen-capture-recorder -r 24000/1001 -q 1 out.avi

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

Так можно даже игрушку записать без особых тормозов:

P.S.: Скринкасты мануальных тестов я записываю при помощи CamStudio и конвертирую при помощи WinFF.

Англоязычные посты по этой теме:

FFmpeg, Screencast Windows (источник)

ffmpeg screen capture directshow windows

Бесплатный онлайн курс для начинающих и продолжающих тестировщиков

Парадокс. Михаил Портнов – это известный преподаватель (а для многих и учитель) дисциплины тестирования программного обеспечения.
А парадокс в том, что на родине и на просторах СНГ о нем очень мало кому известно. Конечно, же, есть узкие круги форума govorimpro.us… но, по-моему это незаслуженно мало.

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

Ссылка на курс по тестированию ПО:
Онлайн курсы/школа тестировщиков программного обеспечения

УЧЕБНЫЙ ПЛАН:

1. Введение: История возникновения профессии, в чем ее суть, наш курс
2. Тестирование Graphic User Interface в Windows и ВЕБ приложениях
3. Учебный проект: ResumeBuilder. Спецификация, тестирование Graphic User Interface, bug reports
4. Учебный проект: ResumeBuilder. Функциональное тестирование, Bug Reporting rules
5. Bug Tracking Databases: Elementool. bug reporting form; creating custom views; bug life cycle
6. Документация в тестировании ПО. Тест План, Тест кейс, Тест Дизайн.
7. Учебный проект Energy-Telecom: требования, назначение, GUI и функциональное тестирование
8. Energy-Telecom project: Testing WEB forms
9. Американское резюме - формат, структура, типичные ошибки при написании
10. Сопроводительное письмо и вопросы на собеседовании

Мое любимое видео:

CukeUp!: Matt Wynne on Refuctoring Your Cukes

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

Именно эту проблему поднимает Matt Wynne в своем докладе Refuctoring Your Cukes и дает полезнейшие советы, как применяя простые практики ре-Fuck-торинга сохранить свое рабочие место.

CukeUp!: Matt Wynne on Refuctoring Your Cukes from Dmitry Zhariy on Vimeo.

Refuctoring Your Cukes
Cucumber aims to help business stakeholders and developers collaborate more effectively. That's great if you care about helping your project succeed, but what about the rest of us who just want to hang on to our damn jobs? In this talk you'll learn how to use Mortgage-Driven Development (MDD) to destroy the readability and value of your Cucumber tests, so that you can protect your position as the only person who understands what the system does

Source: http://skillsmatter.com/podcast/agile-testing/refuctoring-your-cukes

Более подробно о докладе: CukeUp!: Matt Wynne on Refuctoring Your Cukes

Specification by Example: A love story (Alister Scott)

На недавно прошедшей конференции “Watir Bazaar” прозвучал интереснейший доклад Алистера Скотта по теме “Specification by Example: A love story”. Видео доклада вы можете просмотреть по следующей ссылке:
http://kondoot.com/videos/224a1105b17

Слайды этого и других докладов находятся здесь:
https://github.com/watir/watir-bazaar/wiki/Presentations

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

Feature: Beautiful Tea Shipping
Scenario: Free shipping in Australia
Given I am on the Beautiful Tea homepage
When I search for ‘Byron Breakfast’ tea
Then I see the page for ‘Byron Breakfast’ tea
When I add ‘Byron Breakfast’ tea to my card
And I select 10 as the quantity
Then I see 10 x ‘Byron Breakfast’ tea in my card
When I select ‘Check Out’
And I enter my country as ‘Australia’
Then I see the total including GST
And I see that I am eligible for free shipping

Scenario: No free shipping outside Australia
Given I am on the Beautiful Tea homepage
When I search for ‘Byron Breakfast’ tea
Then I see the page for ‘Byron Breakfast’ tea
When I add ‘Byron Breakfast’ tea to my card
And I select 10 as the quantity
Then I see 10 x ‘Byron Breakfast’ tea in my card
When I select ‘Check Out’
And I enter my country as ‘New Zealand’
Then I see the total without GST
And I see that I am eligible for free shipping

Scenario: No free shipping in Australia
Given I am on the Beautiful Tea homepage
When I search for ‘Byron Breakfast’ tea
Then I see the page for ‘Byron Breakfast’ tea
When I add ‘Byron Breakfast’ tea to my card
And I select 1 as the quantity
Then I see 1 x ‘Byron Breakfast’ tea in my card
When I select ‘Check Out’
And I enter my country as ‘Australia’
Then I see the total including GST
And I see that I am not eligible for free shipping

С трудом дочитав это до конца, я понял, что есть какая-то разница между Австралийцами и Новозеландцами. И то, что Австралийцы не хотят доставлять своим соседям из Новой Зеландии чай ‘Byron Breakfast’ на халяву. Дискриминация просто налицо. Кроме того, оказывается что мне, жителю Австралии, бесплатная доставка положена, только если я закажу 10 упаковок чая ‘Byron Breakfast’.
И не положена, если я закажу одну упаковку. А если 5?
Кроме того, мне абсолютно непонятно, почему я должен платить некий GST, а эти ссс… соседи из Новой Зеландии его не платят. А что если я сделаю заказ из Украины? Я буду платить этот GST? (фиг его знает, что это такое, напридумывают тут аббревиатур)

Но исправленный пример для той же самой фичи просто открывает глаза:

Feature: Beautiful Tea Shipping Cost

• Australian customers pay GST
  
• Overseas customers don’t pay GST
  
• Australian customers get free shipping for orders $100 and above
  
• Overseas customers all pay the same shipping rate regardless of order size
  

Scenario: Calculate GST status and shipping rate

Given the customer is from <customer’s country>
When the customer’s order totals <order total>
Then the customer <pays GST>
And they are charged <shipping rate>

Examples:

customer’s country	pays GST	order total	shipping rate
Australia	Must	$99.99	Standard Domestic
Australia	Must	$100.00	Free
New Zealand	Must Not	$99.99	Standard International
New Zealand	Must Not	$100.00	Standard International
Zimbabwe	Must Not	$100.00	Standard International

И мне, как человеку с улицы, как-то стает более ясна общая картина задуманной фичи.
Во-первых из заголовка я понимаю, что есть некоторые законы, которые заставляют платить этот GST только австралийцев. Во-вторых… ну какой нафиг чай? Речь вообще идет о сумме заказа. Заказал на 100 баксов и более – получи бесплатную доставку, если ты австралиец. Заказал на 10 баксов – плати за доставку.

В первом варианте описания фичи было откровенное нечитабельное месиво из чая, кнопки Check Out, GST и австралийцев. За деревьями не видно леса. Второй вариант короче, но четко описывает фичу и дает хорошие примеры. Теперь нам не нужно переписывать тест-кейсы всякий раз когда цена на чай падает.

Кроме того, я уверен что автоматизировать тестирование этой фичи теперь стало еще проще по сравнению с предыдущем вариантом.