Hva betyr - og hva er forskjellen på TDD, BDD og ADD?
- Detaljer
Disse 3 teknikkene er oftest brukt i forbindelse med smidig baserte metoder (slik som Scrum og Kanban), men kan også brukes i fossefall prosjekter. Alle kan brukes for å utforme krav - som kan igjen brukes til å lage test caser – som deretter kan bli automatisert. De brukes som regel sammen. Jeg skal her forsøke å forklare hvordan de fungerer. Til slutt vil jeg nevne noen tenkte fordeler og ulemper knyttet til teknikkene.
Jeg kommer til å gå mer i detalj i senere innlegg, for jeg merker at her er det nyanser og det er absolutt ingen fasitsvar her.
Funksjonell testing og test av ytelse henger tett sammen...
- Detaljer
Ytelse og funksjonelle egenskaper er ofte veldig viktige for sluttbrukeren.
Har du noen gang fundert på samspillet og timingen mellom funksjonell test og test av ytelse?
Jeg vil påstå at det å se sammenhenger ikke alltid så enkelt. Læring skjer i ulike settinger; gjennom å gjøre feil eller få en "aha-opplevelse". Ved å observere andre eller å tenke selv.Derfor ønsker jeg å forsøke å beskrive hvordan funksjonell test samspiller med ytelsestest.
Vil du forbedre et "system" eller en "prosess" i påsken? - Har du hørt om FMEA?
- Detaljer
FMEA er en teknikk som brukes til å finne egenskaper eller deler av et system som kan forbedres. Mer direkte det som rett og slett ikke fungerer ihht. spesifikasjoner.
FMEA'n ("feil og effekt analysen") har som hensikt å finne
- feiltilstandene: Hva kan gå galt med prosess trinnet, funksjonen eller aktiviteten?
- konsekvensen feilen medfører: Hva er konsekvensene?
- årsaken til feilen: Hva er grunnen til at prosesstrinnet, funksjonen eller aktiviteten feiler - Hva er kilden til feilen?
Som en del av analysen så skal man kartlegge om det er kontrollpunkter som svikter, eller om det mangler kontrollpunkter:
Hva er gjeldende kontrollpunkter og prosedyrer, som enten forebygger eller kan detektere årsaken til feilsituasjonen?
Total alvorlighet regnes ut ved å mulitplisere: Alvorlighet x Sannsynlighet x Deteksjonmulighet.
Kanban og smidighet er da ikke så vanskelig...
- Detaljer
Kanban er blitt populær og er ofte adoptert av Devops team, som erstatning for Scrum.
Mens Scrum har feks. har hele 12 regler, så er det kun 3 hovedregler som gjelder ved Kanban:
1) Visualisere arbeidsoppgavene.
2) Hindre flaskehalser i verdikjeden ved å begrense pågående arbeid.(flyt)
3) Optimalisere ledetiden ved å lære gjennom erfaring og målinger.(kontinuerliug forbedring)
Kanban er kanskje ikke så vanskelig siden det bare er 3 regler?
Forventninger til høy leveringstakt med høy kvalitet
- Detaljer
Hvorfor er det viktig for tiden å kunne levere programvare hyppigere og med forventet høy kvalitet?
Spesielt 3 årsaker vil jeg si, etter mine meninger:
- Bedriftene opplever stor konkurranse om kundene. (kundene er ikke så lojale lenger)
- Vi er blitt helt avhengig av fungerende IT-systemer. (kjernevirksomhet)
- Forventninger til høyere leveringstakt, det å raskt kunne levere nye/endrede tjenester. (endringer)'
Hva kan være viktig å fokusere på?
- Å få gjennomført ett større antall endringer ut i produksjon med kortere gjennomløsptid. (god prosess)
- Utføre flere suksessfulle endringer i software og dermed mindre nedetid. (riktig første gang)
- Bli mer konkurransedyktig gjennom at man raskere klarere å levere de "riktige" tjenestene til kundene. (samarbeid med forretningen og i alle andre ledd)
Hva blir mer viktig fremover som «kvalitetssikrere» å kunne beherske?
