Home

Автор: Маарет Пюхяярве (Maaret Pyhäjärvi)
Оригинал статьи
Перевод: Ольга Алифанова

Преподавая тестирование различным людям в групповом и парном формате, я имею уникальную возможность наблюдать, что делают люди, когда их просят тестировать. Наблюдая за студентами, я уже знаю, что бы делала я, и как с задачей справлялись мои студенты ранее. Заметив, что студент что-то упустил, я начинаю следующие разговоры:

"Ты совсем не тестировал на реалистичных данных. Как думаешь, почему так случилось?"

"Ты концентрировался на всех неправильных вариантах, которые можно внести в числовое поле, но очень мало подумал о числах, которые можно туда ввести. Как думаешь, почему так случилось?

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

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

Я обычно задаю этот вопрос, зная, что опрашиваемый тестировщик пропустил баг. Релевантный баг. Или тестирует таким образом, что снижает общую эффективность, откладывая обратную связь о баге, который он, возможно, встретит, а возможно, и нет.

Я видела это столько раз, что сегодня готова указать на паттерн. Тест-дизайн ISTQB излишне упрощает классы эквивалентности и граничные значения, и это вредит нашей области.

Приведу совсем свежий пример с работы.

Моя команда только что внедрила новый пользовательский интерфейс, демонстрирующий определенный идентификатор аэропорта, который называется кодом ИКАО. Мы создали API настроек, дающий возможность получить эту информацию с бэкэнда, и файл настроек, в котором задан этот код.

С точки зрения пользовательского интерфейса этот код – единственное, что мы сейчас должны выводить. Если заглянуть в API и файл настроек, то можно найти и другую информацию, связанную с этим конкретным аэропортом – скажем, его ширину и долготу. Два числа, оба из них указаны как 50,9, потому что кто-то это там напечатал. Как бы вы это тестировали?

Я показала это разным людям, задавая свой вопрос.

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

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

Я начала с того, что спросила себя, какими бывают реальные локации и координаты, и как мне лучше сформировать репрезентативную выборку локаций реальных аэропортов. Я погуглила коды ИКАО, чтобы найти список из трех примеров, и без всякой особой причины выбрала третий код в списке, который оказался аэропортом Чикаго. Не могу воспроизвести весь поход в Google, чтобы объяснить, почему я выбрала именно его, но только для него маленькое информационное окошко на странице Google уже показало мне несколько комбинаций кодов и координат, из которых я выбрала 41.978611, -87.904724. Также, гугля, я узнала, что широты варьируют от 0 до 90, а долготы – от 0 до 180.

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

• Второе число должно быть отрицательным.
• Второе число должно быть длиннее четырех цифр.
• Второе число должно быть менее 90.
• Первое число должно быть положительным.

Наитие привело меня к багу высокого приоритета: реальному сценарию пользователя, который падает. Любая попытка анализировать путем простеньких классов эквивалентности и граничных значений в духе ISTQB тут проваливалась, вам нужен был анализ классов на основе риска в духе BBST, а также комбинаторное тестирование. Случайные числа, возможно, выявили бы баг, но не уверена, что он был бы исправлен так же быстро, как тот факт, что локация реального аэропорта не работает для функциональности, описывающей аэропорты.

Наше время ограничено, а ISQTB-подход к классам эквивалентности слишком концентрируется на негативных тестах. Когда падают позитивные тесты, команда подскакивает. Когда падают негативные, они вспоминают про обработку ошибок, если не происходит чего-то более интересного.

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

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

Обсудить в форуме