Why Testing and Tests?
In simple and short, we test to have confidence in what we expect to believe or claim. For example, I believe this code does what it is supposed to do in a context. The tests in the testing may help to learn that and thereby help in having confidence. Likewise, if the tests in testing are intended to prove with rational evidence that this does not work as expected - this is also a confidence in how we see the claim.
Testing and Tests:
- are highly contextual
- it depends on the person who is testing
- her/his understanding of testing and tests
- how she/he applies the testing and tests
- her/his thought process and ideologies on testing and tests
- it depends on the person who is referring to the outcome of testing
- it is highly oriented toward the expectation of the stakeholders
- on what it has to be
- on how it has to be
- on what it has to serve
If there is anything in Software Development that can be tailored to the need, I see it is Software Testing. It happens that everyone has her/his own understanding and definitions for Software Testing and how it has to be implemented and executed. And, it is done that way!
But the same is not observed with programming, DevOps, finance, sales & marketing; or, not to the extent seen in Software Testing. This is my observation and understanding. Is that wrong? That's altogether a different topic of discussion.
In the organizations, I have worked and in the projects that I have worked on within an organization, the software testing was defined and executed how they wanted it. Though they were a few common things, how these common things were implemented and understood is not the same.
Smoke and Sanity, and Test
Before I begin, here are the questions that I would want you to answer for yourself:
- Would you start with Smoke Test and then start the Sanity Test?
- Would you continue with Sanity Test after the Smoke Test? Why?
- What do you consider in Smoke Test and Sanity Test? Anything in common?
- What did you learn from the outcome of the Smoke Test and Sanity Test?
- What did you decide and what was the next action to the outcome of the Smoke Test and Sanity Test?
- What was the need if you carried out Smoke Test and Sanity Test as a different testing activities?
- How this is helping you and your stakeholders?
- What will you lose if you do not perform either the Smoke Test or the Sanity Test?
- What is the cost of doing so?
- What is your understanding of the Smoke Test?
- How did you establish this understanding?
- Any update to this understanding of yours?
- What is the coverage expected out of the Smoke Test?
- What is your understanding of the Sanity Test?
- How did you establish this understanding?
- Any update to this understanding of yours?
- What is the coverage expected out of the Sanity Test?
- Do software engineers, software companies and practitioners, and engineering teams use these terms as you use?
I learn the word "Smoke Test" comes from the hardware testing context. Then from where did the word "Sanity Test" come from? I don't know!
Further, I understand that the intent of these two words is the same. That is, to have confidence in either continuing to use the build for further tests or not to use that particular build to test.
Scope and Coverage of Smoke and Sanity Tests
What comes in the scope of the "Smoke Test" or "Sanity Test" is again the question and confusion that is being carried and passed on to the generation of Software Test Engineers. Could be this is creating a gap in understanding what it is.
Often, I have seen the scope and coverage expected out of the Smoke Test and Sanity Test are the same. Just these two words, the Smoke Test and Sanity Test are being used interchangeably in the Software Engineering community and practice.
I could not differentiate and identify the uniqueness among them to date in my experience. All I see is the words "test" and "testing" associate very well with any word you bring into a context. Later, everyone will define their own idea and words to it.
If observed, the same does not happen in the other areas of software engineering. Why? I learn that we have kept Software Testing to be far from being technical. This is one of the major setback reasons.
Software Testing is Technical
When I say technical, the programming is treated and accepted as technical; the DevOps is considered technical; the database administration is taken as technical. But the software testing which overlaps with all of these engineering areas is not considered technical.
I started my software testing career in the waterfall practice days. At times, the testing and programming teams were independent and did not interact at all. The business and project management team which got the requirement did not have interaction with testing unless for asking "can you sign off saying this be shipped.".
Today, I see the mindset of accepting software testing is technical. In my career, over the last 7 years, I see the industry is slowly including software testing to tech excellence. But it is yet to get its one common standards and glossary which will be used by all practitioners.
However, I see the software industry and communities yet to accept and acknowledge that people and context dynamics are also the propellers of Software Testing while it is technical.
A Solution to the Problem
When a subject and practice are considered technical, the ideas and how it is defined will also be taken seriously. There will be no casual language when communicating the subject, work and practice.
When I say technical, I mean it in the context of Software Engineering. How we perceive what is technical in Software Engineering, I mean that.
I wish, this comes to Software Testing and possibly put an end to the casually used language and words.
