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

[Inglourious Basterd]

Не може да се споредува технологијата пред 15 години со ова денес. Од експанзија на бизнисите до напредокот на технологиите, има разлика во секој поглед. Не верувам дека пред 15 години секојдневен деплој на продукција било стандард.

Не се согласувам со некои работи во твојот пост. Да, има основни работи кои треба да се знаат. ИТ сметам дека е крајната граница кај шо завршува одговорноста е на девелоперот. Се над тоа, посебно во големи системи со микросервиси, не треба да ме интересира. Е2Е тестови треба да си куца дедициран QA. Не ме интересира што прави сервисот над мене, сакам да знам само шо ми дава како инпут и шо се очекува од мене.
За инфраструктура, едно е да сетираш докер локално, друго е да ја спремиш цела околина на сервер. Како бекендаши цело време тупиме за апстракции, од друга страна од нас се очекува да знаеме конкретни детали за секој чекор од процесот на развивање продукт. На фронт не ги интересира шо база користиш или во кој јазик е искуцан сервисот, му треба само ендпоинт. На бизнис аналистот па ич не го занима со која технологија се занимаваш. На девопс тимот не го интересира бизнис логиката на сервисите. На архитектот не го занима конкретна имплементација во некој сервис. Ама од тебе како бекендаш се очекува:

- да одиш на бизнис состаноци и да ја знаеш бизнис логиката
- да куцаш код кој ќе ја извршува таа бизнис логика
- да знаеш да ја сетираш и менаџираш цела инфраструктура
- да се грижиш за цел циклус на QA
- активно да учествуваш во креирање на архитектурата
- да знаеш да искуцаш и фронт

Порано ако сакаше пример queue, им пишуваш на девопс, сетираат на околина и ти го користиш. Сеа имаш Terraform/Ansible, буквално во описот им стои Infrastructure as a code. Сеа и овој дел е твој за менаџирање, девопс се тука за big picture. Најважниот аспект од работата на бекендаш, според мене имплементацијата на бизнис логиката, е скроз запоставен со ваков начин на организација.
Од друга страна, треба време за било кој да знае успешно да ги извршува сите овие фази. Секоја нова технологија има концепти кои се специфични за истата. Ако сетирам инфраструктура на GCP, сакам да знам која команда што прави. Не на слепо да куцам од некој туторијал на Медиум. Сакам да прочитам за имплементацијата на тоа што го сетирам, да го сетирам според мои потреби. Утре ако имам проблем, да знам да го средам.Ова, заедно со фактот дека на 6 месеци имаш некоја нова технологија која станува buzz word и нормално, сакаш да ја имплементираш, плус експанзијата на бизнис домејнот ( ретко кој менаџира само еден сервис, посебно па сеа со микросервисите, еден домен може да има и 20 сервиси ) ја прави оваа позиција премногу широка. Ова е мое мислење.

Продуктот, неговата зрелост и неговиот квалитет е сопственост на тимот. Така било секогаш, така ќе биде секогаш. Секако дека е корисно во тимот да има што повеќе специјалности. Ама доколку ги нема, работата се приоретизира, од самиот тим, и се работи тоа што е најприоритетно, во рамки на можностите на луѓето.

На пример, ако стабилизација од аспект на квалитет е повредна за продуктот од развивање на нова функционалност, тогаш цел тим ќе биде вклучен во подобрување на неговиот квалитет. Без разлика на титулите на луѓето. Не може да имаме продукт во кој што имаме 50 багови со секој рилис, од кој половина се reappearing, и да речеме QA има да си го автоматизира тестирањето сам, овие 5 девелопери ќе развиваат нови функционалности. Здравиот разум не дозволува.

 

[Емкаа]

Продуктот, неговата зрелост и неговиот квалитет е сопственост на тимот. Така било секогаш, така ќе биде секогаш. Секако дека е корисно во тимот да има што повеќе специјалности. Ама доколку ги нема, работата се приоретизира, од самиот тим, и се работи тоа што е најприоритетно, во рамки на можностите на луѓето.

