"5 ways to Revolution your test QA" reading notes

A few days ago on the internet to see someone else's recommendation, under the electronic manuscript has been put not to see, today has time to read again, or a little harvest.

In this article, the author gives five suggestions for improving the software testing department.

1.There is types of code and they require different types of tests.

The whole software consists of two code types, and the two code types are tested with different test methods

(Note: I can not guarantee 100% correct, if there are errors, welcome to correct)

This is about choosing different test methods for different test content. Here the two types of code refers to experience code (the user's operation, function, characteristics, etc., I understand the code of the presentation layer) and infrastructure code (refers to the underlying, my understanding is the logic layer and the database interaction layer Code, This code is the user does not see the results of execution, unless there is a serious error in the foreground will pop up the message box error). Experience code to more manual testing, because this layer of code effect only with the naked eye to be more accurate, that is to say this part of the code, if the use of automated testing out of no problem, does not mean that we can be relaxed about this part; infrastruct Code to use more automated testing, set the variable to see if there is any problem.

2.Take your testing down a level from features to capabilities.

Lower your Test level from feature testing to functional testing.

Light look at the characteristics of the test, the feeling is not very clear, there are many people may not be able to start, but if a feature is transformed into a number of functional points affecting this feature, then the analysis is good.

The author mentions that their team adopt component-feature-capabilities, I to component this word still can't grasp exactly what meaning, my understanding to this is that the system is divided into modules first, Then the abstract characteristic description of the module is decomposed into several definite function points to analyze.

3.Take your testing up a, from test cases to techniques.

To elevate your test to a level, from test cases to test methods

When your test results appear failure, you can't just look at the case and the results, but you should look at the problem from a larger scope, combining the purpose, content, strategy, and end result of the test to summarize a big problem that can lead to other problems. For example, a case Discovery program to the page of the jump in 0 when the problem occurs, then can be inferred that the system may be the page jump input characters of the illegal situation is not handled correctly, so as to draw out other possible problems: input non-numeric, decimal, etc.

4.Improving development is your top priority.

The understanding of this sentence, after reading the following article I think it should be translated into "to improve the development of the Department as the highest priority"

In the article there is a saying: the development of a good software is not testers, but developers, in order to ensure the quality of software, it is necessary to improve the ability of developers.

Think about it, and if the developer is more capable, the bugs will be less and easier for us testers. So we testers do not repeat every day to operate those test cases to find the bug is done, but through testing to tell the developers what the problem they are facing, they in the process of solving these problems continue to improve themselves, and constantly improve the quality of the software.

The author quoted a person in the article, see the following sentence should be able to better understand the fourth proposal, I do not translate, in order to avoid mistakes fraught.

"The real value of tests is not this they detect bugs in the code, but that they detect inadequacies in the methods, Conce Ntraction and skill of those who design and produce the code. "

5. Testing without innovation is a great the to lose talnet.

The lack of creative testing is very easy to lose talent.

For many people, testing is a tedious task, running test cases repeatedly, clicking and clicking to find bugs. But the real test personnel do not spend a lot of time on the test, but in the continuous analysis and test to improve the test strategy, the latter is the interest of the test.

The above is the harvest after I read this article. I think I like to write a test document more and more, in the early analysis, design testing, the choice of testing tools far more interesting than the implementation of the test. Looks like I'm moving towards the master, hohoho~~.