Jacob Hassing

Hård kritik af ny digitaliseringsstrategi: Urealistiske tidsplaner og underfinansierede projekter

...... lave det sammen ..... Måske HELT uhørt, men hvis det offentlige (stat, regioner og kommuner) betragtede sig som et firma og fandt sammen i beslægtede emner kunne vi rykke så meget. Jeg møder rigtig meget viden og dedikerethed. Så "samle og sejre" i stedet for "del og hersk"

16. maj kl. 07:46
Forældre fandt banale sikkerhedshuller i udbredt it-system til børnehaver

I den "rigtige" verden belønner politiet for at gribe ind, for at undgå skadelig adfærd. Sidst her http://www.dr.dk/Nyheder/Indland/2015/06/10/190940.htmIkke at beskytte personfølsomme oplysninger har retsvæsnet hjemmel for reagere kraftigt over for - også selvom det er i et miljø retsvæsnet ikke er vant til (kan) navigere i. Hvor anklager politiet firmaet ??

11. juni 2015 kl. 11:12
Vi er alle testere

Enig! Som ved alle andre håndværk, så er passion og kompetencer ret afgørende for resultatet.

Men i det daglige "glemmes" ret tit forudsætninger for god test.

  • Metode. Der giver en vis forudsigelighed for aftager og PL'er. Herunder forretningsmæssig prioritering af test cases, test af krav, spec, osv.
  • Tilstrækkelig test basis (grundlag), så vi undgår: "jeg tror ..", "jeg synes ....", ".. det er nok ..." under kodning og test cases
  • Er løsningen testbar. Delafleveringer sker (også) sådan at test kan påbegyndes tidligt. Testdata og miljøer er en del af leveringen.
  • Virksomhedens egne krav til afleveringen er naturligvis også en del af testen
21. april 2015 kl. 13:13
Fagbøger er vist et overset gode

Det er jo ikke sikkert at det er test processen der skal optimeres. Der er mange snuble stene i processen hen til test (uanset hvordan man så udvikler/tester)

  1. Krav/designdokumentation ikke tilstede/dårlig kvalitet/forkert/ikke testbar. Det bevirker at der udvikles andet end kunden ønsker og facitlisten hos testerne bliver lige så mangelfuld

  2. Testmiljøet indeholder forkerte versioner af programmer/konfigurationsdata/testdata/forretningsdata

  3. Programmer er ikke testbare (arkitektur, implementering, rækkefølgen af hvornår programmer bliver leveret til test, .....)

Da du ikke skriver om det er administrative- eller tekniskesystemer, om der er lange test forløb (test kan strække sig over måneder), om der er tænkt over hvordan testdata produceres, hvor moden virksomheden er mht. rettigheder, dokumentation, disciplin i projektet, brug af (projekt) styrings værktøjer om der er lavet en prioritering af forretningsmæssige krav, ......

Så er det rimeligt svært at rådgive mere konkret end brugen af f.eks. TMap Next (eller andre generelle bøger). Grunden til min anbefaling af TMap Next er at jeg har brugt den som test manager i en række år, men jeg er overbevist om at der findes andre bøger der er lige så gode.

23. september 2013 kl. 15:46
Har din testafdeling overhovedet en berettigelse?

Jeg kan ikke læse mig til at en testrapport er et 4 binds værk. Testrapporten kan sagtens dannes ad-hoc og være ret smal. Hovedsagen er at kunne danne et faktuelt, sobert og uafhængigt overblik der blandt andet kan bruges til styring i projektet (hvis det sker hyppigt nok). Automatiserede test KAN give dette billede hvis de er gode nok.

19. september 2013 kl. 13:58
Har din testafdeling overhovedet en berettigelse?

Jeg er nørd-tester så det gør noget og jeg elsker det :-)

