blog on bus software testing

Black Box Testing

Shallow Testing and Deep Testing seem unhelpful terms to anyone outside of software testing. What do you think?

Like many young children, my niece Emily was a little scared of going into the ocean. It was a beautiful Irish June day, and my mother could see she wanted to join all the other children splashing about and having fun.

charrett black box testing

She took her by the hand and led her into the water.

Shallow water can be very deep for some people. 

There’s been some discussion about deep and shallow testing. While perhaps these distinctions provide value to people immersed in our craft, the concept of splitting testing to deep and shallow doesn’t make a lot of sense to our stakeholders, the people who matter.

Most of us are familiar with some form of  risk matrix matrix which categories risk into impact to the business and probability/likelihood of failure. We associate valuable testing with the red high range, yellow should test and low, nice to perform testing. For example, if the impact of the test is low, and the likelihood of a threat to quality being discovered is low, then ‘meh’ test if we have time. 

risk based test management
Risk Based Test Management focuses on prioritising tests in the red square.

Where does deep and shallow testing fit on this matrix? Well if you think of impact to a business user, then surface GUI testing is critical to them, so impact HIGH. The probability of failure? That too is contextual. It depends on the quality of the person coding, the clarity of what’s been asked for. But even if we are pretty confident that there is little probability of failure, it’s still in the ‘should test’ bracket due to the business importance. So business importance trumps probability. 

Black Box Testing
Drawn on the bus!

Shallow testing is critical for business people. To call this testing shallow, negates the relationship we have to our customers and our business. 

If we want to classify our testing, I suggest we do so in terms of how our business perceives it. System Testing, Functional Testing. Black Box and White Box Testing are ways of describing this testing without the inference of trivialness. 

What do you think? 

For initial thoughts on shallow and deep testing go to my blog post on Shallow Testing gets a bad wrap

Or try something different – Quality is a journey 

By Anne-Marie Charrett

Anne-Marie Charrett is an internationally recognized expert in software testing and quality engineering.
She keynotes at international conferences on the topic of Quality, Coaching, and Leadership.
Ex-Head of Engineering at Tyro Payments where she transitioned testers to a quality coaching model
Consultant on Quality Engineering, developer of the quality operating model. Invented and rolled out a consulting model for quality engineering.
Consulting across FinTech, Media, Government, Insurance, Banking & Telco Sectors
Creator and Lecturer of Enterprise Software Testing course at UTS Australia. Co-developed a coaching model aiming to transfer testing skill and know-how using the Socratic method.
B.Eng (Hons) Electronic Engineering (I really am a quality engineer!)
Based in Sydney, Australia works – internationally.

2 replies on “Black Box Testing”

Thanks for sharing this blog posts. Very informative to the beginners. Nowadays more job opportunities are there for software development and software testing. So achieving training for software testing is not a wastage of time.

Leave a Reply

Your email address will not be published. Required fields are marked *