Eight things you don't need to test in software testing _ test

Don't test it.

As a software tester, we may ask ourselves a lot of questions:

We can immediately execute what the best software tests are.

What the software test method I'm going to use.

Is this a bug?

Have I finished the test yet?

But how many of us are going to ask the following questions?

This component needs to be tested all the time.

Do I have to test it?

If it doesn't work, who cares about it?

In my opinion, the questions we have raised are similar to those of the above three questions and are far from enough. Maybe that's because we've been told to test everything. Even some of our people have a process in their quality team that requires someone to label each component "tested." We treat testing like a regular factory process, and we sometimes proudly say ...

"I'm a test engineer. So all things need to be tested ... I'll do it. Even if the non testers have already tested ... Even though I already know it will pass the test ... Even if you need a program member to tell me how to test ... I have to test it, no exceptions. ”

Such ideas may give testers a bad name. Due to the lack of thinking process, it emphasizes the importance of software testing, rather than providing some people with the most valuable information services.

James Bach came up with the following test points:

Basic point of view: "If it exists, I'm going to test it."

As in the previous article and in my frequently published articles, I disagree with this view. Nevertheless, I fully agree with James on August 7, 2006, in his full version of the blog post, on this part of the introduction:

"If it exists, I'm going to test it (the only exception is that I have more important things to do)"

The second sentence is that there are many ways to understand. Why, then? Because we often have more important things to do, usually another test work. Unfortunately, the importance is often not distinguishable clearly. So instead of measuring importance, I prefer to ask the top three questions to look for things that might not be worth wasting my time trying to test. Here are eight examples of what I'm talking about:

1. Components that will not appear in the product-my team has these in every iteration. For example, to enhance the error logging in the function or to track the review report in the production activity. These are grouped into the developer user stories (Developer user Stories) in the Agile development team. These content does not appear casually in the product and because its nature does not directly affect the user.

2, the key product problem patch will not be very bad-one afternoon customers to our technical support phone call, due to our products a blocking nature of the bug caused them to miss a critical deadline (deadline) of the edge. We only have one hours to deliver the repaired product. The programmer quickly fixes the problem, because the current product is not valid, so it is negligible for the risk of further product being repaired. Want to be a hero? Don't let things slow down. Quickly let the product pass the test. If you need to test again later.

......

This article is reproduced from the 51Testing Software test Network, view the full text: http://www.51testing.com/html/43/n-809343.html