How to think about testing as a developer
Here is the video version of this article:
High level view
In any project, there is an area called Quality Management that has two main activities:
- Quality Assurance - mostly means measuring quality via various processes and tools either during the production and/or looking at the end result
- Quality Control - making sure we have processes in place that will guide, verify and change the organisation and in-place processes to assure a certain level of quality built-in
From this perspective, Testing is the outcome of a Quality Control decision and is an activity part of Quality Assurance.
When doing side projects, for example, Quality Management is informal, and you mainly represent it. You decide (or not - but still a decision) what quality you want to have and how much, if anything, you want to do about it.
I will not go too deep into the Quality Management process, but it is good to know that testing is not just dropped into a project. Still, it should be part of a bigger strategy that looks into how much time/effort/money/people the organisation want to put in and how in order to get to a specific level of quality of our building process and the quality of our end result.
Let’s focus now on how developers should see testing and what can it bring to them.
First, what is testing?
There are multiple definitions of testing.
Let me share some of them here for a good and informed starting point when considering testing and I will comment on them while trying to extract key points.
Making sure the software is predictable and consistent
Software testing is a process, or a series of processes, designed to make sure computer code does what is designed to do and, conversely, that it does not anything unintended. Software should be predictable and consistent, presenting no surprises to users.
I like this definition because it does not even use the words bugs, errors and we can focus more on what expectations we have from our code:
- To be predictable
- To be consistent
- To catch surprises or unexpected behavior
Key point As a developer, I should assess if the execution of my code is predictable and consistent.
Key point As a developer, I should make sure that my code will only return expected outcomes/outputs and there should be no surprise.
Verifying the correctness of functionality and finding defects
Testing is both a constructive activity in that it is verifying the correctness of functionality, and it may be a destructive activity in that the objective is to find defects in the implemented software. Testing verifies that the requirements are correctly implemented, and it yields the presence or absence of defects.
Key point As a developer I should verify that requirements are implemented
Key point As a developer, I should check that there are no hidden bugs or cases improperly handled by my code by testing invalid or out-of-boundary inputs, logic, or state
The “destructive activity” part is a good point of view to keep in mind while writing tests and could drive the effort also to execute/find test cases that might break the code/logic/app.
Comparing what-is with what-ought-to-be
At its core, testing is the process of comparing "what is" with "what ought to be."
Key point As a developer, I want to verify that what was requested is what I implemented => my code works the way it is expected
Why do we test?
Based on the definitions above (and many more), it is good to define testing from the perspective of developers.
We test because we want to:
- Verify that requirements are implemented correctly (what was requested is what it was implemented)
- Check that the software behaves predictable and consistent over time (taking the same inputs and initial state, it should give the same result every time)
- Specify the current behavior to improve maintainability
References
[Mayers, 2011] Glenford J. Myers, Corey Sandler, and Tom Badgett. 2011. The Art of Software Testing (3rd. ed.). Wiley Publishing. DOI 10.1002/9781119202486
[O’Regan, 2019] O'Regan, Gerard. “Fundamentals of Software Testing.” Concise Guide to Software Testing (2019).
[Copeland, L. (2003)] Lee Copeland, A Practitioner’s Guide to Software Test design - ISBN:158053791x
#goodenoughtesting #subscribe #email
Get free samples and be notified when a new workshop is scheduled
You might get sometimes an weekly/monthly emails with updates, testing tips and
articles.
I will share early bird prices and discounts with you when the courses are ready.