Conventional and Performance Testing Business Planning Activities

Question: Describe about the Conventional and Performance Testing for Business Planning Activities. Answer: Introduction The document covers the test plan for www.phonebook.com and is designed for the purpose of presenting a set of guidelines that will be followed by the QA testing team during the testing of the features of the web site. The document describes the planning activities and the test strategy that will be followed during the testing activities for the project. Intended Audience Project Manager Business Expert Subject Matter Experts Testing Lead Test Manager Test Engineers Performance testers Assumptions and Dependencies The build for testing will be provided to the team by the development team for carrying out the testing activities The test data that will be used in the testing processes will be ready by the text execution phase. The test environment required by the testing team will be provided and will be ready in advance before the testing activities will begin. Workstations along will the testing tools, hardware and software required for all the testing activities will be provided to the team. Scope In Scope Testing of the ability to make sure that the users are able to create account in the site www.phonebook.com Testing of the ability to make sure that the users are allowed to create more than one sheet in the phonebook and every single sheet can contain details of around 10000 contacts Testing of the ability to make sure that the users can log in to the web site and app with the help of valid set of credentials and are denied the ability to do in case of incorrect credentials. Testing of the ability to make sure that the phone book present in the phone and the account on the site are synced at all times. Testing of the ability to make sure that the users can share the sheer with other friends with the help of the email address of the friend. Testing of the ability to make sure that if the user has provided the read and write access to a friend then the same can make changes to the contact information of the user and in case of only the read access, the user will be able to only see the information. Testing of the ability to make sure that the users can select multiple sheets and any number of sheets to be synced without any limit on the same. Testing of the ability to make sure that the users are able to access and import the information from any CSV (Comma Separated Value) file. Testing of the ability to make sure that the users are able to export the sheet in the CSV file Out of Scope The functionalities that will be pre-existing in the web site will not be tested The hardware issues associated with the user devices will not be tested Test Planning The test activities will be carried out in a number of phases as planning phase followed by development phase then execution and then the closure phase. The first phase will include the test planning such as decision on the test team, roles and responsibilities, testing types, test scope and test strategy. The second phase will include the creation and development of the test data and test suites comprising of the test cases. It will then be followed by the execution phase which will include the execution of the test cases and logging of the defects that will be reported. The final phase will be the closure phase which will include the reporting activities. Test Strategy The test strategy that will be followed during the testing process would be Bottom-up test strategy. As per this strategy, each of the functionality and module will be tested from the lower end that is on an independent basis. It will then be tested as an integrated unit and then the system as a whole along with the connected components. The system testing will make sure that the system as a whole comprises of all the essential features and that the functioning of every component is correct. Functional Test Items Conventional Testing #. Test Phase Features to be tested Approx. no. of test cases Remarks 1 Sanity Test The testing team will perform the sanity test on the newly received build to make sure all the mandatory features are implemented in the build and it is okay to be tested It will include a maximum of 15 test cases The testing will be performed by the test team and the reporting will be done to the test manager and test lead 2 Integration Testing The different functionalities will be integrated together in the form of various modules and then tested to verify and validate the functionality of the individual feature and of the integrated module as well It will include a total of 50 test cases to be tested The testing will be performed by the test team and the reporting will be done to the test manager and test lead 3 Functional System Testing The functionalities that are listed in the scope along with the functionality of the system as a whole will be tested in this testing type It will include a total of 100 test cases The testing will be performed by the test team and the reporting will be done to the test manager and test lead 4 Regression Testing The defects that will be fixed by the development team will be tested to make sure that they are implemented correctly and also the existing functionalities will be tested to make sure that the changes have not impacted the existing functionalities All the defects fixed will be tested in this phase along with the 20 test cases covering the major functionalities The testing will be performed by the test team and the reporting will be done to the test manager and test lead 5 User Acceptance Testing The acceptance testing will be carried out by the end users and the customers to validate the business requirements and their implementation The testing team along with the end users will perform the testing Non Functional Test Items Performance Testing #. Test Phase Features to be tested Approx. no. of test cases Remarks 1 Stress Test This type of testing will be carried out by performance test engineers to validate the capacity of the functionalities in terms of the sheet handling, network requirements and likewise It will include a total of 40 test cases The testing will be performed by the test team and the reporting will be done to the test manager and test lead 2 Load testing This type of testing will be carried out by the performance test engineers to make sure that the functionalities behave correctly in case of the normal conditions and in anticipated peak loads as well such as more than 10000 contacts for a single sheet and likewise It will include a total of 35 test cases The testing will be performed by the test team and the reporting will be done to the test manager and test lead 3 Volume testing This type of testing will be carried out by the performance test engineers to make sure that the functionalities function as per the different database sizes and volumes It will include a total of 25 test cases The testing will be performed by the test team and the reporting will be done to the test manager and test lead Testing Approach Entry Criteria The entry criteria for all the types of testing that have been listed above will include the pre-requisites as the establishment of the test environment along with the readiness of the build that is required to be tested. Exit Criteria The exit criteria for all the testing types would include the complete execution of all the test cases along with the submission of the defect reports and status reports on the same. Defect Management Defect Categorization Severity of the defect Description of the defects under this category Examples of such defects Critical These defects will stop the functioning of the system as a whole and will also result in severe impacts such as missing of the deadlines due to inability of the features to be accessed Inability to login to www.phonebook.com Inability to open the web site at all on any device Urgent The defects will include the ones in which the entire application will be accessible but a major functionality will not be in an operate-able state Inability to view the phone book Inability to sync the phone book and the account Inability to retrieve the account details Moderate The defects will include the ones in which the entire application will be accessible but an important functionality will not be in an operate-able state and the reproducibility rate will not be 100% for such defects Inability to add contact information in more than one sheet Inability to access multiple sheets at one time Low The defects will include the ones in which the entire application will be accessible and there will be minor changes required in the application Spelling errors Incorrect alignment in certain text pieces Defect Metrics and Reporting Test metric Definition Purpose How to calculate Total number of defects These will be the defects that will be in the open state at the time of retrieval of the defect report The number of these defects will directly inform the stability of the functionalities and the system as a whole The number of defects with the status as open will be the total number of defects Defect status The defects status will be any one of the following as: Open: The defect filed by the testing team but not resolved by the development team Resolved: The defect correct and sent back to the testing team and has not be re-tested Closed: The defect has been resolved by the development team and has been validated by the testing team as well. Not a defect: The defect that has been reported by the testing team has been considered as not a defect due to a reason such as inability to be corrected The status will help the project teams to understand the changes that have been done and are required to be done with respect to the project functionalities and application as a whole The status and the defects under a particular status can be retrieved with the help of the testing tool Defect severity It will be the impact that will result due to the presence of the application and the set of functionalities that are present The severity level of the defect with severities as high, medium or low will provide an estimation on the effort that is required The severity and the defects under a particular level of severity can be retrieved with the help of the testing tool Final Test Summary Report The report will provide the total number of test cases that have passed that is the ones that do not have a defect associated with them and the ones that do The progress of the testing activities can be tracked with the help of this report Test case tracking sheet Defect Reports The total number of defects under every defect status and severity level along with the defect id, defect summary, defect description and other essential details The progress of the testing activities can be tracked with the help of this report It can be retrieved directly from the testing tool Test Reporting and Deliverables Sr. No. Report Content Frequency 1 Daily Testing Status report It will include the daily testing effort that will be put by every individual testing team member in terms of test cases created, executed and defect related activities Daily 2 Weekly Testing Status Report It will include the weekly testing effort that will be put by testing team as a whole in terms of test cases created, executed and defect related activities Weekly 3 Defect Report A complete list of the defects along with the ones that are in open state separately highlighted in the report. It can be retrieved from the testing tool itself Weekly 4 Monthly Testing Status Report It will include the monthly test effort details and the project status on the basis of number of open defects Monthly 5 Testing Completion Report It will be a closure report for the testing process which will include the complete account of all the testing activities that will be covered At the end of the test phase References Dae,. (2016). Test Plan Template. Retrieved 27 September 2016, from https://dae.etenders.in/tender_document/tender_297/PO_SECTION_DOCUMENT/sample_test_plan_template.pdf Probert, J. (2016). Test Planning. Retrieved 27 September 2016, from https://www.joshprobert.com/Testplan.pdf