Home

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

Последнее время я спрашивала кандидатов и коллег вот о чем: как бы вы это протестировали?

Я показывала им пользовательский интерфейс. Я показывала им один-единственный тест настроек API, возвращающий настройки. И я показывала им серверный файл конфигурации. Протестировать надо настройки.

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

Сделать то, что разработчик уже сделал локально в end-to-end окружении.

В значительном количестве случаев наблюдается применение еще двух правил:

Попробовать неожиданные / запрещенные значения.

Найти границу и проверить слишком маленькое / большое / адекватное значение.

Я говорила о результативном тестировании (современном исследовательском тестировании), и в этой связи я разочарована. Эти подходы крутятся не вокруг результатов, а вокруг рутины.

Значительное количество людей, занимающихся автоматизацией, применяет еще одно правило:

Случайность дает шанс на обнаружение.

Среди множества разговоров были и отрадные проявления. В лучших из них люди привязывали то, что они видят, к известному им миру ("локация – попробую свой домашний адрес") и пробовали вникнуть в концепции ("широта и долгота, как они выглядят?"). Лушчие автоматизаторы строили предположения, как узнать, что оно работает, как должно, для их случайных значений, и в ходе внедрения у них был шанс выяснить, как оно ломается, даже если они не смогли бы это объяснить.

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

Как оказалось, многие профессиональные тестировщики придают слишком большое значение негативному тестированию (валидации ввода), и слишком малое – позитивному тестированию, которое куда шире одного-единственного теста со значениями по умолчанию.

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

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

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

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

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

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

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

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

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

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