На конференции Гейзенбаг, помимо основной программы, будет бонус от компании T-Systems: на её стенде проведёт небольшой мастер-класс сотрудник Герман Варгин, уже знакомый многим тестировщикам по выступлениям на других конференциях (вот даже Google Images всё про него понимает).
А в преддверии Гейзенбага мы решили узнать больше о том, как обстоят дела с тестированием внутри самой компании, и задали вопросы трём её сотрудникам: самому Герману, Андрею Павлову (он также известен своими докладами) и специалисту по внутренним коммуникациям Марии Зерновой.
Мария Зернова
— В прошлом году вы рассказывали нам, что в петербургском офисе T-Systems с Java-разработкой — а в тестировании Петербург для вас также очень значим? Какие проекты здесь тестируют?
— Да, тестирование очень важно для нашей компании, в Петербурге порядка 50% сотрудников занимаются тестированием разных проектов и сервисов компании. Среди наших проектов (а их в России более 150) есть проекты для BMW, швейцарских железных дорог (SBB), и тестирование осуществляется силами наших команд локально. Кроме того, у нас есть направление, обеспечивающее тестирование интеграции свыше 20 систем Deutsche Telekom. Они составляют единый ландшафт и обеспечивают работоспособность сети крупнейшего телекоммуникационного оператора Deutsche Telekom, нашей материнской компании. А в планах у нас создание центра автоматизации тестирования, который будет оказывать услуги концерну T-Systems по всему миру.
— У T-Systems есть школа Test School — а давно ли она существует? Много ли сейчас в T-Systems сотрудников, попавших в компанию благодаря ней?
— Школа существует с 2011 года. За это время её закончили более 200 человек, и минимум 130 работают в компании на самых разных должностях. Некоторые уже стали преподавателями в новых наборах Test School, некоторые возглавляют команды в роли тест-менеджеров. Сейчас у нас заканчивается юбилейная 25-я школа, а уже в августе стартует новый набор.
Герман Варгин
— Над чем вы работаете в T-Systems? И, поскольку вас интересует тема сертификации тестировщиков, скажите заодно, какими сертификатами обладаете сами?
— Я ведущий эксперт по тестированию в одном из проектов T-Systems. Мы разрабатываем программное обеспечение для наших клиентов в Германии. Дополнительно я веду различные курсы в нашей компании. У меня разработано несколько курсов для сотрудников разного уровня, и иногда я провожу группу для подготовки к ISTQB Advanced экзаменам. У меня несколько сертификатов ISTQB:
- ISTQB Certified Tester, Foundation level (2013)
- ISTQB Certified Tester, Advanced level – Test Analyst (2015)
- ISTQB Certified Tester, Advanced level – Technical Test Analyst (2015)
- ISTQB Certified Tester, Advanced level –Test Manager (2017)
— Как сертификация сказывается при работе в T-Systems? Например, имеет ли для заказчиков значение, чтобы их продукт тестировали сертифицированные специалисты, или им важно только «чтобы багов не было»?
— В T-Systems все очень положительно относятся к сертификации. Более того, любая инициатива по обучению и развитию специалистов всегда поддерживается компанией. Заказчик в проекте, где я работаю, сам является сертифицированным специалистом по тестированию. Поэтому он доверяет коллегам с сертификатами, говорит с ними на одном языке и больше поручает интересных задач, требующих комплексного подхода к решению. Конечно, не во всех проектах такая ситуация. Но я чувствую, что наличие подтверждённых знаний помогает нам открывать разные двери в T-Systems.
— Вы преподаёте в T-Systems Test School — а помогает ли это преподавание в основной работе? Оказывается ли, что сами лучше начинаете понимать что-то важное?
— Интересный вопрос и актуальный для меня. В последнее время я очень много уделяю времени преподаванию в T-Systems. В Test School я веду курс XML для выпускников вузов, которые только начинают свой путь в IT. Наша компания постоянно ищет специалистов, которые свободно говорят по-немецки. Сегодня на рынке таких людей практически не осталось. Поэтому иногда быстрее и легче найти толковых «филологов» с немецким языком и научить их хорошо тестировать. Оказывается, это гораздо проще, чем заставить технаря выучить немецкий язык. Соответственно, в нашей школе я научился буквально на пальцах объяснять людям, что такое XML, веб-сервисы и так далее. Эти навыки общения я часто применяю при работе с нашими клиентами, когда мне надо простым языком объяснить нашим бизнес-партнёрам различные технические детали.
Возвращаясь к основной теме вопроса, сошлюсь на свой курс ISTQB. Когда я подготовил все презентации и разобрал задачи для первой группы, я понял, что готов к экзамену гораздо лучше, чем в тот день, когда сам сдавал его. Поэтому, конечно, помогает. Чем чаще я работаю с теми или иными технологиями, тем лучше это у меня получается, и тем легче и быстрее применять все это в реальных проектных задачах.
— Вы ранее выступали с докладами на разнообразные темы — от перехода проекта к другой команде тестирования, до, наоборот, организации процесса тестирования с нуля. А работа в T-Systems, где много различных заказчиков и проектов, обычно и означает смену разных ситуаций? Или во многих случаях тестировщик подолгу работает над одним полюбившимся проектом?
— Да, подобных случаев хватает. Я знаю коллег в T-Systems, которые уже более 10 лет трудятся в одном проекте над тестированием любимого продукта. Я думаю, здесь все зависит от самого человека и его целей. Сам я работаю в своем текущем проекте уже 5 лет, и у меня до сих пор есть задачи, которые я перенимал у немецких коллег в 2012-м году. При этом я стараюсь вписываться во все дополнительные активности, которые мне предлагает T-Systems. Мои доклады основаны как раз на моём личном опыте, который я получил в T-Systems. Сначала мы выполнили передачу проекта из Германии в Россию. Потом, когда мы завоевали доверие заказчика, тестирование абсолютно новых продуктов он сразу доверил нам. Сейчас наша команда расширяется, количество систем, за которые мы ответственны, увеличивается, и постоянно появляются принципиально новые задачи.
— Можете ли вы как человек с большим опытом тестирования в аутсорсинговой компании сказать, в чём особенности по сравнению с продуктовыми — хоть технические, хоть организационные?
— Моя карьера складывается как раз из аутсорсингового опыта, поэтому о продуктовых могу лишь только предполагать.
В аутсорсинговых компаниях всегда есть множество промежуточных звеньев между теми, кто получает конечный продукт и теми, кто его разрабатывает. Это аналитики, тех. дизайнеры, архитекторы, ряд менеджеров и так далее. Часто бывает так, что разработчики и тестировщики из-за особенностей процесса не могут общаться с конечными клиентами. Разработчики не понимают бизнес, бизнес не интересуется техническими рисками, и так далее. Соответственно, тратится много времени на согласование требований, различные обсуждения, доведения до определённого уровня качества и время до выпуска продукта в релиз увеличивается в разы. Зато качество продуктов всегда остается высоким. Я думаю, что в продуктовых компаниях как раз время является решающим фактором. Если есть идея, как продукт может быть изменён, то быстро принимается решение, стоит это делать или нет. И если да, новая версия идет в продакшен как можно быстрее.
С технической точки зрения я думаю, никакой разницы нет. Я слышал, есть мнение, что продуктовые компании больше «болеют» за свои продукты. Но я с этим не согласен. В T-Systems мы постоянно работаем над тем, чтобы лучше понимать бизнес. Мы стараемся с каждым релизом тестировать все тщательнее, внедрять новые инструменты, увеличивать покрытие. Каждый раз, когда захожу в магазин T-Mobile в Германии, чтобы купить SIM-карту, я испытываю очень тёплые чувства, когда вижу софт, который именно мы тестировали в Санкт-Петербурге.
— На Гейзенбаге вы проведёте на стенде T-Systems мастер-класс — а о чём именно будете там говорить?
— У меня была тема для доклада, связанная с относительностью тестового покрытия. К сожалению, я не успел подать доклад из-за проектной нагрузки и командировки. В моём проекте зарубежные заказчики неожиданно стали неплохо разбираться в тестировании. Они всё качественнее делают ревью наших тест-кейсов и постоянно выдвигают новые требования. Иногда можно увидеть требования в духе «Нужно сделать 100% покрытие функциональных требований». Мы с вами знаем, что абсолютно всё мы проверить не можем. Поэтому к подобным задачам можно подходить по-разному, выполнять разное количество тестов и находить совершенно разные ошибки. По-моему это интересная тема для обсуждения. Мастер-класс продлится минут 15, и на нём мы разберём несколько бизнес-сценариев, напишем тест-кейсы, которые обеспечат максимальное тестовое покрытие этих сценариев.
Андрей Павлов
— В тестировании вы участвовали и в качестве тестировщика, и в качестве аналитика — а в данный момент какова ваша роль в T-Systems?
— В настоящее время я Test Team Lead в проекте TSO Process Test, занимающимся обеспечением качества систем Deutsche Telekom, отвечающих за одно из основных направлений работы концерна — предоставление клиентам услуг скоростного интернета, телефонной связи и цифрового телевидения.
Кроме того, я являюсь главой проекта внутреннего обучения компании, помогающего нашим специалистам постоянно расти и становиться настоящими экспертами в области тестирования.
— А как сказывается то, что у вас есть опыт и тестировщика, и аналитика? Ощущаете ли, что видеть картину с обеих сторон даёт принципиальное преимущество?
— Разумеется, чем больше различных ракурсов, с которых можно посмотреть на ситуацию, тем более широко видно картину в целом. Впрочем, большинство проектов в T-Systems имеют отдельную команду аналитиков, работающих с требованиями и всегда предоставляющих точные и подробные спецификации. Такой подход крайне полезен, поскольку тестирование должно быть максимально независимым от процессов разработки (не только непосредственно программирования продукта, но и от разработки требований): если тестировщик совмещает две роли, он неизбежно теряет часть объективности.
— Помимо этих двух ипостасей, ранее вы были ещё и разработчиком — а этот опыт сейчас насколько сказывается?
— Как и в предыдущем случае, когда знаешь специфику процесса разработки изнутри, это приносит преимущества. Не говоря уже об очевидных возможностях применять white-box техники тестирования, понимать код и иметь возможность его изменять, хотя бы на своём локальном окружении для нахождения дефектов. Это делает более простым процесс коммуникации, важность которого, я думаю, понимает каждый. Общаться всегда проще, когда разработчик понимает, что ему не нужно объяснять на пальцах, как реализована та или иная функциональность, и можно сразу перейти к сути.
То же самое с работой аналитика — когда ты можешь сразу при общении с заказчиком, без дополнительной консультации с разработчиками, объяснить особенности текущей архитектуры. Показать, что интересующую его функциональность будет добавить сложно и дорого. И предложить другие варианты, которые могут заказчика устроить, причём будут просты в реализации и выполнены в принятых на проекте паттернах программирования.
— У вас ранее был доклад о подходе EARS, позволяющем улучшить язык требований — а насколько активно применяете теперь в проектах T-Systems, в которых участвуете?
— В данный момент я не работаю с требованиями, поэтому эту интереснейшую технику не использую, однако, на прошедших с того времени конференциях ко мне подходят слушатели и рассказывают о своем опыте применения EARS, как это помогло им оптимизировать процесс и насколько сократился объём документации при сохранении смысловой наполненности.
— Также вы рассказывали о комбинаторном тестировании в мобильной разработке, упоминая сложности, когда зоопарк Android-устройств ещё и перемножается на количество других параметров. А как в T-Systems выбирают исходный набор смартфонов для тестирования — это всегда зависит от заказчика, или у вас есть стандартный набор моделей, который вы считаете достаточно репрезентативным для большинства случаев?
— Первоначально это, разумеется, зависит от заказчика. От бюджета, который он готов потратить и того качества, которое он хочет получить. Эксперты со стороны тестирования могут предложить определённый набор устройств, исходя, например, из статистики их использования и проинформировать о рисках, которые могут возникнуть, если не тестировать приложение на остальных девайсах. Впрочем, комбинаторное тестирование может использоваться не только для определения набора телефонов и их атрибутов. Сейчас на моём текущем проекте идет обсуждения внедрения этого подхода для, например, определения продуктов, которые мы используем в TSO Process Test, чтобы получить максимальное покрытие опций при минимальном количестве тестов.
Автор: JUG.ru Group
