Many misunderstandings in software testing _ Software Testing

The question was brought to mind because of several recent discussions on this subject. found that even after a few years of software testing of the old employees are more or less some of this confusion. Of course, opinion, just for the talk.

First, software testing is to ensure that the software does not fail to run

For this, I just want to say that this view is only for the good wishes of software testers. It is also impossible for a software tester to guarantee that the software he is testing can run without fault. It can only be said that in the range he has measured, the software will be able to run according to predefined requirements.

A potential problem with this myth is that testers who hold this view may be more likely to expect their test subjects to run "smoothly" rather than try to find problems in the product.

Second, the software testing environment to select the user's environment

What I want to say is: Impossible. Well, maybe for some software products with fixed user, special customized environment, you can find the user's environment well. However, for most software products, I would like to say that even if you know the environment of User A, you do not necessarily understand User B environment. Even the same one may not necessarily be the same today and tomorrow. As a result, which environment do you choose for your test environment?

The problem I want to say is that some typical environments of the user can be prioritized in the test, but the real test environment should always be the one you think will better expose the product problem.

Third, software testing automation more efficient

To be honest, I am not opposed to this point of view, but this view is negotiable. Naturally, this is contrasted with automated tests and manual tests. Perhaps there are many advantages to automation, such as the ability to take pains to perform tedious actions, to pinpoint timing movements, to work long hours, to perform quickly, and so on. But there are drawbacks to automated testing, such as the need for development costs, and the need for a clear definition of product behavior.

Speaking of this, it is conditional to take test automation. Not that it will necessarily adapt to your test, how efficient. In fact, automated testing is more applied to regression testing, and more bugs are actually found in manual tests. Although this fact is not necessarily what you want to see:

Iv. developers are more suitable for software testing

A common understanding in the test circle is that the people who perform the tests are technically less skilled than the developers, and the developers are better able to test their applications, and developers are better able to understand the development, so they can better understand the problem.

However, in my experience, the development team turned around to test the performance of colleagues is not how ideal. The problem with this myth is that it is too simplistic to look at the skill requirements of testing. In general, test engineers require three-dimensional skills: technology, Business domain knowledge, and soft skills. Technology is not only development, but also includes testing technology. People who have been transferred from development to testing do not necessarily have these capabilities, and in some ways they are more focused on developing skills, and may prefer the implementation of tools and the auditing of code. Overall, the developer's skills will certainly be fully qualified for the testing effort.

V. The more bugs, the more effective the test

It is estimated that many managers will have this view, many peer estimates are also deeply affected by the assessment of the pain. However, if you make an inappropriate analogy, say: The higher the GDP, the more effective the economy. I think a lot of people will understand the approximate.

There are many factors in the emergence of bugs, and it does not necessarily require more effective testing. It is better to test the bug than to eliminate it when it is not. The product of the bug is already to the last safeguard link, the cost has been relatively high-relative to the requirements analysis and design phase. Only in the final stage, the same situation is effective. But that's not necessarily a good measure.

This article is reproduced from the 51Testing Software test network, see more: http://www.51testing.com/html/news.html