Manuell och utforskande testning
Skriptad täckning av de flöden som spelar roll, plus oskriptat petande på de ställen som ser sköra ut. De flesta intressanta buggar dyker upp i den andra sorten.
Jag har haft ansvaret för testningen på en start-up, och testning är det jag är bäst på. Jag berättar vad som är trasigt, hur det återskapas och om det bör stoppa din release.
Utvecklare testar det de byggt på det sätt de menade att det skulle användas. Det är ingen kritik, det är bara så det blir när man känner ett system. Jag närmar mig det utifrån.
Skriptad täckning av de flöden som spelar roll, plus oskriptat petande på de ställen som ser sköra ut. De flesta intressanta buggar dyker upp i den andra sorten.
Att testa om det som redan fungerade, efter varje ändring. Tråkigt att göra ordentligt och det enskilt vanligaste som små team hoppar över.
En skriftlig plan som täcker omfattning, miljöer, testfall och vilka risker som prioriteras. Den gör att nästa testomgång upprepar den här i stället för att börja om.
Steg för att återskapa, miljö, allvarlighetsgrad och belägg. Jag har själv suttit som utvecklare och tagit emot dem, så mina är skrivna för att kunna agera på direkt, inte bara arkiveras.
Kontroll av att sajten fungerar i de webbläsare och på de skärmstorlekar dina kunder faktiskt använder, inte bara den den byggdes på.
Anrop, svar, felfall och edge cases. Användbart när gränssnittet ser bra ut men något under ytan tyst är fel.
Automatiserade sviter som täcker dina kritiska flöden, i det ramverk som passar er stack, så att de kontrolleras vid varje release i stället för när någon kommer ihåg det.
Ingen svart låda. Du får planen innan jag börjar och fynden allt eftersom de kommer, inte en rapport i slutet när det inte finns tid kvar att agera på den.
Jag lär mig produkten, vem som använder den och hur ofta ni släpper. Sedan bestämmer vi vad som är värt att testa och vad som inte är det.
Omfattning, miljöer, testfall och prioriteringar, nedskrivet. Du godkänner den innan någon testning börjar.
Jag går igenom planen över webbläsare, enheter och API:er, och lägger extra tid där risken ser störst ut.
Reproducerbara rapporter med allvarlighetsgrad och belägg, levererade allt eftersom jag hittar saker i stället för att sparas till slutet.
När rättningarna är inne verifierar jag dem, kör regressionen igen och ger dig ett rakt svar på om det är redo att släppas.
Timpris passar löpande arbete och för att fylla luckor. Fast pris passar en release med ett tydligt slutdatum. Jag säger vilket som passar efter att vi har pratat om projektet.
En fokuserad genomgång av en funktion, en release eller en sprints arbete.
Full täckning inför en lansering eller en release du inte har råd att få fel.
Testning som ingår i er releasecykel, för team som släpper regelbundet.
Att anställa en heltidsanställd QA-ingenjör är ett stort åtagande, och de flesta små team kan inte motivera det. Det här är versionen som går.
Era utvecklare testar sitt eget arbete mellan andra uppgifter. Saker missas, och ingen har tid att skriva ner vad som täckts.
En release med riktiga pengar eller ett rykte i potten, och en molande känsla av att klicka igenom den en gång på en fredag inte räcker.
Berätta vad du släpper och när. Jag återkommer med en testplan och ett pris, oftast inom en dag.
Begär en offert