Software Engineering Groep 4

Software Engineering Groep 4 Software Test Document Kevin Hendrickx (Test Manager) 3 e Bachelor Computerwetenschappen se4-1112@wilma.vub.ac.be 17 mei 2012 1

Tabel 1: Document geschiedenis v5.0 17/05/2012 Kevin Hendrickx Doorvoeren van opmerkingen teamleden v4.1 17/05/2012 Kevin Hendrickx Toevoegen rapport 4e iteratie v4.0 16/04/2012 Kevin Hendrickx Toevoegen rapport 3e iteratie v3.2 15/04/2012 Kevin Hendrickx Doorvoeren van opmerkingen Jan-Pieter v3.1 12/04/2012 Kevin Hendrickx Doorvoeren van opmerkingen klant v3.0 05/03/2011 Kevin Hendrickx Toevoegen rapport 2e iteratie v2.0 11/12/2011 Kevin Hendrickx Doorvoeren van opmerkingen Quentin v1.1 10/12/2011 Kevin Hendrickx Doorvoeren van opmerkingen klant v1.0 13/11/2011 Kevin Hendrickx Doorvoeren van opmerkingen v0.2 12/11/2011 Kevin Hendrickx Aanvullingen v0.1 10/11/2011 Kevin Hendrickx Kladversie 2

Inhoudsopgave 1 Inleiding 5 1.1 Document....................................... 5 1.2 Doel.......................................... 5 1.3 Referenties...................................... 5 1.4 Definities, acroniemen en afkortingen........................ 5 2 Test items 6 3 Te testen Features 6 4 Niet te testen Features 6 5 Aanpak 6 5.1 Unit tests....................................... 6 5.1.1 Testen met unit tests............................. 7 5.2 Integratietests..................................... 7 5.3 Interface tests..................................... 7 5.3.1 Het correct werken van de UI........................ 7 5.3.2 De gebruiksvriendelijkheid.......................... 7 5.4 Regressietests..................................... 8 5.5 Stabiliteitstests.................................... 8 5.6 Veiligheidstests.................................... 8 5.7 Performantietests................................... 9 5.8 Testen van GPS.................................... 9 6 Goed- en afkeur criteria van de items 9 7 Opschorting criteria en hervattingseisen 9 8 Test deliverables 10 9 Taken 10 9.1 Programmeurs.................................... 10 9.2 Leden......................................... 10 9.3 Requirements Manager................................ 10 9.4 Test Manager..................................... 10 10 Omgevingsbenodigdheden 10 11 Training 10 12 Planning 11 13 Risico s 11 14 Rapporten 11 14.1 5 maart 2012..................................... 11 14.1.1 Opleiding................................... 11 14.1.2 Unit tests................................... 11 14.1.3 Handmatige tests............................... 11 14.2 16 april 2012..................................... 12 14.2.1 Unit tests................................... 12 3

14.2.2 Handmatige tests............................... 12 14.3 17 mei 2012...................................... 13 14.3.1 Unit tests................................... 13 14.3.2 Handmatige tests............................... 13 4

1 Inleiding 1.1 Document Dit document, gebaseerd op de IEEE 829-1998 standaard, is een testplan voor groep 4 - Software Engineering - 2011. Een revisie van de standaard, IEEE 829-2008, bestaat reeds. Doch is er gekozen voor de oudere versie vanwege het grotere aantal referentiemateriaal. De grootste referentiepunten voor de inhoud zijn de STD s van de Software Engineering groepen van het vorige jaar. 1.2 Doel Dit document beschrijft de verschillende testactiveiten nodig voor de Mobile City Guide applicatie. Onder meer hoe en wat er getest zal worden. Het uiteindelijke doel is het zo snel en eenvoudig mogelijk kunnen uitvoeren van testen. Meer informatie over de applicatie zelf is terug te vinden in het SPMP en het SRS. 1.3 Referenties [1] Groep 2. Software engineering groep 2-2010. http://wilma.vub.ac.be/~se2_1011/. [2] Groep 3. Software engineering groep 3-2010. http://wilma.vub.ac.be/~se3_1011/. [3] Groep 4. Software engineering groep 4-2010. http://wilma.vub.ac.be/~se4_1011/. [4] Groep 4. Software engineering groep 4-2011. http://wilma.vub.ac.be/~se4_1112/. [5] IEEE. 829 Standard for Software Test Documentation, 1998. [6] Wikipedia. Test plan. http://en.wikipedia.org/wiki/test_plan. 1.4 Definities, acroniemen en afkortingen GUI SDD SPMP SQAP SRS STD UI VUB Graphical User Interface Software Design Document Software Project Management Plan Software Quality Assurance Plan Software Requirements Specification Software Test Document User Interface Vrije Universiteit Brussel 5

