Review software requirements specification and create test scenarios (what to test for a certain fun...

1 srs
2 what to test
3 establish guidelines on how this deliverable is to be presented , the template
4 decide on whether each member of the team is going to work on the entire document or divide it among themselves.
5 srs review also helps in better understanding if there are any specific prerequisites required for the testing of the software

What do we need to get started?
1 The correct version of the srs document
2 Clear instructions on who is going to work on what and how much time have they got
3 a template to create test scenarios
4 other information on - who to contact in case of a question or who to report incase of a documentation inconsistency

Who would provide this information ?
Team lead
How to crate a template for QA Test scenarios
Project name
Reference document
Crated by
Date of creation
Date of review
Test scenario ID : the rules to follow while assigning this id have to be defined (项目_模块_子模块_序号）
Requirement: it helps that when we create a test scenario we should be able to map it back to the section of the SRS document where we picked it from . IDS ,page number
Test scenario description: what to test
Importance: high medium low or 1-5 whatever the value this field can take , it has to be pre-decided
No. of Test cases: a rough estimate on how many individual test cases we might end up writing that one test scenario.

Some important observations regarding SRS review:
1 no information is to be left uncovered.
2 perform a feasibility analysis on whether a certain requirement is correct or not and also if it can be tested or not.
3 unless a separate performance/security of any other form of test teams exists- it is our job to make sure that all nonfunctional requirements have to be taken into consideration 除非其他测试团队存在
4 not all information is targeted at the testers, so it is important to understand what to note and what not.
5 the importance and no. of test cases for a test scenario need not be accurate and can be filled in with and approximate value or can be left empty.

To sum up, SRS review results in :
1 test scenarios list
2 review results- documentation /requirement errors found by statically going through/verifying the SRS document.
3 a list of questions for better understanding - in case of any
4 preliminary idea of how the test environment is supposed to be like 初步
5 test scope identification and a rough idea on how many test cases we might end up having- so how much time we need for documentation and eventually execution.

Test Plan is a dynamic document. Is more or less like a blueprint of how the testing activity is going.

Test Cases: how we are going to test a requirement

Test Execution
1 the build :being deployed to the QA environment is one of the most important aspects that needs to happen for the test execution to start.
2 test execution happens in the QA environment. To make sure that the dev team's work on code is not in the same place, where the QA team is testing, DEV and QA environment , a production environment
3 test team size is a not constant from the beginning of the project. When the test plan is initiated the team might just have a team lead. During the test design phase, a few testers come on board. Test execution is the phase when the team is at its maximum size.
4 test execution also happens in at least 2 cycles(3 in some projects). The objective of the first cycle is to identity any blocking, critical defects, and most of the high defects. The objective of the second cycle is to identify remaining high and medium defects, correct gaps in the scripts and obtain results .
5 test execution phase consists of -executing the test scripts+ test script maintenance(correct gaps in the scripts)+ reporting(defects, status, metrics, etc.) therefore when planning this phase schedules and efforts should be estimated taking into consideration all these aspects and not just the script execution
6 after the test script being done and the AUT is deployed - and before the test execution begins, there is an intermediary step. This is called the "Test Readiness Review (TRR)". This is a sort of transitional step that will end the test designing phase and ease us into the test execution.
7 in addition to the TRR, there are few more additional checks before we ensure that we can go ahead with accepting the current build that is deployed in the QA environment for test execution.
Those are the smoke and sanity tests.
8 on the successful completion of TRR, smoke and sanity tests, the test cycle officially begins.
9 exploratory testing would be carried out once the build is ready for testing. (探索性测试）
The purpose of this test is to make sure critical defects 关键缺陷 are removed before the next levels of testing can start. This exploratory testing is carried out in the application without any test scripts and documentation. It also helps in getting familiar with the AUT
10 just like with the other phases of the STLC, work is divided among team members in the test execution phase also. The division might be based on module wise or test case count wise or anything else that might make sense.
11 the primary outcome of the test execution phase is in the form of reports primarily, defect report and test execution status report.
Status column: Fail(red color) Pass No run/unexecuted empty
Actual result column: when pass this field can be left empty. When fail a screenshot can be attached

转载于:https://www.cnblogs.com/caojuansh/p/8670610.html