"Нашему отделу иногда предлагают подарить шар предсказаний, но он, по сути, у нас уже есть", – Елена Ролина, заместитель

Можно ли предугадать качество программного продукта в условиях, когда зачастую невозможно протестировать его "от" и "до"? Начальник профильного подразделения ПСБ Елена Ролина отвечает на этот вопрос утвердительно.

В интервью генеральному директору компании Перфоманс Лаб Юрию Ковалеву она рассказала о том, как работает "шар предсказаний" подразделения банка по контролю качества, а также о значимости компетенций отдельного специалиста и об аккуратном подходе к внедрению гибких методологий разработки.

- Елена, расскажите немного о себе: давно ли вы работаете в сфере контроля качества банковских продуктов?

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

- Расскажите, как выстроен процесс тестирования в ПСБ. Какие задачи вы ставите перед специалистами по QA?

- В нашем банке мы разделяем процесс тестирования и контроля качества.

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

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

Что касается непосредственно тестирования, то в ПСБ представлены все основные его виды – ручное функциональное, интеграционное, автоматизированное и нагрузочное. При этом для решения важных задач в сжатые сроки мы активно привлекаем и авторизованных подрядчиков.

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

- В целом обеспечение качества программного продукта – это самостоятельное и многогранное направление IT-индустрии. У него есть широкая аудитория, большое количество векторов для развития специалистов и разнообразные функции.

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

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

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

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

- Мне кажется, это сравнение хорошо подойдет и для описания процесса тестирования в целом. Еще удачно смотрится аналогия со страховкой. Когда человек покупает страховку, то не ждет возврата за инвестиции. Он просто понимает, что защищен в случае непредвиденных ситуаций. С тестированием такая же история. Хотел спросить о требованиях к навыкам специалиста. Давайте предположим, что в один из проектов ПСБ требуется тестировщик. Есть два кандидата на это место. Первый не обладает знаниями о технологиях и инструментах, которые нужны на конкретном проекте, но зато имеет солидный опыт тестирования. Второй, наоборот, не может похвастаться практическими навыками, зато хорошо подкован в теории. Кого бы вы наняли и почему?

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

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

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

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

- Давайте поговорим про гибкие методологии. Они были призваны совершить революцию в процессе разработки программного обеспечения. Удалось им это сделать?

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

- Опыт внедрения Scrum в работу Перфоманс Лаб сформировал у меня другой взгляд на эту проблему. Эта методология включает обязательные элементы. И те наши команды, которые реализовали их в полном объеме, заработали по новым правилам, не смогли этого сделать как раз те, кто адаптировал требования Scrum под себя.

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

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

Нужна не ломка выработанных годами подходов, а их постепенная эволюция в сторону современных наработок.

- Когда нужно принимать решение об успешном завершении тестирования? Когда все дефекты найдены или исправлены?

- Мы работаем с ожидаемым на выходе качеством программного продукта. Содержание этого понятия в каждом конкретном случае устанавливаем путем диалога между заказчиком и IT.

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

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

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

- Здесь удачно подходит ваше сравнение тестирования со страховкой. В моем понимании ответ на этот вопрос лежит в области управления рисками.

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

- Говорят, что все протестировать невозможно. Следует ли из этого, что качество программного продукта всегда непредсказуемо?

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

- Мы тоже используем “предсказательную аналитику” в отношении разработчиков банковского программного обеспечения. Это позволяет нам при старте работ над новым проектом делать предположения по поводу качества софта.

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

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

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

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

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

#интеревью #перфоманслаб #псб #тестирование # нагрузочноетестирование