Contents






Andre sites






Language


 
test
 
 
 
case.dk



eller... "Hvorfor en teknisk tester kan være en fordel"


Freelance konsulent Business card - "helping is my business"





"On target - 80% done!"


in the past OK, så er tilbage 20%... tid? ...arbejde? uklare eksterne integrationer? Testet udenfor snævre success scenarier? Virkelighednære test data? Hvor mange % dækkede testen? Kode inspektion ved at 'køre i hovedet' og se fejlene ligesom svagheder i et matematisk bevis? Omdøbes 'udvikling' til 'fejlretning' for at skippe test og møde ufleksibel planlægning? Regnes fundamentalt med at kunderne selv skal finde en del af fejlene ved idriftsættelse?

Er der effektiv code branching strategi? Hvad er det agile niveau? Kan testen let gentages ved ændring i kodebasen og tillade continous delivery? Er test tilrettelagt til at blokere for eller minimere... time-to-market?

Mangelfuld test betyder at lukkede opgaver kan ende med at skulle genåbnes - og at man reelt arbejder på at skabe en voksende arbejdsbyrde foran sig. Man arbejder på at skabe mere arbejde.

Test bør være der for at hjælpe - ikke besværliggøre processen.

Test giver faktuel viden om, hvor man er.



Hvorfor test er vigtig


in the past Som udgangspunkt findes ingen dårlige IT-løsninger - der findes kun dårlig eller manglende test!

Test er en del af en større, nødvendig proces.

Test bekræftiger forretningsmæssige forståelse og tekniske løsning.

Og det "koster kassen" at rette "i drift". Det koster kunderne kassen at finde og omgå fejl.


-eller-



Hvorfor en teknisk tester er en god ide


in the past


Man kan nemt kende en teknisk tester fra en ikke-fagmand: førstnævnte stiller spørgsmål - sidstnævnte ikke.

Udgangspunkt for enhver test er specifikationer... funktionelle... forretningsmæssige... tekniske... Der er test af specificerede krav og Non-Function-Requirements (NFR). Forståelse af muligheder og begrænsninger af teknikken vil være forstået af en teknisk tester - fordi denne vil have taget samme tur mange gange før.
  • de ved hvad en almidenlig bruger vil forvente
  • de kender almindelige NFR krav udenad (hvor lang tid en bruger vil vente på at en side vises)
  • de kan se teknikken mht. kracspecifikation, mellem linjerne, i forlængelse af teksten osv.


Hvordan en teknisk tester arbejder


in the past Det første en teknisk tester vil gøre (som alle testere) er at læse kravspec og NFR (hvis den er specificeret). Derefter læses eksisterende test cases (hvis der allerede er specificeret nogen). Men derefter vil en teknisk tester lave en test ud fra en teknisk analyse.


Maksimering af Business Value vil findes ved optimal udnyttelse af teknologi til at opnå de forretningmæssige mål, indenfor udstukne tidsrammer. En teknisk tester vil forstå dette forhold.
  • med udgangspunkt i tidsrammer allokeres / prioriteres test, ud fra teknisk største risiko - højeste forretningsmæssig værdi - og mulighed for hurtig realisering af test.
  • tekniske testere kender en typisk forventet NFR
  • de kan se teknikken mht. kracspecifikation, mellem linjerne, i forlængelse af teksten osv.


Automated test miniature setup


in the past There's a number of automation frameworks. Tried major ones. For fast automated test setup, you might consider:

First on GithubCode linesUrl
SoapUI2005266881https://github.com/SmartBear/soapui
REST assured201051005https://github.com/rest-assured/rest-assured
SpockPre-release 201245769https://github.com/spockframework/spock
Postman(chrome webstore 2012 - free since v5.0)? (many modules)https://github.com/postmanlabs

