Great! You’ve been invited to hang out at the software testers’ party, where you might finally have a shot at speaking to that cute tester you’ve been chasing.
Alas, you’re a developer and although the two roles are both “alike in dignity”, the “ancient grudge” between testers and developers has discouraged you from learning more about the other side’s ways.
In this article, I’ll quickly go over the minimum a developer should know about how testing works and its value to software development. Hopefully, any star-crossed lovers out there will finally climb over the wall that exists between them and meet on an equal level!
A cheat sheet to a tester’s heart
There is no successful developing without testing
It is crucial for any team that calls itself agile to ensure that there is a productive relationship between developers and testers. This can be achieved by setting up open communication channels where information can be shared with everybody.
Testing and developing are like two sides of the same coin, one cannot really exist without the other. How well the two coexist within an organisation has a direct bearing on how successful and effective the products launched are.
A tester is your critical eye
Checking for bugs in software needs the analytic precision of a scientist, but understanding what, where and why to check requires an understanding that goes far beyond reading through lines of code.
Great testers have the ability to cast a critical eye on your work but at the same time appreciate it from a linear and a holistic level as well. They can see options which no one else sees and perceive the effects of changes through the eyes of different user types, therefore intuition plays as important a role as logic in testing.
Testing occurs in various stages
Tests are frequently grouped by where they are added in the software development process, or by the level of specificity of the test. There are generally four recognized levels of tests: unit/component testing, integration testing, system testing, and acceptance testing.
- Unit/component testing – The most basic type of testing, which aims to verify each part of the software by isolating it and then perform tests to demonstrate that each individual component.
- Integration testing – Aims to test different parts of the system in combination in order to assess if they work correctly together. By testing the units in groups, any faults in the way they interact together can be identified.
- System testing – As the name implies, all the components of the software are tested as a whole in order to ensure that the overall product meets the requirements specified.
- Acceptance testing – The aim of this accepting testing is to evaluate whether the system complies with the end-user requirements and if it is ready for deployment. At this stage, a product is given the green light or not.
Testers should be involved right from the beginning of the project
In keeping with Agile practices, testers should be involved in the development of a new software product from the very first time all stakeholders meet to develop the backlog.
Contrary to popular perception, testing is an affordable process — as long as it happens as a long-term, on-going activity. It is only when testing is left as a short-term solution for last-minute changes that costs to the organisation start spiralling out of control.
Users’ satisfaction depends on testers doing their job properly
In a sense, testers act as guinea pigs on the users’ behalf. They prod and poke the code to make sure everything work alright and they’re usually the first to know when something is horribly wrong. Hence, testers safeguard the end-users’ experience and contribute directly to increase customer satisfaction with the product.
A tester by any other name
Would still be a tester. If you’re interested in learning more about this fascinating profession and how software testers do their job, I suggest you check out the related articles on the ReQtest blog listed below.