2 Test items Volgende items horen getest/gecontroleerd te worden. De code van het programma. Voor een gedetailleerde beschrijving zie 5.1 en 5.2. De UI moet getest worden op gebruiksvriendelijkheid en correctheid. Zie 5.3. Het systeem moet getest worden op stabiliteit. Zie 5.5 De functionaliteit van de GPS moet getest worden. 3 Te testen Features Alle features dienen getest te worden. Telkens wanneer er een feature wordt toegevoegd aan het product hoort deze getest te worden op alle items vermeld in sectie 2. Een nieuwe release van de applicatie wordt enkel vrijgegeven wanneer het nieuwe feature slaagt voor alle tests. Het is mogelijk dat een nieuwe feature eist dat bestaande code wordt aangepast. Daarom zal alle code automatisch opnieuw getest worden. De UI is moeilijker te testen maar vereist toch dat de gewijzigde onderdelen grondig getest worden. 4 Niet te testen Features Het is mogelijk dat gedurende een iteratie een feature en de code die deze feature mogelijk maakt (dus ook zijn afhankelijkheden) ongewijzigd blijven. Zo n feature hoeft dus in principe niet meer getest te worden. De unit tests hiervoor nemen niet veel tijd in beslag en zullen dus toch worden blijven uitgevoerd. Momenteel zijn er geen features die niet meer getest dienen te worden. Indien dit in een later stadium toch het geval moest zijn worden deze hier, na goedkering van de Project Manager, toegevoegd. 5 Aanpak Verschillende tests moeten worden uitgevoerd. Deze worden hieronder beschreven. 5.1 Unit tests Java maakt gebruik van klassen. Logischerwijs dienen de methoden van de verschillende geschreven klassen getest te worden op hun correctheid, het aanvaarden van input en het teruggeven van output. Gebruikersgerichte input en output is hier niet van toepassing. Zie 5.3 voor meer informatie. Het is de taak van de individuele programmeur om voor elke klasse die hij schrijft te zorgen dat een bijhorende unit test wordt geschreven. De tool ter beschikking is JUnit, een Unit Testing Framework. Deze tests worden geschreven en uitgevoerd onder leiding van de Test Manager. De ontwikkelaar van de code voorziet zelf in zijn unit tests en deelt de code enkel wanneer deze vrij is van fouten. Wanneer deze echter minder triviaal zijn moet het team bij elkaar komen om te redeneren over een oplossing. Dit kan een aanpassing zijn in de implementatie of een herstructurering in het design. Vóór het uitbrengen van een nieuwe versie, zowel intern als extern is het de taak van de Test Manager om de Unit Tests uit te voeren en het team hierover te informeren. Vervolgens zal de verantwoordelijke van de unit de fouten moeten oplossen. Een onderscheid tussen unit tests en integratietests moet gemaakt worden. Deze verschillen worden in 5.2 besproken. 6

