«Зарплата приблизно така ж, як в ІТ». 5 історій QA-фахівців, які перейшли в оборонку

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Ринок вакансій для QA-фахівців залишається одним із найбільш конкурентних в українському ІТ. У II кварталі на одну QA-вакансію припадало в середньому 77 відгуків — це четвертий показник серед усіх ІТ-спеціалізацій.

У defence tech кількість вакансій зростає, а конкуренція за позиції QA нижча, ніж на загальному ІТ-ринку. На одну QA-вакансію в оборонці припадає 25 відгуків. Водночас робота тестувальників у цій сфері охоплює не лише програмне забезпечення. Їм доводиться перевіряти взаємодію софту з залізом, роботу систем у польових умовах, стабільність зв’язку та поведінку виробів за різних зовнішніх факторів.

Ми зібрали п’ять історій QA-фахівців, які працюють із геопросторовим софтом, БПЛА, роботизованою туреллю та засобами зв’язку. Вони розповідають про свій перехід у defence tech, робочі процеси, необхідні навички й відмінності від тестування цивільних продуктів.

«Спочатку перевіряємо вузли, потім — зібраний борт», — Дмитро, QA команди R&D дронів у Frontline Robotics

До defence tech я багато років працював тестувальником у цивільному ІТ. Серед моїх проєктів були мобільні VPN-застосунки й великі enterprise-системи. Я писав документацію, аналізував вимоги, спілкувався зі стейкхолдерами та брав участь у проєктуванні продуктів. Працював і з ручним, і з автоматизованим тестуванням.

Вакансію Frontline Robotics я знайшов на DOU. Найм був схожим на звичайне ІТ: співбесіди, технічна оцінка, знайомство з командою. Більше уваги приділяли конфіденційності, мотивації й цінностям кандидата.

До переходу я волонтерив і навчився збирати FPV-дрони. Це дало базове розуміння апаратної частини. На новій роботі мені було простіше розібратися, за що відповідають окремі вузли й де шукати причину проблеми.

Як дрон проходить перевірки

Я тестую «Лінзу» і «Зум» — мультироторні БПЛА Frontline Robotics. Розробка йде поетапно. Спочатку команда перевіряє окремі компоненти. Потім тестує зібраний виріб. Після кожного етапу є критерії готовності, за якими керівники напрямів вирішують, чи може продукт рухатися далі. Цей процес схожий на stage-gate модель у промисловості.

У лабораторії або на виробництві можна перевірити мотори на стендах, калібрування камер і частину функцій зв’язку. Я порівнюю це з юніт-тестуванням окремих компонентів. Для програмної частини ми використовуємо планувальники місій. Для апаратної — вимірювальні стенди, осцилографи, мультиметри та інше лабораторне обладнання.

Полігон виконує роль інтеграційного тесту. Там усі системи працюють разом. До перевірки додаються погода, завади, нестабільний зв’язок і поведінка зібраного борту. Ці фактори враховуємо у програмі випробувань.

Ударний бомбер «Лінза»

Чому ручного тестування більше

У моїй роботі переважає ручне тестування. Автоматизувати фізичний виріб складніше й дорожче, ніж звичайний софт. Для частини перевірок автоматизація просто не дає достатньої користі. Тому ми дивимось на кожне завдання окремо.

Військові додають сценарії, які важко передбачити в лабораторії. З підрозділами, що давно користуються «Лінзою» і «Зумом», ми спілкуємося напряму або через Customer Support. З новими користувачами знайомимося під час презентацій і польових виїздів. Команда аналізує фідбек, формує завдання і визначає пріоритет. Критична проблема отримує найвищий пріоритет.

У серійному виробництві кожен борт проходить кілька рівнів перевірок. Якщо ключові характеристики не виконані, виріб повертається на доопрацювання. Рішення про перехід між етапами команда приймає після перевірки визначених критеріїв.

Вісім годин, переважно офіс і той самий рівень зарплати

