Testing needs to change

Abraham Lincoln once said:

“The dogmas of the quiet past are inadequate to the stormy present. The occasion is piled high with difficulty, and we must rise with the occasion. As our case is new, so we must think anew and act anew.”

To tackle the changes in the development processes, testing must grow along with these changes. The shift in most companies is from waterfall (or traditional) development to Agile development. To enable this growth, testing should go from an industrial, manufacturing model towards an agricultural model. You cannot predict the outcome of testing, you can just – like a farmer – create the conditions under which testing begins to flourish. Keep in mind that you can predict the outcome of a single test, but not of the complete testing process. To make testing flourish, you need to adapt testing to the context. In some settings it seems enough to reform your testing, but in most cases a transformation is needed.

I advise starting with a clean slate (transforming) over changing your current process (reforming). Aligning with the new context is easier when you are not bound by decisions made in the old context. Start off with thinking about what you need and not what you have! So what do you need? Your context can have a lot of (conflicting) demands, such as:

• Short time to market
• High quality
• Low costs
• High auditability

From these demands, look at efficient and effective ways to arrange your testing process along with the development process. You must not only find out when to test what, but also how this testing should take place. Do you still need the process driven testing, with testing techniques to get you test cases that can check if the product meets its requirements? Or do you need exploratory testing to validate that you built the right product? Or do you need both, or other approaches?

In my opinion you need to look at your product from multiple angles. So in your process, you should find a combination of approaches that best fits your needs. None of the approaches is completely wrong or right, they are just different. So why not try to take the best of all worlds?

Advertisement

How to sell software testing?

In the last two months I was testing software for Enrise via Polteq as a part of their development team The Impediments. Testing for them has been nice and instructive. The people at Enrise did not stop asking questions. Most of the questions I answered immediately, but some took a while to find the right answer. The question that lingered the most was: “How do we sell software testing to our customers?” I have to say that I’m very glad that Enrise asks this question! It shows me that Enrise sees the value and the importance of testing. The high quality software that Enrise delivers, can only be delivered when there is time set aside for software testing.

So how do you sell software testing?

• Sell a project (testing is part of the project).
• Only provide guarantee for production incidents when the customer pays for testing.
• Make the customer aware why you value testing.

Basically, you do not sell testing, you sell quality!

Software development is practiced in teams. Testing is a set of tasks that need to be executed in the teams, so there is implicit time for testing. You need to see that testing is essential to quality software and the time needed to test has to be allocated. The software may appear more expensive to your customer, but this will pay off! In the long-term, you will see less disturbances of production when the software is professionally tested. Investing in quality up front is worth it.

You’re probably thinking: “How will testing add to the quality?” Well, in many ways… I’ll give you three:

1. If you plan to test, you will need testable requirements. Ask questions on user stories until you have clear what your customer actually wants to have. Developers usually make more assumptions and think about the solution, where testers think about value for the customer. More questions in the beginning will result in an easier development process and a smaller chance on defects.
2. A tester tests software instead of checking if the software works. A customer will use the software to see if it works, where the tester tries to find the edge cases and out of the box situations. A negative age is an unlikely situation, but a typo in a birthdate is quite plausible… The tester thinks of these situations, so when these typos arise in production the situation has already been covered.
3. Testing is about mitigating risks. This implies that the risks need to be identified. Testing will create a better view on risks. So even risks that are not mitigated, can be communicated to the customer. Then it’s up to the customer to decide what to do: Invest more to mitigate these risks, or live with the risks?

In short: if you want quality products, you really need to test!

*This blog is also posted at Enrise