Så har der igen været en uge i testdesignteknikkernes tegn. Har været oplægsholder på 2 seminarer om testdesignteknikker - jeg talte om testdesignteknikker generelt, præsenterede tilstandsovergangstest og datacyklustest. Jeg benyttede lejligheden til at causere lidt over det jeg tidligere har kaldt testerens værktøjskasse (herunder testdesignteknikkerne) - en værktøjskasse er ofte gemt lidt væk og er ikke lige til ved hånden altid - hvilket betyder at vi ikke altid får brugt dem. Jeg anvendte derfor begrebet testerens værktøjsbælte - så er testdesignteknikkerne altid lige ved hånden - klar til brug - klar til test.
I forbindelse med et tidligere seminar lavede vi en undersøgelse blandt deltagerne og præsentere nogle af resultaterne i denne uge - 29% kendte flere end 5 testdesignteknikkker - 8% brugte mere end 5 testdesignteknikker i deres daglige arbejde, MEN 100% vil gerne vide mere om testdesignteknikkerne. På den ene side er det lidt bekymrende, at vi testere kender og bruger så få af testdesignteknikkerne, men det er rigtig glædeligt, at vi gerne vil lære mere om dem.
lørdag den 19. november 2011
onsdag den 15. juni 2011
World Quality Report - Sogeti - Del 2
Nedenstående er konklusionen for det nordiske område i Sogeti's World Quality Report.
The Nordic Region (Sweden, Finland, Norway and Denmark)
· High QA maturity mainly within larger companies
QA is well established in many major organizations today in the Nordic Region, with formalized test organizations, supporting budgets and is a recognized profession with dedicated resources. In smaller companies, however, the testing focus is much more erratic.
QA is well established in many major organizations today in the Nordic Region, with formalized test organizations, supporting budgets and is a recognized profession with dedicated resources. In smaller companies, however, the testing focus is much more erratic.
· Mixed maturity in applying automation
With regard to manual test execution, 22% of respondents from the Nordics suggest that their companies run between 81-100% of their tests manually. A good indication of the mixed maturity level in this region is the fact that in contrast 19% of respondents appear to have embraced automation with only a small portion of their tests (0-10%) conducted manually.
Limited adoption of Cloud and SaaS
Over half (52%) of Nordics respondents say that none of their software licenses are used through a SaaS model – compared to 27% across the rest of Europe and North America, suggesting that the Nordic companies prefer to purchase licenses for unlimited use.
Looking to the cloud, 20% of Nordic respondents indicate plans for hosting between 11% and 25% of their applications in the cloud over the next year, less than the European average of 36%. Moreover, a quarter of European respondents indicate they will host between 26-50% of their applications on the cloud, compared to 13% in the Nordics.
Over a third (35%) of Nordic organizations declare that they would not use the cloud, compared to 13% across Europe, yet we believe that leveraging SaaS-model and cloud-based hosting would help Nordic countries to cut QA costs at the bottom line.
With regard to manual test execution, 22% of respondents from the Nordics suggest that their companies run between 81-100% of their tests manually. A good indication of the mixed maturity level in this region is the fact that in contrast 19% of respondents appear to have embraced automation with only a small portion of their tests (0-10%) conducted manually.
Limited adoption of Cloud and SaaS
Over half (52%) of Nordics respondents say that none of their software licenses are used through a SaaS model – compared to 27% across the rest of Europe and North America, suggesting that the Nordic companies prefer to purchase licenses for unlimited use.
Looking to the cloud, 20% of Nordic respondents indicate plans for hosting between 11% and 25% of their applications in the cloud over the next year, less than the European average of 36%. Moreover, a quarter of European respondents indicate they will host between 26-50% of their applications on the cloud, compared to 13% in the Nordics.
Over a third (35%) of Nordic organizations declare that they would not use the cloud, compared to 13% across Europe, yet we believe that leveraging SaaS-model and cloud-based hosting would help Nordic countries to cut QA costs at the bottom line.
World Quality Report - Sogeti - Del 1
Sogeti har netop lanceret den seneste version af World Quality Report, og der peges på følgende top 10 tips til at forbedre virksomhedernes kvalitetssikring og test:
1. QA Professionals: Make sure you use well rounded Quality Assurance (QA) professionals with deep understanding of testing, development and industry specific domain knowledge
2. Test metrics and ROI: Set up formalized QA measurement programs and metrics using a language that the business can understand. Make sure you align these metrics to business goals to measure clear ROI.
3. Reporting tools and ROI: Use automated reporting tools to collect, analyze and publish your metrics to ensure accuracy and real time usage and make sure you continuously monitor ROI.
4. Test methodology: Use industry standard methodologies that are continuously developed and improved by industry experts to industrialise your approach and minimize the cost of developing one internally. Document and publish your company’s QA methodology and communicate to all stakeholders any changes.
5. Test Data Management: Develop a formalized test data management process and use automated tools to minimize human errors in use and reuse of the data.
6. Cloud: Get your QA organization to be ready for the increased use of cloud computing by investing in the development of performance and security testing skills. Best practice is to develop a specific Cloud Test Strategy. Make sure you leverage Cloud possibilities to facilitate QA
7. Early involvement in Software Delivery Lifecycle: Get involved in application security discussions in the earlier phase of application development such as design or requirements definition (in Capgemini/Sogeti terms – achieving PointZERO®).
8. Work with Development: Align with and gain support from development teams achieve inbuilt QA and ensure the long term success of your team.
9. QA organization: Determine a clear approach to the organization of QA, directly related to business drivers, such as in-house or co-located (combined with external suppliers) Testing Centers of Excellence (TCoEs) and outsourcing. When going for outside sourcing, think about specific KPIs that are related to your business goals.
10. Consider automated testing. There is a lot of room improvement with respect to the use of automation that can considerably improve QA accuracy.
mandag den 23. maj 2011
Testdesignteknikker - en testers værktøjskasse
Igennem de sidste par måneder har jeg adskillige gange undervist i brugen af testdesignteknikker - både blandt nye indenfor testfaget og ikke mindst blandt mere 'garvede' testere. De fleste testere har på et eller andet tidspunkt lært en række af testdesignteknikkerne på kurser, men når man kommer hjem til den travle hverdag er der så ikke lige tid til at få implementeret den nye lærdom - og der vendes så tilbage til 'vi plejer at gøre'.
Det er ganske utroligt, idet netop testdesignteknikkerne er med til at sikre os indsigten i HVAD vi tester og ikke mindst HVORDAN.
En opfordring til alle testere skal derfor lyde: Tag en ny testdesignteknik i brug hvert kvartal - bliv fortrolig med den - få den ind under huden.....og brug den.
Det er ganske utroligt, idet netop testdesignteknikkerne er med til at sikre os indsigten i HVAD vi tester og ikke mindst HVORDAN.
En opfordring til alle testere skal derfor lyde: Tag en ny testdesignteknik i brug hvert kvartal - bliv fortrolig med den - få den ind under huden.....og brug den.
tirsdag den 8. marts 2011
Testmetrikker
Jeg har netop færdiggjort mit oplæg til Sogeti's seminar om testmetrikker, der afholdes i København (10/3) og Århus (11/3). Det har være spændende at arbejde med, og jeg har samlet følgende råd omkring selve praktikken:
• Start med et begrænset antal af testmetrikker
• Udvid antallet af testmetrikker langsomt og ’kontrolleret’
• Fasthold at testmetrikkerne skal være ’simple’ – både i indsamling, analyse, fortolkning
• Dataindsamling skal være så ’automatisk’ som muligt – brug eksisterende værktøjer (teststyringsværktøjer, tidsregistreringssystemer, økonomisystemer m.m.)
•Tidsregistrering – sikre korrekt og dækkende brug
• Undgå komplicerede statistiske teknikker og modeller
• Sørg for hurtig feedback til dit testteam – vis dem hvad du gør med informationerne.
tirsdag den 8. februar 2011
Agil udvikling - en udfordring?
I disse år står specielt agil udvikling meget højt på dagsordenen hos it-organisationerne rundt omkring. Jeg deltog i dag på et seminar hos Mannaz med emnet 'agil projektledelse' med oplæg af professor Jan Pries-Heje (RUC). Det var et fantastisk spændende indlæg, og han præsenterede et lille værktøj til vurdering af om agil udvikling skal overvejes. De 5 vurderingsparametre er:
Omkring 'størrelse' drejer det sig om hvor mange personer der er med i projektet samtidig. Hvis man er 10 personer eller derunder peger det i retning af agil udvikling.
Omkring 'kompleksitet' drejer det sig om bl.a. projektets scope, kommunikation med interessenter, om projektet opleves som svært og om der er tidspres eller ej. Jo flere 'ja'er' der er i denne gruppe desto nærmere er man plandrevet udvikling.
Omkring 'projektteamet' drejer det sig bl.a. om hvor mange nyuddannede teammedlemmer der er, viden og erfaring i hvordan der udvikles, antal lokationer teamet er spredt på og om hvorvidt hele teamet er motiveret. Jo flere 'ja'er' der er i denne gruppe desto nærmere er man plandrevet udvikling.
Omkring 'kritikalitet' drejer det sig om hvad en fejl kan medføre - desto højere en konsekvens af en fejl er desto mere peger det i retning af plandrevet udvikling.
Der var på seminaret en spændende diskussion af disse parametre med udgangspunkt i deltagernes forskellige erfaringer med projekter m.m.
- Dynamik / kravændringer
- Størrelse
- Kompleksitet
- Projektteamet
- Kritikalitet
Omkring 'størrelse' drejer det sig om hvor mange personer der er med i projektet samtidig. Hvis man er 10 personer eller derunder peger det i retning af agil udvikling.
Omkring 'kompleksitet' drejer det sig om bl.a. projektets scope, kommunikation med interessenter, om projektet opleves som svært og om der er tidspres eller ej. Jo flere 'ja'er' der er i denne gruppe desto nærmere er man plandrevet udvikling.
Omkring 'projektteamet' drejer det sig bl.a. om hvor mange nyuddannede teammedlemmer der er, viden og erfaring i hvordan der udvikles, antal lokationer teamet er spredt på og om hvorvidt hele teamet er motiveret. Jo flere 'ja'er' der er i denne gruppe desto nærmere er man plandrevet udvikling.
Omkring 'kritikalitet' drejer det sig om hvad en fejl kan medføre - desto højere en konsekvens af en fejl er desto mere peger det i retning af plandrevet udvikling.
Der var på seminaret en spændende diskussion af disse parametre med udgangspunkt i deltagernes forskellige erfaringer med projekter m.m.
mandag den 31. januar 2011
Testmetrikker
En af de mere spændende - men også ofte svære ting - er målinger af test - inden for testprocesforbedring, rapportering af teststatus og -fremdrift og ikke mindst til brug for estimering af fremtidige testopgaver.
Jeg er ved at gennemgå og studere en masse forhold omkring testmetrikker og skal den 10/3 (København) og 11/3 (Århus) sammen med ATP's testchef Thomas Axen holde foredrag om emnet.
Følg med på denne blog for løbende opdatering af emnet.
Jeg er ved at gennemgå og studere en masse forhold omkring testmetrikker og skal den 10/3 (København) og 11/3 (Århus) sammen med ATP's testchef Thomas Axen holde foredrag om emnet.
Følg med på denne blog for løbende opdatering af emnet.
onsdag den 19. januar 2011
5 dage med nye spændende bøger om test
Så har jeg taget mig den frihed at bruge de næste 5 dage på at studere og læse en række nye bøger om test af software, som jeg har anskaffet mig. Det drejer sig i denne omgang om følgende:
- Testing Software and Systems (Proceedings fra ICTSS 2010 konferencen - ICTSS står for International Conference on Testing Software and Systems - og konferencen foregik i Natal i Brasilien i november 2010) og udgivet på Springer.
- Property Testing - Current Research and Surveys, Oded Goldreich (Ed.) og udgivet på Springer.
- The Testing Network - An Integral Approach to Test Activities in Large Software Projects, Pierre Henry. Udgivet på Springer.
- Testen in der Finanzwelt, Norbert Bochynek og Jose Diaz. Udgivet af Diaz Hilterscheid - bemærk venligst at bogen er på tysk inden I eventuelt får den bestilt.
- Becoming Agile in an imperfect world, Greg Smith og Ahmed Sidky. Udgivet af Manning.
- The Tester's Pocketbook. Udgivet af Paul Gerrard og The Tester's Press. Jeg fik den af Paul selv på EuroSTAR 2010 i København (Bella Center).
tirsdag den 18. januar 2011
7 Gode Vaner for Testere
Vane nr. 1 - Vær Proaktiv
En testers mål i et softwareprojekt er at sikre, at softwaren har en så høj kvalitet som muligt. Når projekter kører af sporet på grund af dårlig kvalitet kan man enten være proaktiv eller reaktiv, når årsagen skal findes. Den reaktive tester vil straks give andre personer eller omstændigheder skylden for problemerne. Den proaktive tester vil tage medansvar og forsøge at finde ud af, hvordan samme problemer ikke opstår i fremtiden.
Ved slutningen af et projekt bør testholdet lave en evaluering af projektforløbet. Her bør man både diskutere de ting, der gik godt, men også de ting, der gik mindre godt. Her er en række ideer til, hvordan man som tester kan være proaktiv.
A: Tag ansvar for en god kravspecifikation
Det kan ikke nytte noget at lænse sig tilbage og brokke sig over, at kravspecifikiationerne er for dårligt beskrevet. Tag i stedet og samarbejd med kravspecifikatørerne om at få kravene mere præcise, mere udførligt beskrevet og testbare.
B: Analyser sporbarheden
Lav en matrix for at øge sporbarheden i sammenhængen mellem testcases og krav. Det giver bedre mulighed for at analysere, hvor meget dine testcases dækker, hvor langt du er nået og hvor nem softwaren er at teste. Hold møder med dit team, hvor I gennemgår dine testcases for at sikre at kravene er forstået rigtigt og at testen har den rigtige dækningsgrad. Lad udviklerne læse og give review på dine testcases, før de går i gang med at udvikle. Det giver færre rettelser og der bliver brugt mindre tid på QA i sidste ende.
C: Kommuniker effektivt.
Under testen er det vigtigt, at alle kender status på testarbejdet. Kommuniker dagligt via mail eller online diskussionsfora. Her er det vigtigt at give information i målbare størrelser som eksempelvis antallet af defects, hvor stor dækningsgraden er i forhold til kravspecifikationerne eller hvor mange testcases, der er blevet afviklet.
D: Beskriv fejl udførligt.
Når du har fundet en fejl og skal beskrive den, så gør det grundigt og udførligt. Brug tid på at lave en god beskrivelse- Beskrivelsen skal indeholde de skridt man skal udføre for at reproducere fejlen og screen shots bør også vedlægges som dokumentation.
Vane nr. 2 - Fokuser på slutresultatet
Dit mål i et softwareprojekt bør være at levere software af en høj kvalitet, som samtidig opfylder kundens behov. Før den første kodelinje bliver skrevet, bør projektets succeskriterier være nedfædet. Det kan eksempelvis være at softwaren fungerer efter specifikationerne, eller at der ikke må afleveres et produkt med kente fejl. Det gør det nemmere senere hen at vurdere om projektet har været en succes.
Vane nr. 3 - Start med det vigtigste
Det er vigtigt at prioritere arbejdet efter hvor vigtigt det er. Eksempelvis kan vi sikkert alle blive enige om, at negative tests er vigtige for at sikre, at softwaren kan håndtere utænkte situationer på uden at gå helt i brædderne. Men det er ikke vigtigere end at teste om softwaren er i stand til at udføre den opgave den bliver bygget til. Derfor bør man begynde at teste om softwaren kan det den skal.
Eftefølgende kan man lave de negative test og se om man kan få systemet til at brase sammen. Det kan eksempelvis være test med invalide data eller grænseværdi-tests.
Vane nr. 4 - Se det som et vinderspil
I mange organisationer forsøger testere og udviklere at skubbe aben over til hinanden, når der opstår problemer. Det kan være meget ødelæggende for udviklingsprocessen.
Udviklere og testere bør have samme mål - at sikre at softwaren får en høj kvalitet. Når man har det som fælles mål giver det langt mere mening for alle deltagere at hjælpe hinanden.
Vane nr. 5 - Forstå først og bliv forstået bagefter
Mange har den dårlige vane, at de ikke lytter ordentlig med på diskussionerne, fordi de er så opsatte på selv at få fortalt deres eget syn på sagen. Alle i et projekt deltager med forskellig erfaringsbaggrund og har forskellige perspekiver på processerne.
Før man kan løse et problem er det vigtigt at lytte grundigt til, hvad projektdeltagerene har at sige for at kunne forstå problematikken til bunds. Efter alle har sagt det, de ville er det tid til at opstille flere mulige løsninger på problemet. Flere løsningsmodeller giver mulighed for at diskutere problematikken bedre igennem, og det giver projektdeltagerne mulighed for at komme frem til bedre løsninger, der rækker længere end den første indskydelse.
Hvis man er uenig om løsningen er det vigtigt ikke at virke aggressiv overfor den person, der har stillet løsningsforslaget. Forklar i stedet for, hvorfor du synes løsningen er knap så god.
Vane nr. 6 - Skab synergi
Hold-arbjede er nøglen til at skabe synergi. Et team med synergipotentiale består af forskellige typer, der har forskellige styrker, baggrunde og perspektiver. Sørg for at forskellighederne kommer i spil på bedst mulige måde.
Man er mere effektiv, når man ved, hvad ens teammedlemmer er ved at lave. Derfor er teams mere effektive, når de kommunikerer med hinanden. Det kan eksempelvis være at man deler et fælles dokumentbibliotek, der beskriver best practice indenfor det pågældende arbejdsområde.
Vane nr. 7 - Skærp kniven
Den vane kan beskrives ganske kort. De testere, der vedligeholder og uddyber deres evner er også bedst til at levere det bedste stykke arbejde.
De fokuserer på at gøre deres arbejde bedre og nemmere ved eksempelvis at automatisere testcases og gennemføre best practices.
Det er ikke mig, der har fundet på de syv gode vaner for testere. Det er amerikaneren Steve Miller fra Pragmatic Software. Han er til gengæld blevet inspireret af Stephen R. Covey der i 1989 udgav bogen The Seven Habits of Highly Effective People.
En testers mål i et softwareprojekt er at sikre, at softwaren har en så høj kvalitet som muligt. Når projekter kører af sporet på grund af dårlig kvalitet kan man enten være proaktiv eller reaktiv, når årsagen skal findes. Den reaktive tester vil straks give andre personer eller omstændigheder skylden for problemerne. Den proaktive tester vil tage medansvar og forsøge at finde ud af, hvordan samme problemer ikke opstår i fremtiden.
Ved slutningen af et projekt bør testholdet lave en evaluering af projektforløbet. Her bør man både diskutere de ting, der gik godt, men også de ting, der gik mindre godt. Her er en række ideer til, hvordan man som tester kan være proaktiv.
A: Tag ansvar for en god kravspecifikation
Det kan ikke nytte noget at lænse sig tilbage og brokke sig over, at kravspecifikiationerne er for dårligt beskrevet. Tag i stedet og samarbejd med kravspecifikatørerne om at få kravene mere præcise, mere udførligt beskrevet og testbare.
B: Analyser sporbarheden
Lav en matrix for at øge sporbarheden i sammenhængen mellem testcases og krav. Det giver bedre mulighed for at analysere, hvor meget dine testcases dækker, hvor langt du er nået og hvor nem softwaren er at teste. Hold møder med dit team, hvor I gennemgår dine testcases for at sikre at kravene er forstået rigtigt og at testen har den rigtige dækningsgrad. Lad udviklerne læse og give review på dine testcases, før de går i gang med at udvikle. Det giver færre rettelser og der bliver brugt mindre tid på QA i sidste ende.
C: Kommuniker effektivt.
Under testen er det vigtigt, at alle kender status på testarbejdet. Kommuniker dagligt via mail eller online diskussionsfora. Her er det vigtigt at give information i målbare størrelser som eksempelvis antallet af defects, hvor stor dækningsgraden er i forhold til kravspecifikationerne eller hvor mange testcases, der er blevet afviklet.
D: Beskriv fejl udførligt.
Når du har fundet en fejl og skal beskrive den, så gør det grundigt og udførligt. Brug tid på at lave en god beskrivelse- Beskrivelsen skal indeholde de skridt man skal udføre for at reproducere fejlen og screen shots bør også vedlægges som dokumentation.
Vane nr. 2 - Fokuser på slutresultatet
Dit mål i et softwareprojekt bør være at levere software af en høj kvalitet, som samtidig opfylder kundens behov. Før den første kodelinje bliver skrevet, bør projektets succeskriterier være nedfædet. Det kan eksempelvis være at softwaren fungerer efter specifikationerne, eller at der ikke må afleveres et produkt med kente fejl. Det gør det nemmere senere hen at vurdere om projektet har været en succes.
Vane nr. 3 - Start med det vigtigste
Det er vigtigt at prioritere arbejdet efter hvor vigtigt det er. Eksempelvis kan vi sikkert alle blive enige om, at negative tests er vigtige for at sikre, at softwaren kan håndtere utænkte situationer på uden at gå helt i brædderne. Men det er ikke vigtigere end at teste om softwaren er i stand til at udføre den opgave den bliver bygget til. Derfor bør man begynde at teste om softwaren kan det den skal.
Eftefølgende kan man lave de negative test og se om man kan få systemet til at brase sammen. Det kan eksempelvis være test med invalide data eller grænseværdi-tests.
Vane nr. 4 - Se det som et vinderspil
I mange organisationer forsøger testere og udviklere at skubbe aben over til hinanden, når der opstår problemer. Det kan være meget ødelæggende for udviklingsprocessen.
Udviklere og testere bør have samme mål - at sikre at softwaren får en høj kvalitet. Når man har det som fælles mål giver det langt mere mening for alle deltagere at hjælpe hinanden.
Vane nr. 5 - Forstå først og bliv forstået bagefter
Mange har den dårlige vane, at de ikke lytter ordentlig med på diskussionerne, fordi de er så opsatte på selv at få fortalt deres eget syn på sagen. Alle i et projekt deltager med forskellig erfaringsbaggrund og har forskellige perspekiver på processerne.
Før man kan løse et problem er det vigtigt at lytte grundigt til, hvad projektdeltagerene har at sige for at kunne forstå problematikken til bunds. Efter alle har sagt det, de ville er det tid til at opstille flere mulige løsninger på problemet. Flere løsningsmodeller giver mulighed for at diskutere problematikken bedre igennem, og det giver projektdeltagerne mulighed for at komme frem til bedre løsninger, der rækker længere end den første indskydelse.
Hvis man er uenig om løsningen er det vigtigt ikke at virke aggressiv overfor den person, der har stillet løsningsforslaget. Forklar i stedet for, hvorfor du synes løsningen er knap så god.
Vane nr. 6 - Skab synergi
Hold-arbjede er nøglen til at skabe synergi. Et team med synergipotentiale består af forskellige typer, der har forskellige styrker, baggrunde og perspektiver. Sørg for at forskellighederne kommer i spil på bedst mulige måde.
Man er mere effektiv, når man ved, hvad ens teammedlemmer er ved at lave. Derfor er teams mere effektive, når de kommunikerer med hinanden. Det kan eksempelvis være at man deler et fælles dokumentbibliotek, der beskriver best practice indenfor det pågældende arbejdsområde.
Vane nr. 7 - Skærp kniven
Den vane kan beskrives ganske kort. De testere, der vedligeholder og uddyber deres evner er også bedst til at levere det bedste stykke arbejde.
De fokuserer på at gøre deres arbejde bedre og nemmere ved eksempelvis at automatisere testcases og gennemføre best practices.
Det er ikke mig, der har fundet på de syv gode vaner for testere. Det er amerikaneren Steve Miller fra Pragmatic Software. Han er til gengæld blevet inspireret af Stephen R. Covey der i 1989 udgav bogen The Seven Habits of Highly Effective People.
World Quality Report - Sogeti
Før i tiden var en tester typisk en tidligere udvikler, som havde skiftet en karriere med mere fokus på test og kvalitetssikring. I dag efterspørges testere, der kan mere end bare have erfaring med udvikling af software.
Det skyldes ikke mindst den stigende integration mellem IT og virksomhedens forretningsmæssige mål. Derfor efterspørger virksomheder i dag testere, der både har stærke tekniske færdigheder samtidig med at de besidder relevant forretnings og domæneviden.
Det kan man læse i 2010 World Quality Report, der er udarbejdet af Sogeti og HP i fællesskab.
Rapporten tager udgangspunkt i et spørgeskema, der er sendt til over 30.000 direktører, IT direktører, QA managers og ingeniører i forskellige virksomheder verden over.
Her er ønskelisten
Af svarene i rapporten fremgår følgende:
31 procent af virksomhederne ønsker deres testressourcer besidder evner inden for QA.
22 procent ønsker at deres testere har domæneviden.
14 procent ser gerne, at testerne har databasefærdigheder.
10 procent vil gerne have testere, der kan et eller flere script-sprog som Perl, Python m.fl.
9 procent efterspørger testere der mestrer et programmeringssprog som eksempelvis Java og C++
Længere nede på listen kommer evner inden for it-sikkerhed, mainframe og netværk.
Et våben i kampen mod stigende kompleksitet
Ifølge rapporten skal fremtidens tester favne både forretningsviden og have tekniske evner. QA er på vej til at blive en mere professionel karrierevej, hvor virksomheder forventer at have en mindre men mere kvalificeret og højt udviklet gruppe af medarbejdere der har en tilbundsgående forretningsviden.
I takt med at kompleksiteten i software øges, vil time-to-market udfordringerne kræve, at testere har domæneviden, viden om softwaren og den anvendte teknologi for hurtigt at kunne dissekere fundne fejl og hurtigt give viden videre til virksomhedens udviklere.
Hele rapporten kan hentes her
Det skyldes ikke mindst den stigende integration mellem IT og virksomhedens forretningsmæssige mål. Derfor efterspørger virksomheder i dag testere, der både har stærke tekniske færdigheder samtidig med at de besidder relevant forretnings og domæneviden.
Det kan man læse i 2010 World Quality Report, der er udarbejdet af Sogeti og HP i fællesskab.
Rapporten tager udgangspunkt i et spørgeskema, der er sendt til over 30.000 direktører, IT direktører, QA managers og ingeniører i forskellige virksomheder verden over.
Her er ønskelisten
Af svarene i rapporten fremgår følgende:
31 procent af virksomhederne ønsker deres testressourcer besidder evner inden for QA.
22 procent ønsker at deres testere har domæneviden.
14 procent ser gerne, at testerne har databasefærdigheder.
10 procent vil gerne have testere, der kan et eller flere script-sprog som Perl, Python m.fl.
9 procent efterspørger testere der mestrer et programmeringssprog som eksempelvis Java og C++
Længere nede på listen kommer evner inden for it-sikkerhed, mainframe og netværk.
Et våben i kampen mod stigende kompleksitet
Ifølge rapporten skal fremtidens tester favne både forretningsviden og have tekniske evner. QA er på vej til at blive en mere professionel karrierevej, hvor virksomheder forventer at have en mindre men mere kvalificeret og højt udviklet gruppe af medarbejdere der har en tilbundsgående forretningsviden.
I takt med at kompleksiteten i software øges, vil time-to-market udfordringerne kræve, at testere har domæneviden, viden om softwaren og den anvendte teknologi for hurtigt at kunne dissekere fundne fejl og hurtigt give viden videre til virksomhedens udviklere.
Hele rapporten kan hentes her
ISTQB Certified Tester
Gennem de sidste mange år er softwaretest skiftet fra at være en disciplin som 'alle kan' til en disciplin som er 'anerkendt og accepteret'. En vigtig del af vejen er uddannelse af de udførende testere - herunder certificering. I dag er det mest anvendte rammeværk til certificering ISTQB (International Software Testing Qualifications Board), som har forskellige niveauer - Foundation, Advanced og Expert.
Foundation henviser jeg til:
http://www.mannaz.com/da/kursusbeskrivelser/15852.htm
Advanced henviser jeg til:
http://www.mannaz.com/da/kursusbeskrivelser/21083.htm
Foundation henviser jeg til:
http://www.mannaz.com/da/kursusbeskrivelser/15852.htm
Advanced henviser jeg til:
http://www.mannaz.com/da/kursusbeskrivelser/21083.htm
Test Process Improvement - Improved
De sidste mange år har jeg arbejdet meget med procesforbedring - jeg kan stærkt anbefale at kigge på www.tpinext.com som en model til dette arbejde.
Eksempel i DK........problemer i offentllig IT
IT-fejl giver for stor børnecheck
18. jan. 2011 14.00 Penge Omkring 50.000 af landets børnefamilier vil inden længe få udbetalt et for højt beløb i børne- og ungeydelse.De kan samtidig se frem til et brev fra Skat, der opfordrer til at lægge penge til side.
For det overskydende beløb vil blive modregnet med lavere satser de kommende tre kvartaler.
Smutter hos IT-leverandør
Problemet skyldes ifølge Skat en it-brist, idet selskabet KMD ikke har kunnet nå at lave de nødvendige ændringer i it-systemerne. Derfor kan systemerne ikke tage højde for nye regler, der sætter et loft over, hvor meget man kan få på denne ydelse.
Alle familier, som i januar får udbetalt mere end 8750 kroner, har fået mere udbetalt, end de er berettiget til. De penge vil Skat hente ind i årets sidste tre kvartaler.
En familie kan i værste fald skulle lægge 3000 kroner til side til senere.
Skat beklager
- Set hen over hele året får det her ingen økonomiske konsekvenser for familierne, men ikke desto mindre er vi rigtig kede af it-fejlen, siger koncerndirektør i Skatteministeriet Jesper Skovhus Poulsen til Ritzau.
Kun modtagere med mindst tre børn vil blive omfattet af loftet over ydelsen.
- Det er utrolig uheldigt og alt andet end tilfredsstillende. Ny lovgivning kan i forvejen skabe uklarhed, og når der så er fejl i udbetalingerne, er vi med til at mudre billedet for borgerne. Det er ganske enkelt ikke godt nok, og det taler vi med KMD om, siger Jesper Skovhus Poulsen.
søndag den 16. januar 2011
Ny spændende bog - til ISTQB Advanced Test Management
Jeg kan specielt godt lide bogens struktur, dets fokus og ikke mindst anvendeligheden som opslagsværk.
Abonner på:
Opslag (Atom)