Hierbij de nieuwsbrief van het Vlaams Software Platform (VSP). Graag ontvangen we uw opmerkingen! Stuurt u daarvoor een e-mail naar nieuwsbrief@vsp-vzw.org.
Om u af te melden ("unsubscribe"), uw adreswijziging door te geven of u aan te melden ("subscribe") volstaat het een eenvoudige e-mail te zenden naar nieuwsbrief@vsp-vzw.org. U vindt deze nieuwsbrief binnenkort ook op de VSP website.
De volgende nieuwsbrief verschijnt in december 2006.
Op woensdag 8 november organiseert het Vlaams Software Platform (VSP) een VSP Event met als thema: “testoptimalisatie”. Het Event is gericht op managers, specialisten en academici uit de software-engineeringsbranche.
Bij softwareontwikkeling neemt testen een aanzienlijke hap uit de totale ontwikkelkost van een software-intensief product. Het nut van testen wordt niet in vraag gesteld, maar wel de kost en omvang ervan.
Veel bedrijven maken vandaag gebruik van één of andere vorm van testautomatisatie. De testprocedure wordt gecodeerd in een script dat kan worden uitgevoerd door het op te nemen in een testreeks. De verleiding is groot álle tests te automatiseren. Wanneer aan het softwareproduct wordt ontwikkeld, moeten dan ook de tests mee evolueren. Hier is een kost mee verbonden.
Testoptimalisatie zoekt een antwoord op vragen als:
Dit Event wil, aan de hand van enkele praktische gevallenstudies, enkele aspecten van testoptimalisatie in softwareontwikkeling toelichten. Na de presentaties wordt de gelegenheid geboden met de sprekers en aanwezigen in contact te komen tijdens de netwerkdrink.
Inschrijven via de website van het VSP. Inschrijven is verplicht. Het Event is gratis voor VSP leden en kost 75 euro (excl. BTW) voor niet-leden.
Deze rubriek dient voor aankondigingen van VSP-leden naar de lezers van de VSP nieuwsbrief. Om een bericht te laten opnemen, gelieve een mailtje te schrijven naar nieuwsbrief@vsp-vzw.org, met als onderwerp "AdValvas".
De Ad Valvas rubriek is ook te vinden op de website.
Als antwoord op de toenemende vraag naar ondersteuning voor open standaarden binnen publieke administraties, heeft Microsoft een open source plugin mee ontwikkeld voor ondersteuning van het Open Document Format. Een eerste versie van deze ODF plugin werkt voor Microsoft Word, en ondersteunt het openen van ODF-documenten vanuit Word. Op termijn zal de ODF-plugin eveneens opslag in het ODF-formaat ondersteunen.
Spammers worden mettertijd vindingrijker om hun uiteindelijk doel te bereiken. De laatste vorm van spamming doet zich voor onder de vorm van een georganiseerd lek over bedrijfsresultaten van een doorgaans onbekend beursgenoteerd bedrijf. Het volstaat dat enkele naïeve internauten erin geloven en aandelen van dat bedrijf beginnen te verhandelen om de beurskoers te kunnen manipuleren.
De plannen van SUN Microsystems om een aantal van hun producten in open source vrij te geven zijn niet nieuw. In een vorige editie van de VSP Nieuwsbrief hebben we hier reeds over gerapporteerd. Ditmaal werd een tijdsschema voorgesteld: zowel Java Standard Edition (Java SE) als Java Micro Edition (Java ME) zouden in de loop van 2007 in open source worden uitgebracht. Over de licentievorm zelf is nog geen uitsluitsel gegeven, maar de wil is er om een door OSI erkende licentie te hanteren. Er zijn nog geen plannen om eveneens Java Enterprise Edition (Java EE) in open source vrij te geven.
De populaire virtuele wereld "Second Life" huisvest ruim één miljoen internauten van over de hele wereld. Nadat enkele bedrijven zich in deze wereld hebben gevestigd, hebben nu ook enkele leden van het Nederlandse parlement beslist op campagne te gaan in deze virtuele wereld.
Met de recente overnames van Internetbedrijven door o.a. zoekgigant Google is het volgens Gunter Thielen, baas van Bertelsmann, duidelijk dat we in het midden van een nieuwe Internetbubbel terechtgekomen zijn.
Dit artikel is verschenen op Agoria Online, het elektronisch informatiecentrum van de Agoria-leden, en op Techniline, de portaalsite van de technologische innovatie van WTCM-CRIF.
Gestructureerd testen van software kan diverse voordelen opleveren. De kwaliteit van het opgeleverde product kan gevoelig worden verbeterd, testmiddelen kunnen efficiënter worden ingezet, het proces kan beter worden beheerd ... Dit artikel wil een inleiding zijn in deze werkwijze voor wie denkt dat zijn testproces beter kan.
Waarom test u software? Weet u wat uw testproces kost? Weet u of het efficiënter kan, en zo ja, hoe dan? Weet u wat het risico is van fouten die nog in de software overblijven? Als u als softwareontwikkelaar het antwoord op deze vragen niet kunt geven, doet u waarschijnlijk niet aan gestructureerd testen. U test dan waarschijnlijk om willekeurig zoveel mogelijk fouten uit software te halen.
Bij gestructureerd testen wordt het gehele testproces beschouwd als een project waarbij een veelheid projectmanagementmethodes en -technieken gebruikt kunnen worden. Er wordt dan typisch een teststrategie en een begroting opgesteld, en er worden deelprocessen geïdentificeerd als intake, inspectie, testontwerp en -specificatie, analyse, rapportage ... Deze projectmatige aanpak brengt uiteraard overheadkosten met zich mee, in zowel tijd als geld. Er zijn echter ook grote voordelen verbonden aan gestructureerd testen.
Gestructureerd testen biedt voorts vergaande mogelijkheden om de test-effort te richten op het beheersen van risico - door zowel het projectrisico als de risico's op fouten in het opgeleverd product te verkleinen .
Door een risicoanalyse, als onderdeel van het testproces, ziet het management wat er zoal fout kan gaan in het opgeleverde product, en wat de gevolgen van deze fouten kunnen zijn. Hierop kan het zijn testproces en andere activiteiten aanpassen. Een goede risicoanalyse (1) zal niet alleen de fouten beschouwen die kunnen voorkomen, maar ook hun oorzaken en hun effecten. Het geeft onder andere antwoord op de volgende vragen:
Met deze risicoanalyse kan de rest van het testproject worden opgesteld, waaronder de testspecificaties. Een voordeel hierbij is dat een expliciete beslissing kan worden genomen over het inzetten van resources. Als bijvoorbeeld test-resources schaars zijn, kan op een rationele manier worden beslist waar deze test-resources voor te gebruiken.
Waarschijnlijk zullen de test-resources zeker worden gebruikt om te zorgen dat díe onderdelen goed werken, die bij faling de grootste problemen opleveren. En kan er extra aandacht worden besteed om díe fouten te verhelpen die een groot risico hebben om op te treden. Als ze moeilijk op te sporen zijn, kan besloten worden hier extra resources aan te besteden, eventueel ten koste van testen op andere onderdelen.
Daarbij kan het management gedurende de softwareontwikkeling een goed zicht hebben op de kwaliteit van de op te leveren software. In plaats van een uitspraak als ‘we hebben x testen gedraaid en y fouten gevonden', kan het management de voortgang van de kwaliteit van het op te leveren product in detail volgen. Van de diverse onderdelen kan het management de diverse kwaliteitsaspecten in de gaten houden. Met name zou het management zicht moeten hebben op die onderdelen die als belangrijkst zijn geïdentificeerd, en op die kwaliteitsaspecten die als cruciaal zijn benoemd.
Fouten zijn onvermijdelijk. De rol van het testteam is niet om ze te voorkomen, maar om onzekerheid te verkleinen en het management op de hoogte te houden.
Er bestaan tal van standaarden, methodes en tools om gestructureerd testen in te voeren. Die grote hoeveelheid zorgt er aan de ene kant voor dat vele bedrijven wel iets van hun gading vinden, aan de andere kant maakt het de meest geschikte aanpak voor een bepaald bedrijf niet eenvoudig te kiezen.
Een overzicht van beschikbare mogelijkheden is niet mogelijk in een artikel als dit. Wel geven we u enkele referenties die een indruk van de mogelijkheden geven. Vaak gebruikte standaarden zijn:
Deze standaarden geven aan wat moet gebeuren om op een gestructureerde manier te testen, maar blijven meestal vaag m.b.t. hoe men dit moet doen. Deze leemte wordt opgevuld door de testmethodes.
Vandaag bestaan er veel methodes die elk op hun manier het testproces gestructureerd doen verlopen. Niet alle methodes hanteren dezelfde terminologie, waardoor een vergelijking verwarrend kan zijn. Hieronder volgt een niet-exhaustieve lijst van courante benaderingen:
In deze methodes wordt duidelijk de link gelegd tussen requirements (het bestek) en tests. Veel testmanagementtools en -methodes voorzien dan ook expliciet in deze link. Door de requirements op een gestructureerde manier op te stellen, en de tests deze structuur te laten volgen, is een requirementscoverageanalyse gemakkelijk te extraheren.
Gestructureerd testen heeft diverse voordelen. Het testproces kan beter worden gevolgd en bijgestuurd, het projectrisico kan worden verkleind en de risico's op fouten in het opgeleverd product kunnen beter beheersbaar worden. Tevens stimuleert het om al bij specificatie eenduidig af te spreken welke systeemgedragingen nog correct zijn en welke niet meer.
Bij het invoeren van gestructureerd testen in uw bedrijf is een gefaseerde invoering mogelijk en bestaat er een ruime ondersteuning van methodes en ondersteunende tools. Als u uw testproces efficiënter wilt maken of meer greep wilt krijgen op projectrisico en risico op fouten in het product, kan het zeker lonen om u nader te informeren.
Dit artikel kwam tot stand met de steun van het Brussels hoofdstedelijk gewest.
I started to write this month's Theory and Practice column about using and creating mock objects in testing. That was before I attended Agile 2006, the Agile Alliance's annual conference on Agile methods and techniques. Oh, I can hear you say "Ahhg! Not another article on agility." I assure you that is not my intention. The conference presentations and discussions I had with several people got me thinking about process in general and the role of process in software development.
Of course, what the people at this conference and elsewhere are really interested in is finding a silver bullet for getting their software done. It dawned on me that the conference discussions were centered on a particular level of success within an organization, a level that had to do with a company's size, the size of its software development teams, and the scope of the process used to ensure success. I started trying to sort all this out, and I think I've arrived at some helpful ways to think about the role of process in software development.
For starters, as smaller organizations grow to enterprise organizations, things change and your processes must change as well. The Agile community is quick to point out that one of agility's fundamental principles is reflection upon what you do, with the aim of improving the way you work. But this principle is no different in RUP or any other modern methodology. So the question arises: "Does process matter?"
The vast majority of improvements in software development tools and techniques focus on the development of new applications or components for greenfield projects. Unfortunately, this often means that organizations with substantial assets developed using older, once popular and accepted technologies and methods cannot easily migrate to new applications or components.
As the size and complexity of software has rapidly grown during the past two decades, it has become a big challenge to assure quality of software and to curb the cost of developing software. Many ways have to be brought to bear in order to meet this challenge. One of them is the design and documentation of software architecture.
Traditional techniques such as Black, White and Gray Box testing map well into Web Services deployments, but there are some challenges. A novel approach extends Gray Box’s reach into realm of White Box testing.
De Poolse beveiligingsonderzoekster Joanna Rutkowska heeft van rootkits en verborgen malware haar belangrijkste onderzoeksterrein gemaakt. Eerder dit jaar toonde ze een 'exploit' aan die een rootkit installeerde op een bètaversie van Windows Vista. Zij vertelt in dit interview over de huidige en toekomstige kwaadwillige software, en over de rol die software- én hardwarevirtualisatie hierin kunnen spelen.