На пример, ако стабилизација од аспект на квалитет е повредна за продуктот од развивање на нова функционалност, тогаш цел тим ќе биде вклучен во подобрување на неговиот квалитет. Без разлика на титулите на луѓето. Не може да имаме продукт во кој што имаме 50 багови со секој рилис, од кој половина се reappearing, и да речеме QA има да си го автоматизира тестирањето сам, овие 5 девелопери ќе развиваат нови функционалности. Здравиот разум не дозволува.

Малце мешаме инцидентни појави со секојдневни одговорности. Со ова темпо до кај ќе тераш? Секоја нова функционалност побарува промени во автоматизираните тестови. Дали автоматизирани тестови се дел од твојата одговорност? Ако да, која е границата до која тестираш?

Во конкретниов пример, зошо имаш 50 бага со секој релис? Може пошо кодот не е дизајниран добро од старт, па со секоја промена во едно место расипуваш на уште три места. Ама немаш време да рефакторираш пошо треба да вршиш работа и за QA.

 

[Inglourious Basterd]

Малце мешаме инцидентни појави со секојдневни одговорности. Со ова темпо до кај ќе тераш? Секоја нова функционалност побарува промени во автоматизираните тестови. Дали автоматизирани тестови се дел од твојата одговорност? Ако да, која е границата до која тестираш?

Во конкретниов пример, зошо имаш 50 бага со секој релис? Може пошо кодот не е дизајниран добро од старт, па со секоја промена во едно место расипуваш на уште три места. Ама немаш време да рефакторираш пошо треба да вршиш работа и за QA.

Tимот одлучува. Ако ги направи дел од Definition of Done, тогаш да, се одговорност на било кој што има скилс да ги напише. Во хипотетичкиов случај што го раскажуваш, нема вредност да бидат дел од DoD. Како ви е издефиниран DoD и дали го дискутирате на ретроспективи?

Да, прашањата се супер. Баш тие треба да бидат. Зошто се 50. Ако се заради лош код, тогаш се друго ќе се деприоретизира, и ќе се работи на рефакторинг. Ако се заради сложен и изврзан домејн, ќе се пишуваат повеќе тестови. Ако рефакторот има поголема вредност од пишување на автоматски тестови, зошто побогу би те терал некој да ги пишуваш?

 

[zmej gorjanin]

Малце мешаме инцидентни појави со секојдневни одговорности. Со ова темпо до кај ќе тераш? Секоја нова функционалност побарува промени во автоматизираните тестови. Дали автоматизирани тестови се дел од твојата одговорност? Ако да, која е границата до која тестираш?

Во конкретниов пример, зошо имаш 50 бага со секој релис? Може пошо кодот не е дизајниран добро од старт, па со секоја промена во едно место расипуваш на уште три места. Ама немаш време да рефакторираш пошо треба да вршиш работа и за QA.

Или пошто не работат test driven development.

 

[Емкаа]

Tимот одлучува. Ако ги направи дел од Definition of Done, тогаш да, се одговорност на било кој што има скилс да ги напише. Во хипотетичкиов случај што го раскажуваш, нема вредност да бидат дел од DoD. Како ви е издефиниран DoD и дали го дискутирате на ретроспективи?

Да, прашањата се супер. Баш тие треба да бидат. Зошто се 50. Ако се заради лош код, тогаш се друго ќе се деприоретизира, и ќе се работи на рефакторинг. Ако се заради сложен и изврзан домејн, ќе се пишуваат повеќе тестови. Ако рефакторот има поголема вредност од пишување на автоматски тестови, зошто побогу би те терал некој да ги пишуваш?

