Quote:
Testers will be looking at the application and it's behaviour and i don't think the tester need to through the code & try to understand the system. It doesn't work.
Actually when done properly it does work and those black box testers who have a high-level knowledge of the code behind what they are testing are generally better testers than those who don't understand any of the program internals.
In regards to test planning, understanding the high-level internals of the code + decision paths in the software is the only way a truly effective functional test plan can be created. What this knowledge also provides is the ability to reduce the test effort yet still obtain same coverage.
For instance let's say an app has both a thin and fat client. The thin client has a subset of the fat client's functionality. Not spending any time to investigate the code will result in duplication of testing because in reality all the functionality sits on the server side. Let's say the app has query operation. In a given week one would generally not want to execute the query test cases on both the thin and fat client because it's duplication of testing i.e. the same code on the server is being called. What would be much more efficient is to simply put the clients on a rotation i.e. one week test query functionality on thin client and next week test it on the fat client. And each week an acceptance test is run on both the thin and fat clients for added insurance + the fact there are of course differences in the "route" a query requests takes depending if it's initiated from a thin client vs. a fat client.
I know there are some who would disagree w/ this testing strategy but you have to take chances and risks during a project. I would say this would not be my strategy near key milestones...Beta and during the last few weeks prior to shipping but I'd feel comfortable with such guidelines for rest of the project. Without any knowledge of the code though I'd be totally uncomfortable with this and would simply request the test team to test everything every week.
This is how even a small amount of knowledge about the internals of the application can have a big impact on efficiency and quality.
这个回帖谈了Disadvantage:
I think the answer the original poster was looking for was "black box testing".
In your example, thekid, even someone with no knowledge of internals would be smart enough to test both a thin and thick client.
While I generally feel no knowledge is wasted, there are both advantages and disadvantages to having knowledge of internal code. Some of the diadvantages are exactly the same as for programmers. Just because you know what's there doesn't mean what's there is correct. Someone with this knowledge can focus too much on validating what's there instead of validating what is supposed to be there. I know plenty of programmers that reduce their testing coverage because they "know" what their stuff touches. It's amazing how many errors we find in their code .
I have people on my staff that are code-savvy and people who are not. There is little difference in terms of value to the organization, as they tend to "miss" different types of errors. The key in my organization has just been to deploy people according to the needs of the project and their skill sets.
有句话说的很好：
Just because you know what's there doesn't mean what's there is correct. Someone with this knowledge can focus too much on validating what's there instead of validating what is supposed to be there.作者: qinmei 时间: 2007-8-10 16:17
说的都有道理，
第一个的意思是你懂一点代码，至少可以避免一些重复劳动。
我觉得如果你懂一点代码，可以更加有效率的抓住一些bug，曾经我的一个developer跟我说过，对于计算机程序，有些你是可以trust，有些你不能，比如你要测一个函数，程序要先取来某些变量然后计算得出一个结果。最容易出问题的部分其实是他取的这些变量对不对，真正计算的过程倒是不容易出错的。我觉得很有道理。
第二个回帖给我的启发很大。因为我也是开发转测试，我也会习惯性的以开发的思维去测试，就象文中所说，focus too much on validating what's there。
支持,最低限度要能看懂...