5.1.1 Testen met unit tests Niet alles is even belangrijk voor de werking van het systeem. Private methods zijn hier een voorbeeld van. We nemen een pragmatische aanpak en testen enkel de belangrijke methods. Wanneer een method een method van een ander object oproept dan voorzien we hier een mock object voor. 5.2 Integratietests De grens tussen unit tests en integratietests is vaak een grijze zone. Beiden kunnen op verschillende manieren geïnterpreteerd worden. In dit document gaan we er vanuit dat Unit tests methoden testen die onafhankelijk zijn van andere methoden (tenzij een mock object), databanken,.... Zodra er sprake is van afhankelijkheid spreken we over integratietests. Hun doel is om te testen over verschillende methoden correct samenwerken met anderen. Ondanks het verschil in beschrijving worden integratietests ook geschreven door middel van JUnit. De programmeur die zorgt voor de integratie is verantwoordelijk voor het schrijven van de integratietest. De uitvoeringen van integratietests blijven gelijk aan dat van de unit tests in 5.1. 5.3 Interface tests We onderscheiden 2 soorten interface tests. Het correct werken van de user interface en de gebruiksvriendelijkheid ervan. 5.3.1 Het correct werken van de UI Het testen van de verschillende componenten van de UI (knoppen, tekstvelden,... ) moet manueel gebeuren. Er bestaan reeds libraries en frameworks voor het automatiseren van Android GUI tests maar dit is nog steeds verre van triviaal. Vanwege de beperkte omvang van het project zal er minder tijd worden besteed aan het manueel testen dan een automatisering hiervan. Het is de taak van de Test Manager om steeds na te gaan of het product nog volledig functioneel is op gebied van GUI. Doch kunnen kleine wijzigingen in de code de UI onklaar maken. Het is de verantwoordelijk van de programmeur om te testen of zijn code een impact heeft op de werking van de UI. Wanneer hij problemen ondervindt moet hij deze eerst proberen zelf op te lossen door de pas geschreven code te overlopen en de unit tests uit te voeren. Vindt hij geen antwoord dan moet de testmanager en de rest van het team op de hoogte gesteld worden. Het is dan toegelaten om de niet-functionerende code toe te voegen aan de repository. 5.3.2 De gebruiksvriendelijkheid Om te voldoen aan de eisen van de klant moet de UI aantrekkelijk zijn en eenvoudig te gebruiken. Gebruiksvriendelijkheid van software is een ruim onderwerp. Het omvat oa. mensenkennis en kennis over hoe mensen software gebruiken. Dit is iets waar geen van onze teamleden ervaring mee hebben. Het inhuren van specialisten is geen optie. Daarom zal dit in eerste instantie getest worden door de Requirements Manager. Deze kent het best de eisen van de klant. Vervolgens zal het ook getest kunnen worden door de overige teamleden om de Requirements Manager bij te staan. Wanneer er onzekerheden zijn zal er contact worden opgenomen met de klant om zo te voldoen aan de requirements betreffende gebruiksvriendelijkheid. Enkele items behorende tot gebruiksvriendelijkheid zijn. Weinig tekstuele informatie Een grote brok aan tekst op een scherm durft de gebruiker afschrikken en zorgt voor een 7

