There are many different types of performance test – sometimes referred to as performance testing techniques. It’s not always easy to know which you need so this article aims to give some guidance on the performance testing technique you might want to consider for your system.
- Customer satisfaction by early and continuous delivery of valuable software
- Welcome changing requirements, even in late development
- Deliver working software frequently (weeks rather than months)
- Close, daily cooperation between business people and developers
- Projects are built around motivated individuals, who should be trusted
- Face-to-face conversation is the best form of communication (co-location)
- Working software is the primary measure of progress
- Sustainable development, able to maintain a constant pace
- Continuous attention to technical excellence and good design
- Simplicity—the art of maximising the amount of work not done—is essential
- Best architectures, requirements, and designs emerge from self-organising teams
- Regularly, the team reflects on how to become more effective, and adjusts accordingly
It’s interesting that despite the first principle being; ‘Customer satisfaction by early and continuous delivery of valuable software.’ UAT, as we have traditionally known it, doesn’t fit well into an Agile delivery model. Many Agile teams dispense with UAT and rely more heavily on the Show and Tell session to get customer sign off. In Scrum, this is done in the Sprint Review Meeting and involves a demonstration of the user stories that have been delivered (according to the Definition of Done) in the sprint. One of the objectives is to elicit stakeholder feedback.This is good practice, fosters collaboration and creates a high level of discipline while also meeting the objectives of the first principle. Product demonstrations should be interactive so that stakeholders have the chance to provide feedback however, I often wonder “Is this enough?”. Participants in the ‘Show and Tell’ and the Sprint Review Meeting should include, amongst others, the Product Owner, Stakeholder and Sponsors and Customers. However, in practise, I tend to find two problems;
Like other engineering principles, software engineers should be responsible for delivering high quality, bug free products that work under all conditions. I wholeheartedly agree that developers (and the whole team) should be accountable for product quality and there needs to be a mind, and culture, shift so that the responsibility of quality control is not abdicated to the testing team.
The glib answer to the question “where does testing fit into your Digital Transformation project?” is “to get a high-quality product and the expected business outcomes, testing needs to feature highly in your digital transformation – as it does with any IT project.“
Successful DevOps needs automated processes throughout the software delivery life cycle. It relies on a culture and environment where building, testing and releasing software can happen rapidly, frequently and reliably.
I often find many of the high-level risks have repeated themselves on the projects I’ve worked on. However, the risk profile, risk appetite, detail of the risk, how it gets managed, mitigated and controlled varies massively.
It’s possible to keep your stakeholders happy, even if quality is not great, simply by managing their expectations from start to finish.
Building a high performing team is never an easy undertaking. Building the test team for a Digital Transformation project is no different.
IT teams and testers have been challenged by automated testing for decades now. It seems to me that many organisations haven’t really cracked the nut yet with regards to functional automation and many (too many) automated testing efforts fail to meet their objectives, budget and stakeholders’ expectations. Expectations seem to be lower for load and performance testing. I’m not sure if this is because it’s perceived to be more difficult or the risk is perceived to be lower or both. Either way I don’t think that’s true, but that’s for another post. There isn’t much conversation happening yet about automated security testing - yet. I find this strange considering 47% of companies surveyed for this year’s World Quality Report said that enhancing security is part of their IT Strategy. The number of security breaches is increasing – the 2018 Cyber Security Breaches Survey shows 43% of businesses in the UK experienced a security breach in the past year.
Whether a system is to be used internally by your work force or externally by your customers, it’s stability and performance directly correlates with your success.