Automatisch testen met CodedUI

Zoals veel testautomatiseerders ben ik begonnen met Selenium. Selenium is een freeware tool en daardoor toegankelijk voor alle testers. Maar ook CodedUI is een uitstekende tool om te testen! Daar kwam ik recentelijk achter toen ik bij Centric de kans kreeg om handmatige testen te automatiseren.

CodedUI is sinds 2010 op de markt en dus relatief nieuw. De nieuwste versie is samen met Visual Studio 2013 op de markt gebracht om dit systeem gemakkelijker te beoordelen en te debuggen. Maar ook Team Foundation Server (TFS) was belangrijk voor CodedUI. Want met TFS werd het mogelijk om werk-items te volgen, versies te beheren, builds te automatiseren en testen en releases te managen.

In deze blog een aantal bevindingen en tips die je kunnen helpen bij het toepassen van CodedUI.

Denk vanuit de gebruiker
Werk je met CodedUI, start dan altijd vanuit het gebruikersperspectief. De gebruikers zijn je klanten en zij moeten achter je concept staan. Het zou toch zonde zijn als je automatische testen niet meer worden gebruikt zodra je weg bent?! Daarnaast moeten er voldoende mensen zijn die de code kunnen wijzigen. Ontwikkelaars moeten daarom je project ondersteunen. De kennis van ontwikkelaars kan ook van pas komen als je vastloopt met het integreren van je project in de build.

Kies het beste framework
Het gekozen framework en de testmethode bepalen uiteindelijk het succes. Zo kun je ervoor kiezen om je testen data driven te maken. In CodedUI doen we dit door Shared Tables, maar het kan ook met een txt-, csv-, xml-, xls-, xlsx- of SQL-bestand. Daarna kun je kiezen voor een bepaald type framework. Ik gebruik altijd het page object-model, maar het modular driven framework volstaat ook. Dit kan worden gecombineerd met een constante variabelen class. Daarnaast zijn er verschillende methoden om testen te configureren. Bijvoorbeeld met config files en global properties (vaak onderschat men de waarde hiervan). Ook een goede Exception Handeling kan veel toevoegen aan de testen. Overigens zal je eerste scenario altijd uit één class bestaan, die je later onderverdeelt.

Gebruik weinig of geen third party packages
Testers willen vaak veel verschillende ondersteunende libraries (packages) downloaden. Maar deze libraries vallen in de praktijk vaak tegen. Bij CodedUI kun je twee verschillende soorten libraries gebruiken, namelijk Nunit of Testapi. Probeer deze packages optimaal te benutten, want er is vaak meer mogelijk dan je denkt.

Verder is het verstandig zo min mogelijk third party packages te gebruiken. Bedenk wat de risico’s zijn van een third party package als je de Testapi of Nunit package update. De complete test zou falen. In dit geval geldt: less is more. Download alleen een library als je zeker weet dat deze breed wordt ondersteund en dus wordt geüpdatet als de Testapi wordt geüpgraded. Laat je niet misleiden door marketingtruckjes!

Welke dekking heeft de test?
Of je daarnaast nu met paden, beslispunten, equivalentieklassen, pairwise testing, grenswaarde-analyse, CRUD, operational profiles, load profiles, goedpaden/foutpaden of afvinklijsten werkt of welke andere methode ook; de cruciale vraag welke dekking heeft de test? moet worden beantwoord. Goed rapporteren is daarom erg belangrijk. Het voordeel van CodedUI is dat alles in TFS automatisch kan worden geregistreerd. Daardoor is het mogelijk om zowel manuele testen als automatische testen onder één folder onder te brengen. De overzichtspagina in MTM of TFS laat goed zien welke testen zijn geslaagd met screenshots van alle stappen.

Testmodellen
In mijn huidige project heb ik een page object georiënteerde testframework gemaakt met shared parameters. Dit geheel is geïntegreerd met TFS en wordt gestart vanuit een build op een remote testomgeving. Supercool dus! Selenium is ook te integreren met TFS, maar Selenium biedt minder mogelijkheden voor drag and drop en picture verificatie. Bovendien zijn de rapportagemogelijkheden minder sterk. Ook het beïnvloeden van omgevingsvariabelen, zoals schermresolutie inzoomen en keyboard events zijn sterker met CodedUI.

Sterke eigenschappen van CodedUI
Een overzicht van de sterke punten van CodedUI:
• testbevindingen zijn gecentraliseerd
• traceerbaarheid
• samenwerken in een online omgeving
• automatisch de test starten na een softwareoplevering (build)
• eenvoudig fouten opsporen
• ontwerpen van generieke stappen
• eenvoudig verbinden met tools, zoals xls of shared parameters in TFS
• gemakkelijk om testen te organiseren
• realtime reporting van automatische testen!

Waarom überhaupt automatisch testen?
Tot slot wil ik nog kort ingaan op het waarom van automatisch testen. Testautomatisering is met name het gevolg van ontwikkelingen in Azure, TFS en DevOps. Vanuit het Competence Center Microsoft van Centric wordt hiermee flink geëxperimenteerd. Het thema dat als een rode draad door deze ontwikkelingen loopt, is continue delivery. Deze softwareontwikkelmethode is erop gericht om ideeën zo snel mogelijk in productie te krijgen. ’Businessaannames kunnen hierdoor snel bij de klant worden gevalideerd om zo op een kort cyclische wijze een product vorm te geven’ (Wikipedia).

In de realiteit betekenen deze kort cyclische wijzigingen dat op korte termijn nieuwe features worden verwerkt in de software en dat deze achter elkaar op de markt worden gebracht. Het is daarom van groot belang om de kwaliteit van ‘oude’ software te kunnen garanderen.

Wil je ook starten met CodedUI? Dan is deze tutorial het beste startpunt: https://www.youtube.com/watch?v=TKgsMDiPWOs. Daardoor krijg je inzicht in zowel MTM als CodedUI.