Basic Testing Approaches

Static Testing

Static testing is performed at the design phase of the development of a system or an application. During the design phase of development, most of the software defects are found. During the design phase, no actual programming or coding is done. What needs to be tested at this stage, is the big question and the answer is ‘Documentation’ such as requirements documents, specifications, design documents, etc. Documentation is an important aspect of software development and it is done throughout the development of a system or an application. So, during the design phase of development, available documentation is tested by using different techniques such as desk checking, inspections, walkthroughs, and presentations to examine the truthfulness and completeness of the documentation under test. The defects found in the documentation being tested, are supposed to be tracked, resolved, and updated to avoid any further defects during the development phase. There are two specific reasons for the documentation to be statically tested by the testers only which include:

• Testers receive appropriate training to get expertise in document testing techniques.
• Secondly, testers are treated as an unbiased third party who is credible to find document defects as compared to the document owner who is less likely to identify any defects.

White Box Testing

White box testing is performed when the actual programming code has already been written by the in house developers for the new system or the application under development. For the white box testing to be performed, source code and executable code have to be available. The development team and the testers’ team are the perfect group to execute the white box testing. The development and testing teams together review and test each line of code. The development team plays an important role during this testing by giving their contribution as they are the one who know the source code in and out, what the code is supposed to do and the code is working that is positive testing. The testers play their role by contributing knowledge of white box testing techniques that is beyond the developers’ knowledge of source code positive testing. 

Black Box Testing

Black box testing is performed when the executable code is available for testing of the new system or the application and there is no need of source code to execute tests. The development team, testing team, and group of end users are the best people to perform black-box testing. The testers play an important role by contributing their test planning and execution expertise to perform positive as well as negative black box testing. End-user play their role contributing their knowledge and expertise of business behavior to be expected of the new system or the application. Developers share their knowledge of business behavior implemented in the new system or application. So, the testers run the black box testing with the help of developers and a group of end-users by verifying the expected outcomes against the actual outcomes.

Performance Testing

Performance testing is performed to test the new system or application performance and when it is proved that the new system operates perfectly. During this testing, the main emphasis is on the response time and the output. The testing team or a group of experienced testers are the best people to plan and execute the performance testing. Testers are the only people who apprehend and perform the performance testing perfectly. The testers with a number of good testing skills are needed to execute the performance tests as the performance testing is a complex one. The testing team creates a testing environment with the performance test tools and the business experts assist the testing team with the transactions for the performance testing to be completed.

Testing Strategy

Software testing appears to be a simple choice among the testing techniques, the strategy for using these testing techniques is very complex. The clue to successful testing is to create a pertinent testing strategy for the software under development before any actual testing starts.

For the introductory investigation, analysis, and design phases, only one testing strategy to be planned that specifies static testing for the software under development. At this point of time in the Software Development Life Cycle, the software only exists in the form of documents such as requirements specifications, data structures, etc. So, at this stage only the documents are tested as no code has been written yet. There are two issues concerning this testing strategy during the software development life cycle which include:

• First, identifying imperfect, wrong and conflicting details in all documents.
• Secondly, making sure that documents goals are testable when they get converted into the software.

For the introductory construction phase, there are three testing strategies to be planned that specify static testing, black box testing and white box testing for the software under development. At this point of time in Software Development Life Cycle, the software exists in the form of executable program source code, data and program code. So, at this stage environment set up documentation, program source code, data and program code are tested. Newly written code paths and code input/output behavior are also tested under the white box and black box testing strategies.

For the concluding construction phase, there are three testing strategies to be planned that specify static testing, black box testing, and performance testing for the software under development. At this point in time in the Software Development Life Cycle, documentation such as user guides, training tutorials, installation guides, operating manuals, etc., created in the later phase is to be tested. The black box testing that is the testing of complex code input and output behavior continues in this phase. At the final stage of this phase of testing, it is verified that the new software installs and operates correctly in its documented production environment.

For the post-implementation phase, there are two testing strategies to be planned that specify static testing and performance testing for the software under development. Once the now software installation gets verified, the static testing is performed on the implementation checklists and operational manuals first use. The new software operations are under continuous monitoring for few weeks to get a compare software performance and workload with verified software performance and workload. Based on the issues or inconsistency found in the software performance and workload, short term or long term solutions are identified.

Test Planning

The most successful and feasible way to create and deliver the testing is documenting the endeavors into two separate entities:

•  Test Plan – Overall Test Plan Description

The test plan has a scope that consists of the whole testing strategy. A typical test plan consists of the following parameters:

1. Systems/software and applications to be tested