onaangename ervaring. Daarom moet de hoeveelheid aan tekst in de applicatie beperkt worden. Een logisch en consistent menu Gerelateerde opties horen samen in het menu. Wanneer de gebruiker een bepaalde optie niet vindt dan is er duidelijk iets mis met de indeling hiervan. Snelstart mogelijkheden Veel gebruikers willen enkel de basisfunctionaliteiten van het programma. Daarom is het naar hun toe efficienter om extra knoppen te plaatsen om deze functionaliteit onmiddelijk na het opstarten te kunnen uitvoeren. Zoals de optie om meteen te navigeren naar een bepaald punt of meteen een wandeling samen te stellen. Duidelijke foutmeldingen Een goede foutmelding omvat 3 dingen. Wat voor fout het is Waarom de fout zich voordoet Wat de gebruiker moet doen om de fout te voorkomen Snelle en duidelijke laadtijden Typisch denkt de gebruiker na 5 seconden een bevrozen scherm te zien dat het programma gecrasht is. Zorg dan voor een animatie om aan te tonen dat het programma bezig is. 5.4 Regressietests Na elke integratie zal het systeem in zijn geheel getesten worden om na te gaan of er geen regressie heeft plaatsgevonden. Dit houdt dus in, de aangepaste en niet aangepaste onderdelen van de applicatie. Alle bovenstaande tests zullen worden uitgevoerd. Dus unit tests, integratietests en interface tests. 5.5 Stabiliteitstests De applicatie moet stabiel blijven onder alle omstandigheden. Zo moet er beperkte functionaliteit zijn wanneer verbinding tot het internet tijdelijk wegvalt en de applicatie mag niet falen wanneer er geen GPS verbinding is. Belangrijk is dus dat deze functionaliteit getest kan worden. De ervaring hiermee door de gebruiker behoort tot interface testing 5.3. De Test Manager gaat na of de applicatie voldoet aan de stabiliteitseisen zoals vermeld in het SRS. Dit zijn tests die manueel dienen worden uitgevoerd. De applicatie kan automatisch getest worden op de 2 verschillende manieren van functioneren maar de plotselinge overgang van toestand wordt best getest in de praktijk. Het systeem moet ook stabiel blijven bij niet bedoelde input van de gebruiker. 5.6 Veiligheidstests De code is open source. Belangrijk is dus dat er geen gegevens die nefast kunnen zijn voor de database of in het algemeen, de software, verdwalen in de code. Ook zullen praktijken zoals SQL injectie moeten voorkomen worden. Algemeen omvat dit dat het systeem bestand moet zijn tegen alle mogelijke input van de gebruiker. Deze risico s kunnen worden verholpen door elke input te valideren op correctheid. Unit tests en integratietests worden vervolgens gebruikt om de bijhorende code voor validatie te testen. Er is tot op heden nog niet overlegd over de verschillende mogelijke veiligheidsrisico s. Noch is er geweten wie van de teamleden reeds over de nodige informatie en kennis beschikt. Dit onderdeel blijft open voor aanvullingen. 8

5.7 Performantietests Performantie van bepaalde onderdelen zullen niet expliciet getest worden. De tijden worden gemeten door JUnit en zijn dus een onderdeel van de unit tests en integratietests. Pas wanneer een interfacetest faalt vanwege de lange laadtijden, wat niet hoort bij gebruiksvriendelijkheid, moet er aandacht besteed worden aan het mogelijk versnellen van bepaalde algoritmen. De Requirements Manager kijkt dus na of de applicatie snel genoeg is. 5.8 Testen van GPS De functionaliteit moet manueel getest worden. Jan-Pieter, de implementator van de GPS functie meldt dat er nog geen geautomatiseerde oplossing is gevonden. Zie 5.5 voor een de stabiliteit van de GPS. 6 Goed- en afkeur criteria van de items Deze criteria zijn voor de hand liggend. Een item moet compileerbaar zijn. Een item moet foutvrij zijn. Een item mag waarschuwingen bevatten. Doch zal er worden aangeraden deze zo spoedig mogelijk op te lossen. Een item moet voldoen aan de kwaliteitseisen. Een item moet voldoen aan de designspecificaties. Indien van toepassing moet de bijhorende UI correct werken. De bijhorende UI moet voldoen aan de eisen van de klant. 7 Opschorting criteria en hervattingseisen Testactiveiten kunnen door inwendige of uitwendige factoren tijdelijk stopgezet worden. De Wilma-server is ontoereikbaar. De unit tests en integratietests vertonen defecten. Deze moeten zo snel mogelijk worden opgelost alvorens deze tests voortgezet kunnen worden. Tijdelijke stopzetting van ontwikkeling en het testen is mogelijk door een vakantiedag of dagen. Na het aflopen van deze vakantie kunnen de tests worden voortgezet en wordt er verwacht dat de teamleden paraat staan om de fouten zo snel mogelijk op te lossen. Android-Smartphones zijn niet in handen van de leden die de bijhorende tests dienen uit te voeren. Er zal gevraagd worden deze terug te bezorgen. De interface toont defecten. Deze heeft hetzelfde stappenplan als de unit tests en integratietests. 9

