Adobe Flex : Visual Flex Unit

One of the major trailblazers on the Flex front is the company Allurent which features none other than Joe Berkovitz himself as VP of Engineering.
For you out there not yet familiar with Joe's (I hope he won't mind too much that I mention him by firstname) achievements, you should check his blog out right away and stay listening as its one of the major sources for good stuff out in respect to the Flex development environment out there as well as in respect to the entire Flash platform as well.

Anyways, Allurent have chosen to share another of their works, namely the Visual Flex Unit which "is an Allurent open source project to establish a framework for the testing of components' visual appearance. The goal is to enhance FlexUnit with additional features to support visual assertions. In a nutshell, a visual assertion asserts that a component's appearance is identical to a stored baseline image file. Tests can be run using a GUI interface or through an Ant build process."

It looks very promising and as a huge fan of automated test I will definitely try to give it a shot.

Check it out:
http://code.google.com/p/visualflexunit/

Strategi for Test

Jeg kunne godt ønske mig (og jeg kunne faktisk også forestille mig at det kunne være formålstjenligt) at få nogle faste rutiner lagt ind i den løbende test-disciplin...
Det kunne måske være noget i stil med:

1. Funktions test (Med udgangspunkt i de funktionelle krav testes systemet fra brugerens perspektiv).
2. Sikkerheds test (test af systemet udfra de konkret definerede krav til sikkerhed for det enkelte system såfremt der er specielle hensyn og så selvfølgelig de helt almindelige krav der er til den givne applikationstype (For en generel webapplication: SQL-Injection, URL-modification, osv)).
3. Load test (der bekræfter at systemet understøtter de lovede load).

Tilbage ville så være følgende test, der i så fald kunne afvikles som en del af den afsluttende transition:

1. Chrash-Recovery-Continue test (Test af hvilken load-belastning der bringer systemet i knæ, hvilken tilstand systemet er i når crashet er sket samt om systemet kommer til sig selv igen og hvis ikke, hvilke handlinger der kræves for at bringe systemet tilbage i drift).

Afslutningvist ville kunden derefter forestå afvikling af en accept-test, som egentlig bare ville indeholde samtlige ovenstående test. Denne accepttest ville derfor være en ren formssag da de allerede var blevet afviklet under det forudgående udviklingsforløb.

Afslutningsvist for denne email vil jeg lige dele nogle af mine premisser for de ovenstående tanker:
• En test-strategi (uanset sin udformning og indhold) er et must-have for ethvert projekt !
• Samtlige test-former kan med den forhåndværende tool-support automatiseres (ja, sågar funktionstest bliver efterhånden med stor fordel automatiseret).
• Der er en absolut og direkte sammenhæng mellem kvaliteten af test og kundens tilfredshed. Denne sammenhæng korresponderes af kvaliteten af systemet (systemets levedygtighed, systemets vedligeholdelses-dygtighed, osv).
• Test betragftes som en overvejende regressiv aktivtet og derfor ikke-kreativt hvilket er med til at gøre det til en uattraktiv disciplin blandt de fleste mennesker. Dette er ikke sandt, testing kan sagtens gøres kreativt.
• Test giver frihed til kreativitet da man ikke er nødt til at basere sine beslutninger på antagelser (antagelser har det med at være forkerte).
• Der er meget få mennesker der synes det er interessant at teste, men at de trods alt findes, Denne type udvikler/projektmand er uundværlig og personer vi skal lede konkret efter i forbindelse med optagelse af nye medarbejdere, eller alternativt selv skabe i egne rækker ved feks. at automatisere test-aktiviteterne og derved gøre det mere attraktivt at give test-discplinen noget opmærksomhed.
• Test af et system er det eneste eksisterende synonym for at et system beviseligt virker. Da den videnskabelige metode i sin grundform er baseret på (lettere simplificeret og omskrevet til formålet): ide --> eksperimentering --> vurdering --> konklusion betyder det at vi uden test arbejder i modstrid med den videnskabelige metodes grundtese og derfor i modstrid med stamfaderen til alle best practice’s og alle moderne processer samt metoder... imho. ikke en særlig god ide :-)

This post was published to The Cynical Corner at 11:27:19 31-08-2007