There is no such testing type exists which will tell you the name for not "Understanding the code".
If you are not doing the reviews, debugging of the proc. etc. or don’t want to see the actual coding logic written and trying to concentrate on the "Functionality" only then it is called "Black box Testing”.
[ QUOTE ]
Junior Tester no need to know about the code of the program.He should know the application very well its, functions navigations,integration. Whether it satisfy the specifications or not ?
requires knowledge of user interface / functionality / requirements only, does not dig into the code at all.
[ 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.
[/ QUOTE ]
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.
Reserve a few months every so often and preview retirement throughout your career. You won't regret that a 35 year career was reduced to 34 years to take vacations measured in months in order to remember what a stress and care-free life is all about.
Books and hard work will get you anywhere you want to go.
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 [img]/images/graemlins/smile.gif[/img].
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.