Може имаме различни сфаќања за некои термини. Како ДоД, според мене е разумно да се вклучени ИТ ( унит тестовите се подразбира ). Како ИТ јас ги рачунам тестовите кои тестираат едно цело flow, со мокирање на надворешните зависности. Е2Е тестовите може да се во рамки на твојот домејн ( во овој случајј истите сценарија како ИТ, но не се мокира ), но може и да вклучуваат комплицирани flows кои опфаќаат повеќе сервиси од различни домејни кои не се под твоја "надлежност".
Овој последниов дел е веќе надвор од одговорностите на девелоперите според мене, ама еве по ново и тоа треба да се работи.

 

[zmej gorjanin]

Може имаме различни сфаќања за некои термини. Како ДоД, според мене е разумно да се вклучени ИТ ( унит тестовите се подразбира ). Како ИТ јас ги рачунам тестовите кои тестираат едно цело flow, со мокирање на надворешните зависности. Е2Е тестовите може да се во рамки на твојот домејн ( во овој случајј истите сценарија како ИТ, но не се мокира ), но може и да вклучуваат комплицирани flows кои опфаќаат повеќе сервиси од различни домејни кои не се под твоја "надлежност".
Овој последниов дел е веќе надвор од одговорностите на девелоперите според мене, ама еве по ново и тоа треба да се работи.

Зошто девелопер би правел E2E тестинг освен ако нема тестери во фирмата? Девелопер пишува unit и integration тестови и тоа не на 100% од кодот пошто се дуплира времето за работа. Она што е тотално без врска особено во поголеми фирми е кога се бара од тебе да напишеш цела техничка докумнетација за кодот кој треба да го напишеш доколку се работи за некој нов feature, модул или нов проект и бара од тебе да напишеш точна естимација. Или кога на тестери треба јас да им пишувам acceptance criteria и тестинг сценарија во тикетот. Се губи доста време.

 

[Inglourious Basterd]

Може имаме различни сфаќања за некои термини. Како ДоД, според мене е разумно да се вклучени ИТ ( унит тестовите се подразбира ). Како ИТ јас ги рачунам тестовите кои тестираат едно цело flow, со мокирање на надворешните зависности. Е2Е тестовите може да се во рамки на твојот домејн ( во овој случајј истите сценарија како ИТ, но не се мокира ), но може и да вклучуваат комплицирани flows кои опфаќаат повеќе сервиси од различни домејни кои не се под твоја "надлежност".
Овој последниов дел е веќе надвор од одговорностите на девелоперите според мене, ама еве по ново и тоа треба да се работи.

Јас имам овервју врз 5 тима. Секој од тимовите е оунер на 1-3 продукти. И буквално секој тим, за секој различен проект, има различен DoD.

Имаме продукт за кој ни јунит тестови не се дел од DoD. Само девелопмент и мануелен тестинг.
Од друга страна имаме продукт каде што 90% code coverage (што јас не сметам дека е исправно, превисока е бројката и не мора да значи ништо), интеграциски, автоматски функционални со 100% покриени тест кејсови и перформанс во рамките на RAG критериумот за проектот е дел од DoD.
Имаме трет, b2b проект на кој тестирањето е комплетно автоматизирано, и QAs само пишуваат тест кејсови и тест сценарија, а нивното имплементирање се врши од девелоперите.

И за секоја од различните DoD има причина зошто се такви (комбинација помеѓу бизнис потреби и зрелост и способност на тимот). Поентата ми е, во софтвер инженеринг нема универзални правила. Од мое искуство има само еден универзален принцип, дека продуктот е сопственост на тимот и дека тимот треба да знае што е најдобро за продуктот.

 

