Ce procent din timpul total de dezvoltare reprezinta crearea de unit teste?

Imi dau seama ca nu exista o cifra exacta si depinde de multi factori, ce m-ar interesa e o medie din experienta voastra personala. Practic cand ati scris un cod nou si i-ati facut si unit teste, care a fost raportul intre timpul petrecut scriind codul si cel petrecut facand unit testele pentru el.

99%. restul pana la 99.9% sa-i conving pe altii ca-i o solutie buna.

Edited by laffin, 23 August 2021 - 13:57.

Ce sunt "unit teste", daca nu sunt indiscret? Sa inteleaga si altii despre ce este vorba aici.

astea: https://en.wikipedia...ki/Unit_testing
in functie de complexitatea codului si de cum a fost structurat, cam 10-50% din timpul aferent unui task se duce pe unit testing

0% in multe firme de outsourcing de la noi, testarea o face clientu.

Edited by Webbbob, 23 August 2021 - 15:15.

 _Smiley_, on 23 august 2021 - 14:45, said:

Pai "unit testing" suna intr-un fel, iar "unit teste" suna a ceva... tiganeala.

Ok, am inteles.

 Webbbob, on 23 august 2021 - 15:14, said:

Eu clientul... , asta e mega beleaua, multe fime testeaza codul direct la client si iese dezastru, intarzieri de saptamani ca sa modifice o litera sau un / la o cale undeva.
Le-am sugerat sa isi aloce macar 20% din timp sa testeze ce produc, inainte sa mi le arunce ca "resolved". Nu's daca au alocat exact asa dar ceva s-a imbunatatit, nu au mai fost multe erori de care te prinzi la prima rulare integrala a codului.
Tin sa spun totusi ca "sugestia" de cele mai multe ori a fost ignorata, a trebuit trecut prin PM si reject-uri serioase pe taskuri ca sa miste ceva in aceasta directie.
Cei 20% nu puteau a fi trecuti separat in mod oficial ci erau inclusi tot in timpul lor standad alocat pentru techincal developments. Sau puteau, dar in acest caz devenea exagerat de lung timpul alocat lor si se scurta cel al clientului . Bataile intre PMs..

Exemplu mai extrem: https://stackoverflo...tion-code-ratio

 aeon, on 23 august 2021 - 16:10, said:

te inteleg perfect si imi e rusine ca sunt coleg de breasla cu magarii care fac asa, probl asta pleaca de la manager pana la sclavetele care scrie codu toti accepta tacit sa nu respecte procedurile de lucru si codu de bune practici.

 aeon, on 23 august 2021 - 16:10, said:

Data viitoare alegi si tu o firma care are testeri dedicati, eventual au implementat un sistem Agile, Scrum in firma.

 Shinji, on 23 august 2021 - 13:21, said:

Unit testingul ii aloc 30% din timpul de dezvoltare, face parte din dezvoltarea propriuzisa, are sprint special dedicat pt acest lucru.
In plus folosim extensiv SonarQube pt monitorizarea codului ,care trebuie sa fie minim 90% cod de calitate.

 Bursul, on 23 august 2021 - 17:54, said:

Nu neaparat.Poti sa incluzi un sprint dedicat pt acest lucru de la inceput in costul proiectului.

N-am măsurat, dar aș zice între 10-15%.
Apoi cam 20% design tehnic/propunere soluție, 5-10% code review, 10-15% specificații funcționale (pt client) și tehnice (interne), cam 15% teste automate design/execuție.
Scris cod propriu-zis, cam 25-35% din timpul total.

 YalFa, on 23 august 2021 - 20:10, said:

Contribuiți și voi cu reguli sau aveți un profil generic?

Contribuim , avem om special pentru asta: Data Qualtiy  Architect.(DQA), post creat de catre Enterprise Architecture Management(EAM) Committee al corporatiei unde lucrez.
EAM-ul si DQA-ul reprezinta Data Governance-ul care raspunde sau ofera solutii pt Board of Directors , daca ideilor lor impacteaza cumva  managementul datelor.

La nivel de echipa, calitatea codului + testele unitare ,sunt pilonul de baza pt prime de vacanta si mariri in timpul anului de salariu(pe langa cele stabilite la inceputul anului fiscal).

Edited by YalFa, 23 August 2021 - 21:37.

 Bursul, on 23 august 2021 - 17:54, said:

Toti cu care lucrez au implementat Agile si/sau Scrum dar in final si acestea au ajuns doar niste balareli producatoare de matrici si exceluri degeaba. Problema sunt managerii care nu vad decat tabele si alocari sau sprint-uri necorelate, fara a avea idee de realitate.

S-a ajuns ca testarea sa fie facuta de client, acesta trebuind sa demonstreze ca "nu merge corespunzator" cu foarte multe detalii. Adica timp gramada consumat pe unit-testing cand de fapt clientul ar trebui sa se concentreze pe UAT...

Edited by aeon, 24 August 2021 - 09:28.

Probabil nu s-a implementat cum trebuie. La noi a venit doi traineri au tinut cursuri pentru toate departamentele si au continuat apoi sa vina in firma sa vb cu Scrum Masterii.

 aeon, on 24 august 2021 - 09:22, said:

Evident ca este o implementare gresita, deficitara care pierde timp si bani pentru ca:

Quote

In mediul Agile/Scrum, clientul face parte din echipa, este co-pariticipant la daily-urile echipei. Scopul este ca tocmai sa previne demonstratii ca "nu merge corespunzator".
Nu se ajunge sa se investeasca timp si bani in cod scris pt un feature care nu va merge corespunzator sau mult mai rau va fi eliminat doarece clientul a vrut altceva.
Nu stiu cum sunt prin alte firme, dar la noi o astfel de problema este un criteriu de concediere a echipei manageriale pt incompetenta si pierderi de bani.

Scopul metotologiei Agile este livrarea incrementala de feature-uri de calitate atat in conceptie cat si implementare. La noi clientul stie dinaintea noastra cum va arata produsul final
iar cand scoatem versiunea 1 pe piata, clientul demult stie sa lucreze cu ea inca din stadiul beta(de dinaintea testelor functionale).

Cum spuneam, comunicare stransa cu clientul este scopul Agile iar la noi, un reprezentant/delegat al clientului face parte din echipa dezvoltare.
Daca clientului final(beneficiarul)  nu-i place ce a iesit este efectiv problema intre reprezentatul/delegatul clientului si clientul final(beneficiarul)
Astfel aia se pot certa intre ei, iar noi le luam banul si mergem mai departe.

Edited by YalFa, 24 August 2021 - 12:10.

Zero.

Clientul a zis clar ca decat sa plateasca 10 ore pentru a scrie teste acum, mai bine plateste 200 de ore de depanare pe parcursul a catorva luni.

"Scopul metotologiei Agile este livrarea incrementala".. asta e una din probleme, multi incearca sa forteze Agile la proiecte care nu suporta livrare incrementala (sau suporta prea putin). Asta duce la aberatii inclusiv la testare