Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

.
Тест-анализ и тест-дизайн
Баги клавиатуры: тестирование в реальной жизни, часть 3
27.12.2019 00:00

Автор: Кассандра Ланг (Cassandra H. Leung)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Часто ли вы задумываетесь о тестировании методов ввода? Клавиатура, мышь, тач-скрин, загрузка, камера, или что угодно иное – все это методы ввода, а ввод - важная часть практически всех приложений. Так как экранная клавиатура обычно рассматривается как часть устройства (к примеру, смартфона или планшета), или даже как отдельное приложение – вы, возможно, не планируете тестировать ее в ходе проверки использующего такую клавиатуру приложения. Однако я неоднократно обнаруживала, что тестировать экранную клавиатуру в приложении надо так, как будто бы она неотъемлемая часть вашего продукта. Неважно, как вы это назовете – интеграционным тестированием или каким-то иным. Важно, что пользователи заметят, если клавиатура криво работает с вашим приложением, и все нежелательные варианты поведения могут повлиять на их решение пользоваться приложением впредь.

Подробнее...
 
Как документировать тестирование при помощи SBTM: тестирование в реальной жизни, часть 2
18.12.2019 00:00

Автор: Кассандра Ланг (Cassandra H. Leung)
Оригинал статьи
Перевод: Ольга Алифанова

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

В этой статье я дам ряд практических советов по документации исследовательского тестирования при помощи отчетов сессионного тест-менеджмента (SBTM). Тут можно узнать о SBTM больше.

Подробнее...
 
Записная книжка тест-дизайнера, часть 2: вдохновение тестировщика
13.12.2019 10:55

Автор: Рикард Эдгрен (Rikard Edgren)
Оригинал
Перевод: Ольга Алифанова

Часть 1

Часто (и по праву) говорят, что нужно учитывать куда больше, нежели явные требования, чтобы быть в состоянии хорошо тестировать[1].

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

Подробнее...
 
Записная книжка тест-дизайнера, часть 1: общая информация
03.12.2019 00:00

Автор: Рикард Эдгрен (Rikard Edgren)
Оригинал
Перевод: Ольга Алифанова

Мы начинаем публиковать перевод книги Рикарда Эдгрена "Записная книжка тест-дизайнера". В первой главе книги он говорит о теоретической основе тест-дизайна, его научной базе и особенностях пространства тестирования.

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

Я начал разбираться в этом вопросе глубже, когда в сто пятый раз ощутил, что существующие техники тест-дизайна не отражают мой подход после десятилетней работы с одним и тем же набором продуктов. Это вылилось в расширенную генерализацию идей, о которых я узнал благодаря коллегам (я учился у всех своих коллег, но особенно у Хенрика Эмилссона и Мартина Янссона. Библиография отражает наиболее важные моменты. Хочется также поблагодарить рецензентов, которые потратили свое время на то, чтобы сделать ценные замечания: это Роберт Бергквист, Лиза Криспин и Мэтью Хоссер).

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

Я хочу сделать упор на результатах тестирования, на широкой выборке, делающей возможными озарения (концепция "озарения" набирает популярность в тестировании, впервые, насколько я знаю, об этом написал Джонатан-Бах в статье Session-Based Test Management – журнал "Software Testing and Quality Engineering", 11/00, см. также Rikard Edgren, Testing is an Island, A Software Testing Dystopia, EuroSTAR conference 2008) и нацеленной на полноценное освещение важных областей (об освещении областей см. Rikard Edgren, Is your testing saturated?). Возможно, книга лучше всего подойдет ручным тестировщикам, которые концентрируются на важных проблемах – людям, которые хотят выяснить важную информацию, а не удовлетворяются соответствием или несоответствием требованиям.

Книга рассказывает про методы тест-дизайна, которые долгое время применяются как мной, так и многими другими тестировщиками (о работе тестировщика написано много статей, но Фиона Чарльз затронула основные моменты в статье Modeling Scenarios using Data).

Подробнее...
 
Тестирование текстового поля
29.11.2019 00:00

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

Текстовое поле в приложении кажется таким обычным делом, однако это одна из наиболее важных вещей, которую мы можем протестировать. Почему? Потому что текстовые поля дают доступ к приложению и его базе данных. Валидация текстового поля – это то, что предотвращает появление в базе плохих данных. Эти данные могут вызвать разнообразные проблемы для пользователей и разработчиков. Валидация также предотвращает атаки межсайтового скриптинга и SQL-инъекции.

Подробнее...
 
Легкий способ бросить тест-кейсы (часть 7)
27.11.2019 00:00

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

В ходе этого цикла статей мы ищем альтернативу подходам к тестированию, основанным на артефактах – а именно, подход, основанный на деятельности.

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

Подробнее...
 
Как понимать, что именно тестировать: тестирование в реальной жизни, часть 1
25.11.2019 00:00

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

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

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

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

Подробнее...
 
Тестирование CRUD, часть 2 – обновление и удаление
14.11.2019 00:00

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

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

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

Подробнее...
 
Тестирование CRUD, часть 1: создание и чтение
11.11.2019 00:00

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

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

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

Подробнее...
 
Метод бисекционного деления в тестировании
21.10.2019 00:00

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

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

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

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

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

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

Подробнее...
 



Страница 1 из 7