Review software requirements specification and create test scenarios (what to test for a certain functionality)
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
Review software requirements specification and create test scenarios (what to test for a certain functionality)的更多相关文章
- 软件需求规范说明 (Software Requirements Specification, 简称SRS)
GB/T 9385-2008 笔记 为了形成确定和完备的规格说明, 我们需要明确 软件的顾客希望得到什么; 软件的供方理解用户想要什么; 4.2 SRS的基本性质 SRS是对在具体环境中执行确定功能的 ...
- Guideline 2.5.1 - Performance - Software Requirements
Guideline - Performance - Software Requirements Your app uses the "prefs:root=" non-public ...
- 打包上传被拒 Guideline 2.5.1 - Performance - Software Requirements
打包上传被拒 Guideline 2.5.1 - Performance - Software Requirements 在项目中全部搜索:prefs:root 找到后,把这个私有的 NSURL *u ...
- BI项目需求分析书-模板
目录 目录 .............................................................................................. ...
- BOS物流管理系统-第一天
BOS物流管理系统-第一天-系统分析.环境搭建.前端框架 BoBo老师 整体项目内容目标: 对项目概述的一些理解 亮点技术的学习 注意学习方式:优先完成当天代码. 其他内容. 最终: 学到新的技术,会 ...
- 学习java23种设计模式自我总结
首先先做个广告,以前看过@maowang 这位大神转的Java开发中的23种设计模式详解(转) ,但是看了之后都忘差不多了, 所以,开个帖子边学习边自我总结(纯手敲).一直以来像这种需要长久的运动,真 ...
- 【项目 · Wonderland】需求规格说明书 · 终版
[项目 · Wonderland]需求规格说明书 · 终版 Part 0 · 简 要 目 录 Part 1 · 流 程 / 分 工 Part 2 · 需 求 规 格 说 明 书 Part 1 · 流 ...
- 【项目 · WonderLand】 系 统 设 计
团 队 作 业 ---- 系 统 设 计 Part 0 · 简 要 目 录 Part 1 · 完 善 需 求 规 格 说 明 书 Part 2 · 团 队 编 码 规 范 Part 3 · 数 据 库 ...
- CV3
Self Assessment: 1. Skilled in developing with HTML/JavaScript/ASP.NET/C#, experienced in 3-l ...
随机推荐
- PAT A1012 The Best Rank (25 分)——多次排序,排名
To evaluate the performance of our first year CS majored students, we consider their grades of three ...
- 原生js 数组的迭代的方法
一.原生js Array给我们提供很多了方法.方便我们操作数组.这些方法的参数,都需要传入一个匿名函数,匿名函数中有三个参数,分别含义是:数组中的项.该项的索引.以及数组本身. 1.filter方法: ...
- mysql试题
drop,delete与truncate的区别:优先级: drop > truncate > deleteTRUNCATE 按行删除并不把删除操作记录记入日志保存(不可恢复)DELETE ...
- Objective-C @executable_path、@loader_path和@rpath
工程配置中,有三个路径和库的加载息息相关: 1.@executable_path 可执行文件的路径,例如/Applications/WeChat.app/Contents/MacOS. 2.@load ...
- MySQL 基础三 函数(聚合、字符串、时间、条件判断)
1.聚合 其它:GROUP_CONCAT.avg.sum.count.max.min SELECT typeid,GROUP_CONCAT(goodsname) FROM `goods` GROUP ...
- LeetCode263:Ugly Number
public bool IsUgly(int num) { if(num<1) return false; while(num>1) { if(num%2==0) { num=num/2; ...
- mysql利用binlog进行数据恢复
目录 mysql利用binlog进行数据恢复 binlog基本配置和格式 binlog基本配置 查看binlog状态 binlog的三种格式 转换成sql mysql自带的mysqlbinlog 利用 ...
- 同一个解决方案或有依赖关系的两个项目引用同名但不同版本的DLL
问题描述 我们最近在使用Redis作Session的集中化,中间碰到了一个如下问题:我们有一些项目比较老,引用了NewtonJson的4.0.3.0版本的DLL,但是Redis提供的C#集成DLL引用 ...
- 2-SAT超入门讲解
Preface 说实话2-SAT的题目我都没怎么做过,所以这里讲的都是些超入门什么的 还有一些板子题,由于是暑假的时候学的所以有些我也记不清了 主要学习参考自:Mancher的课件&& ...
- 【Qt】窗口居中显示
w.move((a.desktop()->width() - w.width())/, (a.desktop()->height() - w.height())/); 上述方法可以置中,但 ...