Після переходу я зберіг приблизно той самий рівень зарплати [за даними djinni, вимога до кандидата — від трьох років досвіду. Медіанні зарплати рівня middle для QA в deftech починаються від $2000, — ред.]. Компенсація залежить від досвіду й навичок. Навіть технічне хобі може стати перевагою; у моєму випадку це було складання FPV-дронів.

Мій стандартний робочий день триває вісім годин. Більшість часу працюємо в офісі, бо багато завдань пов’язані з фізичними виробами. Для роботи, яку можна виконати дистанційно, доступний змішаний формат.

«На полігон виходимо зі стабільною версією», — Микита, QA команди R&D роботизованої турелі «Буря» у Frontline Robotics

До Frontline Robotics я півтора року працював Embedded QA і тестував ігрову периферію. Defence tech був для мене близьким напрямом, оскільки я хотів допомагати армії й розвиватися у сфері embedded.

Під час найму я вперше проходив поліграф. На старті мені бракувало частини знань про продукт. Я був готовий вчити теорію і відразу закріплювати її на практиці.

Що проходить кожна зміна в софті

Я працюю з роботизованою туреллю «Буря». Ми тестуємо систему з боку софту. Кожна зміна проходить smoke- і regression-тестування. Також використовуємо ad hoc і дослідницькі перевірки. Основний фокус залишається на ручному тестуванні. Автоматизацію застосовуємо там, де вона дає найбільшу ефективність.

У лабораторії перевіряємо критичні зміни й усе, що можна надійно покрити без виїзду. Для кожної зміни іноді треба підготувати кілька сценаріїв з різними умовами й визначити критерії покриття.

На полігон виходимо вже зі стабільною версією. Там перевіряємо взаємодію з наземним роботизованим комплексом і зброєю, проводимо дослідження. Погода й пора року впливають на візуальне сприйняття, тепловізійне зображення і балістику. Рельєф змінює радіогоризонт. Механічна частина теж може вплинути на поведінку системи.

Тому QA має не тільки знати софт свого продукту, а й розуміти фізичні явища, механіку та процеси, які впливають на застосування.

Роботизована турель «Буря»

Як баг із фідбеку доходить до патчу

Фідбек військових потрапляє в обговорення. Команда визначає пріоритет і план роботи. Такі зустрічі часто виникають поза планом. Новий сценарій може з’явитися вже тоді, коли інші завдання або баги перебувають у роботі.

Критичний баг може перерости у швидкий патч для всіх користувачів. Перед релізом «Буря» проходить regression-тестування. Критичних багів у версії бути не повинно. Потім інструктори проводять внутрішню дослідну експлуатацію в полі або на полігоні. Після успішної перевірки користувачі отримують оновлення. Якщо ми знаходимо баг, виправляємо його і знов тестуємо версію в полі.

Готовність версії визначають regression-тест, відсутність критичних дефектів і результат польової експлуатації. Термінові потреби трапляються, команда намагається звести такі передачі до мінімуму..

Що змінилося в умовах роботи

Зарплата, графік і можливість працювати дистанційно залишилися приблизно на попередньому рівні. Для мене це зручні умови. Навантаження зросло, work-life balance у команді зберігся.

Професійний розвиток відбувається постійно. Технології змінюються швидко. Треба вчитися, спілкуватися з колегами, пріоритезувати проблеми й запобігати їм. Для одного продукту корисною буде автоматизація, для іншого — дослідницьке тестування або вміння будувати тест-плани.

Найбільше мене здивувало спільне бажання команди поліпшувати «Бурю» і процеси навколо неї. Ідею можна підняти в обговоренні, перевірити й довести до зміни в продукті.

«У хорошого QA з цивільного ІТ вже є головна база», — Назар, QA Lead у Farsight Vision

До ІТ я близько двох років працював на бронетанковому заводі. Спочатку був слюсарем у цеху, потім інженером з автоматизації. Тоді я не називав цю роботу defence tech. Вона дала мені базове розуміння виробництва: як окремі операції складаються в процес і чому результат залежить від кожного етапу.

