We’re fortunate in testing that we generally follow a well-defined process, have clear role definitions and test tools to support us. Our test tools record activity, manage planned and current activity, and support communication between teams and individuals. This is in the form of bugs and passed & failed tests. The process is there to steer us safely through difficult periods of a project when many people around us may be making irrational decisions.
Topics: Software Testing
I’m not sure why but automated security testing is, without doubt, the poor relation to all other types of automated testing. The software testing industry has been trying super hard to automate functional testing for well over 20 years – and the results have been patchy at best. I see all sorts of attempts but it’s rarely questioned as a sensible aspiration, even in situations when the return on investment (ROI) is nowhere to be seen. We relish the thought of automating unit tests and even have whole conferences dedicated to test driven development. Automated integration testing is considered an absolute necessity for DevOps and Continuous Integration (CI). We absolutely love to have automated build, deploy test capability. Unless performance and load testing are automated we don’t even consider doing it. We even have automated code review tools. Why is it then that whenever I recommend automating security testing to my clients, it feels like I really have to sell the idea. More often than not, they choose to do it manually. And I’m always surprised when they do.
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.