— Требования?
— Не, не слышали.
— Ну, а заказчик что хочет?
— ¯\_(ツ)_/¯

После всего этого тестировщик думает: куда я попал? И вообще куда я шёл и туда ли я иду?

Это состояние тестировщика называется неопределенностью.

Как я раньше страдала, попадая в эту самую неопределенность! Тебе дали задачу, но не сказали, что с ней делать. Опыта у тебя ноль. Хотелось все бросить и сказать: «Это мы не проходили, это нам не задавали».

Что я чувствовала:

  • Растерянность. С чего вообще начать?
  • Дискомфорт от неопределенности. Что будет, если я это не сделаю?
  • Страх ошибки. А что, если я это сделаю, но неправильно?

Затем с ростом экспертизы и понимания процессов (как оно все работает) мне становилось всё проще и проще при столкновении с неопределенностью: пфф, сейчас разберемся.
Теперь любая ситуация неопределенности заставляет искать решения: при решении каких-то сложных задач я вижу возможности. А вот ошибаться я не перестала. Но страх ошибки стал гораздо меньше, и я всегда пользуюсь формулировкой «давай попробуем». И знаете, чаще таки получается!

Толерантность к неопределенности — способность человека работать и принимать решения в условиях неопределенности.

Что приятно, эту способность можно в себе развить.

Давайте посмотрим, что можно сделать с неопределенностью на паре примеров из жизни тестировщика в «Тамтэк». Все совпадения неслучайны.

История 1: Заказчик не вовлечён

Проект примерно на полгода. Стартап. Много хотелок от заказчика, но нет понимания, как это всё вместе должно работать, плюс активное игнорирование фазы приёмки. Вот сделали мы хороший кусок функциональности, протестировали, передвигаем в колонку «Ready for acceptance» и тишина…

Какой тут основной риск? Правильно, мы могли что-то сделать не так, как хотел заказчик. А он нам не даёт обратную связь.

Мы начинаем пинговать заказчика: «Проверь, пжлста!» А он такой: «Ок, сделаю». И опять тишина.

Неопределённость? Ещё какая!

Начинаешь сомневаться в своём английском. Вдруг ты что-то ляпнул, а тебя не так поняли. Или мы не вполне четко договорились о процессе приемки нашей работы. И еще десяток мыслей в голове по этому поводу. А человек — он такой: если есть неопределенность, то мы начинаем додумывать, исходя из своего опыта и фантазий.

А дело оказалось в том, что заказчик просто не понимал, как это можно проверить! Что у нас с окружениями, куда надо идти, какие исходные данные нужны, чтобы получить нужный результат.

Решение

Наш тестировщик взял и создал документ «Как проводить приемочное тестирование». В нем он расписал, что у нас с окружениями, где и какая документация лежит, ссылки на сторонние сервисы и шаги со скриншотами, как тестировать.

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

История 2: Дирижабль и «паркетник»

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

—  Что это и с какой стороны подойти?
— Да тут всё просто. Надо в Zeppelin’e скриптец на Scala написать, чтобы тот распарсил выходные паркетники, и посмотреть, что все параметры на месте и нет ничего лишнего.
— WTF о_О???

Неопределенность? Да полная! Непонятно было всё:

  • Что такое Zeppelin? Я пока знаю только, что это дирижабль такой.
  • Как писать на Scala?
  • Кто такие паркетники? У меня в голове этакий облегченный вариант внедорожника.
  • Какие должны быть параметры в этих паркетниках? А каких не должно быть?!

Неопределенность? Да полная!

Что делать?

  • 5 минут медитирую/саморефлексирую, не больше.
  • Читаю Wiki проекта, иду в гугл, ищу информацию во всех доступных источниках.
  • Что не смогла найти, спрашиваю.

Паркетники — это файлы особого формата, с вот такой-то структурой. Zeppelin — это такое вот крутое приложение, где можно работать с большим объемом сырых данных. Вот тебе доступы, вот тебе примеры других пользователей. А в этих примерах и скрипты оказывается похожие есть. 

Всё —  проблемы нет, пошла тестировать.

К чему я про все эти истории? Таких примеров масса, и с неопределенностью мы живем каждый день. Значит, нужно уметь с ней справляться, повышать к ней свою толерантность.
Давайте посмотрим, что можно сделать.

Стратегия 1. Создай определённость сам

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

Стратегия 2. Прими неопределённость

Речь о безусловном принятии неопределенности как факта, на который невозможно повлиять.

К примеру:

  • самолет задерживается на 5 часов. Неопределенность? Да. Повлиять возможно? Нет. Тогда лучше я пойду и займусь тем, чего мне так хочется: почитать и поспать (в капсульном отеле, например).
  • новый контракт проекта, который неизвестно когда стартует. От меня это не зависит, но я могу с пользой провести свободное время и изучить новые технологии/инструменты, которые понадобятся.

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

Чтобы научиться жить и работать в условиях неопределенности, можно и нужно прокачать следующие сверхспособности:

  • самостоятельно находить данные,
  • ставить задачи (была проблема, стала решаемая задача),
  • формулировать вопросы (!),
  • оценивать начальные условия,
  • пересматривать начальные условия (то, что было вчера, сегодня может быть уже неактуальным).

Напоследок слова одного страшно высокооплачиваемого бизнес-тренера Т.Роббинса:

«Качество вашей жизни прямо пропорционально количеству неопределенности, с которым вы можете комфортно жить». 

Творчество этого тренера под большим сомнением, а вот слова эти мне нравятся. Так что пусть останутся тут.

Ольга Ипполитова, QA Engineer

RSS