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 ...
随机推荐
- rsync实现数据备份
rsync实现数据备份 1.简介 rsync(remote synchronization)是一款开源的,快速的,多功能的,可实现全量和增量的的本地或远程数据同步备份的优秀工具. 2.功能 scp.c ...
- VsCode插件开发之插件初步通信
参考了Egret Wing,想像Egret Wing那样在上方titlebar最右边上面增加一个menu(这个menu相对于一个按钮,当点击这个按钮时会出现一个window弹框,这个window弹框里 ...
- js之清除Cookie
最近新的系统开发用的是Cookie存储用户信息,使用des加密 工具类如下所示: /** * Copyright (c) 2013-Now http://jeesite.com All rights ...
- Linux系统学习之正则表达式
一.基础的正则表达式 1."."(一个点)符号 点符号用于U匹配除换行符号之外的任意一个字符.例如:r.t可以匹配rot.rut,但是不能匹配root,但如果使用r..t,就可以匹 ...
- mysql 存儲emjoy表情是報錯Incorrect string value:
解决方法: [mysqld] character-set-client-handshake=FALSE character-set-server=utf8mb4 collation-server=ut ...
- spring,springmvc,mybatis整合ssm框架出现ORA-02289:序列不存在问题
今天整合了一个SSM项目,完了后部署到Tomcat服务器,正常启动.但是当我发送请求时,报错,,如下 报错说序列不存在,可是我明明创建了序列呀,然后我测试了一下,测试语句:select tb_user ...
- Html5 标签一(文本)
1.html编辑器:Sublime Text 2.标签(文本) 一 Sublime Text 作用:html编辑器. 下载地址:http://www.sublimetextcn.com/ 二 文本 总 ...
- android 模仿大众点评团购卷列表多余3条时折叠,点击时显示剩余全部的功能
要实现这样一个效果:加载一组数据,当这组数据的条数超过2条时,则这显示两条,其余的隐藏,当点击“展开全部时”在显示余下的部分.效果如下图所示: 展开前的效果: 展开后的效果 : 实现思路:控制数据而不 ...
- https原理简析
[转]http://www.cnblogs.com/carsonzhu/p/5225778.html HTTPS的工作原理 HTTPS在传输数据之前需要客户端(浏览器)与服务端(网站)之间进行一次握手 ...
- SQL Server-聚焦深入理解死锁以及避免死锁建议(转载)
前言 终于进入死锁系列,前面也提到过我一直对隔离级别和死锁以及如何避免死锁等问题模棱两可,所以才鼓起了重新学习SQL Server系列的勇气,本节我们来讲讲SQL Server中的死锁,看到许多文章都 ...