Table of Contents
TESTING, VERIFICATION AND VALIDATION
...1UNIT TESTING PROCEDURES
...3C1 100% COVERAGE
...31
TESTING, VERIFICATION and VALIDATION
• Black Box Testing
• White Box Testing
• Regression Testing
• Integration Testing
• Simulated performance Testing
• Acceptance Testing
Specifically, DCM Technologies has had experience in Unit Testing for the Automotive industry.
Unit Testing involves testing the smallest possible unit of an application. Unit testing is
recognized as an essential component of the software development process. Unit testing practitioners enjoy such benefits as easier error detection, which has the very desirable end result of increasing software quality at the same time that it reduces development time and cost. Easier error reduction leads to reduced development time, effort, and cost because less time and resources are consumed finding and fixing errors. In addition, Unit testing involves several complex types of testing:
• White-box testing: Ensures that code is constructed properly and does not contain any hidden weaknesses.
• Black box testing: Ensures that code functions in the way that it is intended to function.
• Regression testing: Ensures that modifications do not introduce errors into previously correct code.
DCM has been carrying out White-box testing for Automotive companies, it being a critical part of the automotive software. White box testing checks that code is robust by determining if it performs correctly when it encounters unexpected input. This type of testing must be performed with full knowledge of the unit's implementation details as specified in the specifications/design. The goal of white-box testing is to execute every branch of code under different input conditions to uncover any abnormal behavior.
White-box test cases should uncover defects by fully exercising the code with a wide variety of inputs. To create effective white-box test cases, one needs to examine the given unit's internal structure, and then write test cases that will cover all of the code as fully as possible, and uncover inputs that will cause the unit to crash. Achieving the scope of coverage required for effective white-box testing mandates that a significant number of paths are executed.
WORK FLOW
The workflow between the customer and DCM, for Unit Testing can be summarized below:
No Yes No Yes No Yes No Yes No Yes Compilation of code
Preparation of Test cases (Unit Test Plan)
First level Review of test cases with input and theoretical values
Is Correction Required?
Stubs/ Compilation/ Testing (Execution of Test Plan)
Second level Review
Is Correction Required?
Correction and Verification Verifying Specs/Design against Code
Query Discrepancy? Missing files? Clarification Required? Correction and Verification DCM Receives Document and Code
3
UNIT TESTING PROCEDURES
Testing is done as per the guidelines set by the customer as specified in the unit Test Manuals and customer requirements.
1. DCM receives the design, specifications and source code. 2. The Design / Specifications received are studied and analyzed.
3. Verification of the received source code against the specifications / design. 4. In case of any discrepancy/bugs, the same are reported to the customer.
5. Then the code is dummy compiled in the Test Environment provided by the customer to check for any missing files required for test plan execution
6. If any more files are required for compilation / some files are missing then again a query is raised.
7. Test cases are prepared according to design / specifications.
8. Each Test case and the items under test are documented in detail in a set format.
9. The input and the initial values are then filled in the Unit Test Plan (UTP) as per each test case & theoretical values evaluated.
10. The UTP is then reviewed by a second person (peer review); this is the first level review of UTP.
11. If any correction / bugs are reported during review then correction and verification is done at this stage only.
12. The UTP is then executed after generation of testing stubs and successful compilation in the test environment sent by the customer.
13. It means that at this level there is complete execution of unit test plan. The theoretical values are compared with actual values obtained after the execution of Test Plan.
14. Any deviations in the values of the test items are reported as NOT OK cases.
15. Second level review of UTP is done. In case bugs/ defects are reported at this stage and changes need to be made, they are made simultaneously in the UTP.
16. Final review is conducted before making delivery to the customer. Delivery set contains source code, Unit Test Plan, test results and other relevant files.
C1 100% COVERAGE
One of the important requirements of Unit Testing is that the test program should execute all test items in all program steps. This is specified as C1 100% coverage. To have C1 100% coverage, test plan is made such that all conditions & all possible paths are covered. Reviews are done to confirm the same and in case the compiler supports generation of profiler reports, the same are obtained to judge that 100% coverage has been made or not.
QUERY GENERATION
Query generation is an essential process in case of offshore projects. The queries need to be systematically communicated and databases of the same needs to be maintained in order to effectively utilize the same. There is a streamlined process followed for Query generation in DCM as summarized below:
Query generation for change or clarification
CUSTOMER DCM
Procedure for Query generation
1. If any clarifications are required about code/specification document/design a Query is generated and sent to the customer. Missing files or problems related to the test environment are also conveyed to the customer through queries.
2. Any change in specs/ code leads to new documents sent by the customer.
3. If there is no change the Query is answered by email with required answers to the clarifications.
4. Major changes can lead to changes in the delivery date schedule. In case schedules get
Return From Query
Generation Yes
No Send Back Mail
No Yes Query generated Impact analysis Spec/ Code change Query Closed Clarifications/Dis crepancy Send new Specs
Document and code modules.