Потім я перейшов у цивільне ІТ. Працював із пошуковим сервісом для медичної сфери у США, страховими рішеннями, платіжними системами, системами збору й аналізу даних та адміністративними утилітами. Останні вісім років працюю QA Lead.

Що саме я тестую

Farsight Vision працює передусім із софтом. Ми створюємо ортофотоплани [цифрове зображення місцевості з багатьох аеро- або космічних знімків, — ред.] та 3D-моделі. Система класифікує і відстежує об’єкти, виявляє аномалії. Окремі рішення пов’язані з віртуальною реальністю. Ще один напрям — модуль навігації для наземних роботизованих комплексів. Він допомагає будувати маршрут між точками й враховувати перешкоди.

Через це QA працює відразу з кількома шарами продукту. Треба розуміти API, бази даних, Unix-based системи й нетворкінг. Також корисні навички роботи з hardware, геопросторовими даними та GIS. Досвід із FPV, UGV або 3D-моделюванням буде перевагою, але не є обов’язковим для кожного кандидата.

Навчити користуватися конкретним девайсом, терміналом чи мережею можна. Значно складніше навчити людину брати відповідальність і пропонувати рішення.

У хорошого QA з цивільного ІТ вже є головна база: вміння перевіряти гіпотези, локалізувати проблему, ставити запитання і бачити зв’язки між системами. Специфіку продукту команда допомагає підтягнути.

Окрему увагу я приділяю edge cases. У цивільному продукті бізнес може свідомо відкласти сценарій, який зачіпає невелику частину користувачів. Для нашого софту навіть 10% — велика частка. Тому QA має ширше дивитись на середовище: температуру, нестабільний зв’язок, неповні дані, поєднання софту з залізом і реальний спосіб використання в полі.

Досвід служби допомагає краще зрозуміти проблему користувача. Англійська теж може знадобитись, якщо фахівця залучають до виставки або презентації продукту. Я сприймаю це як переваги кандидата. Основною вимогою залишається досвід у QA і готовність швидко вчитися.

Скільки триває тестування

У багатьох випадках тестування триває довше, ніж у цивільному продукті. Команда не випускає функцію, якщо її результат може зашкодити або підштовхнути користувача до неправильного рішення. У такій ситуації ми перевіряємо версію, допоки не розуміємо її поведінку.

Бувають і завдання з жорстким обмеженням у часі. Тоді QA має швидко дати фідбек, щоб розробники встигли виправити проблему. Команда докладає більше зусиль у короткий проміжок часу. Саме тому просте порівняння «довше чи швидше» не працює. Тривалість залежить від ризику, межі в часі та готовності конкретної версії.

Приклад ортофотоплану Farsight Vision

Що дає полігон

Частину сценаріїв ми перевіряємо в полі. Ґрунтову дорогу або ліс відтворити відносно просто. Пошкоджену міську забудову, специфічні перешкоди й вплив РЕБ змоделювати значно складніше. Для окремих випробувань потрібні дозволи. Сам час роботи на локації обмежений, тому виїзд треба готувати заздалегідь.

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

Я постійно питаю себе: що буде, якщо зв’язок нестабільний, дані неповні, а польові умови відрізняються від тестових? Оце «а що, якщо?» у deftech регулярно і стається.

Графік, зарплата і розвиток

У команді є люди, які працюють із дому, і люди, які працюють з офісу. Загальної вимоги щодня бути в офісі поки що не було. Важливі продуктивність, швидка реакція на запити й зрозуміла комунікація з командою.

Робочий день менш передбачуваний, ніж у моїх попередніх цивільних проєктах. Є спокійні дні. Інколи запит приходить поза стандартним графіком. Тоді треба відповісти в месенджері, скоординувати колег або ненадовго долучитися до роботи. Такі ситуації не відбуваються щодня, але бувають. Команда може залежати від відповіді конкретної людини, тому важливо заздалегідь пояснювати, коли ти будеш на зв’язку.

