Contents
Andre sites
Language
|
|
eller... "Hvorfor en teknisk tester kan være en fordel"
Freelance konsulent Business card - "helping is my business"
"On target - 80% done!"
 |
OK, så er tilbage 20%... tid? opgaver? budget? ekstern integrationsarbejde? Er der testet udenfor snævre 'positive-sti' success scenarier? Virkelighedsnære test data? Hvor mange % dækkede testen?
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
 |
Well... Som udgangspunkt findes ingen dårlige IT-løsninger - der findes kun dårlig eller komplet 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
 |
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
 |
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 
 |
There's a number of automation frameworks. Tried major ones. For fast automated test setup, you might consider:
 | First on Github | Code lines | Url |
|---|
| SoapUI | 2005 | 266881 | https://github.com/SmartBear/soapui |
| REST assured | 2010 | 51005 | https://github.com/rest-assured/rest-assured |
| Spock | Pre-release 2012 | 45769 | https://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
| |
