Introduksjon
Siden jeg begynte som programvare utvikler i 2009 har ting endret seg mye innen QA, og spesielt som følge av DevOps tankegangen. Den gangen var ikke kodekvalitet og testing blitt prosessmessig definert på samme måte som idag, og gikk stort sett i code review sessions. Forretningsmessige kritikaliteter kom i større grad fremfor disse tingene som ble ansett som mer periferalt. Resultatet var at de prosjektene som varte lenge var vanskelig å forvalte, ergo tidskrevende og dyrt.
Dagens QA prosess
I dagens utviklingsprosess er QA og testing blitt formalisert i større grad. Verktøyene legger opp til at man for hver endring må lage en 'pull request' som må godkjennes av en annen utvikler for at endringen skal tas med. I tillegg har man maskinelle statiske kodeanalyse verktøy.
IT prosjekter
Siden vi lever i en tid med mye endringer, enten det er konkurransesituasjonsendring eller politiske endring er det umulig for en som jobber på leveransenivå å kunne si noe om hvor lenge prosjekter varer. Det betyr at man ikke skal gå forlangt den andre veien heller når det kommer til QA prosessen, dvs, lene seg fullstendig over til sin teknikerrolle (som blir veldig subjektiv i en pull-request setting).
Min erfaring
Til og med 'de lærde strides' som det sies, og dette fenomenet ser man også høyt i akademiske miljø. Når en konsulent vier hele sitt fokus på den tekniske delen og ransaker denne opp-og-ned-i-mente helt etter egen subjektiv mening, og glemmer andre faktorer som effektivitet ja da blir det dyrt. Jeg vil si edruelig vurdering er en uvurderlig egenskap, for de fleste har en tendens til å kun ha fokus på enkelte metrikken (som de subjektivt vurderer) og gir 100% på disse, uten å tenke på kostnaden dette medfører å helheten. Klart det koster virksomheter og skattebetalerer.
Etter min mening er det ken følgende elementer man skal ha med i en pull-request code review for å sikre at helheten (les alle ledd tas hensyn til):
Resten blir kosmetisk, ergo fører til sløsing av tid å legge seg opp i.
Siden jeg begynte som programvare utvikler i 2009 har ting endret seg mye innen QA, og spesielt som følge av DevOps tankegangen. Den gangen var ikke kodekvalitet og testing blitt prosessmessig definert på samme måte som idag, og gikk stort sett i code review sessions. Forretningsmessige kritikaliteter kom i større grad fremfor disse tingene som ble ansett som mer periferalt. Resultatet var at de prosjektene som varte lenge var vanskelig å forvalte, ergo tidskrevende og dyrt.
Dagens QA prosess
I dagens utviklingsprosess er QA og testing blitt formalisert i større grad. Verktøyene legger opp til at man for hver endring må lage en 'pull request' som må godkjennes av en annen utvikler for at endringen skal tas med. I tillegg har man maskinelle statiske kodeanalyse verktøy.
IT prosjekter
Siden vi lever i en tid med mye endringer, enten det er konkurransesituasjonsendring eller politiske endring er det umulig for en som jobber på leveransenivå å kunne si noe om hvor lenge prosjekter varer. Det betyr at man ikke skal gå forlangt den andre veien heller når det kommer til QA prosessen, dvs, lene seg fullstendig over til sin teknikerrolle (som blir veldig subjektiv i en pull-request setting).
Min erfaring
Til og med 'de lærde strides' som det sies, og dette fenomenet ser man også høyt i akademiske miljø. Når en konsulent vier hele sitt fokus på den tekniske delen og ransaker denne opp-og-ned-i-mente helt etter egen subjektiv mening, og glemmer andre faktorer som effektivitet ja da blir det dyrt. Jeg vil si edruelig vurdering er en uvurderlig egenskap, for de fleste har en tendens til å kun ha fokus på enkelte metrikken (som de subjektivt vurderer) og gir 100% på disse, uten å tenke på kostnaden dette medfører å helheten. Klart det koster virksomheter og skattebetalerer.
Etter min mening er det ken følgende elementer man skal ha med i en pull-request code review for å sikre at helheten (les alle ledd tas hensyn til):
- er testdekning tilstrekkelig mtp. forretningscases? (er alle relevante happycase og exceptioncases tatt med)
- er variabler og metodenavnene presise mtp. innhold og hva metodene gjør?
- er normaliseringen av ansvar noenlunde edruelig? (ala. Single Responsibility Principle)
Resten blir kosmetisk, ergo fører til sløsing av tid å legge seg opp i.
Kommentarer
Legg inn en kommentar