Waar ik naar kijk
Als ik een fout zie in Postman, kijk ik eerst of de verwachte waarde en het script kloppen. Daarna kijk ik naar de response, mapping en brondata. Ik gebruik ook mijn werkzaamhedenoverzicht om te zien wat nog openstaat.
Testresultaten
In de rode run mislukken zes controles bij organisation-detail, terwijl de status 200 is. Het gaat onder andere om het id, primaryCode en name. In de andere run slagen ze. In mijn chat met Roger staat het resultaat: het DTO klopte niet helemaal, waardoor de mapping fout liep. Ik meldde herstel en stuurde de groene run mee. De chat bevat geen verwijzing naar de precieze codewijziging.
Hier zijn studyLoad.value en duration null. Ik moet per veld kijken of dit mag en of de bron wel een waarde heeft. Zomaar een waarde invullen is geen oplossing.
Code
Deze punten heb ik bij het aanvullen van mijn portfolio in de projectcode gevonden. Die heb ik niet tijdens mijn stage opgelost.
| Bestand in het Retriever-project | Wat ik zie | Wat ik wil verbeteren |
|---|---|---|
Services/ProductService.cs, regel 70 | primaryCode staat direct in de SQL-query. | De waarde via een gebonden parameter meegeven. |
Services/ProductService.cs, regel 161 | GetProduct begint met een leeg DTO. De function controleert juist op null. | Duidelijk teruggeven wanneer een object niet bestaat. |
MappingProfiles.cs, regel 45 | SKU[2] wordt gebruikt zonder hier de lengte te controleren. | Een korte SKU en ontbrekende bronvelden afvangen. |
Services/RandomizerService.cs | De Guid wordt uit een seed berekend. | Met een engineer bepalen hoe id’s ook bij bronwijzigingen stabiel blijven. |
Open werk
Offerings staan bij TODO. Bij de basisonderdelen staat GUID-opslag nog bij databasewerk. Die punten vragen eerst afstemming over de bron en daarna pas extra code.
Reactie van mijn begeleider
In deze chat stel ik herstel van organisation-detail voor. Roger vraagt om het te herstellen en vraagt naar de omvang. Ik geef mijn inschatting en koppel later het resultaat terug. De fout uit de test en de reactie van mijn begeleider komen hier dus samen.
Dezelfde chat bevat feedback over mijn tijdskolom. Die gaat over mijn werkwijze; de herstelvraag gaat over de software zelf.
Mijn vastgelegde testanalyse
In mijn DevOps-verslag staat organisation-detail als gefaald en staan de bestaande-id- en verplichte-veldencontroles als deels geslaagd. De totalen zijn 96 geslaagd en 6 gefaald. Daarom stelde ik herstel voor.
Het verslag noemt ook tests voor onbekende id’s, queryparameters en toegang als geslaagd. De afzonderlijke requests en responses zijn niet zichtbaar in deze screenshot. Bovendien spreekt TC-003 over ongeldige id’s terwijl het scenario niet-bestaande id’s noemt; dat moet ik bij een volgende test duidelijker scheiden.
De testnummers in deze wiki zijn de oorspronkelijke nummers; ze zijn niet dezelfde nummering als mijn later uitgebreide testplan.
Feedback uit het overleg
Dit bespreek ik in maart-sortering.mp4. Het fragment lever ik apart aan.
We bespreken of de resultaten bij paging steeds in dezelfde volgorde terugkomen. Ik krijg het advies om dezelfde methode vijf keer zonder en vijf keer met ORDER BY uit te voeren. Ik zeg dat dit goed is. Met die vergelijking kan ik kijken of de volgorde wisselt. Het fragment laat de vraag en het testvoorstel zien; er staat nog geen testresultaat bij.