Let’s Explore how Agile Architecture Spikes are used in Shift-Left BDD

An Architecture Spike in Agile methodologies usually implies a software development method, which originates in the Extreme Programming offshoot of Agile. It boils down to determining how much effort is needed to solve a particular problem or to discover a workaround for an existing software issue

So let us explore the benefits and see how these spike can help in improving quality and making testing easier – through shifting our attention to the left – challenging the specification at very early phase, asking questions and getting the ground ready for sensible software architecture – which will in turn improve the testability of our application under test. If you are preparing for an interview you can learn more through BDD interview questions.

More Details about Spikes

There are many benefits of spiking – to get to know the unknown unknowns, discover risks, reduce complexity, provide proof for proving or disaproving a theory. Taking a deep dive into the idea behind the solution can help in getting better at understanding potential architectual solutions and the likelyhood of will it work.

A spike is not there to provide a finished working product, or even an MVP, it’s purpse is mainly to test a theory, so even though this concept is used (in the long run) to produce working software, the code writen for spikes is often disgarded after it has served it’s purpose. Spiking usually is done by ignoring architecture styles (which might seem odd at first as it can help in discovering the righ archictectural approaches for the system we are building), coding style, design patters and general clean coding practices in favor of speed. So even though the spike may not directly produce software that will be delivered to the customer, in the long run it still helps us ship better code in the end.

Spiking is a good tool for handlign risk, by discovering unknown risks, and it provides a great way to learn and reduce complexity. A very common approach is to come up with spikes around a theory and to follow the code by a small number of simple tests. Even though the spikes are often seen as discardable code, we don’t really just throw them aside. While they don’t end up in the actual code which gets delivered, they provide useful insights and can serve as documentation to show how a certain solution was reached.

A Simple Example Let us assumen that we have a new feature we need to develop, we need to allow the users to be able to save a photo in their profile, to do that a developer can make a spike where the following could be done:

• Have the JavaScript on the Front-end communicate with the database

a. Setup a database server locally
b. Setup a NodeJS (or another server)
c. Use ODBC (Open Database Connectivity) API to connect to the DB

• Test the spike

a. Run a few sample queries
b. Test the CRUD functionality

What is mentioned in this simple example is all we need for a spike, it does not require any detailed documentation. The developer working on a spike will need to do some googling, run a few commands from the terminal, write a few lines of code for each theory. The spike would provide a posible direction for solving the challenge at hand, it can also include links for resources used, install scripts and the actual produced code to be used a blurprint. Trying things out is way more beneficial than simply theretisizing about them. The team was able to recude the risk related to this feature – in this example especially from technical integrations side and even discovered new risks such as accessing the DB using local JS!

How does this impact testing?

Allowing us to explore, spikes helps with identifying the unknown unkwonwns, so in a sense spikes are a tool for early testing (used often she shifting testing to the left). By getting answers to what works and what will not work, we avoid a lot of potential issues, and delays, by probing the requirements to distill them further. In turn, there are less bugs to report, fix, verify and keep track of. Also, the earlier the testing is done, the more economical and fast it will be.

Can QA use spikes?

There is no real reason why not to, I have seen testers use spikes to try out, and experiment, with different approaches to automating some part of the system under test, do determine the best approach. An architecture spike can help us in trying out different testing tools, such as new frameworks and libraries, give us a first hand experience of how a certain tool would behave with out system, when we try to automate some business rule, for example. Spikes are generally regarded as technical tasks (different than user stories) usually under an epic, that is in early development stages.

Conclusion

So the wrap this up, spikes in Agile are one of the tools which allows us to do what Agile is intended to do in the first place: short, quick feedback cycles give us answers early in the development process, we focus on doing and trying instead od long overly-detailed planing. That is not to say that code architecture does not matter in Agile (as we know, in Waterfall architecture is very important and usually done in the design phase), in Agile we just use a different approach. Agile practice, such as spikes, allow us to get an idea about architectural solutions that may work, as well as info about the ones that may not work.

Software produced in the above mentioned manner, help us reduce risk in our user stories, enabled the team to discover right solutions using collaboration, constructive discussion, frequent experimentation and compromise. In a informal sense, a lot of people happen to be using spikes without even realizing it! As long as you are trying to identify the unknown unknowns, have short feedback cycles and you’re trying to determine technical and also functional risks, you are doing Agile. Spikes will help us in situation where we are not certain about the requirements and if there are a lot of unknowns and answers that need answers.

Mirza Sisictester

Mirza has always been a technology geek, helping friends and family with computer-related issues. Started in tech support and moved to software testing. Mirza worked as a freelance web developer for a while as well. When he’s not sharing memes online Mirza is usually learning new things, writing posts for his blog, and being an active member of the testing community. His site: https://juniorlearnstocode.blogspot.com/

See author's profile