Quality with Minimal Testing – Q&A with Pete Walen

**This is a follow-up Q&A blog post, following the guest webinar session Pete Walen gave as part of PractiTest’s Webinar Series. 

Achieving quality with as little “testing” as possible

We are all witnesses to a large amount of talk and chatter around expanding testing outside of the traditional realms and boundaries of our profession. 

Some people call it “shifting left” and “shifting right”, others talk about concepts such as “testing in production”, and it is hard to imagine anyone with access to the Internet who has not heard about “All team Quality” or “Achieving a Quality Culture in the Organization”.  

These are only some of a large number of terms and approaches being talked about today as expansions of testing and methods that can help teams work more efficiently, better, and even faster.  But they are not directly related to testing… Or are they???

In their recent webinar session, Pete Walen and Joel Montvelisky analyzed some of these concepts by reviewing how they work, how effective they can be, and by explaining some of the common mistakes made when failing to apply them correctly.

The webinar’s Q&A portion was worthy of its own place and time, and so this following post was born, where Pete Walen addresses many of the questions that came up during his session. 

To view the original webinar session the questions relate to, go here 


Question 1:  We’re always talking about the critical points of testing or how quality can be ensured as much as possible. But what about the quality of the tester? Do you think as the demand rises for testers, more and more people become testers regardless of the required skill set?

[Pete]  Thoughtful testing, the work that goes beyond checking “expected results” and “acceptance criteria” is hard to learn. It is hard to teach when people are not open to the idea. 

People going into testing do so for a variety of reasons. Many simply because they need a job. There are a lot of reasons why someone might be a poor quality tester. Most will do precisely what they are told to do and be satisfied to get paid. Some will look into doing things better and hoping for a promotion. 

A few will go out and learn things on their own. They will explore and make themselves better craftspeople. These are the ones who move things forward and ask questions about why things are done the way they are. 

The problem I often see is organizations that take an approach that testing is a check-box activity. It is up to organizations to change their approach and adopt a  true quality culture for making software. 

If the ONLY testing being done is that against executable code there is no real relationship between testing and quality. No amount of testing software after it has been coded will make it a quality product.

The point of “Quality” with as little “testing” as possible is to apply the critical skills of testing to every aspect of the development process. From the original request, through the requirements identification and discovery on through to design and code. 

 

Question 2: In these times of pandemic, do you think quality or specifically QA as a role will be given importance in software companies?

[Pete] I think for many companies, the idea of quality and testing are important for different reasons. The challenge now, in 2020, is that the expectations are all changing. The easy to measure checkpoints are proving to be less valuable than they were seen to be even last year. 

I think the better companies, the ones with thoughtful leadership and broad thinking will find a way to do things differently. The best companies will find a way to excel. For them, good quality practices will be absolutely vital.

 

Question 3: What are your opinions on cross-functional scrum teams including UX/UI and Ops people into every team?

[Pete]: Fully staffed, cross-functional teams that have every specialty area represented are a bit like the Golden Fleece – everybody thinks they are a fantastic idea and really wants one. Then they try to pick it up and find out how heavy the golden fleece is. It is a very expensive proposition for most companies.

In an ideal world, I’d love to see teams with all the expertise they need as part of the team. Most companies are not in a position to make that happen. Really good specialists are expensive. When people run into problems with the specialists not being available, I suspect there is another problem going on. 

 The challenge often is expressed as they (the experts) are “never available” when they are needed. In my experience, if you let them or their manager know you will need help, and a rough estimate of when – long before you actually need their help – they often can be very accommodating and will do their best to help out.

If you DO have them embedded with your team, and they are good at what they do, then rejoice and be glad.

 

Question 4: What’s the most interesting bug or unexpected outcome you’ve seen in your career?

[Pete]: This took me a minute to think about. My initial response was – “Nah. Most of the stuff is pretty mundane. Loads of people have found way cooler bugs.”

Then I remembered the “System Health Monitor” tool I was testing several years ago. The idea was there would be a small bit of code running in the background on the hosting server (or servers.) It would do things like periodically check the state of the file system or DB system. It would also check the state of the system itself, memory, performance, and so forth.