[JaqenH'ghar]

Или кога на тестери треба јас да им пишувам acceptance criteria и тестинг сценарија во тикетот. Се губи доста време.

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

 

[Емкаа]

Зошто девелопер би правел E2E тестинг освен ако нема тестери во фирмата? Девелопер пишува unit и integration тестови и тоа не на 100% од кодот пошто се дуплира времето за работа. Она што е тотално без врска особено во поголеми фирми е кога се бара од тебе да напишеш цела техничка докумнетација за кодот кој треба да го напишеш доколку се работи за некој нов feature, модул или нов проект и бара од тебе да напишеш точна естимација. Или кога на тестери треба јас да им пишувам acceptance criteria и тестинг сценарија во тикетот. Се губи доста време.

И јас се прашувам истото. Тоа ми е поентата на цел муабет, дека и QA како позиција се проретчува и одговорностите се шифтаат кон бекендашите. Барем тука, во ниеден тим досега сум немала тестери. Има по неколку во цела компанија, и одговорноста не им е тестирање ниту автоматизирани тестови, повеќе се ориентирани кон release management. Одговорноста за е2е тестирање, без разлика дали е мануелно или автоматски, паѓа на девелопери. Сум седела во канцеларија со 5 девелопери кај шо МАНУЕЛНО тестираме е2е flow. Се пушта реквестот од фронт, па првиот тим потврдува дека е испроцесирано и пратено, вториот тим потврдува дека е примен реквестот и така. Тотално губење време за девелопери. После кога дојде време за пишување автоматизирани е2е тестови пак девелоперите ги пишуваа. Еве и сега сменав работно место, до пред две години имале дедициран QA по тим, сеа се останати 5 во цела компанија.

Јас имам овервју врз 5 тима. Секој од тимовите е оунер на 1-3 продукти. И буквално секој тим, за секој различен проект, има различен DoD.

Имаме продукт за кој ни јунит тестови не се дел од DoD. Само девелопмент и мануелен тестинг.
Од друга страна имаме продукт каде што 90% code coverage (што јас не сметам дека е исправно, превисока е бројката и не мора да значи ништо), интеграциски, автоматски функционални со 100% покриени тест кејсови и перформанс во рамките на RAG критериумот за проектот е дел од DoD.
Имаме трет, b2b проект на кој тестирањето е комплетно автоматизирано, и QAs само пишуваат тест кејсови и тест сценарија, а нивното имплементирање се врши од девелоперите.

И за секоја од различните DoD има причина зошто се такви (комбинација помеѓу бизнис потреби и зрелост и способност на тимот). Поентата ми е, во софтвер инженеринг нема универзални правила. Од мое искуство има само еден универзален принцип, дека продуктот е сопственост на тимот и дека тимот треба да знае што е најдобро за продуктот.

Нормално дека тимот сам одлучува за тие работи. Поентата ми е дека одговорностите од други позиции се повеќе и повеќе се шифтаат кон девелоперите, па веќе станува природно да имаш бекендаш кој може да хендла се, од фронт, до бизнис логика, до инфраструктура на клауд. Што според мене не е во ред.

 

[zmej gorjanin]

И јас се прашувам истото. Тоа ми е поентата на цел муабет, дека и QA како позиција се проретчува и одговорностите се шифтаат кон бекендашите. Барем тука, во ниеден тим досега сум немала тестери. Има по неколку во цела компанија, и одговорноста не им е тестирање ниту автоматизирани тестови, повеќе се ориентирани кон release management. Одговорноста за е2е тестирање, без разлика дали е мануелно или автоматски, паѓа на девелопери. Сум седела во канцеларија со 5 девелопери кај шо МАНУЕЛНО тестираме е2е flow. Се пушта реквестот од фронт, па првиот тим потврдува дека е испроцесирано и пратено, вториот тим потврдува дека е примен реквестот и така. Тотално губење време за девелопери. После кога дојде време за пишување автоматизирани е2е тестови пак девелоперите ги пишуваа. Еве и сега сменав работно место, до пред две години имале дедициран QA по тим, сеа се останати 5 во цела компанија.



Нормално дека тимот сам одлучува за тие работи. Поентата ми е дека одговорностите од други позиции се повеќе и повеќе се шифтаат кон девелоперите, па веќе станува природно да имаш бекендаш кој може да хендла се, од фронт, до бизнис логика, до инфраструктура на клауд. Што според мене не е во ред.

Што користите за е2е автоматизирани тестови? Puppeteer,Selenium?

 

[Miss Paranoia]

Или кога на тестери треба јас да им пишувам acceptance criteria и тестинг сценарија во тикетот. Се губи доста време.

Ac треба да пишува бизнис аналист/ по. На рифајмент да се ревјуира и дополни од цел тим. Мене ми нема поента девелопери да пишуваат acceptance criteria, дев да дефинира, дев да имплементира, дев да тестира. Ако знаат да го најдат багот не би го ни направиле, нели

@Емкаа ме чуди ова што го пишуваш, веројатно зависи и од фирмите, од она јас што го гледам кај нас, соодносот дев/qa се поише се изедначува. Конкретно кај мене во тим се 5 дев со 4 qa. Ама се согласувам со @Inglourious Basterd дека работата треба да ја заврши тимот односно тој што знае како и може. Тоа значи ако qa има технички скилс да направи ендпоинт и има време и е приоритет за проектот треба да го направи, и да куца ит и јунит и да сетира околини итн. И обратно дев да пишува е2е ако му е потребно тоа на проектот/продуктот. Е сега проблемот е што реткост се такви технички зрели тимови.

 

[Jax Rebel]

Дедициран QA според мене е халфтајм позиција. 40 саати неделно не знам како би го исполнил времето. Еве се прави некој нов feature, unit тестови пишуваат програмерите. Ако им треба 2 недели да ја направат комплет фунцкионалноста, во тоа време QA-от би тестирал веројатно некој претходен release. Кога ќе завршат програмерите после 2 недели, QA-от прави мануелно и автоматско тестирање на новата фунцкионалност, ама колку време му треба за тоа?

Единствено ако QA-от паралелно со програмерите не пишува тест сценарија, ама пак не знам колку е тоа изводливо. Мислења?
(п.с. немам многу искуство во работа со тим со дедицран QA човек)

Идеалан пакет ми е мене QA + Technical writer, мислам дека не постои боље комбо во ИТ свет.

 

[Miss Paranoia]

Дедициран QA според мене е халфтајм позиција. 40 саати неделно не знам како би го исполнил времето. Еве се прави некој нов feature, unit тестови пишуваат програмерите. Ако им треба 2 недели да ја направат комплет фунцкионалноста, во тоа време QA-от би тестирал веројатно некој претходен release. Кога ќе завршат програмерите после 2 недели, QA-от прави мануелно и автоматско тестирање на новата фунцкионалност, ама колку време му треба за тоа?

Единствено ако QA-от паралелно со програмерите не пишува тест сценарија, ама пак не знам колку е тоа изводливо. Мислења?
(п.с. немам многу искуство во работа со тим со дедицран QA човек)

Идеалан пакет ми е мене QA + Technical writer, мислам дека не постои боље комбо во ИТ свет.

Пример: бекенд дев треба да развие ендпоинт, qa треба да напише тестови за него. Реквест и респонс бодија се дефинирани на рифајнмент и работата на сите почнува паралелно. QA ќе ги напише автоматските додека дев го имплементира. После само се пуштаат на околина и се пријавуват багови ако има. Слично и за Фе, се пишуваат feature files, или пејџ објекти и тест сценарија и се чека имплементацијата. Секако под претпоставка дека дизајнот е спремен. За добро организиран тим, нема никакво чекање и тестирање претходни релиси.

 

[Inglourious Basterd]

Пример: бекенд дев треба да развие ендпоинт, qa треба да напише тестови за него. Реквест и респонс бодија се дефинирани на рифајнмент и работата на сите почнува паралелно. QA ќе ги напише автоматските додека дев го имплементира. После само се пуштаат на околина и се пријавуват багови ако има. Слично и за Фе, се пишуваат feature files, или пејџ објекти и тест сценарија и се чека имплементацијата. Секако под претпоставка дека дизајнот е спремен. За добро организиран тим, нема никакво чекање и тестирање претходни релиси.

Не го лажи човекот, признај си дека QA e half time.

 

[Miss Paranoia]

Не го лажи човекот, признај си дека QA e half time.

1/4 едвај