Home

Автор: Кассандра Ланг (Cassandra H. Leung)

Оригинал статьи
Перевод: Ольга Алифанова

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

Первая часть – мой ответ на вопрос "Как вы узнаете, что вам тестировать?", заданного в клубе Министерства Тестирования.

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

В прошлый раз мы начали разбираться с тестированием CRUD. Как вы помните, CRUD означает "Create, Read, Update, Delete" (создание, чтение, обновление и удаление). В прошлый раз мы обсуждали тестирование создания и чтения, а теперь рассмотрим обновление и удаление.

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

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

Несмотря на непривлекательное название, тестирование CRUD очень важно! CRUD – это аббревиатура для Create, Read, Update, Delete (создание, чтение, обновление, удаление). Как знает любой тестировщик, большая часть нашего тестирования включает эти операции. Сегодня мы обсудим наилучшие способы тестирования создания и чтения.

Самое важное, что нужно знать, тестируя CRUD: недостаточно полагаться на то, что вы видите в интерфейсе, чтобы убедиться, что значение поля было создано или изменено. Это связано с тем, что интерфейс может кэшировать значения для более эффективной загрузки в браузере. Для того, чтобы абсолютно точно удостовериться, что значение изменилось, нужно проверить базу данных, где оно хранится. В результате вы убеждаетесь, что значение задано в двух местах – в интерфейсе и в базе данных. Если вы занимаетесь тестированием API, то можете подтвердить это в трех местах, но тестирование API мы сейчас затрагивать не будем.

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

Иногда баги сами нас находят. Вот мы впихали большую строку данных — и система подвисла. Это она из-за 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.