Передумови створення проєкту SDETedu
Contents
Передумова 1: Низький рівень підготовки тестувальників
До початку війни я працював лідом команди тестування у доволі великій міжнародній компанії. Я прийшов у компанію з автоматизації фінансового обліку. Крім того, у мене був відносно вільний рік, який я витратив на вивчення повного циклу розробки ПЗ: від створення архітектури, планування проєктів, ведення Scrum-проєктів, реалізації коду і до CI/CD та тестування.
Як лід, я, звісно, проводив багато співбесід і виявив, що рівень тестувальників катастрофічно низький. Як наслідок, ставлення до тестувальників завжди було (і залишається) як до найменш кваліфікованої IT-професії. Я б порівняв це зі ставленням до прибиральниці, яка миє підлогу в кабінеті програмістів і лише тому має відношення до IT…
Передумова 2: Навчальні компанії — інфоцигани
Почалася війна. Ніхто нічого не розумів, і різні компанії поводили себе по-різному: хтось фінансував релокацію співробітників у безпечніші міста, хтось залишав їх напризволяще. Компанія, де я працював, вирішила скорочувати персонал, почавши з тестувальників, а потім і з усіх команд із проєктами, що знаходились у розробці. Зарплати за останні місяці не виплатили, але це вже зовсім інша історія…
Через деякий час мені запропонували написати та вести курс з тестування, і я, звісно, погодився (я дуже люблю викладати). Першу версію плану курсу мені відхилили, сказавши, що це надто складно і “не потрібно”. Наша цільова аудиторія — невдахи та пенсіонери 🙂 Мені запропонували переглянути курси конкурентів. Я подивився і зрозумів: мета не навчити — мета продати “воду”, доки тема “увійти в IT” (ненавиджу цей слоган) у тренді.
Курс я все ж написав, більш-менш інформативний (довелося за вимогою інфоциган додати трохи “води”, але мінімально). Навчив за ним понад 100 студентів, відгуки можна переглянути в цьому відео:
Ну, а гроші за половину проданих курсів я, звісно, не отримав. А чого ще чекати від інфоциган? (Але це історія для іншого разу.)
Передумова 3: Досвід роботи з ERP-системами
Я маю доволі великий досвід роботи з ERP (Enterprise Resource Planning) і є великим прихильником таких систем. Ідея в тому, щоб мати цілу екосистему програм, пов’язаних між собою, але таких, що працюють із абсолютно різними ресурсами підприємства.
Спрощений приклад: у нас є інтернет-магазин, який складається із сайту, кол-центру, складу та бухгалтерії.
- На сайті клієнт оформлює замовлення товару — це одна “програма”.
- Замовлення потрапляє до кол-центру, і співробітник телефонує клієнту, підтверджує наявність товару, уточнює дату доставки тощо. До речі, цей етап — це лише наша українська жахлива практика. Ненавиджу, коли мені телефонують для підтвердження: я ж усе вже вибрав на сайті й навіть оплатив. Навіщо? Тим не менш, це друга програма — програма кол-центру.
- Після підтвердження замовлення товар потрапляє на склад — це третя програма, програма складського обліку.
- Нарешті, інформація про продажі, надходження грошей, списання товару зі складу, робочі години співробітника тощо з усіх інших програм системи потрапляє у програму фінансового обліку, де збирається разом і формує як управлінські звіти (для власника), так і бухгалтерські — для ведення обліку.
Хто такий SDET?
“Інженер з тестування програмного забезпечення (SDET) також є розробником, але його увага зосереджена на тестованості та загальній інфраструктурі тестування. SDET’и розглядають дизайни та уважно вивчають якість коду й ризики. Вони рефакторять код, щоб зробити його більш тестованим, і пишуть фреймворки для модульного тестування й автоматизації. Вони є партнерами у кодовій базі SWE, але більше переймаються підвищенням якості та покриття тестами, ніж додаванням нових функцій або підвищенням продуктивності.”
— Джеймс Віттакер, Джейсон Арбон, Джефф Каролло, Як ми тестуємо в Google