Ірі корпорацияларда тестілеуден қалай өтуге болады: тәжірибелік кейстер
Жаңа кеңсеге келу кейде мүлдем басқа шынайылыққа тап болғанмен бірдей. Он шақты әріптесіңіз отыратын үйреншікті open space-тің орнында — үш жүз адамға арналған тұтас бір қабат. Бір ғана өнімнің орнында — әрқайсысының өз API-і, деректер базасы және әзірлеушілер командасы бар ондаған өзара байланысқан жүйе. Бұған қоса, бәрін бүлдіріп алудан қорыққандықтан ешкім тиіспеген, осыдан сегіз жыл бұрын жазылған легаси-код тағы бар.
Көптеген тестілеушілер үшін мұндай ауысу шок болып келеді. Олар жаман маман болғандықтан емес. Тек корпоративтік орта жұмысқа мүлдем басқа көзқарасты талап етеді.
Корпоративтік тестілеудің стартаптағы жұмыстан айырмашылығы
Стартапта сен шағын өнімге жауаптысың. Команда кішкентай, коммуникация тікелей, релиздер күн сайын шығады. Егер бірдеңе бұзылса – бір сағатта жөндеді.
Корпорацияда бәрі басқаша. Сенің өніміңді жүздеген мың адам пайдаланады. Есептеу логикасындағы қате компанияға миллиондарға түсуі мүмкін. Релиз терезесі – екі аптада бір рет, ал үлгермесең, келесісін күт. Кодтық база үлкен және ешкім оны толық білмейді.
Өзіңді интернет-банкті тестілеп жатырсын деп елестет. Стартапта бұл карталар арасында ақша аударуға арналған қосымша болар еді. Корпорацияда бұл – процессингпен, CRM, антифрод, салық есептілігі және тағы ондаған сервистермен байланысқан жүйе. Сен аударымды тексересің, ал ол істен шығады, себебі көрші модульде деректер форматын жаңартты.
Басты айырмашылық – корпорацияда сен сирек жалғыз жұмыс істейсің. Сен күрделі механизмнің бөлігісің, мұнда әрбір әрекетің басқаларға әсер етеді.
Бірінші тұзақ: күрделі инфрақұрылымнан қорқу
Корпорациялардағы жаңа тестілеушілер жиі адасып қалады. Олар жүздеген тестілерді, ондаған орталарды, CI/CD пайплайндарын, көптеген логтар мен мониторингтерді көреді. "Мен мұны ешқашан түсінбеймін" деген ой туындайды.
Шын мәнінде, бәрін бірден түсінудің қажеті жоқ. Корпорацияда Layer of Abstraction принципі жұмыс істейді. Сен әрбір модульдің қалай жұмыс істейтінін білуге міндетті емессің. Олардың арасындағы өзара әрекеттесу интерфейстерін түсіну жеткілікті.
💡 Кеңес: Жаңа корпорацияға түскенде, біреуден баста. Бір микросервисті немесе бір функционалдылықты таңда. Оны толық талда: интерфейстен дерекқорға дейін. Оны түсінген бойда – байланысқан жүйелерге өт. Біртіндеп сурет өзі құралады.
Типтік қате – бір айда бәрін үйренуге тырысу. Бұл күйіп кетуге апаратын жол. Корпоративтік код жылдар бойы өседі. Оны екі аптада меңгеру мүмкін емес. Өзіңе уақыт бер.
Үлкен командадағы коммуникация: қалай жоғалмау керек
Корпорацияда сен тек әзірлеушілермен ғана емес, сонымен қатар аналитиктермен, өнім менеджерлерімен, DevOps инженерлерімен, техлидтермен, архитекторлармен, көрші командалардың менеджерлерімен сөйлесесің. Әрқайсысының өз тілі, өз басымдықтары және өз мерзімдері бар.
Проблема тестілеуші өз міндетіне тұйықталып, кеңірек қарауды тоқтатқанда туындайды. Мысалы, сен баг таптың. Саған бұл айқын проблема. Бірақ әзірлеуші: "Бізде басқа басымдықтар бар, бұл маңызды емес" дейді. Жанжал басталады.
💡 Кеңес: Корпорацияда өзінің техникалық талаптарын бизнес тіліне аудара білген жеңеді. "Бұл баг өріс валидациясын бұзады" дегеннің орнына: "осы баға байланысты пайдаланушылардың 5% тіркелуді аяқтай алмайды, бұл күніне 2000 лид жоғалтуға әкеледі" деп айт. Сандар қабылдауды өзгертеді.
Тағы бір тұзақ – чаттардағы хат алмасу. Корпорацияда сенің ондаған чаттарың болуы мүмкін: жоба бойынша, автоматтандыру бойынша, релиздер бойынша, инфрақұрылым бойынша. Батып кету оңай. Қарапайым ереже: егер талқылау бес хабарламадан асып, шешімге әкелмесе – дауыстық байланысқа өт. 10 минуттық бейнеқоңырау чатта бір сағат талқыланатынды шешеді.
Қолмен тестілеуден автоматтандыруға дейінгі жол
Корпорацияда қолмен тестілеу – бұл барлық жұмыс емес, тек оның бөлігі. Уақыт өте келе сен міндетті түрде тексерулерді автоматтандыру қажеттілігіне тап боласың. Неліктен? Себебі регрессиялық тестілеуді қолмен жасау бір аптаға созылады, ал релизді екі апта сайын шығару керек. Автоматтандыру – мұндай қарқында сапаны ұстап тұрудың жалғыз әдісі.
Бірақ бір нюанс бар. Корпорацияларда жиі легаси-технологиялар қолданылады. Мысалы, Java 8-дегі монолитті архитектурасы бар ескі бағдарламалық жасақтама. Мұны автоматтандыру қиын. Көп нәрсені "продакшнда" немесе мониторинг арқылы тестілеуге тура келеді.
Бір банкте картадан картаға аударым бойынша тестіміз істен шықты, себебі нақты процессингпен тестілік ортамыз болмады. Біз былай жасадық: транзакция генерациялайтын тест жаздық және релизден кейін процессинг логтарын тексердік. Егер транзакция 30 секунд ішінде өтпесе – баг. Бұл типтік емес әдіс, бірақ ол жұмыс істеді.
Кәсіби күйіп кету: мамандықтан қалай шығып кетпеу керек
Корпорациялар – бұл ұзақ қашықтық. Сен спринт жүгірмейсің, сен марафон жүгіресің. Күн сайын 120% берілсең, ресурс алты айда сарқылады.
Тестілеушілердің күйіп кету белгілері ерекше. Сен багтарды жібере бастайсың. Немесе өз жұмысыңның құндылығына сенуді тоқтатасың. Немесе циник боласың: "Барлығы бірдеңе үшін керек емес, релиз шықса болды".
💡 Кеңес: Күйіп кетпеу үшін үш ережені енгіз: - Багтардың өз "нормаңды" анықта. Сен кез келген жүйедегі барлық багтарды таба алмайсың. Мұны қабылда. - Экраннан демалу. Жұмыстан кейін ноутбукты кемінде бір сағат ашпа. - Қызмет түрін өзгерту. Қолмен тестілеуді автоматтандырумен, логтарды талдауды құжаттама жазумен, командамен сөйлесуді өздік жұмыспен алмастыр.
Корпорацияларда тестілеушілер жиі гипержауапкершіліктен зардап шегеді. Оларға багты жіберіп алса, өнім құлайды сияқты көрінеді. Бірақ шындық мынадай: өнім бүкіл команда – әзірлеушілер, аналитиктер, DevOps, тестілеушілер – қателік жіберсе ғана құлайды. Сен жалғыз емессің.
Тестілік шешімдердің архитекторы қалай болу керек
Тестілік шешімдердің архитекторы – бұл корпорацияларда 5-7 жыл жұмыс істегеннен кейін келетін рөл. Бұл жай ғана "аға тестілеуші" емес. Бұл бүкіл тестілеу жүйесін жобалайтын адам: құралдарды таңдаудан бастап қамту стратегиясына дейін.
Не білу керек:
- Өнім архитектурасын сервистер, дерекқорлар, хабар кезектері деңгейінде түсіну.
- Құралдарды "сәнді болғандықтан" емес, нақты міндеттерге қарай таңдау. Мысалы, микросервистерді тестілеу үшін жиі контрактылық тестілер жеткілікті, ал E2E тек критикалық сценарийлер үшін қажет.
- Экономиканы есептей білу. Архитектор басшылыққа: "Егер біз осы модульді автоматтандыруға 300 сағат жұмсасақ, алты айдан кейін қолмен тестілеудің 500 сағатын үнемдейміз" деп түсіндіруі керек.
- Күн сайын істен шықпайтын тестілік орталарды жобалау.
💡 Кеңес: Архитектор болу үшін біреуден баста: өз модуліңнің шеңберінен шық. Бүкіл жүйенің қалай ұйымдастырылғанын қара. Тар жерлері қайда? Ең жиі не істен шығады? Қандай тестілер қайталанады? Суретті толық түсінген кезде, сен жақсартуларды ұсына аласың.
Тәжірибелік кейс: финтех-корпорацияда тестілеуді қалай құрдық
Бес командасы бар, әрқайсысы өз микросервисін жазатын компанияға түстің делік. Өнім – төлем шлюзі. Әр команда өз модулін оқшау түрде тестілейді. Интеграцияға релиз алдында екі күн қалады. Және әр уақытта бірдеңе бұзылады.
Проблема неде? Жалпы тестілеу стратегиясы жоқ. Интеграциялық тестілер жоқ. Модульдердің бір-бірімен қалай әрекеттесетіні туралы түсінік жоқ.
Біз не істедік:
- Әр API үшін контрактылық тестілер енгіздік. Енді командалар басқаларды хабардар етпей эндпоинтті өзгерте алмайды.
- Тізбекті тексеретін жалпы smoke-тест жаздық: пайдаланушы → төлем → раста