If something were to be outside specified parameters, it would start issuing messages for someone to act on. 

Pretty cool stuff for the time.

I was working away exercising this. I had manipulated the test server environments limiting available file space and system memory. IT took a fairly long time to get this set up just right, and resetting it was an equal pain. One day at the end of a rough work week, while I was testing this tool, a couple of co-workers stuck their heads in my test lab and “encouraged me” you join them for end of the week relaxation.

That sounded much more fun than resetting servers I would need to change again the next Monday to continue the tests. So I left them exactly as they were.

I came in the next Monday and the test servers I was working with were all down. All of them. There was nothing running on the mat the time except the “Health Monitor.” That was how I found out that app had a memory leak of its own. If I had not let it sit and run in the background, I likely would not have noticed.

 

Question 5: Is there any guideline to achieve Quality by adopting 80 x 20 rule with minimum testing?

[Pete]: Not that I have seen really holds up. No two organizations are the same, no two teams are the same. All situations are different. Practices from one team may not help another team, even in the same company. 

What I have found to work is talking with the developers and BAs and PMs about being in the very earliest meetings. Mostly to observe, but also to learn how the project ideas are discussed at the very beginning. Then, using careful analysis, look for gaps within the documented results from the meetings. Ask questions aimed at furthering your understanding, which, hopefully, will lead them to explain in greater detail and possibly find flaws in their own thinking. 

Experimentation is the key.

 

Question 6:  How to be kind to developers?

[Pete]: It helps to not tell them they did something wrong. It helps to not berate them for bugs in the code. Everyone makes mistakes and misunderstandings will happen. Recognize that they might not have made the mistake. They may have been given instructions that were wrong themselves. They might have easily been given bad information. They might also have not made the mistake. The tester could very easily have made the mistake as well.

Oh. Bring them sweets or baked treats from time to time.

 

Question 7 a:  Any suggestion for Manual Seniors Leads … what areas they need to work on … how they can jump into automation \new technologies?
Question 7 b: As a QA Trainee Sir what would you prefer to do to improve or groom ourselves in this field?


[Pete]: No matter where you are in your career, it is your career. Your employer is not the one to teach or train you what you need to do. When I’ve been in a position of looking to grow my career or shift into a different type of role, I’ve looked at a variety of sources of learning.

Books, blogs, online training courses all can provide essential learning for you, no matter where you are in your career. There are low-cost options available, many of which can point you to low-cost or free (legal!) versions of the software or tools the course will teach you about. If you are in a position to pay a bit more for training, there may be a code boot camp type of learning available near where you live. 

This might not be precisely what you want to learn, but it will help you understand things better and might lead to the promotion you seek, or the new position doing this work.

 

Question 8: How do you change developers’ minds on testing?

[Pete]: I presume you mean developers don’t think very highly of testers, even very skilled testers. Without knowing more about your particular situation, I will instead make some general suggestions. These are very similar to what I suggested in the question just above.

Learn some of the fundamentals of the language they are working in. Learn the fundamentals of the DB system involved. Learn to write basic SQL queries to help you predict your testing results.

Consider how you, as a tester, can add value to the product and work your company makes. Can you work beyond what some developers tell testers to do? The “This is how you should test this” is a great help for testing. It tells us, as testers, what the developer thinks is important. 

That is a good start. If you can read and understand the notes made along the way, for example, code snippets that may be referenced in work tickets or work items, you can move beyond what the developer suggests you test. Then you can find ways to test the software they had not considered, and you help them look good as their software has fewer and fewer bugs in production. 


About Pete Walen

Peter G. Walen has over 25 years of experience in software development, quality, testing, and agile practices. He works hard to help teams understand how their software works and interacts with other software and the people using it. He is a member of the Agile Alliance, the Scrum Alliance and the American Society for Quality (ASQ) and an active participant in software meetups and frequent conference speaker.

 

About PractiTest

Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.

Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.

With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.

No comments yet.

Leave a Reply

shares