Manual scripted testing is the oldest and most rigorous type of software testing. In this particular type of testing, test cases are designed and reviewed by the team before executing it. There are many variation of this basic approach, test cases can be created at the basic functionality level or they can be created at the scenario level.

Value of the scripted testing has been questioned by many experts in the field and they consider scripted testing as a waste of resources, in most of the situations. They claim that scripted manual testing closes the mind of tester and inhibit them to use their creativity. Also, this approach is very heavy on the documentation and require considerable amount of resources to create the test scripts in the first place and they often get out dated because of the inevitable changes in the system.

Despite these drawbacks, manual scripted testing is used in many organizations of all the sizes. They make test cases repeatable and easy enough for a new person to come on board and start testing with minimum supervision. Manual scripted testing is also used in places where contractual agreement states that written specification of the software must be met for the successful implementation of the project. Scripted test cases might be useful where tests are used for the benchmarking purpose and tests have to be executed exactly in the same way, every time.

Since in manual testing test cases are created beforehand, it can be assumed that testers have knowledge of the system. In most of the cases, this knowledge is often theoretical, and various documents like requirement documents, functional design specifications and so on become the primary source of information for the testers.

Effective testers working in this type of scenario can use supplementary sources of information to increase their knowledge of the system by discussing with development team, by comparator product or by earlier knowledge of testing similar system and so on.

This type of testing is mostly seen in places where a waterfall methodology along with the V-Model is followed. This approach is also suitable for projects where requirements are frozen and likelihood of changes in those requirements is very little. This might also be suitable for the situations where safety or regulatory situations demand proof of testing in this particular way.

Generally, this approach is considered old and is relevant in very little situations in the current era of market driven applications.

Organizations following this approach must evaluate, if there are any compelling reasons to use this particular approach over others. If they struggle in finding the answer, may be there is a need for change.