Корпоративтік тестілеу бойынша ЖҚС: сұрауға қорқатын сұрақтарға жауаптар
Сіз корпорацияға «тестілеу — ол барлық жерде бірдей» деген оймен келесіз. Ал бір айдан кейін он бес ортаның, шағын кітаптай CI-пайплайнның және «Canary release» немесе «Chaos engineering» сияқты терминдердің алдында аузыңыз ашылып отырасыз. Таныс па?
Ірі компанияда жұмыс бастаған тестілеушілерде туындайтын, бірақ неге екені дауыстап сұрауға ұялатын басты сұрақтарды қарастырайық.
Корпорацияда тестілеу қалай ұйымдастырылған? Бұл бір процесс емес пе?
Процесс қарапайым болуы керек сияқты: тапсырманы алдың — тексердің — бердің. Стартапта дәл солай жұмыс істейді. Корпорацияда — жоқ.
Сіз жеке үй салып жатырсыз деп елестетіңіз. Терезелердің орнын, төбенің биіктігін және іргетасты қашан құюды өзіңіз шешесіз. Ал енді 10 000 пәтерге арналған тұрғын кешен салып жатқаныңызды елестетіңіз. Жобалаушылар, сметашылар, сапаны бақылау бөлімі, техникалық қадағалау, қаламен келісу пайда болады.
Стартапта сіз ертең шығарылатын бір фичаны тестілейсіз. Корпорацияда сіз 50 қатарлас жүйеге әсер ететін модульді тексересіз. Админкада «Сақтау» батырмасын бастыңыз — ал бір жерде бухгалтерияның жалақы есебі бұзылды. Себебі сіздің код жолыңыз SAP үшін деректер пішімін өзгерткен болып шықты.
Корпоративтік тестілеу — бұл тек багтарды іздеу емес. Бұл 24/7 жұмыс істейтін және миллиондаған сұраныстарды өңдейтін жүйенің тұрақтылығын қамтамасыз ету. Мұнда «мен бәрін тексердім, шығарайық» деп айта алмайсыз — өзгерту жылдар бойы жұмыс істеп тұрған ештеңені бұзбайтынын дәлелдеу керек.
Корпорацияда автоматтандыру міндетті ме? Мен жай ғана қолмен тестілеуші болғым келеді
Мүмкін. Бірақ ұзақ емес.
Корпорацияда қолмен тестілеу — бұл «батырмаларды басу» емес. Бұл автотесттермен қамтылмайтын күрделі сценарийлерді зерттеу тестілеуі. Бірақ regress (әр өзгерістен кейін ескі функционалды қайта тексеру) сіз үшін робот жасайды. Әйтпесе жай ғана батып кетесіз.
💡 Кеңес: Автоматтандыруды «тек белгі үшін» үйренбеңіз. CI/CD-іңіздің қалай жұмыс істейтінін түсініңіз. Тіпті код жазбасаңыз да, пайплайнды түсіну сізді «тексердім» деп айтқан кезде, тесттер іске қосылмаған жағдайдан құтқарады, себебі джоба бұзылды. Іске қосу журналдарын оқыңыз — бұл кез келген курстан күштірек дүниетанымыңызды дамытады.
Орташа жол келесідей: алдымен regress-ті автоматтандырасыз. Содан кейін API тексеруін. Содан кейін тестілік деректерді дайындауды. Ал бір жылдан кейін қолмен жұмыстың көп бөлігі автоматтандырылғанын байқайсыз, енді сіздің міндетіңіз — автоматтандыруға болмайтын сценарийлерді жобалау және бар тесттерді жақсарту.
Үлкен командада әзірлеушілермен қалай сөйлесу керек, егер олар естімейтін болса?
Шағын командада әріптесіңізге барып, мониторға саусағыңызбен нұсқауға болады. Корпорацияда — жоқ. Мұнда коммуникация — жеке пән.
Типтік жағдай: сіз баг таптыңыз, тикет жасадыңыз, әзірлеуші оны «қайталанып көрсетілмейді» деген түсініктеме жазып жапты. Содан басталады: сіз қайта ашасыз, ол қайта жабады, тикет өз өмірін сүре бастайды.
Корпоративтік тестілеудегі басты қақпандардың бірі — «батырма жұмыс істемейді, түзетіңіз» деген стильде тикет жазу әдеті. Әзірлеуші мұндай тикетті ашып, не істеу керектігін түсінбейді. Ол қайталау қадамдары жоқ түсініксіз сипаттаманы көреді. Нәтижесінде тикет жылдар бойы өмір сүреді, «баг өзекті» деген түсініктемелермен толығады, содан кейін оны «қайталау мүмкін еместігіне» байланысты жабады.
Ереже қарапайым: әрбір тикет — басы, ортасы және соңы бар әңгіме. Қайталау қадамдары. Күтілетін нәтиже. Нақты нәтиже. Орта. Журналдар. Скриншоттар. Егер баг он жағдайдың үшеуінде қайталанса — дәл осы үш жағдай үшін шартты сипаттаңыз.
💡 Кеңес: Әзірлеушіге тикет жасамас бұрын, өзіңізге «Мен бұл багты басқа тестілеушіге бірінші реттен қайталата аламын ба?» деген сұрақ қойыңыз. Егер жоқ болса — дәлірек сипаттауға барыңыз.
Ештеңеге үлгермейтініңізді сезінгенде, қалай күймеуге болады?
Корпорацияда жұмыс — бұл шексіз ағын: тапсырмалар, багтар, регрестер, релиздер, кеңестер. Егер шекаралар белгілемесеңіз, бір жылдан кейін күйзеліс (выгорание) келеді.
Ең қауіптісі — «мен бәрін тексеруім керек» деген ұстаным. Мүмкін емес. Әрқашан тексерілмеген нәрсе болады. Бұл фактіні қабылдау — кәсіби жетілуге бірінші қадам.
Тәуекелдермен жұмыс істеңіз. Функционалдың 100% тесттермен қамтуға тырыспаңыз — бұл қажет емес. Бизнес үшін не маңызды екенін анықтаңыз. Егер сатып алудың негізгі сценарийі құласа — бұл стоп-релиз. Егер ешкім пайдаланбайтын беттегі «Көбірек көрсету» батырмасында баг болса — релиз жасап, келесі спринтте түзетуге болады.
💡 Кеңес: Бір ережені енгізіңіз: жұмысты уақытында аяқтаңыз. 23:00-де емес, 18:00 немесе 19:00-де, қабылданғандай. Егер үлгермейтініңізді түсінсеңіз — бірден тимлидке немесе PM-ге айтыңыз. Үнсіз артық жұмыс бағаланбайды. Уақытты бағалап, мерзімнен кейін емес, оған дейін шындықты айта білу бағаланады.
Қарапайым тестілеушіден тестілік шешімдер архитекторына дейін қалай даму керек?
Бұл секіріс емес, қадамдар сериясы. Әр қадам ескіні алмастырмай, жаңа құзыреттілік қосады.
Бірінші деңгей — қолмен тестілеу. Сіз фичаларды тексересіз, багтарды іздейсіз, жақсы тикеттер жазуға үйренесіз. Құралдарды меңгересіз: Postman, DevTools, дерекқорлар.
Екінші деңгей — автоматтандыру. Сіз Python немесе Java-да скрипттер жазасыз. Тест сценарийлерін құрастырасыз. CI/CD, Docker, интеграциялық тестілеу қалай жұмыс істейтінін түсінесіз.
Қолмен тестілеуден автоматтандырылған тестілеуге көшу — велосипедтен автомобильге көшу сияқты. Сіз әлі де велосипедпен жүре аласыз және кейде бұл ыңғайлы. Бірақ алыс қашықтыққа сапар үшін машина керек. Корпорация — бұл алыс қашықтықтар.
Үшінші деңгей — тестілік шешімдер архитектурасы. Сіз әр тестті жазбайсыз. Сіз фреймворкты жобалайсыз: қандай тесттер керек, оларды қай деңгейде іске қосу, қандай деректерді енгізу, іске қосу уақытын қалай азайту. Сіз масштабтау туралы ойлайсыз.
💡 Кеңес: Архитектор болғыңыз келсе, командаңыздағы басқа тестілеушілер пайдаланатын фреймворк жазудан бастаңыз. Басында қолдан жасалған, идеалды емес. Содан кейін кері байланыс негізінде жақсартыңыз. Бұл жүйені қалай құру керектігін түсінуге мүмкіндік береді, тесттерді жай ғана жазу емес.
Төртінші деңгей — тестілеу процестерін басқару. Бұл метрикалар туралы: regress-ке қанша уақыт кетеді, продакшнға қанша баг кетеді, релиз уақытын қалай қысқарту. Сіз процестерді енгізесіз, оларға жай ғана қатыспайсыз.
Корпорацияның күрделі инфрақұрылымында қалай жоғалмауға болады?
Легаси-код, жүздеген микросервистер, он бес орта, түсініксіз құрастыру артефактілері — бұл корпорация үшін қалыпты жағдай. Егер сіз хаос сияқты көрінетін нәрсені көрсеңіз, бұл хаос емес, жылдар бойы жиналған күрделілік.
Бәрін бірден үйренуге тырыспаңыз. Бүгін жұмыс істейтін нәрсені үйреніңіз. Тикет жасадыңыз — жүйенің осы бөлігінің қалай ұйымдастырылғанын түсіндіңіз. Тест жаздыңыз — орта қалай жұмыс істейтінін білдіңіз. Бір жыл ішінде жүйенің картасын басыңызға жинайсыз.
💡 Кеңес: Құжаттаңыз. Архитектураның түсініксіз бөлігін анықтаған кезде — жазбаларыңызға немен не байланысқанын схемалық түрде жазып алыңыз. Бір айдан кейін бұл білім қажет болады, ал сіз ұмытасыз. Жеке білім базасын жүргізу (Confluence-те немесе Obsidian-де) — корпорациядағы суперкүш.
Корпоративтік тестіле
