Студенттен кәсіпқойға: корпоративтік тестілеуде қалай аман қалу және өсу

Көрші партадағы досыңызбен өмір бойы шахмат ойнап, оның стилін, әлсіз тұстары мен сүйікті дебюттерін жақсы білуіңіз мүмкін еді. Бірақ кенеттен сізді бір уақытта он тақтада ойнайтын және әр фигурасы өз ережесімен жүретін гроссмейстермен бетпе-бет отырғызып қояды.

Академиялық ортадан (немесе тіпті шағын өнімдік компаниядан) корпоративтік тестілеуге көшу шамамен осылай көрінеді.

Сен болжамдылыққа үйренгенсің. Нақты талаптарға. Локальді машинаңда кодың құлап, қатені бірден көретініңе.

Корпорацияда бәрі басқаша.

Мұнда сен бір ай бойы тек айдың белгілі бір фазасында және он жыл бұрын жұмыстан кеткен әзірлеуші жазған ішкі кітапхананың нақты нұсқасында ғана көрінетін багты іздей аласың. Мұнда сенің автотестің апталар бойы өтуі мүмкін, себебі инфрақұрылым — көптеген тісті доңғалақтары бар күрделі механизм.

Бірақ басты айырмашылық тіпті техникалық күрделілікте емес.

Ол осында шешімдердің қалай қабылданатынында.

Неліктен «жай ғана баг табу» — бұл тек басы

Академиялық ортада немесе стартапта сенің жұмысың айқын: сен өнімді тексересің, ақауларды табасың, баг-репорттар жасайсың. Көп болса — соғұрлым жақсы. Сен — пайдаланушыларды қателерден құтқаратын батырсың.

Корпорацияда мұндай логика әрқашан жұмыс істемейді.

Жаңадан бастаушының типтік қатесі — өз дегеніңде тұру. «Қалай? Баг бар! Оны түзету керек!» Және суық жауап алу: «Біз мұны талқыладық. Шешім қабылданды».

Корпорацияда сапа — бұл абсолютті шама емес. Бұл жылдамдық, құн және тәуекел арасындағы ымыра.

Сондықтан сенің міндетің — жай ғана баг табу емес. Сенің міндетің — оның бизнеске әсерін бағалау. Және дәл осы ақауды кейінге қалдырмай, дәл қазір түзету керек екенін дәлелдей алу.

💡 Кеңес: Багты тапқанда, өзіңнен сұра: «Бұл кімге және қалай әсер етеді?» Егер бұл ақша жоғалтуға, беделге нұқсан келтіруге немесе заң бұзуға әкелсе — сенің дәлелің салмақты. Егер бұл «тек айына бір рет әкімшілер көретін интерфейстегі баг» болса — оны кейінге қалдыруға болады.

Инфрақұрылым: легасиде қалай батып кетпеу

Енді сен күтпейтін нәрсе туралы.

Корпорацияда сен сирек «таза» өніммен жұмыс істейсің. Сен жылдар бойы, тіпті онжылдықтар бойы құрылған жүйемен жұмыс істейсің.

Кодтың бір бөлігі ешкім есіне алмайтын тілде жазылған. Тесттердің бір бөлігі — тәулігіне бір рет кронмен іске қосылатын Bash скрипттері. Құжаттама болмауы мүмкін немесе соншалықты ескірген, оған сенуге болмайды.

Міне, сен — жаңа тестілеуші маман — осыны түсінуің керек.

Қалай?

Біріншіден. Бәрін бірден түсінуге тырыспа.

Корпорацияда жүйе туралы ақпарат көлемі «Соғыс және бейбітшіліктің» бірнеше томымен салыстырылады. Егер сен бәрін қатарынан оқи бастасаң — бір айдан кейін жанып кетесің.

Дұрыс стратегия — «қабаттармен».

Алдымен, жүйенің сырттан қалай көрінетінін түсін: ол не істейді, кімге арналған, қандай негізгі сценарийлер бар.

Содан кейін — оның логикалық құрылымы қандай: қандай сервистер, олар қалай әрекеттеседі, деректер қайда сақталады.

Және тек содан кейін ғана — техникалық детальдар: CI/CD қалай конфигурацияланған, тесттер қайда жатыр, қандай фреймворктар қолданылады.

