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

У нас есть обратный поток в JMS, но обычно мы отправляем сообщения в EMS (Tibco). Тут возникла задачка отправлять сообщения сразу в два потока: EMS и RabbitMQ.

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

1. Настройка включена, параметры настроены — все работает.
2. Настройка включена, параметры не настроены — в лог падает ошибка.
3. Настройка выключена, параметры настроены — сообщения НЕ уходят, настройка то выключена.
4. Настройка выключена, параметры не настроены — сообщения не уходят, проверки на корректность параметров нет (ошибки не валятся).

См также:

Применение класса «ноль-не ноль» при подключении к JMS — подробнее о том, почему именно такие тесты.

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

Типы границ на примере стиральной машинки

Это статья из серии «Теория в картинках»

В моей классификации есть всего три типа границ (мнемоника ЛТП):

• Логическая — ограничение, накладываемое логикой, не программой.
• Технологическая — ограничение, накладываемое используемой технологией
• Произвольная — ограничение, накладываемое аналитиком или разработчиком.

(Откуда взялась моя классификация, я тоже напишу, но чуть позднее в другой статье. Скажу лишь, что автор типов — Алексей Баранцев, переиспользовать в книге / статьях разрешение давал)

Типы границ на примере стиральной машинки

(Пример любезно предоставлен Юлией Мироновой)

У вас есть стиральная машинка.

1. Логическая: нельзя засунуть меньше 0 киллограммов белья. Это логика.

Не заставляйте меня думать. Стив Круг

Ссылка на OZON

Боже мой, где эта книга была раньше? Это же просто прекрасно! Книга о юзабилити, которая.. юзер-френдли! Тонкая, много картинок, большие отступы между абзацами, читается легко и быстро... Must read!

Как сам автор пишет, он хотел, чтобы его книгу можно было прочитать за время перелета или другого длительного ожидания, но одного. Это круто! Тоже хочу такую книгу. На самом деле я свою книгу для начинающих исходно планировала как второго Савина, тоже тоненькую. Мол, что там такого рассказывать то? Но что-то где-то пошло не так ツ Будет толстая, как серия «Head First O`Reilly». Ну и ладно! Зато у меня примеров реальных много, это полезно. Но потом! Потом хочу тоненькую книжку, вот как эта от Стива Круга )))

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

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

Я при чтении не чувствовала какого-то раздражения из серии «здравствуй, кэп». Да, многое кажется очевидным, но при этом в духе «Да! Да! Именно так и надо», а не «Пффф, я и так это знал» ツ

Мысли, которые я себе выписала:

Мнемоники: БЛОК, СЛОН и NOPE

На моем курсе «Школа для начинающих тестировщиков» есть творческое задание — придумать свою мнемонику по тестированию! Разумеется, оно необязательное ツ

Посмотрите, что придумали ребята на этот раз!

Михаил: БЛОК

Вера: СЛОН

Тест должен быть конкретным!

Прочитав тест, я должна понять:

• Что мне сделать;
• Как это сделать;

Допустим, мы тестируем навесной замок:

Как будем тестировать? "Ну, я его открою и закрою" или “проверить, что он открывается и закрывается” — это не тест.

Классы эквивалентности для строки, которая обозначает дату

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

Но потом доходит до дела и сразу ступор: а как применять классы эквивалентности где-то еще? Ладно, используем правило «ищи число»: если речь идет о поле с символами, берем длину поля (число) и тестируем на границы. Вроде все хорошо, логично и понятно.

Однако на своих студентах я заметила, что это правило стало серебряной пулей. Если это нечисловое поле — по границам тестируем ТОЛЬКО на длину. Точка. Просишь протестировать дату, получаешь примерно такой ответ:

• Нормальная дата (17.03.2018)
• Дата «в прошлом» или «в будущем» (смотря что подходит под ваше ПО)
• Пустое поле
• Нафигачили туда 100500 символов
• Ввели «0»

За сим границы и проверены. И даже ноль проверен, чем тренер недоволен? А тренер недоволен тем, что по границам вместо ДАТЫ тестируется СТРОКА. Поэтому я предлагаю написать проверки именно для даты. И прежде, чем читать дальше, отложите книгу в сторону и попробуйте сами набросать эти проверки.  А потом сравните, все ли вы нашли?

Четкий формат дд.мм.гггг

Допустим, я могу ввести в профиле свою дату рождения и система сама посчитает, сколько мне лет. Формат даты известен заранее, на поле стоит маска, дату в другом формате я ввести не смогу.

Додо книга

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

Отличная книга из серии success-story про развитие бренда, как книги про Starbucks, Zappos, Toyota и т.д. Тоненькая, читается легко и быстро, я за пару поездок в метро прочитала.

В книге рассказываются концепции бренда, но соотношение «теория-практика» самое мощное из всех книг про бренды. Тут нет воды, сплошные истории из жизни. Очень интересно читать ツ

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