ИТ фирми и пракси во Скопје

[ToxicTown]

Ако тебе ти одговара да ти прават вака, слободно.

Jas baram rabota so meseci i ne e mnogu razlicna od ova na videoto. Live coding e prakticno standard vo posledno vreme, i se pocesto nudat samo B2B sorabotka (preku firma/konsultant), so sto moze da te izbrkaat koga im dusa saka.

 

[Емкаа]

Јас го поддржувам пристапот на немање release верзии и пуштање на тикет на PROD веднаш што ќе биде одобрен. Ова стварно го убрзува развивањето, ја намалува шансата за багови затоа што тасковите ги пушташ еден по еден, не 20 наеднаш.

Ама мислам дека е тешко да развиваш комплексен софтвер без QA. Еднставно, колку и да имаш автоматизирани тестови, тешко е да ги покриеш сите можни сценарија што можат да се случат. Добар QA инженер е пред се ултра јак корисник на системот. Ги знае сите финти и edge case-ови.
Во голем систем, ти како рандом дев немаш шанса да ги знаеш сите функционалности на системот. Како резултат на тоа, не си способен да напишеш тестови што ќе можат ефективно да го истестираат. Најголемата разлика е во контекстот што го има dev-от и тој што го има QA-от.

Кај мене во фирма, кога имаме некој покомплексен feature за тестирање, QA човекот може да помине неколку дена во пишување на test case-ови. Не е ова затоа што тој се лабави и пие кафиња, туку толку е времето што му треба да ги дефинира. После иде тестирањето што може да трае и цела недела.
Во овој случај, и те како сакам да имам QA човек кој ќе се бави со оваа работа, отколку ова време да го троши некој девелопер, што уствари може да донесе многу поголема вредност ако работи на друг тикет.

Ne znam ni kakov vi e produktot, ni kakva vi e firmata, pa mozhebi kaj vas e soodvetno da nema covek so takva pozicija. I ja rabotam vo takva firma, PO e toj sto pravi proverki i na kraj samite musterii Na prethodniot proekt, takvo nesto bese nevozmozno da se izvede. Brz development, celosniot proekt bese nepoznat za povekjeto inzeneri za da mozhat sami da pratat sto se isporacuva.

Proverka na kvalitet e normalna rabota vo site industrii, ne samo vo IT. Dali kje go pravi covek koj e specijaliziran vo toa, samite inzineri i tn, si e stvar na organizacija. Nekoj kje si gubi vreme so toa. Po mene dosta podobro e da e covek specijaliziran za toa, kolku i da e rabotata poednostavna.

Работам во банка без физички филијали, значи се е дигитализирано. Платформата има над 2 милиони корисници. Апсолутно не е едноставен продукт, има мал милион предизвици, посебно пошто главен продукт на банката е трејдање. Ако ваков мега продукт може да биде успешен без QA, не гледам зошто истиот пристап не би можел да се примени во продукти од помали размери.

Сум работела за многу помали продукти каде пристапот беше тотално различен, церемонијален, бавен. Со пуштање на прод секој втор четврток, па секој втор понеделник затворање на сите ПР и merging на релис бренч, па секој втор вторник тестирање на пред продукција од страна на QA, па фиксање багови под стрес во среда, па четврток стискање палци и пуштање се наеднаш. Е ако има баг кој знае од што е, копај низ комити и мисли се.
PO-то креираше сториња на Јира и го менаџираше планирањето, ама не беше дел од тимот. Ние едноставно добивавме листа со барања која ја преточувавме во софтвер, некој друг тестираше и тоа беше тоа.

Искрено кога започнав на сегашното работно место ми беше страв од првичниот впечаток на лабав пристап, ама после толку време поминато тука, не би менувала ваков начин на работа за ништо друго.

Прво самиот тим има мајндсет you build it you own it. Во секоја смисла. Ние како тим сме одговорни за квалитетот на софтверот, значи при сама изработка и во секојдневната работа дискутираме секакви сценарија. Ние сме истовремено и девелопери и business owners поради ваквиот пристап, можам да кажам дека секој во тимот е на некој начин и експерт за самиот домејн. Некогаш и свесно не покриваме 100% од случаите, има некој edge use case чија имплементација не носи толку голем бенефит во споредба со времето изгубено на покривање на тој случај. Едноставно креираме метрики и следиме колку често би имале таков проблем во продукција, па соодветно итерираме и оптимизираме за тоа.
И добар QA често не може да предвиди некои однесувања на корисниците, ти може да дизајнираш скроз bulletproof систем што поминал секакви тест сценарија, и да дојде некој 80 годишен дедо, да направи каша попара ( а притоа сценариото е скроз леџит ) и пак се враќаш на нула.

Тематикава е длабока, и самиот факт што работам во продукт компанија а не како консултат на дел од софтвер што истовремено се гради од 10 тима низ цел свет придонесува за фактот што повеќе тежнеам кој овој пристап. Свесна сум дека не може да се употреби секогаш и насекаде, ама ете имајте го на ум дека се деливира добар и квалитетен софтвер и без QA, кога работите во фирма каде имате блиска соработка и брз фидбек од сите засегнати.
Знам дека за многумина ваквиот начин на работа е неконвенционален ама гледам и многу фирми, барем тука дека се насочуваат на ваков начин на работа, што од финансиска, што од организациска потреба.

 

[Bridger]

Работам во банка без физички филијали, значи се е дигитализирано. Платформата има над 2 милиони корисници. Апсолутно не е едноставен продукт, има мал милион предизвици, посебно пошто главен продукт на банката е трејдање. Ако ваков мега продукт може да биде успешен без QA, не гледам зошто истиот пристап не би можел да се примени во продукти од помали размери.

Сум работела за многу помали продукти каде пристапот беше тотално различен, церемонијален, бавен. Со пуштање на прод секој втор четврток, па секој втор понеделник затворање на сите ПР и merging на релис бренч, па секој втор вторник тестирање на пред продукција од страна на QA, па фиксање багови под стрес во среда, па четврток стискање палци и пуштање се наеднаш. Е ако има баг кој знае од што е, копај низ комити и мисли се.
PO-то креираше сториња на Јира и го менаџираше планирањето, ама не беше дел од тимот. Ние едноставно добивавме листа со барања која ја преточувавме во софтвер, некој друг тестираше и тоа беше тоа.

Искрено кога започнав на сегашното работно место ми беше страв од првичниот впечаток на лабав пристап, ама после толку време поминато тука, не би менувала ваков начин на работа за ништо друго.

Прво самиот тим има мајндсет you build it you own it. Во секоја смисла. Ние како тим сме одговорни за квалитетот на софтверот, значи при сама изработка и во секојдневната работа дискутираме секакви сценарија. Ние сме истовремено и девелопери и business owners поради ваквиот пристап, можам да кажам дека секој во тимот е на некој начин и експерт за самиот домејн. Некогаш и свесно не покриваме 100% од случаите, има некој edge use case чија имплементација не носи толку голем бенефит во споредба со времето изгубено на покривање на тој случај. Едноставно креираме метрики и следиме колку често би имале таков проблем во продукција, па соодветно итерираме и оптимизираме за тоа.
И добар QA често не може да предвиди некои однесувања на корисниците, ти може да дизајнираш скроз bulletproof систем што поминал секакви тест сценарија, и да дојде некој 80 годишен дедо, да направи каша попара ( а притоа сценариото е скроз леџит ) и пак се враќаш на нула.

Тематикава е длабока, и самиот факт што работам во продукт компанија а не како консултат на дел од софтвер што истовремено се гради од 10 тима низ цел свет придонесува за фактот што повеќе тежнеам кој овој пристап. Свесна сум дека не може да се употреби секогаш и насекаде, ама ете имајте го на ум дека се деливира добар и квалитетен софтвер и без QA, кога работите во фирма каде имате блиска соработка и брз фидбек од сите засегнати.
Знам дека за многумина ваквиот начин на работа е неконвенционален ама гледам и многу фирми, барем тука дека се насочуваат на ваков начин на работа, што од финансиска, што од организациска потреба.

LEAN пристап, ама за тоа мора многу споделена одговорност, брз процес на прегледување итн. Имам три прашања доколку сакаш да споделиш искуство.

1. Директно комитате на dev trunk?
2. Кој ви е соодносот на е2е/интеграциски/unit тестови, колку време ви трае тестирање на комитот од прилика?
3. Истите правила важат и за новите луѓе на проектот?

 

[Taker]

Ај дур сме на темава, trunk based development или gitflow користите на проектите каде што работите?

 

[iMirisIUkus]

QA може да се случи да не детектира проблеми врзани со инфраструктура, проблеми врзани со concurrency каде имаш dead locks во база, race conditions во cache меморија, performance bottlenecks кои се јавуваат за време на heavy loads, па кога ќе се направи деплојот проблемите да излезат, може да се случи и да фали нешто во база или да фалат енв варијабли, исто така QA е немоќно тука. Ама ако се работи за тим каде многу луѓе влегуваат и излегуваат и доведена е во прашање конзистентноста и интегритетот на кодот, тогаш QA е must have. Не дека девелопери не можат да си тестираат сами и да пишуваат и мењаат интеграцииски и јунит тестови после секоја промена во кодот, ама дека дев ќе земе и ќе ги помине сите edge кејсови при e2e тестирање, тешко малце, прво пошто се нема време.

 

[KyleXY]

^Зависи од културата внатре во фирмата. Имаш фирми каде што те оценуваат според тоа колку тикети си затворил и дали може да те стават на 2-3 клиенти истовремено. Ама имаш и фирми каде што ти даваат функционалност и од старт те прават да си одговорен за истата. Овие вторите можат многу долго да тераат без QA.

 

[jamey jasta]

Работам во банка без физички филијали, значи се е дигитализирано. Платформата има над 2 милиони корисници. Апсолутно не е едноставен продукт, има мал милион предизвици, посебно пошто главен продукт на банката е трејдање. Ако ваков мега продукт може да биде успешен без QA, не гледам зошто истиот пристап не би можел да се примени во продукти од помали размери.

Сум работела за многу помали продукти каде пристапот беше тотално различен, церемонијален, бавен. Со пуштање на прод секој втор четврток, па секој втор понеделник затворање на сите ПР и merging на релис бренч, па секој втор вторник тестирање на пред продукција од страна на QA, па фиксање багови под стрес во среда, па четврток стискање палци и пуштање се наеднаш. Е ако има баг кој знае од што е, копај низ комити и мисли се.
PO-то креираше сториња на Јира и го менаџираше планирањето, ама не беше дел од тимот. Ние едноставно добивавме листа со барања која ја преточувавме во софтвер, некој друг тестираше и тоа беше тоа.

Искрено кога започнав на сегашното работно место ми беше страв од првичниот впечаток на лабав пристап, ама после толку време поминато тука, не би менувала ваков начин на работа за ништо друго.

Прво самиот тим има мајндсет you build it you own it. Во секоја смисла. Ние како тим сме одговорни за квалитетот на софтверот, значи при сама изработка и во секојдневната работа дискутираме секакви сценарија. Ние сме истовремено и девелопери и business owners поради ваквиот пристап, можам да кажам дека секој во тимот е на некој начин и експерт за самиот домејн. Некогаш и свесно не покриваме 100% од случаите, има некој edge use case чија имплементација не носи толку голем бенефит во споредба со времето изгубено на покривање на тој случај. Едноставно креираме метрики и следиме колку често би имале таков проблем во продукција, па соодветно итерираме и оптимизираме за тоа.
И добар QA често не може да предвиди некои однесувања на корисниците, ти може да дизајнираш скроз bulletproof систем што поминал секакви тест сценарија, и да дојде некој 80 годишен дедо, да направи каша попара ( а притоа сценариото е скроз леџит ) и пак се враќаш на нула.

Тематикава е длабока, и самиот факт што работам во продукт компанија а не како консултат на дел од софтвер што истовремено се гради од 10 тима низ цел свет придонесува за фактот што повеќе тежнеам кој овој пристап. Свесна сум дека не може да се употреби секогаш и насекаде, ама ете имајте го на ум дека се деливира добар и квалитетен софтвер и без QA, кога работите во фирма каде имате блиска соработка и брз фидбек од сите засегнати.
Знам дека за многумина ваквиот начин на работа е неконвенционален ама гледам и многу фирми, барем тука дека се насочуваат на ваков начин на работа, што од финансиска, што од организациска потреба.

Се си има pro's и cons. Па така и ова.
Прво ова захтева солидно, да не речам експертско познавање на бизнис логика од страна на девелопер, што го прави тимот така, прилично затворен, пред се нови луѓе да влезат, што ете, поставува можеби проблем на team scalability.
Друго, можеби не сте дошле до таму, но што ако после X години, истите тие edge cases се зголемат драстично ? Секако, постојат сценарија од тој тип кој ни најдобриот QA не може да ги предвиди. Што ако токму таков испуштен edge case утре можеби предизвика катастрофални последици по бизнисот ? Како митигирате edge cases ?
Како запазувате регулативи и такви ствари ? Како кај внатрешен/надворешен регулатор (што веројатно го има за финтек апликации, шпекулирам) му преточувате дека немате формален QA процес и процес на тестирање ? Како воопшто оди тој процес ?
Еве, доколку се случи проблем? Земате верзија од маин гранка и правите хотфикс локален бранч и правите ПР директно кон маин? Досега не ви се случил хаос со хотфиксови ?
ме интересира баш како функционира, од технички до мајндсет и бизнис аспект.
Tnx

 

[Roronoa]

Совети за благонадежен иден .NET developer?

 

[Xibalba]

Совети за благонадежен иден .NET developer?

Учи занает, плочкар, водоводџија, молер, што и да е.

Ај дур сме на темава, trunk based development или gitflow користите на проектите каде што работите?

Trunk based development

 

[Roronoa]

Учи занает, плочкар, водоводџија, молер, што и да е.



Trunk based development

Фатен сум на орото веќе и активно учам...

 

[Емкаа]

LEAN пристап, ама за тоа мора многу споделена одговорност, брз процес на прегледување итн. Имам три прашања доколку сакаш да споделиш искуство.

1. Директно комитате на dev trunk?
2. Кој ви е соодносот на е2е/интеграциски/unit тестови, колку време ви трае тестирање на комитот од прилика?
3. Истите правила важат и за новите луѓе на проектот?

1. Не, секој таск има посебен бренч
2. Околу 30-40% од развивањето нова функционалност ни оди во пишување автоматизирани тестови и дополнително мануелно тестирање ( кога може ). Интеграциските тестови мислам дека се најмалце застапени, при комплицирана логика секогаш се стремиме да имаме добар unit coverage, но не и за обични круд операции. Најголем дел од тестовите се е2е, и тука гледаме да опфатиме најголем број од сценаријата и било какви инфраструктурни проблеми.

Се си има pro's и cons. Па така и ова.
Прво ова захтева солидно, да не речам експертско познавање на бизнис логика од страна на девелопер, што го прави тимот така, прилично затворен, пред се нови луѓе да влезат, што ете, поставува можеби проблем на team scalability.
Друго, можеби не сте дошле до таму, но што ако после X години, истите тие edge cases се зголемат драстично ? Секако, постојат сценарија од тој тип кој ни најдобриот QA не може да ги предвиди. Што ако токму таков испуштен edge case утре можеби предизвика катастрофални последици по бизнисот ? Како митигирате edge cases ?
Како запазувате регулативи и такви ствари ? Како кај внатрешен/надворешен регулатор (што веројатно го има за финтек апликации, шпекулирам) му преточувате дека немате формален QA процес и процес на тестирање ? Како воопшто оди тој процес ?
Еве, доколку се случи проблем? Земате верзија од маин гранка и правите хотфикс локален бранч и правите ПР директно кон маин? Досега не ви се случил хаос со хотфиксови ?
ме интересира баш како функционира, од технички до мајндсет и бизнис аспект.
Tnx

Како што и реков, самите девелопери сме веќе експерти во домејнот. Нас ПО-то ни кажува што сака да имплементира и тоа е тоа, не седнуваме на целодневен планинг кај што пишуваме сториња со стриктни чекори и acceptance criteria. Пошо веќе 80% од функционалноста ни е позната, со ПО расчистуваме детаљи во итеративен процес.
Начинот на работа ни е моб програмирање, ние 4 денови неделно работиме заедно, тоа значи сите истовремено работиме на еден таск. Затоа и knowledge sharing оди многу брзо за нови девелопери. Тимот од стартна постава со 4 девелопери, се разви во три подтимови со 10 девелопери, така да во поглед на скалабилност не наидовме на некои големи предизвици. Домејнот го сецнавме на три помали домејни кои се тесно поврзани, но оваа поделба ни дава каде каде помал cognitive load.

Во поглед на регулативи, нема регулатива која вели дека секоја функционалност мора да помине низ qa, па тука немаме проблем. Е сега секој инцидент кој афектира поголем број корисници се пријавува на регулаторно тело. На ниво на фирма, досега можам да се сетам на три прилично големи инциденти кои завршија и во јавноста. Два од нив беа од инфраструктурна природа, еден беше грешка на конкретен тим. Зависи од типот на грешката, некогаш се поминува со казна, некогаш лош ПР е полош.

Бекендот е микросервисна архитектура во сопственост на тимот, додека веб и мобилната се монорепо, така да фиксање багови на бекенд е многу поедноставно, едноставно креираме посебен бренч и мерџаме. На веб доколку има фикс за пуштање се стопира се останато, исто е и за мобилната со тоа што багови таму потешко се хендлаат. Најчесто во мобилната пуштаме нови функционалности со feature flag и пуштаме прво за вработени, па постепено зголемуваме процент. Така правиме и интересни експерименти со А/В тестирање.

Постов може е каша попара ама го пишувам три денови, courtesy of my toddler

 

[Menethil]

Работам во банка без физички филијали, значи се е дигитализирано. Платформата има над 2 милиони корисници. Апсолутно не е едноставен продукт, има мал милион предизвици, посебно пошто главен продукт на банката е трејдање. Ако ваков мега продукт може да биде успешен без QA, не гледам зошто истиот пристап не би можел да се примени во продукти од помали размери.

Сум работела за многу помали продукти каде пристапот беше тотално различен, церемонијален, бавен. Со пуштање на прод секој втор четврток, па секој втор понеделник затворање на сите ПР и merging на релис бренч, па секој втор вторник тестирање на пред продукција од страна на QA, па фиксање багови под стрес во среда, па четврток стискање палци и пуштање се наеднаш. Е ако има баг кој знае од што е, копај низ комити и мисли се.
PO-то креираше сториња на Јира и го менаџираше планирањето, ама не беше дел од тимот. Ние едноставно добивавме листа со барања која ја преточувавме во софтвер, некој друг тестираше и тоа беше тоа.

Искрено кога започнав на сегашното работно место ми беше страв од првичниот впечаток на лабав пристап, ама после толку време поминато тука, не би менувала ваков начин на работа за ништо друго.

Прво самиот тим има мајндсет you build it you own it. Во секоја смисла. Ние како тим сме одговорни за квалитетот на софтверот, значи при сама изработка и во секојдневната работа дискутираме секакви сценарија. Ние сме истовремено и девелопери и business owners поради ваквиот пристап, можам да кажам дека секој во тимот е на некој начин и експерт за самиот домејн. Некогаш и свесно не покриваме 100% од случаите, има некој edge use case чија имплементација не носи толку голем бенефит во споредба со времето изгубено на покривање на тој случај. Едноставно креираме метрики и следиме колку често би имале таков проблем во продукција, па соодветно итерираме и оптимизираме за тоа.
И добар QA често не може да предвиди некои однесувања на корисниците, ти може да дизајнираш скроз bulletproof систем што поминал секакви тест сценарија, и да дојде некој 80 годишен дедо, да направи каша попара ( а притоа сценариото е скроз леџит ) и пак се враќаш на нула.

Тематикава е длабока, и самиот факт што работам во продукт компанија а не како консултат на дел од софтвер што истовремено се гради од 10 тима низ цел свет придонесува за фактот што повеќе тежнеам кој овој пристап. Свесна сум дека не може да се употреби секогаш и насекаде, ама ете имајте го на ум дека се деливира добар и квалитетен софтвер и без QA, кога работите во фирма каде имате блиска соработка и брз фидбек од сите засегнати.
Знам дека за многумина ваквиот начин на работа е неконвенционален ама гледам и многу фирми, барем тука дека се насочуваат на ваков начин на работа, што од финансиска, што од организациска потреба.

Vo Makedonija iskustvoto ni e so drug tip na proekti, kade ova vaseto tesko bi funkcioniralo spored mene. Vo groto od slucaevite, firmite fakjaat proekti koj imaat vekje nekakov legacy code, ili ako se pravi nesto novo e najcesto pod strogi deadlines za isporacuvanje na novi delovi. Imav proekti so 50+ developeri vo razlicni zemji i firmi. Nieden ne mozese da gi vrsi ovie raboti sto vie gi pravite, odnosno da bide i biznis owner i QA. Mislam hipoteticki bi mozhel, ama sigurno kje kosta vreme.
E sea za RLX, oni se product pa mozda kaj niv bi mozhele da se organiziraat kako vas. Ama prilicno sum siguren deka kje ostane isto, samo kratat lugje i plati. A ne gleam zaso nekoj bi se raduval na toa, lesno mozhe i na developerite da go napraat istoto.

 

[arsars701]

1. Не, секој таск има посебен бренч
2. Околу 30-40% од развивањето нова функционалност ни оди во пишување автоматизирани тестови и дополнително мануелно тестирање ( кога може ). Интеграциските тестови мислам дека се најмалце застапени, при комплицирана логика секогаш се стремиме да имаме добар unit coverage, но не и за обични круд операции. Најголем дел од тестовите се е2е, и тука гледаме да опфатиме најголем број од сценаријата и било какви инфраструктурни проблеми.


Како што и реков, самите девелопери сме веќе експерти во домејнот. Нас ПО-то ни кажува што сака да имплементира и тоа е тоа, не седнуваме на целодневен планинг кај што пишуваме сториња со стриктни чекори и acceptance criteria. Пошо веќе 80% од функционалноста ни е позната, со ПО расчистуваме детаљи во итеративен процес.
Начинот на работа ни е моб програмирање, ние 4 денови неделно работиме заедно, тоа значи сите истовремено работиме на еден таск. Затоа и knowledge sharing оди многу брзо за нови девелопери. Тимот од стартна постава со 4 девелопери, се разви во три подтимови со 10 девелопери, така да во поглед на скалабилност не наидовме на некои големи предизвици. Домејнот го сецнавме на три помали домејни кои се тесно поврзани, но оваа поделба ни дава каде каде помал cognitive load.