8 Test deliverables Elk teamlid heeft toegang tot het gehele project en kunnen zelf dus alle tests uitvoeren. Bovendien is het aantal tests beperkt. Het is dus niet nodig om een rapport samen te stellen van elke test dat wordt uitgevoerd. Wel zal er na elke iteratie, beginnende bij de 2e iteratie, een rapport worden toegevoegd aan dit document met alle problemen en bugs die zich nog voordoen en opgelost dienen te worden bij de volgende iteratie. 9 Taken 9.1 Programmeurs De individuele programmeur is verantwoordelijk voor het correct functioneren van zijn code. Hij voorziet de nodige unit tests en integratietests voor elk component dat hij schrijft. De programmeur is ook in staat deze op regelmatige basis afzonderlijk te testen vooraleer hij het onderdeel uitgeeft aan de rest van het team. 9.2 Leden Alle leden zullen de mogelijkheid krijgen om vóór elke iteratie de interface te testen. Wanneer nodig kan de Requirements Manager de hulp inroepen van het team om hem bij het testen van de interface bij te staan. 9.3 Requirements Manager De Requirements Manager zorgt ervoor dat de UI van de applicatie gebruiksvriendelijk is en voldoet aan de eisen van de klant. 9.4 Test Manager De Test Manager is verantwoordelijk voor de correcte werking van de applicatie. Hij voert de gezamenlijke unit tests en integratietests uit. Ook kijkt hij de UI na op defecten. Als laatste moet hij nagaan of de applicatie stabiel blijft bij het uitvallen van de connectie met het internet. 10 Omgevingsbenodigdheden Om de unit tests en integratietests te kunnen uitvoeren maken we gebruik van het framework JUnit. Dit is open source dus alle teamleden kunnen hierover beschikken. De interface tests kunnen uitgevoerd worden a.d.h.v. een emulator voor Android-smartphones. Doch is het noodzakelijk te beschikken over een echte versie om de functionaliteit te garanderen. 2 zulke smartphones zullen het tweede semester in bruikleen worden gegeven. 11 Training Het is een vereiste dat alle teamleden de nodige informatie hebben over het werken met JUnit. De nodige kennis zal worden opgedaan via een les en een bijhorende tutorial die beschikbaar gesteld zal worden door de Test Manager, ten laatste tegen 28 november 2011. De verschillende criteria waarop getest dient te worden is meer dan triviaal. Daarom is het verstandig deze te overleggen om zo een checklist te kunnen opstellen. 10

