Over the next 5 - 6 weeks we will embark on a journey. A journey to take a look at "The Five W's of Testing." This journey will take us through the Who, What, When, Where, and Why of testing our applications. We will also look at the 6th man of the equation, The How. This series is geared to all levels of skill. I hope that everyone can take away a new piece of knowledge from what we discover.
If you have touched a piece of code you have undoubtedly heard of testing. There are a number of Testing Methodologies that we as developers employ on our various projects.
Shall we begin?
Let's dig more into what this chapter is about, The Who. Not the band, although those guys are pretty epic as well, dare I say even more so than testing.
The Who I'm referring to would be...us, developers. Be it new developers just getting their feet wet or seasoned developers who have been practicing the art of testing code since day one.
At least that's what the typical testing demographic is portrayed as. Over the years it has become very common to see BA, QA and an even more focused QE role helping to build automated test suites for our applications.
One of the biggest advantages of having these roles help with the testing initiative, is their uncanny ability to try and break our code. As developers we, generally, code to Acceptance Criteria that is defined by our Product Owner(s)/Stakeholder(s). We usually do our testing around those defined criteria. The roles we mentioned above have been taught to think outside the box, to create edge case scenarios that we as developers likely would not have thought of. This generally leads to fewer bugs making it into production in most cases.
Some opinions would suggest that having these specialized roles take part in the testing process is not warranted. Having to rely on another group to test our application is just another lane in the product life cycle, after all the engineers are TDD/BDDing the application right...? Why would we want to have another set of folks verifying that the application works.
Utimately "The Who" of testing comes down to how your team is structured and the Agile methodologies you have in place. Ideally anyone on your team can "test". Testing is defined, in a nutshell, as the process of determing the quality of an application to provide to stakeholders as well as the discovery of defects or bugs. Testers are not limited to specific roles within your team structure. Keep this in mind the next time you are down to the last few days of an iteration and you need a few extra hands for testing.