These are the systems or software and applications or group of applications that are covered in the current testing effort.

2. Testing goals and their requirements and risks

These are the specified goals that are supposed to be attained for the particular systems or applications for testing. Testing goals must be measurable and achievable within the predefined timelines and concentrate on the business needs and potential risks.

3. Test plan scope and its limitations

Testing resource requirements must be forecast appropriately and the project expectations set accurately. The test plan should clearly state what to be tested and what not to be tested.

4. Business expertise for test planning and execution

A person from the Business side having business expertise is required to enter and help the Testing team to design, interpret and execute tests concerning the business context as the Testing team is not expected to have the business expertise.

5. Development expertise for test planning and execution

A person from the technology or development side having Technical expertise is required to enter and help the Testing team to design, interpret and execute tests concerning the targeted technology environment as the Testing team might be unaware or unfamiliar with the new system’s languages and databases developed by the development team.

6. Multiple environments for testing and environments’ management

The development team needs to transfer the code into a different testing environment once they finish writing and testing the code so that the testing team can test the code independently. The testing environment in which the testing team performs independent testing has to be an exact copy of the production environment to achieve reliable test results. The testing team should be able to manage and control the separate testing environment so that they can run and rerun the tests without any conflicts with the production and development environments.

7. Testing Strategy

Testing strategy is defined for the system or application under test.

8. Testing details for each development phase – ‘repeated’

This consists of the testing details for each development phase which include:

• Development Phase Name
• When to start the testing
• When to finish the testing
• Test Case List-Id, title, and a brief description
• Test Case Writing Schedule
• Test Case Execution Schedule
• Test Case Outcomes Analysis and Reporting Schedule

The notation ‘Repeated’ is used here to specify that the above list of item is repeated for each development phase.

9. Complete Testing schedule – to be updated with new information and revalidated

The complete testing schedule consists of all the testing schedules such as test case documentation, execution and reporting schedules.

• Test Cases – Detailed Test Execution Instructions

After writing a test plan, the most important outcome that comes into the highlight is a list of test cases. In the beginning, the Testing team recognizes the test cases as high-level testing requirements with respect to the new systems or applications Business requirements, and risks or software Specification. As the detailed requirements are identified by the development team, the testing team enlarges the test case to incorporate detailed testing instructions and expected outcomes.

First, identifying the simplest Business activities supported by the new system or the application and specify test cases for each business activity is a good start. Then target the bigger Business activities and define test cases for each business activity. Now go through the requirement Specification and make sure that all the business activities are covered and test cases have been created for each business activity. Define the test cases for the remaining business activities that are not yet covered. Test cases consist of the following items:

1. Distinctive Test Case Id

This is a string of numbers and letters, and the test case document is uniquely identified by this distinctive test case Id. This test case Id is already defined at the time of test plan design.

2. Distinctive Title

This is a label with a short description of the purpose of the test case. This title is already defined at the time of test plan design.

3. Brief Description

This is the description of the title that gives additional details about the purpose of the test case. The brief description is already defined at the time of test plan design.

4. Development Phase

This links to the development phase part of the test plan that defines this test case. 

5. Specific Testing Objectives and achievement measures

This item evaluates the specific testing objectives considering the test case purpose defined in the title and brief description. This also calculates how the testing team measures the achievement of specific testing objectives.

6. Suggested Test Data and Tool

This item recognizes the least amount of data with the most beneficial data sources and allows the tester to suggest the most appropriate testing tools to execute the test case in the test environment. The suggested testing tools in all test cases finally become the ground for automated test tools recommendation by test manager in the test environment.

7. Test startup Approach

This item identifies the hardware, software, and data at hand for the test execution. IT also determines how the needed software and application under test should be set up to enable the first step of test case execution to be attained.

8. Test Closedown Approach

This item determines how the software and application under test should come to a stop smoothly. This allows the software activities to become inactive slowly and the software to stop normally.

9. Test Execution Steps – ‘repeated’

This consists of the step number, step action, expected results, and actual results. The notation ‘repeated’ is used here to specify that the list of items is repeated for each step number.

10. First Attempt to Execute the Test Case – Date/Time

This item captures the date and time when the first attempt is made with the steps of the test case.

11. Number of Attempts to Execute the Test Case

This item evaluates the number of attempts needed to achieve successful execution of the test case.

12. Software Defects Found by the Test Case

This item logs the genuine software defects found by the test case.

13. Test Case Executed Successfully – Yes/No

This item’s response is possible only when the first attempt is made. The response can be Yes or No depending on the success or failure of the test case execution.