Home

Автор: Назина (Киселева) Ольга (автор тренинга Школа для начинающих тестировщиков)

Иногда баги сами нас находят. Вот мы впихали большую строку данных — и система подвисла. Это она из-за 1 млн символов упала? Или ей какой-то конкретный не понравился?

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

Если найти минимальные данные для воспроизведения, то:

• Вы сэкономите время разработчику — ему не придется подключаться к тестовому стенду, самому грузить файл и дебажить
• Менеджер сможет легко оценить приоритет задачи — это нужно срочно исправлять, или баг может подождать? Пока название «некоторые файлы падают, хз почему» — это сделать сложно...
• Описание бага от понимания причины падения тоже только выиграет.

Как найти минимальные данные для воспроизведения бага? Если есть какие-то подсказки в логах, применяем их. Если подсказок нет, то самый оптимальный метод — метод бисекционного деления (также известный как метод «деления пополам» или «дихотомия»).

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Мы, как тестировщики и автоматизаторы, часто обдумываем "Счастливый путь" – сценарий, которым пользователь с наибольшей вероятностью воспользуется в нашем приложении. Создавая автоматизированные UI-тесты, мы стремимся убедиться, что эти сценарии автоматизированы, а автоматизируя API, хотим проверить, что каждая конечная точка вернет "200 ОК" или схожий успешный ответ.

Однако о негативном тестировании тоже важно думать – как при ручном, так и при автоматизированном тестировании, и вот почему:

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Часть 1
Часть 2
Часть 3
Часть 4
Часть 5

В прошлый раз мы остановились на вопросе "Как сфокусировать работу тестировщика, который уже что-то знает о продукте, не переусердствовав в этом?"

В четвертой части этой серии статей я уже предлагал ряд примеров. Вот еще один: сценарное тестирование. Примеры, приведенные здесь, основаны на работе, проделанной несколько лет назад Джеймсом Бахом и Джорди Киттом (позднее я помогал ряду других организаций внедрять этот подход, но они не согласились делиться деталями).

Идея тут в использовании сценариев, направляющих тестировщика на пути исследования, экспериментирования и получения опыта на продукте. Все это должно давать ему идеи о реальном использовании и о том, как продукт можно использовать неправильно. Приятно верить, что тщательно проработанный дизайн, юнит-тесты, BDD и автоматические проверки предотвратят баги продукта – и они, безусловно, помогают в этом деле – но, перефразируя Гертруду Штайн, опыт учит опыт учит опыт. Простите за выражение, но если вы хотите найти проблемы, с которыми люди могут столкнуться при использовании продукта, то использование этого чертова продукта может, знаете ли, помочь!

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

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

Тестируя вывод, нужно думать о трех основных моментах:

Как отображается результат?

Отличным примером результата, внешний вид которого стоит проверить – это телефонный номер. Когда пользователь добавляет телефонный номер в базу данных вашего приложения, то этот номер (я надеюсь) сохраняется без любых скобок, точек и дефисов. Однако при отображении телефона для пользователя вы, возможно, не захотите выводить его как 8008675309 – это тяжело читается. Вы предпочтете, чтобы номер форматировался так, как этого ожидает пользователь. Для пользователей из США номер будет отображаться как 800-867-5309 или (800) 867-5309.

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Часть 1
Часть 2
Часть 3
Часть 4

Во время нашей тренинг-сессии Фрида все еще играла роль менеджера, одержимого тест-кейсами – и играла ее очень хорошо. Она разыгрывала типичную карту менеджмента "А как же изучение продукта? Ведь тест-кейсы – хороший способ для этого!"

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

Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

В конце этой статьи я попробую подобрать интересные и полезные ссылки про эвристики.

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Часть 1
Часть 2
Часть 3

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

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

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Часть 1
Часть 2
В прошлый раз "Фрида", моя клиентка на тренинге, спросила про разработку тест-кейсов для аудиторов и контролирующих органов. В курсе Rapid Software Testing мы считаем полезным называть это формализованным тестированием.

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

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

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова
Предыдущая статья

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

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

- Ваши тесты, или ваше тестирование? – спросил я.

- Насколько я понимаю, мои тесты. Я несогласна с этим, но пытаюсь посмотреть на вопрос с их точки зрения, - ответила Фрида.