12 Planning De programmeur test regelmatig zijn eigen code op fouten. De overige tests worden altijd uitgevoerd alvorens er intern en extern een nieuwe versie van de applicatie wordt uitgegeven. 13 Risico s Onderstaande opsomming geeft een overzicht van de mogelijke risico s. Zulke situaties zullen we proberen te vermijden omdat ze een grote impact hebben op de stabiliteit van het systeem. Onvoldoende testen: Input en output die niet werden voorzien in de tests kunnen voor problemen zorgen en zelfs fataal zijn voor het systeem. Het negeren van fouten die aan het licht komen bij de testen omdat er te weinig tijd is om ze te verbeteren. Requirements die wijzigen waardoor de tests ook moeten worden gewijzigd. Een onderdeel kan afhankelijk zijn van een onderdeel geschreven door iemand anders. Vooraleer dat deze volledig kan worden getest dienen beide onderdelen functioneel te zijn. Een ketting van afhankelijkheden kan het testen bemoeilijken en moet dus vermeden worden. 14 Rapporten 14.1 5 maart 2012 De eerste 2 iteraties zijn druk geweest en daarom heeft het grondig testen nog op zich laten wachten. Vanaf iteratie 3 hopen we dat hier verandering in komt. 14.1.1 Opleiding De teamleden hebben reeds een introductie gehad over JUnit. Het is de bedoeling om hun stapsgewijs meer kennis bij te brengen over de verschillende mogelijkheden. Na een grondige herziening lijkt het mogelijk om ook android activities te testen. Of we dit in praktijk kunnen omzetten valt af te wachten. 14.1.2 Unit tests De allereerste unit test voor de GPS werd geschreven. Deze unittest is nog in experimentele fase en geeft dus geen meerwaarde aan de correcte werking van de code. 14.1.3 Handmatige tests Buiten bovenstaande zijn er nog bugs die nog niet zijn getest via geautomatiseerde tests. Talen De aanpak om de taal te wijzigen werkt op Android niet zoals het hoort. Wanneer men de taal wijzigt dan worden alle activities op de stack geupdate maar nieuwe activities gebruiken nog steeds de oude taal. Dit wijst erop dat de nieuwe activities niet dezelfde instantie gebruiken voor de taal. 11

Wachtwoord vergeten Aanvragen van een nieuw wachtwoord gebeurt niet via de datalaag. Het wijzigen van het wachtwoord is ook nog niet persistent. Validatie De input van een gebruiker moet nog beter gevalideerd worden om veiligheidsrisico s zo laag mogelijk te houden of uit te sluiten. Registratie De registratie wordt opgeslagen in de lokale databank. Deze hoort in de remote database. Rotatie Elke keer wanneer men roteert wordt er een nieuwe activity aangemaakt. (input wordt blijkbaar wel overgedragen). Dit kan als gevolg hebben dat er telkens nieuwe, tijdsrovende instanties moeten aangemaakt worden. Manieren om dit te counteren moeten gezocht worden. GPS De GPS werkt zonder internetverbinding. Hij weet dit ook te melden wanneer verbinding wegvalt. Er moet alleen een manier gevonden worden om de map te cachen bij offline gebruik. Gebruiksvriendelijkheid Er werd nog geen definitief plan uitgewerkt voor de applicatie gebruiksvriendelijk te maken. Hier kunnen dus nog geen uitspraken over gedaan worden. 14.2 16 april 2012 14.2.1 Unit tests Van de 19 uitgevoerde tests zijn er 3 die falen. Deze problemen hebben niets te maken met de foute werking van de code maar een gebrek aan kennis over unit testing. Oplossingen dienen gevonden te worden de volgende iteratie. 14.2.2 Handmatige tests Registreren Registreren gaat enkel wanneer men verbonden is met het internet. Het programma vangt dit probleem correct op maar geeft nog geen melding aan de gebruiker. Inloggen Applicatie crasht wanneer men tracht in te loggen wanneer er geen internetverbinding is. Met internet werkt dit zoals normaal. Bovendien kan men nog steeds inloggen nadat het programma opnieuw wordt geinstalleerd of cache wordt geleegd. Wachtwoord vergeten Wanneer er geen wifi verbinding is dan krijgt de gebruiker een melding om deze aan te zetten. Er wordt geen rekening gehouden met het 2g/3g netwerk. Als er verbinding is en men een willekeurige naam in (bestaand of onbestaand) dan crasht de applicatie. 12

