I was having a chat with my friend who is a beginner in testing. He was sharing his problem with me on how to initiate testing. Although there are many books and articles on theories and concepts of testing but there is no help or information available on how to start testing and how a tester should proceed with the same. I thought of penning down my experience and sharing with all about my style on how to start testing. There are no specific norms but based on my experience while working on various projects I have listed down items which I have been doing while performing functional testing.
During the project initiation, when "Business Requirement Document" or "Software Requirement Document" or "Functional Specifications" are defined at that stage, tester should be involved to understand the background of the project. This also helps tester in getting first-hand information about user needs, their pain areas and expectations from the system which is yet to be developed.
While the project is in second stage of the cycle, which is Development Stage, Test Plans should be prepared. This helps tester in analyzing the requirements from testing aspect such as Test Case preparation based on features to be tested, Test Data requirements, defining defect priority and severity norms.
The Test plan comprises of schedule and timeline for test case writing and execution, entry and exit criteria for testing, number of regression test cycles to be performed and test cases to be executed in each cycle. Test plan also defines the status reporting template and frequency for the same.
After preparation of test plans, we should not rush to writing test cases but we need to analyze the needs of the system apart from functional requirements of the system. We need to identify test scenarios, covering alternate flows, boundary values and business rules/validation needs for writing test cases. During our testing, we need to ensure that our testing is also covering those requirements as well. One example of such requirements could be browsers to be supported by the web application. Further, we need to prioritize Test Scenarios based on user needs and business criticality. This helps in focusing the critical areas of application and helps in performing comprehensive testing.
The test cases provide details about steps to be performed during testing. Usually every test case comprises of information about steps to be performed, data to be consumed, expected and actual results. The test cases are written to perform testing for both negative and positive scenarios. While positive test scenario related test cases helps the tester to find obvious defects, similarly negative test scenario related test cases help the tester to find defects and behavior of software/application under abnormal circumstances. This helps in checking the failure conditions and how error handling is performed in the application.
To provide full coverage of testing we can maintain traceability matrix of use cases or requirements with test cases. This helps us to ensure that all the requirements are covered while writing test cases.
Once we have written test cases, we will execute the test cases as per test plan defined earlier. While executing test cases, we will compare the actual results with expected results. In case of any discrepancy between actual output and expected output, we need to log it as a defect. The priority and severity of the defect is defined and are reported to Development team.
Further, as a practice you should maintain test results for each test case for every cycle of testing performed. We need to ensure that new code drop is not causing any defect to reopen during development cycles.
After defects are reported to development team, development team will deploy code after fixing the defects. Next step will be to perform regression testing. Regression testing will be based on executing the test scenarios with high priority and related to areas where code changes have been done by development team.
During the last and final stage of testing we need to ensure that all test cases are executed and there are no defects found in the verification. You can use automation testing, specifically for the areas of application, which are stable and will undergo minimum changes. This will help in keeping maintenance effort for the automation suite to minimum and will help in reducing manual testing effort by providing testing coverage for the critical areas. My general approach is always to re-run the test cases against which defects are detected, and the test cases associated with the related areas of application. This helps in detecting defects, which could have been injected by the developer in the code while fixing the reported defect. In case of 100% success, all the defects are closed, and testing report is submitted. However, in case any of the defects is re-opened or new defects are logged then the above-mentioned steps are executed again after the development team deploys fresh code.
These are the steps which are usually followed under normal circumstances for performing functional testing. However, in certain projects, testers are supposed to perform functional testing under following scenarios:
Incomplete requirement documentation or no business requirements defined.
Testing is initiated after the project is developed.
Time allocated for testing is too short to perform thorough testing of the software.
The approach for functional testing will be different in all the above stated cases. Let’s discuss each scenario and approach tester should follow in each case:
1. Due to lack of functional or business requirements, it is very difficult for us to write test cases or define test scenarios. It is always recommended that in such cases tester should communicate with the business users and developers to define valid test scenarios. The tester should then envision features and functionality of software being developed and create a scenario based on the same. Tester should get these test scenarios validated by Users and developers. Based on signed off scenarios Tester should create test cases. The execution cycle in this scenario will remain same as explained above.
2. The second case is relatively simple, since the software has been developed, then the test time in the test plan is even easier to arrange, more conducive to the implementation. The base for writing test cases should be mixed of functional specifications and the actual software. This helps in ensuring that developers have not misinterpreted any requirement or if the development team has missed out implementation of any requirement.
3. For third scenario, we can perform risk based assessment of the application. With the help of business users, we will define the most critical areas of the application from the business aspect. Similarly, after coordinating with Development team, we will define the most complicated areas of the application from development perspective. Our test scenarios and test cases will focus on these two aspects and cover the areas defined under both the scenarios. If you have experience in testing, then you can further save time by not writing the test cases and performing testing in accordance to test scenarios identified. The reporting hence will comprise of only the test scenarios covered, and defects found.
In case you are stuck with the projects with no requirements, tight timeline and no experience in similar testing then you need to burn overnight fuel to prepare for it.
These are the personal opinions which I have for software functional testing. Certain aspects may differ from case to case basis, for example, in case of project following agile methodology for development then the approach for Agile testing will be different than stated above. This article is for your reference only on how to initiate testing and move forward with test plans, test cases and test reports.
During the project initiation, when "Business Requirement Document" or "Software Requirement Document" or "Functional Specifications" are defined at that stage, tester should be involved to understand the background of the project. This also helps tester in getting first-hand information about user needs, their pain areas and expectations from the system which is yet to be developed.
While the project is in second stage of the cycle, which is Development Stage, Test Plans should be prepared. This helps tester in analyzing the requirements from testing aspect such as Test Case preparation based on features to be tested, Test Data requirements, defining defect priority and severity norms.
The Test plan comprises of schedule and timeline for test case writing and execution, entry and exit criteria for testing, number of regression test cycles to be performed and test cases to be executed in each cycle. Test plan also defines the status reporting template and frequency for the same.
After preparation of test plans, we should not rush to writing test cases but we need to analyze the needs of the system apart from functional requirements of the system. We need to identify test scenarios, covering alternate flows, boundary values and business rules/validation needs for writing test cases. During our testing, we need to ensure that our testing is also covering those requirements as well. One example of such requirements could be browsers to be supported by the web application. Further, we need to prioritize Test Scenarios based on user needs and business criticality. This helps in focusing the critical areas of application and helps in performing comprehensive testing.
The test cases provide details about steps to be performed during testing. Usually every test case comprises of information about steps to be performed, data to be consumed, expected and actual results. The test cases are written to perform testing for both negative and positive scenarios. While positive test scenario related test cases helps the tester to find obvious defects, similarly negative test scenario related test cases help the tester to find defects and behavior of software/application under abnormal circumstances. This helps in checking the failure conditions and how error handling is performed in the application.
To provide full coverage of testing we can maintain traceability matrix of use cases or requirements with test cases. This helps us to ensure that all the requirements are covered while writing test cases.
Once we have written test cases, we will execute the test cases as per test plan defined earlier. While executing test cases, we will compare the actual results with expected results. In case of any discrepancy between actual output and expected output, we need to log it as a defect. The priority and severity of the defect is defined and are reported to Development team.
Further, as a practice you should maintain test results for each test case for every cycle of testing performed. We need to ensure that new code drop is not causing any defect to reopen during development cycles.
After defects are reported to development team, development team will deploy code after fixing the defects. Next step will be to perform regression testing. Regression testing will be based on executing the test scenarios with high priority and related to areas where code changes have been done by development team.
During the last and final stage of testing we need to ensure that all test cases are executed and there are no defects found in the verification. You can use automation testing, specifically for the areas of application, which are stable and will undergo minimum changes. This will help in keeping maintenance effort for the automation suite to minimum and will help in reducing manual testing effort by providing testing coverage for the critical areas. My general approach is always to re-run the test cases against which defects are detected, and the test cases associated with the related areas of application. This helps in detecting defects, which could have been injected by the developer in the code while fixing the reported defect. In case of 100% success, all the defects are closed, and testing report is submitted. However, in case any of the defects is re-opened or new defects are logged then the above-mentioned steps are executed again after the development team deploys fresh code.
These are the steps which are usually followed under normal circumstances for performing functional testing. However, in certain projects, testers are supposed to perform functional testing under following scenarios:
Incomplete requirement documentation or no business requirements defined.
Testing is initiated after the project is developed.
Time allocated for testing is too short to perform thorough testing of the software.
The approach for functional testing will be different in all the above stated cases. Let’s discuss each scenario and approach tester should follow in each case:
1. Due to lack of functional or business requirements, it is very difficult for us to write test cases or define test scenarios. It is always recommended that in such cases tester should communicate with the business users and developers to define valid test scenarios. The tester should then envision features and functionality of software being developed and create a scenario based on the same. Tester should get these test scenarios validated by Users and developers. Based on signed off scenarios Tester should create test cases. The execution cycle in this scenario will remain same as explained above.
2. The second case is relatively simple, since the software has been developed, then the test time in the test plan is even easier to arrange, more conducive to the implementation. The base for writing test cases should be mixed of functional specifications and the actual software. This helps in ensuring that developers have not misinterpreted any requirement or if the development team has missed out implementation of any requirement.
3. For third scenario, we can perform risk based assessment of the application. With the help of business users, we will define the most critical areas of the application from the business aspect. Similarly, after coordinating with Development team, we will define the most complicated areas of the application from development perspective. Our test scenarios and test cases will focus on these two aspects and cover the areas defined under both the scenarios. If you have experience in testing, then you can further save time by not writing the test cases and performing testing in accordance to test scenarios identified. The reporting hence will comprise of only the test scenarios covered, and defects found.
In case you are stuck with the projects with no requirements, tight timeline and no experience in similar testing then you need to burn overnight fuel to prepare for it.
These are the personal opinions which I have for software functional testing. Certain aspects may differ from case to case basis, for example, in case of project following agile methodology for development then the approach for Agile testing will be different than stated above. This article is for your reference only on how to initiate testing and move forward with test plans, test cases and test reports.
Fuente: http://softwareqatestings.com/introduction-to-software-testing/basic-steps-of-functional-testing.html
