Интервью начальника отдела контроля качества программного обеспечения Промсвязьбанка Елены Ролиной генеральному директору компании Перфоманс Лаб Юрию Ковалеву.
Можно ли предугадать качество программного продукта в условиях, когда зачастую невозможно протестировать его “от” и “до”? Начальник профильного подразделения ПСБ Елена Ролина отвечает на этот вопрос утвердительно.
В интервью генеральному директору компании Перфоманс Лаб Юрию Ковалеву она рассказала о том, как работает “шар предсказаний” подразделения банка по контролю качества, а также о значимости компетенций отдельного специалиста и об аккуратном подходе к внедрению гибких методологий разработки.
Генеральный директор Перфоманс Лаб
Начальник профильного подразделения ПСБ
-- Елена, расскажите немного о себе: давно ли вы работаете в сфере контроля качества банковских продуктов?
-- Расскажите, как выстроен процесс тестирования в ПСБ. Какие задачи вы ставите перед специалистами по QA?
— В нашем банке мы разделяем процесс тестирования и контроля качества.
Что я имею в виду? В крупных организациях зачастую возникает ситуация, когда соседние команды, работающие над продуктом и сервисом, не используют наработки друг друга, по сути решая похожие задачи и тратя время и ресурсы в двойном размере.
Впервые ПСБ столкнулся с такой рассинхронизацией несколько лет назад, и тогда мы пришли к мысли о необходимости выстраивания в банке IT-горизонтали по обеспечению контроля качества программных продуктов.
Эта IT-горизонталь представляет собой совокупность методологов и специалистов, которые определяют наиболее целесообразные подходы и инструменты для проектов банка в части тестирования.
Таким образом мы определяем уровень их качества на входе, в дальнейшем контролируем, что процессные договорённости соблюдаются.
Что касается непосредственно тестирования, то в ПСБ представлены все основные его виды – ручное функциональное, интеграционное, автоматизированное и нагрузочное. При этом для решения важных задач в сжатые сроки мы активно привлекаем и авторизованных подрядчиков.
-- Как вы считаете, тестирование – это самостоятельная инженерная область со своими технологиями и правилами или деятельность с нулевым порогом вхождения, где могут быть успешными практически все?
— В целом обеспечение качества программного продукта – это самостоятельное и многогранное направление IT-индустрии. У него есть широкая аудитория, большое количество векторов для развития специалистов и разнообразные функции.
Для успешного вхождения в эту область первостепенную важность имеют даже не профессиональные навыки, а определенный склад характера и ума. Поэтому сегодня я встречаю в своей практике случаи, когда в тестирование уходят успешные специалисты из других IT-сфер: аналитики, разработчики, проектные менеджеры. При этом я имею в виду тестирование в более широком аспекте – обеспечение качества продукта в целом.
Мы не могли бы наблюдать такое явление в случае отсутствия должной зрелости и самостоятельности этого направления.
-- Сегодня необычайно популярна автоматизация тестирования. Если уподобить тестирование процессу лечения больного, то где здесь, с вашей точки зрения, место автоматизации?
— Предлагаю немного раздвинуть границы этой аналогии. Я бы сравнила автоматизацию с системой профилактики заболеваний, которую в свое время строил Советский Союз. Главной ее целью было недопущение недуга, а основополагающим принципом – действовать до появления проблемы и прививать культуру самосохранения.
-- Мне кажется, это сравнение хорошо подойдет и для описания процесса тестирования в целом. Еще удачно смотрится аналогия со страховкой. Когда человек покупает страховку, то не ждет возврата за инвестиции.
Он просто понимает, что защищен в случае непредвиденных ситуаций. С тестированием такая же история. Хотел спросить о требованиях к навыкам специалиста.
Давайте предположим, что в один из проектов ПСБ требуется тестировщик. Есть два кандидата на это место. Первый не обладает знаниями о технологиях и инструментах, которые нужны на конкретном проекте, но зато имеет солидный опыт тестирования. Второй, наоборот, не может похвастаться практическими навыками, зато хорошо подкован в теории. Кого бы вы наняли и почему?
Единственно верного ответа на этот вопрос нет. Выбор того или иного кандидата будет обусловлен спецификой проекта, составом имеющейся команды, ожиданиями заказчика и другими факторами. За время работы в ПСБ я нанимала людей и со знанием конкретных инструментов, и с практическим «бэкграундом», и с методологическим опытом. Каждое решение имело свои последствия – иногда позитивные, иногда не очень. Благо, в банке нет недостатка в разноплановых задачах, что позволяло всегда найти выход из ситуации.
Если абстрагироваться от требований конкретных проектов и говорить в общем, то для меня важнее склад характера человека, поэтому желание исследовать, смотреть под разными углами и умение кандидата специфически мыслить я ценю выше, чем знание того или иного инструмента.
Технологии и методологии быстро сменяют друг друга. Знание популярного инструмента может гарантировать трудоустройство сегодня, но завтра это преимущество сойдет на нет. Если специалист не вкладывается постоянно в свое развитие, то он быстро потеряет ценность на рынке труда.
Другими словами, я считаю, что изучить конкретную технологию под цели проекта проще, чем привить культуру тестирования как таковую.
-- Давайте поговорим про гибкие методологии. Они были призваны совершить революцию в процессе разработки программного обеспечения. Удалось им это сделать?
-- Опыт внедрения Scrum в работу Перфоманс Лаб сформировал у меня другой взгляд на эту проблему. Эта методология включает обязательные элементы. И те наши команды, которые реализовали их в полном объеме, заработали по новым правилам, не смогли этого сделать как раз те, кто адаптировал требования Scrum под себя.
— Я имела в виду не подход к работе или конкретные инструменты, а более общие понятия. Начинать внедрение гибких методологий необходимо с целеполагания.
Как мне представляется, не нужно ставить целью переход на Scrum или Agile в течение двух недель или даже двух месяцев. Сначала стоит опробовать отдельные элементы этих методологий и доказать сотрудникам их эффективность.
Нужна не ломка выработанных годами подходов, а их постепенная эволюция в сторону современных наработок.
-- Когда нужно принимать решение об успешном завершении тестирования? Когда все дефекты найдены или исправлены?
— Мы работаем с ожидаемым на выходе качеством программного продукта. Содержание этого понятия в каждом конкретном случае устанавливаем путем диалога между заказчиком и IT.
Бывает, что необходимо получить максимально отказоустойчивый и стабильно работающий программный продукт. Или же, наоборот, заказчику важнее получить решение максимально быстро, чтобы проверить ту или иную гипотезу.
Самое главное, чтобы обе стороны одинаково представляли себе результат работы и были готовы к возможным последствиям.
-- Известно, что при тестировании нужно сравнивать проектные трудозатраты на поиск и исправление дефекта с возможным ущербом от его попадания в среду эксплуатации. Как это сделать, если дефект не был найден?
— Здесь удачно подходит ваше сравнение тестирования со страховкой. В моем понимании ответ на этот вопрос лежит в области управления рисками.
Важно осознавать, какие риски снимает тот или иной вид тестирования, собирать информацию с промышленных сред, скрупулезно разбирать инциденты с попаданием дефектов в промышленную среду, определять критичность бизнес-процессов и договариваться с заказчиком об ожидаемом качестве выпускаемого продукта.
-- Говорят, что все протестировать невозможно. Следует ли из этого, что качество программного продукта всегда непредсказуемо?
— Я считаю, что предсказать качество продукта можно. В ПСБ мы собираем статистику по разного рода метрикам: задачи и ошибки, изменение требований, после выпуска анализируем критичность сбоев, локализуем проблемы релизов и ищем точки оптимизации. Это позволяет строить гипотезы в случае повторения сходных ситуаций в разных релизах и принимать решения в нестандартных условиях.
-- Мы тоже используем “предсказательную аналитику” в отношении разработчиков банковского программного обеспечения. Это позволяет нам при старте работ над новым проектом делать предположения по поводу качества софта.
— Для нас типичны ситуации, когда статистика помогала нам взглянуть не только на качество прошедшего релиза, но и позволила строить гипотезы и прогнозы и предугадывать возможное поведение того или иного процесса для будущих плановых обновлений системы. В командах иногда в шутку обещают подарить отделу контроля качества шар предсказаний, но он, по сути, у нас уже есть.
-- Существуют разные способы повышения корпоративных компетенций. Так, можно обучать или нанимать сильных специалистов, а потом развивать и удерживать их в компании.
Есть и другой путь – совершенствовать внутренние процессы, чтобы организацию не покидали с ключевыми сотрудниками знания и навыки. Что для вас наиболее предпочтительно и почему?
— Заменить ключевого сотрудника сегодня – это большая проблема. И дело здесь не только в его знаниях и навыках, но и в том, что процесс адаптации в компании, изучения определенных систем, выстраивания коммуникаций – настоящее искусство. Недаром люди, которое долго работают вместе, начинают друг на друга походить. Прямо как в семье. Поэтому свои кадры надо ценить и любить.
Необходимо помнить, что человеку на одном проекте свойственно «перегорать». Чтобы этого избежать, мы стараемся регулярно проводить ротацию сотрудников, предлагать им в кризисный момент новые возможности для развития.
Одновременно с этим ПСБ выстраивает и внутренние процессы, чтобы в условиях жесткой конкуренции на рынке IT-услуг не стать заложниками ситуации при переходе важных специалистов на другую работу.