(se evt. http://ordnet.dk/ddo/ordbog?query=test) for def. af test

Essensen af det foredrag artiklen tager udgangspunkt i, er:

  • Mennesker udnytter sine evner til godt håndværk – alle kan ikke lave alt lige godt. Det gælder også i IT verden.
  • Testere kritiserer, men ikke personligt! Kun ud fra en specifikation.
  • En testers produkt er en uvildig, upersonlig, sober måling af om specifikation lever op til det der bliver leveret
  • Kommunikation er vigtig – desværre også formen

Hvor denne måling foretages, hvornår, på hvad, ...... kan gøre testen mere eller mindre præcis.

Tænk hvis du bestiller et hus (specifikation) og det færdige hus ikke lever op til det du har bestilt.

18. september 2013 kl. 17:02
Store huller i testen - hvad er problemet?

Man kan sige meget om eksempler/analogier, men de er nemmere at huske og kan (!) skærpe pointen, men desværre også det modsatte. Jeg vover her.

Målet for dette indlæg er om I har kender til faglitteratur der i PRAKSIS gør krav testbare. Altså enten at forretningsarkitekter danner testbare krav eller test design teknikker til at teste krav (det kunne være review, men hvad skal der så reviewes efter?)

Min påstand 1 Ifl. http://ordnet.dk er ”test” en ……undersøgelse….. , men hvad betyder det egentligt? Hvad skal undersøges, hvornår, med hvor stor usikkerhed, …. (hvad vil du med denne ”påstand”?)

Min påstand 2 Hvis ikke der er reguleringsmekanismer, arver efterfølgende led direkte. Både det gode og det dårlige, så jo tidligere i fødekæden jo større effekt.

Min påstand 3 Som eksempel; bygnings håndværkere og IT håndværkeres arbejde ligner på en række områder hinanden. • Kontrakter /aftaler er beskrivelse af hvad kunden ønsker og leverandøren agter at levere • Projekter er måden at styre hen mod resultatet. Ændringer/forhindringer i projektet er en naturlig del af et projekt • Ordentlig kommunikation er bare vigtigt • Håndværksmæssige kundskaber er en væsentlig faktor for succes Motivation - jobbeskrivelse I ”ikke-IT verdenen” er der ret mange mennesker ansat til at kontrollere. Det kan være parkeringsvagter, Bilsyn, godkendere af husbyggeri og mange andre. Fælles for disse funktioner er, at menneskers PERSONLIGE skøn vægtes lavt ift. de regler, skøn og standarder der er på området, er opsamlet gennem årene og gjort konkrete i f.eks. love (erfaringsopsamling). Analogien i IT-verdenen er testere – vi er kontrollanter :-)

Motivation – udgangspunktet Starten på mange projekter er kontrakten, der i mange tilfælde (det er en påstand) baseres på hvad kunden ønsker ”dingenoten” skal kunne. F.eks. hvis du vil have lavet et hus, så er det ret smart, hvis leverandøren ved hvad du vil have – men GRUNDLÆGGENDE er krav til IT-systemer og specifikation af et hus det samme.

I byggebranchen er der en mangeårig erfaring i hvad der kan lade sig gøre. Jo mere der afviges fra hvad man plejer at gøre, jo mere risiko. Der er så også ret meget lovgivning om hvad man må. Pointen er, at der er mange flere frihedsgrader i IT end der er i f.eks. byggebranchen. Frihedsgrader ……..frihed  godt ! (??) er i hvert fald den tankerække jeg får, men der er så også en konsekvens af det. I denne sammenhæng betyder det i hvert fald præcisering. Alle de løse ender er frihedsgrader og en eller anden skal jo tage stilling til hvad svaret på disse skal være.

Når du har præcise krav ved alle interessenter hvad meningen er. Men hvordan ved du om dine krav er præcise nok INDEN du begynder på opgaven? (bagefter kan man måle det på skænderierne og det er ikke så relevant)

Motivation – processen Vidensoverdragelse fra den taknemmelige ”Word-verden” til den konkrete ”implementerings-verden” foregår på mange måder, men sker det ikke, laver fingrene noget andet end hovedet gerne vil have. Analogien til at bygge et hus, kunne være at elektrikeren sidder med forældede tegninger og sætter el-kontakterne et andet sted end komfuret skal stå.

Spørgsmål Er kravene mangelfulde i projekter med mange frihedsgrader, hvordan ved vi så om vi har leveret varen? Udvikleren ved ikke hvad der skal udvikles og testeren ved ikke hvad der skal testes, så hvad bliver resultatet? Det kan blive til mange personlige skøn om hvad resultatet skal være – vi mangler en facitliste. Hey – net: Hvem har skrevet noget fornuftigt og KONKRET om det her? Er vi der hvor vi skal have hjælp fra andre grene af videnskaben end vi traditionelt bruger? Anvendt filosofi for at finde ud af hvad vi egentligt mener med vores ord? Eller mangler jeg bare at læse: ______________________________________?

13. juni 2013 kl. 08:42
Fagbøger er vist et overset gode

Ganske enig i emnet (og mediet er skingrende ligegyldigt). I de første par år som tester læste jeg ret mange artikler, der (sikkert) er OK hver for sig, men sjældent gav et overblik. At anbefale en bestemt bog kan være ret svært, men den bedste generelle "håndbog" er TMap Next ( og ja - jeg har været ansat i Sogeti ;-) )

Anden for for professionalisering kan opnås ved at give sig i kast med et emne sammen med andre (i fora, foredrag, kollegaer, ol.), men det kan være svært at afgøre hvor god en løsning der kommer ud af det.

Find den metode der passer til opgaven og hold dig til den

24. april 2013 kl. 13:35
Android-skolen del 3: Snak satellitter og Google-kort med den grønne robot

Hmmm strengt taget mangler det også i eksemplet her på siden. Det burde have været: 14 15 16 17 18 19

og fejlmeddelelsen i loggen var rettelig: java.lang.ClassNotFoundException: net.learn2develop.GoogleMaps.MapsActivity in loader dalvik.system.PathClassLoader

8. februar 2011 kl. 09:12
Android-skolen del 3: Snak satellitter og Google-kort med den grønne robot

jeg fik noget ....."java.lang.RuntimeException: Unable to instantiate activity ComponentInfo"..... fordi jeg ikke havde sat i manifestfilen

8. februar 2011 kl. 08:51