We will give SoapUI a look here. Not the Pro version. I'd prefere to avoid the Pro version for SoapUI alltogether, if I can. SoapUI is the oldest, has more code lines than any of them and offers fluent migration between manual/automated testing. And I wouldnt be surprised if it has been tested most. Feature: SoapUI has a Maven plugin, so you can run tests in a maven build. Disadvantage: some of the Maven plugin features are limited to SoapUI Pro. Even so, in the pom.xml file you usually need to hardcode which tests in SoapUI to execute. Also maven build execution will not give you a detailed picture of which tests actually succeded or failed.

We're going to fix this!

Now will be demonstrated techniques to automatically and dynamically run SoapUI tests. Please find SoapUI project setup with a test suite containing 3 tests for demo purposes. You will also find start-up and tear down scripts to configure which tests to run. Input will be taken either from:
  • environment variable ENABLE_TEST
  • plain-text file 'testsuite.labels'
and after running tests, will deliver text file with status
  • plain-text file 'testsuite.result.txt'



Link to file with setup

Fx. if you want to only run test case 1) and 3), you enter into file 'testsuite.labels' the text string 'AUTO_hellocase,AUTO_seeyoucase' and the maven build will do exact execution of those tests.

Basic build output summary

[INFO] Scanning for projects...
...
SoapUI 5.3.0 Maven2 TestCase Runner
...
 INFO  [SoapUITestCaseRunner] Running TestSuite [Testsuite 1], runType = SEQUENTIAL
 INFO  [log] Reading file... with lines=1 and content=AUTO_hellocase,AUTO_seeyoucase
 INFO  [log] Environment dictates test case: AUTO_hellocase,AUTO_seeyoucase
 INFO  [log] List of test for enable: [AUTO_hellocase, AUTO_seeyoucase]
 INFO  [log] Enabling test case : AUTO_hellocase
 INFO  [log] Disabling test case : AUTO_goodbyecase
 INFO  [log] Enabling test case : AUTO_seeyoucase
 INFO  [log] Completed startup
 INFO  [SoapUITestCaseRunner] Running SoapUI testcase [AUTO_hellocase]
...
 INFO [SoapUITestCaseRunner] Assertion [Script Assertion] has status VALID
...
 INFO  [SoapUITestCaseRunner] Running SoapUI testcase [AUTO_seeyoucase]
...
 INFO  [SoapUITestCaseRunner] Assertion [Script Assertion] has status VALID
...
 INFO  [log] Enabling test case : AUTO_hellocase
 INFO  [log] Enabling test case : AUTO_goodbyecase
 INFO  [log] Enabling test case : AUTO_seeyoucase
 INFO  [log] Test result :AUTO_hellocase=OK,AUTO_seeyoucase=OK,
 INFO  [log] Completed teardown
 INFO  [SoapUITestCaseRunner] TestSuite [Testsuite 1] finished with status [FINISHED] in 2849ms
[INFO] 
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ soapui-maven-example ---
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] Building jar: soapui-maven-example-1.0-SNAPSHOT.jar
[INFO] 
[INFO] --- maven-install-plugin:2.4:install (default-install) @ soapui-maven-example ---
[INFO] Installing soapui-maven-example-1.0-SNAPSHOT.jar 
[INFO] Installing pom.xml to .m2\soapui-maven-example-1.0-SNAPSHOT.pom
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 53.888 s
[INFO] Finished at:
[INFO] ------------------------------------------------------------------------


Look up 'openshift bearer authentication' on the net and let me sum it up for you:


IEEE 829-1998


Der findes forskellige standarder for test case templates. Som udgangspunkt stiller standarderne krav til hvilke ting bør kunne forefindes i en test case. Dette er bestemt en fornuftig standard - men der bør også altid også tages hensyn til tidligere traditionel udformning. En testcase er primært god, hvis den bliver forstået af dem, som skal udføre den.


Hvordan en test case kan se ud i praksis


Test cases bliver normalt altid tilpasset aktuel praksis. Der kan blive tale om tilpasning til HP QC eller Jira.

Her er angivet eksempel i hhv. word og pdf format.

Inportant sites



auktion
auktioner
auction
Comics auctions