Talen Nog niet alles is opgenomen in de dictionary waardoor bepaalde woorden/zinnen undefined weergeven. Gebruikersgegevens wijzigen De gebruiker krijgt geen melding over foute input. In eerste instantie lijkt dit onderdeel helemaal niet te werken. De knop Go back zorgt ervoor dat er een nieuwe activity op de stack wordt geplaatst waardoor we terug willen gaan via de speciale knop die hiervoor gemaakt is, we terug belanden bij de instellingen. GPS De gebruiker krijgt een melding wanneer zijn wifi niet aanstaat. Er wordt geen rekening gehouden met het 2g/3g netwerk. Als men een melding krijgt om wifi aan te zetten door op de knop te drukken dan hoeft dit niet noodzakelijk via deze manier. Maar eenmaal men wifi aanzet krijgt men nog wel steeds de melding waardoor men verplicht is toch op knop te drukken. Navigatie/promenade Zonder wifi verbinding crasht de applicatie. 14.3 17 mei 2012 14.3.1 Unit tests Van de 59 tests zijn er 5 failures en 1 error. Deze zijn hoogstwaarschijnlijk te wijten aan slecht geschreven tests in plaats van correct werkende code. 14.3.2 Handmatige tests APK installatie De installatie van de applicatie resulteert in 2 identieke knoppen waarvan de tweede functioneert en de eerste resulteert in een force quit. Registreren Wanneer er geen verbinding is met het internet en men zijn registratie probeert te bevestigen krijgt men een melding dat deze gefaald is maar geeft geen oorzaak. Als dit te wijten is het gebrek van een internetverbinding moet er aan de gebruik gevraagd worden om dit aan te zetten. Als er geen verbinding is met het internet kan de backend niet geraadpleegd worden. Dit zorgt ervoor dat de spinner voor taalkeuze niet gepopuleerd wordt met de verschillende talen. Hetzelfde probleem doet zich voor bij het kiezen van beperkingen. Men komt op een lege pagina terecht omdat er geen informatie uit backend kan worden gehaald. Dit kan opgelost worden door deze informatie te dupliceren in de frontend database. Het probleem zou zich echter nog altijd voordoen wanneer men de cache leegt en de applicatie opnieuw opstart zonder internetverbinding. Bij de allereerste keer (ook na een clear cache) dat de applicatie opstart zou er dus altijd verbinding moeten zijn met internet. Als men naar register gaat zonder internetverbinding dan doet bovestaande zich voor. Als men dan de applicatie terug afsluit en opstart met internet dan blijven deze problemen zich 13

soms voordoen. Door het ramgeheugen te legen wordt dit probleem opgelost. Inloggen Inloggen zonder internetverbinding werkt niet. Men krijgt dan altijd een melding dat gebruikersnaam of wachtwoord foutief is. Dit zou wel mogelijk moeten zijn. Wanneer men naar login gaat zonder interverbinding en een lege cache en vervolgens de internetverbindig aanzet dan kan men nog steeds niet inloggen. Het ramgeheugen moet dan geleegd worden om te kunnen inloggen. Talen Er zijn nog veel bugs gerelateerd met het taalgebruik. Wanneer de taal gewijzigd wordt na inloggen en men gaat terug naar Login dan is dit venster in de laatste taal die gekozen is door de ingelogde gebruiker. Wanneer men gekozen heeft om ingelogd te blijven en de applicatie afsluit dan zal de applicatie terug opstarten in de standaardtaal (Engels) wanneer het ramgeheugen geleegd wordt. Wachtwoord vergeten Wanneer men niet verbonden is met het internet dan krijgt de gebruiker een melding op naar wifi settings te gaan (Met een undefined woord). Tegelijkertijd krijgt hij ook een melding dat een gebruikersnaam niet leeg kan zijn wanneer dit het geval is. Wanneer men verbonden is met het internet crasht de applicatie bij elke mogelijke invoer. Geen username, onbestaand of bestaand. Wijzig taal De knop wijzig taal is blijven bestaan omdat er rekening wordt gehouden met het uitgevoerde werk van verschillende programmeurs. Deze is echter overbodig. Het gebruik van Wijzig Profiel wordt aangeraden. Wijzig profiel De applicatie crasht wanneer we naar wijzig profiel willen gaan zonder internetverbinding. Wanneer we in deze activity zitten en we zetten het internet dan krijgen we een melding failed wanneer we ons profiel proberen te wijzigen. Bekijk Poi s Deze geeft een lege pagina wanneer er geen internetverbinding is. Anders zijn de benamingen van de Poi s gigantisch groot. Wannneer men bij het weergeven van de lijst het internet uitzet en op een Poi klikt dan crasht de applicatie. In sommige gevallen blijft de lijst leeg nadat deze eerst opgevraagd werd zonder internetverbinding. Het ramgeheugen moet dan geleegd worden. Wanneer men op de knop Voeg toe aan mijn wandeling klikt dan crasht de applicatie. Bekijk wandelingen De geeft een lege pagina wanneer er geen internetverbindig is (indien er niets is opgeslagen). Anders zijn de benamingen van de wandelingen gigantisch groot. Wannneer men bij het weergeven van de lijst het internet uitzet en op een wandeling klikt dan krijgen we een pagina met standaard layout maar zonder enige ingevulde data. Het klikken op de knoppen resulteert dan ook in een crash. In sommige gevallen blijft de lijst leeg (of enkel opgeslagen wandelingen) 14

