Buddy testing и Pair testing

Buddy testing (Совместное тестирование) — это когда два человека тестируют отдельно один и тот же модуль. У каждого свой взгляд на тестирование:

• Разработчик смотрит через призму кода.
• Тестировщик — через призму своих знаний и опыта. 

Потом можно сравнить результаты:

• Сколько багов нашли оба?
• Сколько только разработчик? Почему тестировщик их не нашел, каких знаний ему не хватает?
• Сколько нашел лишь тестировщик? Ну, молодец, чё! По статусу положено )))

Это необязательно должны быть разработчик и тестировщик. Любые два человека — два джуниор-тестировщика, один джуниор и один опытный, тестировщик и аналитик, тестировщик и разработчик... Но смысл всё тот же, сравнить результаты.

Pair testing (Парное тестирование) – это когда два человека тестируют вместе. Сидят за одним компьютером. Один печатает, второй подсказывает, что делать. Потом меняются местами. Или сначала обсуждают план, а потом уже один делает, второй смотрит.

Однозадачность. Девора Зак

 

Ссылка на OZON

Отличная книга для тех, кто верит в термин «многозадачность — это круто!». Это и правда последнее время стало модным. Кажется, что если ты не умеешь делать много задач сразу, то ничего не успеешь.

Но на самом деле это не так. Человек не может делать несколько дел параллельно. По крайней мере, «конкурирующих» за один и тот же участок мозга. То есть если вы что-то делаете на автомате (моете посуду, например), вы можете делать что-то параллельно. Разговаривать с другом, думать о предстоящем совещании...

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

Минуту внимания! Сэм Хорн

 

Ссылка на OZON

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

Другое дело — когда читаешь книгу по ораторике, готовясь к выступлению! Можно перечитывать то, что читал раньше, можно читать новую книгу. Да, идеи будут повторяться, да, вы это уже читали, но... Но именно сейчас чтение конкретных строк воодушевляет изменить свою презентацию!

Из-за короновируса о выступлениях на конференции я пока не думаю, так что и книгу отложила. Но когда разгребала свои книжные полки, обнаружила, что у меня две одинаковые книжки. Слишком много todoread, забываю, что там есть, вот и купила вторую случайно. Хотела отдать одну через пост, но ведь даже ссылочку поставить некуда, я то книгу ещё не читала. Так и решила прочитать.

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

Чек-лист для тестирования числового поля

При тестировании встречаются как интересные задачки с замудреной логикой, так и простые, вроде проверки простой строки или числового поля. Для простых полей можно один раз написать чек-лист проверок, а потом переиспользовать, лишь немного меняя под «своё» поле.

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

Ссылка на ХАБР

Итак, у нас есть некое поле, куда нужно вводить число. Например, поле «возраст» при регистрации:

При этом на сайте нельзя регистрироваться до 18 лет, есть запрещённый контент.

Какие проверки тут можно провести:

1. Корректные значения
2. Некорректные значения (за пределами валидных диапазонов или нелогичные: 200 лет, 88 секунд...)
3. Граничные значения
4. Пограничные значения
5. Дробное число — формат (через запятую и через точку)
6. Дробное число — округление (с кучей знаков после запятой)
7. Ноль
8. Один
9. Пустое поле
10. Очень большое число (поиск технологической границы)
11. Отрицательное число
12. Нечисловые и «не совсем числовые» значения

Где брать идеи для тестов (подборка полезных ссылок)

Вот выдали нам (тестировщикам) функционал и сказали: 

— Держи, тестируй!

А с чего начать? Для новичка это может быть целой проблемой. Особенно когда нет подробного ТЗ. Поэтому я решила создать эту подборку, где можно поискать вдохновение! 

Ссылка на ХАБР

Статьи 

Они обычно называются «классы эквивалентности для...», или «чек-лист для...», или «чит-лист для...», или как-то так. Вот вам мои подборки:

Текст

Тестирование текстового поля

Тестируем поля логин/пароль

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

Число

Чек-лист для тестирования числового поля

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

Дата

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

Что такое XML

Если вы тестируете API, то должны знать про два основных формата передачи данных:

• XML — используется в SOAP (всегда) и REST-запросах (реже);
• JSON — используется в REST-запросах.

Сегодня я расскажу вам про XML. В списке доп литературы будет ссылка на книгу по XML, у меня нет цели ее дублировать, но я расскажу про этот формат тем, кто XML еще в глаза не видел. А дальше уже гуглим сами ))

Ссылка на Хабр (там содержание кликабельное)

XML, в переводе с англ eXtensible Markup Language — расширяемый язык разметки. Используется для хранения и передачи данных. Так что увидеть его можно не только в API, но и в коде.

Этот формат рекомендован Консорциумом Всемирной паутины (W3C), поэтому он часто используется для передачи данных по API. В SOAP API это вообще единственно возможный формат входных и выходных данных!

См также:

Что такое API — общее знакомство с API

Введение в SOAP и REST: что это и с чем едят — видео про разницу между SOAP и REST.

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