Not all my projects are thundering successes… Different early decisions have set the scene – but still the play, so to speak, have been full of lessons in what testers find – when asked open questions:
- A team had previously synchronized information in the old context, so they where invited to test the new solution… which turned out would eliminate the need for synchronization. but nobody had troubled them to tell them so.
- That the development team was not acting agile, sprints and scrums in words only
- That the biggest PBI (product backlog item) in hours, actually was to get GUI automation of modal-windows to work.
- That despite having a requirements sheet, the actual value of the sheet was zilch
- That despite putting in extra hours and overtime, the quality and stability of the delivered did not improve
- That the biggest problem towards integration was problems between .Net and java implementation of SOAP
- That simple requirements on virus scanning documents, was both hard and expensive to solve
- That part of the project deliveries was upgraded business guides, when tested they needed corrections too
Calling them all defects or even software bugs, does sound odd to me, because those that really take time is not the software issue it self, but misunderstandings and due to not knowing everything (will we ever). Standards tell you that testing finds risks in the Product, the Process and the Project – it seems to me even more we find issues in management decisions, architecture decisions, cultural issues, organisational change… it’s just software but it does have a business impact.
Complexity is a Matter of Perspective 
Nice post. And so true. That’s the field and business where a tester has to work! Kr Ralf
LikeLike
[…] Visualizing the pipeline, as described by @lisacrispin & @aahunsberger, can help you find all the places from idea to deploy, where the story can be tested. I think this model could work even for non-DevOps deliveries too – testing can add value everywhere and there’s more to testing than gatekeeping. […]
LikeLike
[…] do need the darling solutions for the things that sets you uniquely apart and for the unknown of the new incoming features. We need the cattle, structure and standards for factory solutions and stable operations. […]
LikeLike
[…] I quickly learned that the cloud provider was already sanitizing the input, so no Little Bobby Tables were allowed. It made the customer think, though, and she added a rule for the shop with regard to the Ressource names. This was coded as a regular expression (Start with a capital letter, then some letters, perhaps some numbers) – not that we or the cloud cared for that strict naming scheme, it was more of a business usage rule. Was that a bug? No mostly something that testing finds – not a bug. […]
LikeLike