Object Oriented Cybersecurity Detection Architecture (OOCDA) Suite |
---|
|
---|
Testing Plans
Introduction Testing is the process of achieving error free system. There should be a test plan, which includes unit test, stage development testing and system testing. The architect-design should include testing stages and plans. Testing teams and tools should be available and should be an independent team. Offshore testing has both Pros and Cons and management should look at the risks and cost. Testing as a Science There is new title called Test Architect. The primary responsibility of a test architect is to provide technical leadership and strategic direction for their testing organization. Test architects focus on a diverse set of goals and perform a wide variety of tasks. Some spend time developing testing infrastructure, test authoring frameworks, or evaluating features in order to create complex tests. Some are in charge of a particular technology for their group. A test architect has in-depth knowledge of a variety of testing techniques and methodologies used. A test architect often provides technical assistance and/or advice to the test Manager. Test Plan Our goal is to simplify testing Identify the basic structure of testing as follows: 1. What is being tested? 2. The scope and priority 3. The test effort 4. On/Offshore 5. The personal 6. Test Material Testing Specs Our Project Management Planner (PMP) Framework has the following testing specs: 1. Test Objective 2. Technique 3. Test Tools 4. On-line test plans and procedures 5. Test cases 6. Test data 7. Security and Access Control 8. Automation of testing 9. Set of test values to insure that the system is exhaustively tested. 10. Dump of values 11. Independent party testing (On/Offshore) 12. Testing done on different and independent machine 13. Third Party testing. For example, using insurance agents to test Kemper products before it is released – Beta version 14. Field Testing 15. Classification of errors A. Input B. Output C. Old and new errors D. Accuracy E. Logical flow of input F. Cosmetics errors G. Calculation errors H. Memory 16. Sequence order for input/output 17. User Interface Testing 18. Failure / Recovery Testing 19. Must have features 20. Nice to have features 21. Failure rate and downtime 22. System performance 23. System bottlenecks 24. Special Considerations As for infrastructure testing see Object Oriented Design (OOD) Testing link: Object Oriented Design (OOD) Testing Automation, Intelligence and Virtualization of Testing Automation of Testing Our architect approach to automatic testing is with the following steps: • One code test segment, a test script or a test component • It is designed to read data from a number of input data files • It would run as a separate module • It calls a number of key functions where certain parameters are passed as part of testing design • Both data dump and logging files are stored and parsed • Parsing can be done manually or automation searching for the expected key values • Both test segment and input data can be modified with different changes based on code version • The new data dump and logging files are compared by file comparison • The differences between files are logged for future tracking and comparsion • All the above steps can automated Intelligence of Testing Our automation approach can create a number of code segments, scripts, code components. Parsers would be created to parse the data dump and logging files. An automated parsers would be created to check for patterns, errors and duplicate of values. Virtualization of Testing Virtualization can be used to create test servers, test environment and parsers. |
---|