After introducing Functional Test Automation to the entire platform in one of my past projects, as an organization, we started to realize the need of starting some sort of performance testing. Teams were already starting to get the benefits of using BDD as a framework, especially from the conversational perspective (between the different roles in the project), and, I thought: why not introduce performance testing into the same discussion? Yes, Performance Testing and BDD. Follow me into the next paragraphs to understand why two apparently different topics can actually mix.
Why I really like BDD
I consider myself to have been lucky enough to have had the chance to see proper Behavior Driven Development working dynamics from an early stage of my career. BDD is much more than writing some Given-When-Then keyword based Test Automation scripts (an idea from which many critics of the framework never get beyond). It’s a powerful tool to drive healthy communication habits inside teams, mixing 3 different perspectives: the actual code, a quality vision and business needs. On each deliverable, teams successfully balance the 3 and reach an agreement which sits at the basis of a fast, stable and consequently reliable SDLC. The beauty of the agreement is the mix of perspectives, and the fact that it’s living and executing next to the runtime code. Consequently, the beauty of BDD is that it raises awareness and interest in other aspects one might not be involved in, creating a general feeling of end-to-end ownership.
Problems when starting Performance Testing
Performance – one part of Quality that it’s generally mistreated and forgotten until very bad things start to happen in an organization, because of various reasons:
- Functionalities are thought for one user. Period. Product focus is generally on the User Experience, and it’s missing its plural.
- The low frequency of tackling performance in a typical conversation during grooming or development itself (between people with different profiles: Developers, QA, Product). The mix of complexity of functionality, priority of different projects and daily work sometimes just doesn’t help for this conversation to start out of nowhere.
- Except for modern organizations, if there is a Performance Testing activity, it’s done by a specialized team, either on demand, asynchronously or at a late stage during development, very close to releasing.
- When starting with Test Automation in an organization, the primary focus is generally raising coverage of the Functional part, leaving Performance for a much later stage.
- The fear of the unknown: different tools, programming languages, approaches or philosophies, make different professionals leave this activity for sometime later. Mañana.
Isn’t there any other way of solving all of these problems?
Mixing BDD and Performance Testing, and making it a thing
Understanding the promises of BDD, and the struggles of kicking off Performance Testing, can make one think beyond the usual. What if:
- BDD is extended, and next to the existing scenarios, we start seeing references to multiple users?
- Performance “Behavior” is discussed from the very beginning, and the “agreement” consists also of response times?
- Product starts to naturally understand Site Reliability aspects of the Platform, and even asks for projects of improvement?
- The team which develops the functional code, also is aware and looks after it’s performance and invests in improvements?
- Performance Testing can reuse all of the existing Functional code and infrastructure, including living in under the same repository or folder?
- Performance Testing is just another simple step in the CI/CD Pipeline?
- Covering a functionality with automation starts to mean also covering Performance?
If any of these questions has brought a smile, a spark of motivation or has made you day-dream for a while, it means that there is a match between BDD and Performance Testing, there might just be enough reasons for us to make it happen, and that it can just be a perfectly functioning mix.
And this is how project pretzel has started. Stay tuned, in the next article I’ll write about how one can technically tackle that inside the Java ecosystem.