Цікава тема для обговорення
На конференції Гейзенбаг, окрім основної програми, буде бонус від компаніїT-Systems: на її стенді проведе невеликий майстер-клас співробітникГерман Варгін, вже знайомий багатьом тестувальникам з виступів на інших конференціях ( ось навіть Google Images все про нього розуміє).
А напередодні Гейзенбага ми вирішили дізнатися більше про те, як справи з тестуванням усередині самої компанії, і поставили питання трьом її співробітникам: самомуГерману,Андрію Павлову(він також відомий своїми доповідями ) та спеціалісту з внутрішніх комунікаційМарії Зернової.
Марія Зернова
- Так, тестування дуже важливе для нашої компанії, в Петербурзі близько 50% співробітників займаються тестуванням різних проектів та сервісів компанії. Серед наших проектів (а їх в Україні понад 150) є проекти для BMW, швейцарських залізниць (SBB), і тестування здійснюється силами наших команд локально. Крім того, ми маємо напрямок, що забезпечує тестування інтеграції понад 20 систем Deutsche Telekom. Вони становлять єдиний ландшафт та забезпечують працездатність мережі найбільшого телекомунікаційного оператора Deutsche Telekom, нашої материнської компанії. А у планах у нас створення центру автоматизації тестування, який надаватиме послуги концерну T-Systems по всьому світу.
— У T-Systems є школа Test School — а чи давно вона існує? Чи багато зараз у 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 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 мають окрему команду аналітиків, які працюють із вимогами та завжди надають точні та докладні специфікації. Такий підхід дуже корисний, оскільки тестування має бути максимально незалежним від процесів розробки (не тільки безпосередньо програмування продукту, а й від розробки вимог): якщо тестувальник поєднує дві ролі, він неминуче втрачає частину об'єктивності.
— Крім цих двох іпостасей, раніше ви були ще й розробником — а цей досвід зараз наскільки позначається?
— Як і в попередньому випадку, коли знаєш специфіку процесу розробки зсередини, це дає переваги. Не кажучи вже про очевидні можливості застосовувати white-box техніки тестування, розуміти код і мати можливість його змінювати хоча б на своєму локальному оточенні для знаходження дефектів. Це робить простішим процес комунікації, важливість якого, я думаю, розуміє кожен. Спілкуватись завжди простіше, коли розробник розуміє, що йому не потрібно пояснювати на пальцях, як реалізована та чи інша функціональність, і можна відразу перейти до суті.
Те саме з роботою аналітика — коли ти можеш одразу при спілкуванні із замовником, без додаткової консультації з розробниками, пояснити особливості поточної архітектури. Показати, що функціональність, що його цікавить, будедодати складно та дорого. І запропонувати інші варіанти, які можуть замовника влаштувати, причому будуть прості у реалізації та виконані у прийнятих на проекті патернах програмування.
— У вас раніше була доповідь про підхід EARS, що дає змогу покращити мову вимог — а наскільки активно застосовуєте тепер у проектах T-Systems, у яких берете участь?
— На даний момент я не працюю з вимогами, тому цю цікаву техніку не використовую, проте на конференціях, що відбулися з того часу, до мене підходять слухачі і розповідають про свій досвід застосування EARS, як це допомогло їм оптимізувати процес і наскільки скоротився обсяг документації при збереженні. смислової наповненості.