nadat deze eerst opgevraagd werd zonder internetverbinding. Het ramgeheugen moet dan geleegd worden. Wandelingen die opgeslagen worden in de cache staan genoteerd met een sterretje *. De niet opgeslagen wandelingen wordt alsnog in de lijst weergegeven waardoor de wandeling dubbel staat. Men kan niet scrollen waardoor de pagina van een wandeling soms niet op het scherm past en er dus niet op de knoppen geklikt kan worden. Wanneer men met een internetverbinding de details van een opgeslagen wandeling probeert te bekijken dan toont hij de verkeerde informatie. Quentin vermeldt dat dit probleem zich voordoet omdat hij met het id van de promenade de details gaat opzoeken in de backend database ipv. de cache, waar de opgeslagen wandeling staat. Er valt ook nog op te merken dat wanneer men dit probeert zonder internetverbinding wel de juiste informatie getoond wordt. Opslaan en uitvoeren van wandeling Men kan een wandeling opslaan en vervolgens op de knop Voer wandeling uit klikken. Ook zonder internetverbinding. Men gaat dan vervolgens naar de kaart maar daar wordt er gevraagd om het internet aan te zetten. In sommige gevallen crasht de applicatie echter wanneer met op Voer wandeling uit klikt nadat er een wandeling is gekozen. De reden is onbekend. Nieuwe wandeling We kunnen een naam opgeven en deze wordt toegevoegd aan de lijst van wandelingen. Wanneer men echter de details hiervan bekijkt zijn dit niet de correcte gegevens wanneer er internet is. Dit is hetzelfde probleem als bij Bekijk Wandelingen. Vervolgens een tweede wandeling proberen aan te maken lukt niet. Deze wordt niet getoond in de lijst. GPS Wanneer er geen internetverbinding is krijgt men de keuze om wifi en/of 3G op te zetten. De applicatie crasht wanneer men op de 3G knop klikt. Verder werd het volgende gerapporteerd door Jan-Pieter. Soms krijg ik geen GPS fix, enkel een WiFi fix en langer wachten helpt ook niet. Normaal gezien duurt het maximum 60 a 90 seconden om een GPS fix te verkrijgen. Als ik dan de applicatie volledig afsluit (via de task manager) en ik probeer opnieuw, krijg ik dikwijls snel een GPS fix. Geen idee aan wat dit ligt. In uitzonderlijke gevallen staat de blauwe mapmarker met de huidige locatie niet op dezelfde plaats als de bol met de precisie van de GPS fix. Als er een nieuwe fix is, dan staan deze plotseling wel opnieuw op elkaar. Ook hier geen idee aan wat dit ligt. Als ik soms in de buurt ben van metalen structuren (treinen, dak van station) doet het kompas raar: de pijl verandert constant. Deze functie is door Android zelf geïmplementeerd, dus ik heb geen idee aan wat dit ligt. 15