Мої навички та досвід оцінюють відповідно до рівня, тому і зарплата відповідна [за даними зарплатного віджета DOU, медіанна зарплата QA Lead в deftech відповідає QA Team Lead в IT-компаніях і становить $3500, — ред.].

«Час тестування має бути якнайкоротшим без втрати якості», — Automation QA Engineer у HIMERA

У цивільному ІТ я працював понад 25 років. Більшість моїх проєктів були пов’язані з embedded. У defence tech я шукав позицію, де попередній досвід дасть найбільшу користь. Роботу знайшов за рекомендацією.

На старті я знайомився з продуктом і специфікою його використання. Великого технологічного розриву не відчув, бо проєкт відповідав моїй експертизі.

Як засіб зв’язку проходить перевірки

У HIMERA ми тестуємо засоби зв’язку. Продукт проходить послідовні етапи від ідеї до впровадження й використання. На кожному етапі QA визначає, чи готове рішення рухатися далі та зрештою потрапити до військових.

Час тестування має бути якнайкоротшим без втрати якості. Головне завдання QA — швидко дати команді надійну відповідь про готовність продукту на конкретному етапі.

У лабораторії перевіряємо відповідність заявленим характеристикам. На полігоні дивимося, як пристрій працює в умовах, наближених до реальних. Навіть полігон не відтворює всього бойового контексту. На результат впливають рельєф, ландшафт, РЕБ та інші фактори.

Як правило, одного успішного виїзду недостатньо. Команда лишається на зв’язку з військовими, досліджує знайдені баги й додає їх у подальше тестове покриття.

Система зв’язку HIMERA G1

Manual і Automation працюють паралельно

Сучасний Manual QA не обмежується введенням команди й перевіркою реакції. Він використовує різні технології та інструменти. Через це важко чесно порахувати відсоток ручних і автоматизованих перевірок. У нашій роботі вони часто йдуть паралельно і доповнюють одна одну.

Прямий фідбек від військових має найвищий пріоритет. Якщо користувачі знаходять баг, команда досліджує його, виправляє і додає сценарій у тест-кейси.

«Спочатку — „стіл“, потім корпус, лабораторія і полігон», — Embedded QA Engineer у HIMERA

До defence tech я близько десяти років працювала QA Engineer у цивільному ІТ. За цей час бачила різні продукти, технології, команди й процеси. У HIMERA потрапила за рекомендацією колеги з попередньої компанії.

Під час відбору багато уваги приділяли моїй мотивації, поглядам і цінностям. Компанія була готова навчати специфічних речей. Для мене головною технічною зміною став перехід від вебу до embedded. Базові принципи QA залишилися знайомими. Інструменти й підходи довелося опановувати на практиці [за даними DOU, медіанна зарплата Embedded QA в deftech становить $2500, — ред.]

Чотири етапи перед передачею користувачеві

Шлях продукту починається зі «столу». Далі залізо збирають у корпус. Після цього ми тестуємо готовий пристрій у лабораторії. Наступний етап — полігонні випробування в умовах, максимально наближених до реальних.

У лабораторії ми закриваємо базові погодні умови й відпрацьовуємо описані сценарії. Паралельно шукаємо нестандартні дії, які можуть зламати систему. Тут дуже допомагає звичка QA постійно питати: «Що буде, якщо зробити не за інструкцією?»

Для перевірки зв’язку в живих умовах виїжджаємо в ліс, на відкриту місцевість, у забудову та на складний рельєф. Також перевіряємо роботу на граничних відстанях. На полігоні дивимося на стійкість до завад і надійність зв’язку.

Засоби зв’язку HIMERA

Коли продукт вважають достатньо готовим

Під час війни рішення часто потрібне дуже швидко. Продукт передають у роботу, коли він надійно виконує основне завдання. Команда постійно тримає баланс між надійністю і часом, який є на розробку та перевірку.

Такий темп означає постійне навчання. Після вебу я фактично опановувала нову технічну спеціалізацію. Для мене це можливість зростати через роботу з залізом, зв’язком, польовими сценаріями й автоматизацією.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU