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

  • Креатор на темата Креатор на темата StaticStupid
  • Време на започнување Време на започнување
Blabla234 напиша:
Ако тебе ти одговара да ти прават вака, слободно.
Кликни за повеќе...
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.
 
Amaterasu напиша:
Јас го поддржувам пристапот на немање release верзии и пуштање на тикет на PROD веднаш што ќе биде одобрен. Ова стварно го убрзува развивањето, ја намалува шансата за багови затоа што тасковите ги пушташ еден по еден, не 20 наеднаш.

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

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

Menethil напиша:
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 :D 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, кога работите во фирма каде имате блиска соработка и брз фидбек од сите засегнати.
Знам дека за многумина ваквиот начин на работа е неконвенционален ама гледам и многу фирми, барем тука дека се насочуваат на ваков начин на работа, што од финансиска, што од организациска потреба.
 
Емкаа напиша:
Работам во банка без физички филијали, значи се е дигитализирано. Платформата има над 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. Истите правила важат и за новите луѓе на проектот?
 
Ај дур сме на темава, trunk based development или gitflow користите на проектите каде што работите?
 
QA може да се случи да не детектира проблеми врзани со инфраструктура, проблеми врзани со concurrency каде имаш dead locks во база, race conditions во cache меморија, performance bottlenecks кои се јавуваат за време на heavy loads, па кога ќе се направи деплојот проблемите да излезат, може да се случи и да фали нешто во база или да фалат енв варијабли, исто така QA е немоќно тука. Ама ако се работи за тим каде многу луѓе влегуваат и излегуваат и доведена е во прашање конзистентноста и интегритетот на кодот, тогаш QA е must have. Не дека девелопери не можат да си тестираат сами и да пишуваат и мењаат интеграцииски и јунит тестови после секоја промена во кодот, ама дека дев ќе земе и ќе ги помине сите edge кејсови при e2e тестирање, тешко малце, прво пошто се нема време.
 
^Зависи од културата внатре во фирмата. Имаш фирми каде што те оценуваат според тоа колку тикети си затворил и дали може да те стават на 2-3 клиенти истовремено. Ама имаш и фирми каде што ти даваат функционалност и од старт те прават да си одговорен за истата. Овие вторите можат многу долго да тераат без QA.
 
Емкаа напиша:
Работам во банка без физички филијали, значи се е дигитализирано. Платформата има над 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
 
Последно уредено:
You must log in or register to reply here.

Kajgana Shop

Back
На врв Bottom