Во поглед на регулативи, нема регулатива која вели дека секоја функционалност мора да помине низ qa, па тука немаме проблем. Е сега секој инцидент кој афектира поголем број корисници се пријавува на регулаторно тело. На ниво на фирма, досега можам да се сетам на три прилично големи инциденти кои завршија и во јавноста. Два од нив беа од инфраструктурна природа, еден беше грешка на конкретен тим. Зависи од типот на грешката, некогаш се поминува со казна, некогаш лош ПР е полош.

Бекендот е микросервисна архитектура во сопственост на тимот, додека веб и мобилната се монорепо, така да фиксање багови на бекенд е многу поедноставно, едноставно креираме посебен бренч и мерџаме. На веб доколку има фикс за пуштање се стопира се останато, исто е и за мобилната со тоа што багови таму потешко се хендлаат. Најчесто во мобилната пуштаме нови функционалности со feature flag и пуштаме прво за вработени, па постепено зголемуваме процент. Така правиме и интересни експерименти со А/В тестирање.

Постов може е каша попара ама го пишувам три денови, courtesy of my toddler

За да немате QA сигурно имате само некое строго flow, каде што се потполнуваат само полиња и клик Cancel or Submit. Нема простор за ad-hoc testing.

 

[Емкаа]

Vo Makedonija iskustvoto ni e so drug tip na proekti, kade ova vaseto tesko bi funkcioniralo spored mene. Vo groto od slucaevite, firmite fakjaat proekti koj imaat vekje nekakov legacy code, ili ako se pravi nesto novo e najcesto pod strogi deadlines za isporacuvanje na novi delovi. Imav proekti so 50+ developeri vo razlicni zemji i firmi. Nieden ne mozese da gi vrsi ovie raboti sto vie gi pravite, odnosno da bide i biznis owner i QA. Mislam hipoteticki bi mozhel, ama sigurno kje kosta vreme.
E sea za RLX, oni se product pa mozda kaj niv bi mozhele da se organiziraat kako vas. Ama prilicno sum siguren deka kje ostane isto, samo kratat lugje i plati. A ne gleam zaso nekoj bi se raduval na toa, lesno mozhe i na developerite da go napraat istoto.

Да, затоа и укажав дека не работи ваков пристап насекаде. Работев во МК пред да заминам, знам и како стојат работите со проекти и како се работи. Работиш дур клиентот има потреба од тебе, потоа чао пријатно.
Едноставно поентата ми беше дека барем денес со сите автоматизирани тестови некако не гледам иднина за qa како професија, впрочем и одговорностите на самите девелопери се каде каде поголеми отколку порано. Пред само 5 години фул стек значеше фронд и бекенд девелопер, денес тоа значи фронт, мобилна, бекенд, инфраструктура, qa и business owner.

За да немате QA сигурно имате само некое строго flow, каде што се потполнуваат само полиња и клик Cancel or Submit. Нема простор за ad-hoc testing.

Имаме прилично комплицирани workflows, ама домејнот ни е мал и имаме длабоко познавање на истиот.

 

[Menethil]

Да, затоа и укажав дека не работи ваков пристап насекаде. Работев во МК пред да заминам, знам и како стојат работите со проекти и како се работи. Работиш дур клиентот има потреба од тебе, потоа чао пријатно.
Едноставно поентата ми беше дека барем денес со сите автоматизирани тестови некако не гледам иднина за qa како професија, впрочем и одговорностите на самите девелопери се каде каде поголеми отколку порано. Пред само 5 години фул стек значеше фронд и бекенд девелопер, денес тоа значи фронт, мобилна, бекенд, инфраструктура, qa и business owner.

Имаме прилично комплицирани workflows, ама домејнот ни е мал и имаме длабоко познавање на истиот.

Pa nz dali kje isceznat, kje se namalat sigurno. Ama toa e i za nas ostanatite. Odgovornostite se spojuvaat zasto se kratat pari i pozicii, inaku nikoj ne bi sakal sestolog. Dopolnitelno, sekogas kje ima takov tip na proekt i kompanii ko nasite.