💡 Кеңес: Бірінші аптада өзіңе міндет қой: «Жүйені бесінші сынып оқушысы түсінетіндей бір бетте сипаттау». Егер сипаттай алсаң — мәнін түсіндің. Егер жоқ болса — сен әлі қажет емес детальдарды қазып жүрсің.

Коммуникация: «сол тестілеушіге» қалай айналмау

Корпорациялардағы ең жиі шағым: «Тестілеушілер релиздерді баяулатады».

«Багтарды табады» емес. «Сапаны арттырады» емес. Баяулатады.

Және бұл әрқашан әділетті емес, бірақ бұл — шындық.

Неліктен бұлай болады?

Себебі үлкен командада тек сенің техникалық сараптамаң ғана емес, оны қалай ұсынатының да маңызды.

Егер сен чатқа: «құрастыру құлады, бәрі жаман, түзетіңдер» деп жазсаң — сені түсінбейді. Әзірлеушінің өз тапсырмалары, өз мерзімі, өз контексті болуы мүмкін.

Қолмен тестілеуден архитектураға: өсу картасы

Енді сен не үшін келгенің туралы — мансап туралы.

Корпорацияда QA-инженерінің классикалық жолы келесідей:

1. Junior / Manual QA — қолмен тексересің, чек-парақтар жазасың, багтар тіркейсің.
2. Middle QA / Automation QA — регресті автоматтандырасың, тестілеу фреймворктарын жазасың, CI конфигурациялайсың.
3. Senior QA / QA Lead — тестілеу стратегиясын жобалайсың, команданы басқарасың, өнім деңгейінде сапаға жауап бересің.
4. QA Architect / Test Architect — тестілеу инфрақұрылымын құрасың, құралдарды таңдайсың, стандарттарды анықтайсың.

Бірақ бір нюанс бар.

Осы деңгейлер арасындағы өту — бұл жай ғана «жаңа құралды үйрену» емес. Бұл ойлаудың өзгеруі.

💡 Кеңес: Manual-дан Automation-ға өту үшін Selenium-ді үйрену жеткіліксіз. Әзірлеуші сияқты ойлауды бастау керек: кодтың модульділігі, қателерді өңдеу, тесттердің өнімділігі туралы.

Senior-ден Architect-ке өту үшін жақсы тесттер жазу жеткіліксіз. Бизнес-стратегияны түсіну керек: неге дәл осы архитектураны таңдадыңыз, CI-дің бір минуттық тоқтауы қанша тұрады, сапа пайдаланушыларды ұстап қалуға қалай әсер етеді.

Егер сен өскің келсе — тек кодқа ғана емес, жоғарыға да қара.

Жану тұзағы: өзіңді қалай жоғалтпау

Корпорация — бұл қарқын туралы.

Екі апта сайын релиздер. Күн сайын митингтер. Чаттарда мыңдаған хабарламалар. Үнемі ақпарат ағыны.

Егер сен өзіңе шекара қоймасаң — алты айда жанып кетесің.

Тестілеуші үшін жанудың белгілері ерекше:

— Кез келген багты табуға болатынына сенуді тоқтатасың. «Бәрібір бір нәрсені жіберіп аламыз». — «Регресс» сөзін жек көре бастайсың. — Тек «позитивті сценарийді» тексересің, себебі «негативтіге» күш жоқ. — Әзірлеушілермен дауласуды тоқтатасың, тіпті дұрыс болсаң да.

💡 Кеңес: Корпорацияда «батырлық» тұзағына түсу оңай. Егер сен бәрін өз мойныңа алсаң — алдымен мақтайды, сосын жұмысқа көміп тастайды. «Жоқ» деп айтуды және неге екенін дәлелдеуді үйрен. «Мен мұны істемеймін» емес, «Мен мұны сапалы түрде мерзімде үлгермеймін, басымдықтарды қайта қарайық».

Күрделі инфрақұрылымнан қорқу

Тағы бір тұзақ — қорқыныш.

Сен 50 сервистен тұратын микросервистік архитектураға, таратылған дерекқорға, көптеген джобтары бар CI/CD-ге қ