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

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

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

Первое оправдание: я не знаю, как эта фича работает

Чересчур часто тестировщики просто следуют скудным указаниям, выданным разработчиком в стори, и не имеют ни малейшего понятия, а чем же они заняты. К примеру, "Прогони этот SQL-запрос и убедись, что результат = 1". Почему? Какую информацию получает этот запрос? Как вы узнаете, что ответ верный? Если окажется, что в этой фиче баг, как вы сможете доказать, что тестировали ее?

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

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

Второе оправдание: фичу невозможно протестировать

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

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

Третье оправдание: разработчик неправильно это закодировал

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

Четвертое оправдание: баг пропустил другой тестировщик

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

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

Пятое оправдание: на тестирование не хватило времени

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

Шестое оправдание: если я оформлю баг, найденный на проде, меня спросят, почему я раньше его не нашел

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

Седьмое оправдание: я не умею программировать

Разработка ПО серьезно изменилась за последние двадцать лет. Раньше компании выпускали релизы каждые полгода, и у тестировщиков была куча времени на регрессионное тестирование. Теперь ПО выпускается каждую неделю-две. Просто невозможно вручную проверить приложение целиком в такие сроки, и поэтому автоматизация необходима, а вам нужно учиться автоматизировать! Брать университетский курс по Java для этого совершенно необязательно. Все языки программирования основаны на очень простых логических принципах, которые легко понять. Единственная сложность – это синтаксис используемого языка, и чем больше вы знакомитесь с кодом, тем больше вы будете в нем понимать.

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

Начинайте с малого! Вам не нужно сразу же все изучить. Рассматривайте изучение кода, как изучение нового языка. Когда вы учите язык, никто не ожидает, что вы будете свободно на нем общаться на следующий же день. Вы выучиваете несколько фраз и используете их, и постепенно добавляете и добавляете лексику.

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

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