Lacking or Poorly Written Requirements
If needs are lacking or poorly written, then the test team must have a defined method for uncovering and defining test objectives.
A test objective is simply a testing “goal.” It is a statement of what the test team or tester is expected to accomplish or validate during a specific testing activity. Test objectives, usually defined by the test manager or test team leader during requirements analysis, guide the development of test cases, test scripts, and test data.
Test objectives enable the test manager and project manager to gauge testing progress and success, and enhance communication both within and outside the project team by defining the scope of the testing effort.
Each test objective should contain a statement of the objective, and a high-level description of the expected results stated in measurable terms. The users and project team must prioritize the test objectives. Usually the highest priority is assigned to objectives that validate high priority or high-risk requirements defined for the project. In cases where test time is cut short, test cases supporting the highest priority objectives would be executed first.
Test objectives can be easily derived from using the system requirements documentation, the test strategy, the outcome of the risk assessment, and the test team assignments. A few techniques for uncovering and defining test objectives if the requirements are poorly written include brainstorming and relating test objectives to the system inputs, events, or system outputs.
Ideally, there should be less than 100 test objectives for all but the very largest systems. Test objectives are not simply a restatement of the system’s requirements, but the actual way the system will be tested to assure that the system objective has been met.
Completion criteria define the success measure for the tests.
As a final step, the test team should perform quality control. This activity entails using a checklist or worksheet to ensure that the process to set test objectives was followed, or reviewing them with the system users.
Changes in Technology
Effective testing must be done by a team comprised of information services professionals and users. In corporations where the users are not readily available, i.e., they are in a remote location, a professional test group can represent the users. Also vendors of software may not be able, or may not want to have users testing their systems during the developmental process.
Again, in these instances, a professional test group can represent the users. The test group is known by different names, including IT testing,.
The following technological developments are causing organizations to revise their approach to testing:
1 • Integration
Technology is being more closely integrated into day-to-day business resulting in business being unable to operate without computer technology. For example, the airlines can only take reservations when their computer systems are operational.
2 • System Chains
Computer systems are interconnected into cycles of chains such that problems in one can cascade into and affect others.
3 • The Domino Effect
One problem condition, such as a wrong price or a program defect, can cause hundreds or even thousands of similar errors within a few minutes.
4 • Reliance on Electronic Evidence
With hard-copy documents being removed from processing, the validity of the transactions is dependent upon the adequacy of controls, and thus a control error may result in extensive losses.
5 • Multiple Users
Systems no longer belong to single users, but rather to multiple users, making it difficult to identify a single organizational unit responsible for a system.
The organizational approach to testing commences with a policy on testing computer systems. The policy should be developed under the direction of the IT department, but should represent the philosophy of the entire organization. Once the policy has been established, then the procedures and the methods of testing can be developed based upon the desires of management as expressed in the testing policy.
Limited Tester Skills
Testers should be competent in all ten of the CSTE Common Body of Knowledge skill categories to be effective. Lack of the skills needed for a specific test assignment constrains the ability of the testers to effectively complete that assignment.
SOFTWARE TESTING FUNDAMENTALS
SOFTWARE TESTING FUNDAMENTALS PART TWO
SOFTWARE TESTING FUNDAMENTALS PART THREE
WHY SHALL WE TEST A SOFTWARE PRODUCT ?
TESTABILITY OF A SOFTWARE
APPROACHES TO SOFTWARE TESTING
TESTING STRATEGIES
ORGANIZING SOFTWARE TESTING
TESTING COMPLETION CRITERIA
SOFTWARE DEVELOPMENT PROCESS
SOFTWARE DEVELOPMENT LIFE CYCLE
PROJECT MANAGEMENT AND SOFTWARE TESTING
ECONOMICS OF SOFTWARE TESTING
DIFFERENT TEST LEVELS
TESTING TECHNIQUES
SPECIAL TEST TYPES
TESTING STANDARDS
ISO STANDARDS OF TESTING
TESTING PROCESS
TESTING PROCESS PART TWO
If needs are lacking or poorly written, then the test team must have a defined method for uncovering and defining test objectives.
A test objective is simply a testing “goal.” It is a statement of what the test team or tester is expected to accomplish or validate during a specific testing activity. Test objectives, usually defined by the test manager or test team leader during requirements analysis, guide the development of test cases, test scripts, and test data.
Test objectives enable the test manager and project manager to gauge testing progress and success, and enhance communication both within and outside the project team by defining the scope of the testing effort.
Each test objective should contain a statement of the objective, and a high-level description of the expected results stated in measurable terms. The users and project team must prioritize the test objectives. Usually the highest priority is assigned to objectives that validate high priority or high-risk requirements defined for the project. In cases where test time is cut short, test cases supporting the highest priority objectives would be executed first.
Test objectives can be easily derived from using the system requirements documentation, the test strategy, the outcome of the risk assessment, and the test team assignments. A few techniques for uncovering and defining test objectives if the requirements are poorly written include brainstorming and relating test objectives to the system inputs, events, or system outputs.
Ideally, there should be less than 100 test objectives for all but the very largest systems. Test objectives are not simply a restatement of the system’s requirements, but the actual way the system will be tested to assure that the system objective has been met.
Completion criteria define the success measure for the tests.
As a final step, the test team should perform quality control. This activity entails using a checklist or worksheet to ensure that the process to set test objectives was followed, or reviewing them with the system users.
Changes in Technology
Effective testing must be done by a team comprised of information services professionals and users. In corporations where the users are not readily available, i.e., they are in a remote location, a professional test group can represent the users. Also vendors of software may not be able, or may not want to have users testing their systems during the developmental process.
Again, in these instances, a professional test group can represent the users. The test group is known by different names, including IT testing,.
The following technological developments are causing organizations to revise their approach to testing:
1 • Integration
Technology is being more closely integrated into day-to-day business resulting in business being unable to operate without computer technology. For example, the airlines can only take reservations when their computer systems are operational.
2 • System Chains
Computer systems are interconnected into cycles of chains such that problems in one can cascade into and affect others.
3 • The Domino Effect
One problem condition, such as a wrong price or a program defect, can cause hundreds or even thousands of similar errors within a few minutes.
4 • Reliance on Electronic Evidence
With hard-copy documents being removed from processing, the validity of the transactions is dependent upon the adequacy of controls, and thus a control error may result in extensive losses.
5 • Multiple Users
Systems no longer belong to single users, but rather to multiple users, making it difficult to identify a single organizational unit responsible for a system.
The organizational approach to testing commences with a policy on testing computer systems. The policy should be developed under the direction of the IT department, but should represent the philosophy of the entire organization. Once the policy has been established, then the procedures and the methods of testing can be developed based upon the desires of management as expressed in the testing policy.
Limited Tester Skills
Testers should be competent in all ten of the CSTE Common Body of Knowledge skill categories to be effective. Lack of the skills needed for a specific test assignment constrains the ability of the testers to effectively complete that assignment.
SOFTWARE TESTING FUNDAMENTALS
SOFTWARE TESTING FUNDAMENTALS PART TWO
SOFTWARE TESTING FUNDAMENTALS PART THREE
WHY SHALL WE TEST A SOFTWARE PRODUCT ?
TESTABILITY OF A SOFTWARE
APPROACHES TO SOFTWARE TESTING
TESTING STRATEGIES
ORGANIZING SOFTWARE TESTING
TESTING COMPLETION CRITERIA
SOFTWARE DEVELOPMENT PROCESS
SOFTWARE DEVELOPMENT LIFE CYCLE
PROJECT MANAGEMENT AND SOFTWARE TESTING
ECONOMICS OF SOFTWARE TESTING
DIFFERENT TEST LEVELS
TESTING TECHNIQUES
SPECIAL TEST TYPES
TESTING STANDARDS
ISO STANDARDS OF TESTING
TESTING PROCESS
TESTING PROCESS PART TWO
No comments:
Post a Comment