34 Sources for Test Ideas
Consider the following, and think about values, risks, opportunities; find shortcuts to cover what is important.
1. Capabilities. The first and obvious test ideas deal with what the product is supposed to do. A good start is requirements, examples
and other specifications, or a function list created from actual software. But also try to identify implicit requirements, things users
expect that haven’t been documented. Be alert to unwanted capabilities.
internal/external, anticipated/unexpected, (un)intentional, realistic/provoked failures. Challenge the fault tolerance of the system; any
object or component can break.
3. Quality Characteristics. Quality characteristics are always important for the project to be successful, although the OK zone can be
easy to reach, or difficult and critical. Our definition includes capability, reliability, usability, charisma, security, performance, IT-bility,
compatibility, supportability, testability, maintainability, portability, and a plethora of sub-categories.
Many of these can be used as ongoing test ideas in the back of your head, executed for free, but ready to identify violations.
4. Usage Scenarios. Users want to accomplish or experience something with software, so create tests that in a variety of ways simulate
sequences of product behavior, rather than features in isolation. The more credible usage patterns you know of, the more realistic tests
you can perform. Eccentric soap opera tests broaden coverage.
5. Creative Ideas. All products are unique, and require some test ideas not seen before. Try lateral thinking techniques (e.g. Edward De
Bono’s Six Thinking Hats, provocative operators, the opposite, random stimulation, Google Goggles) to come up with creative test ideas.
Metaphors and analogies is a good way to get you started in new directions.
6. Models. A state model helps identify test ideas around states, transitions and paths. A system anatomy map shows what can be tested,
and can highlight interactions. Create a custom model using structures like SFDPOT from Heuristic Test Strategy Model.
A visual model is easier to communicate, and the modeling activity usually brings understanding and new ideas.
7. Data. By identifying intentional and unintentional data (there is always noise), you have a good start for a bunch of test ideas. Follow
easy and tricky data through the application, be inside and outside boundaries, use CRUD (Create, Read, Update, Delete), exploit
dependencies, and look at the data in many places.
8. Surroundings. Environment compatibility (hardware, OS, applications, configurations, languages) is an important testing problem,
but also investigate nearby activities to your product. By understanding the big system you can get credible test ideas that are far-fetched when looking at functionality in isolation.
9. White Box. By putting a tester’s destructive mindset on developers’ perspective of architecture, design and code, you can challenge
assumptions, and also find mistakes. Pay special attention to decisions and paths you might not understand from a black-box
perspective. Code coverage is not worthless, it can be used to find things not yet tested.
10. Public collections. Take advantage of generic or specific lists of bugs, coding errors, or testing ideas. As you are building your own
checklist suitable for your situation, try these:
• Appendix A of Testing Computer Software (Kaner, Falk, and Nguyen)
• Boris Beizer Taxonomy (Otto Vinter)
• Shopping Cart Taxonomy (Giri Vijayaraghavan)
• Testing Heuristics Cheat Sheet (Elisabeth Hendrickson)
• You Are Not Done Yet (Michael Hunter)
Learn some testing tricks or techniques from books, blogs, conferences; search for test design heuristics, or invent the best ones for you.
11. Internal Collections. Use or create lists of things that often are important in your context, some call these quality/test patterns.
12. Business Objectives. What are the top objectives for the company (and department break-downs) ? Are there any requirements
that contradict those objectives? Do you know the big picture, the product vision and value drivers?
13. Information Objectives. Explicit and implicit purposes of the testing are important guides to your effort.
If you don’t have them, you can create quality objectives that steer test ideas for any feature.
14. Product Image. The behavior and characteristics the product is intended to display might be explicit or implicit, inside the walls
and minds of the people producing or consuming the software. You will be able to write compelling problem reports if you know and
can show threats to the product’s image, e.g. by pointing to a violation of marketing material.
15. Product Fears. Things that stakeholders are really worried about are much stronger than risks, they don’t need prioritization, they
need testing. Typical hard-to-verify, but useful-for-testing fears are: loss of image, wrong decisions, damage, people won’t like the
software. Different people have different fears; find out which matters most.
16. Project Risks. Some of the difficult things in a project can be addressed by testing. You want to know about which functionality
developers are having trouble with, and you will adjust your schedule depending on risks that need mitigation first.
11
17. Rumors. There are usually lots of talk about quality and problems floating around. Some hurt the product and the organization. Use
the rumors themselves as test ideas. It is your mission to kill them or prove them right.
18. Product History. Old problems are likely to appear in new shapes. Search your bug/support system or create an error catalogue,
remember critical failures and root cause analysis. Use old versions of your software as inspiration and oracle.
19. Test Artifacts. Not only your own test ideas, logs and results can be used for sub-sequent tests, also try out test results from other
projects, Beta testing reports, usability evaluations, 3rd party test results etc. What questions do you want to be able to answer in future
status reports?
20. Debt. The idea that a debt is constantly growing because of all the shortcuts being made. This could be project debt, managerial
debt, technical debt, software debt, testing debt or whatever you wish to call it. If the team keep track on what is on the debt list, you can
map a set of test ideas against those items.
21. Business Knowledge. If you know the purpose of the software, and the context it operates in, you can understand if it will provide
vale to customers. If you can’t acquire this knowledge, co-operate with someone who knows the needs, logic and environment.
22. Field Information. Besides knowledge about customer failures, their environments, needs and feelings, you can take the time to
understand your customers both in error and success mode. Interview pre-sales, sales, marketing, consultants, support people, or even
better: work there for a while.
23. Users. Think about different types of users (people you know, personas), different needs, different feelings, and different situations.
Find out what they like and dislike, what they do next to your software. Setup a scene in the test lab where you assign the testers to role
play different users, what test ideas are triggered from that? Best is of course unfiltered information directly from users, in their context.
Remember that two similar users might think very differently about the same area.
24. Conversations. The informal information you get from people may contain things that are more important than what's included in
specifications. Many people can help you with your test design, some are better judges of importance, what can you gain from MIP:s
(Mention In Passing)? If developers know you can find interesting stuff, they might give you insider information about dubious parts of
the software. A set of questions to a developer might be an innocent “what do you think we should test?” or “what part of your code would
you have liked to do better?”
25. Actual Software. By interacting with the software, you will get a lot of ideas about what is error-prone, connected, interesting. If you
can eat your own dog food (euphemism: sip your own champagne), you are in much better position to understand what is important
about the software. If "Quality is value to some person", it is pretty good if that person is "me".
26. Technologies. By knowing the inner workings of the technology your software operates in, you can see problematic areas and
things that tend to go wrong; understand possibilities and security aspects; which parameters to change, and when. You can do the right
variations, and have technical discussions with developers.
27. Standards. Dig up relevant business standards, laws and regulations. Read and understand user interface standards, security
compliance, policies. There are articles out there that describe how you can break something even if it adheres to the standards, can you
include their test ideas in yours?
28. References. Reference material of various kinds is a good source for oracles and testing inspiration, e.g. an atlas for a geographic
product. General knowledge of all types can be handy, and Wikipedia can be enough to get a quick understanding of a statistical method.
29. Competitors. By looking at different solutions to similar problems you can get straightforward test ideas, but also a feeling of which
characteristics end users might focus on. There might be in-house solutions (e.g. Excel sheets) to be inspired by, and often there exists
analogue solutions for similar purposes. Can you gain any insightful test ideas from your competitors support, FAQ or other material?
30. Tools. If something can be done very fast, it is a good idea to try it. Tools are not only the means to an end, they can also be used as
the starting point for exploration.
31. Context Analysis. What else in the current situation should affect the things you test, and how? Do you know about the market
forces and project drivers? Is there anything that has changed that should lead to new ways of testing? What is tested by others?
32. Legal aspects. Do you need to consider contracts, penalties or other legal obligations? What would cost the company the most in a
legal issue? Do you have lawyer that can give you hints on what must be avoided?
33. Many Deliverables. There are many things to test: the executable, the installation kit, programming interfaces, extensions, code &
comments, file properties, Help, other documentation, Release Notes, readme:s, marketing, training material, demos etc. All of these also
contain information you can use as inspiration.
34. YOU! Your experience, knowledge, skills, feelings, subjectivity, and familiarity with problems. What do you want to test?
34 Sources for Test Ideas的更多相关文章
- Game Engine Architecture 7
[Game Engine Architecture 7] 1.SRT Transformations When a quaternion is combined with a translation ...
- iOS 并行编程:GCD Dispatch Sources
1 简介 dispatch source是一种用于处理事件的数据类型,这些被处理的事件为操作系统中的底层级别.Grand Central Dispatch(GCD)支持如下的dispatch sour ...
- ubantu10.04安装ns-2.34
LQ大神说是这个搭配才能完美移植leach 安装如下: 1. 安装必须的软件,因为版本较久远, sudo gedit /etc/apt/sources.list(大概是个意思) 把里面的内容换成: d ...
- es6 Object.assign(target, ...sources)
Object.assign() 方法用于将所有可枚举属性(对象属性)的值从一个或多个源对象复制到目标对象.它将返回目标对象. 语法 Object.assign(target, ...sources) ...
- http://mirror2.openwrt.org/sources/
http://mirror2.openwrt.org/sources/ Index of /sources/ ../ 1.0.4.3.arm 22-Dec-2008 20:29 93996 2.13. ...
- mysql-5.6.34 Installation from Source code
Took me a while to suffer from the first successful souce code installation of mysql-5.6.34. Just pu ...
- CSharpGL(34)以从零编写一个KleinBottle渲染器为例学习如何使用CSharpGL
CSharpGL(34)以从零编写一个KleinBottle渲染器为例学习如何使用CSharpGL +BIT祝威+悄悄在此留下版了个权的信息说: 开始 本文用step by step的方式,讲述如何使 ...
- 4.修改更新源sources.list,提高软件下载安装速度(提供Kali 2.0 更新源)
1.切换到root用户(如果已经是root用户就直接看第二步) dnt@HackerKali:~$ su 密码: 2.用文本编辑器打开sources.list,手动添加下面的更新源 root@Hack ...
- C#开发微信门户及应用(34)--微信裂变红包
在上篇随笔<C#开发微信门户及应用(33)--微信现金红包的封装及使用>介绍了普通现金红包的封装和使用,这种红包只能单独一次发给一个人,用户获取了红包就完成了,如果我们让用户收到红包后,可 ...
随机推荐
- Hive安装(三)之奇怪的错误
启动hive命令报错 “Metastore contains multiple versions” 解决方案: 因为hive metastore存储在mysql中,所以登录mysql,use hive ...
- 问题解决——MFC SDI程序 CFormView中控件随窗口缩放
从来都是做对话框程序,这次想做个SDI的程序,想着用一下带Robbin界面的office2007风格,就不用使用那些花钱的商业控件/UI库了. 如果你不想看我打的文字,可以直接拷走代码,自己声明上定义 ...
- Linux下配置PHP开发环境
转载于: http://www.uxtribe.com/php/405.html 该站下有系列PHP文章. 在Linux下搭建PHP环境比Windows下要复杂得多.除了安装Apache,PHP等软件 ...
- python datetime模块参数详解
Python提供了多个内置模块用于操作日期时间,像calendar,time,datetime.time模块,它提供 的接口与C标准库time.h基本一致.相比于time模块,datetime模块的接 ...
- 在 ServiceModel 客户端配置部分中,找不到引用协定“WebServiceTest.WebServiceSoap”的默认终结点元素。这可能是因为未找到应用程序的配置文件,或者是因为客户端元素
原文 http://blog.csdn.net/bugdemo/article/details/9083497 主题 技术 在引用WebService后,程序运行到实例化WebService时报错, ...
- 启动rabbitmq web管理后台插件
安装完rabbitmq server之后,访问http://server_ip:15672/ 无法打开网页, 通过netstat -ano |grep 15672 查看此端口号并没有开启 需要启用 ...
- 【node.js】安装express后,'express' 不是内部或外部命令的问题
因express默认安装是最新的版本,已经是4.x.x的版本.而最新express4.0+版本中将命令工具分出来了,所以必须要安装express-generator,执行: D:\TOOLS\Node ...
- log4j加载方式导致的bae和sae部署异常
这2天改在bae上部署代码,为了便于程序的功能测试,引入了log4j日志,但是问题来了..测试程序采用的是spring3.2.8框架搭建,web.xml引入日志代码为: <context-par ...
- Linux root 密码重置与用户管理
---forget root password restart your linux system press 'e' when start. press 'e' again then choose ...
- 《TCP/IP详解 卷一》读书笔记-----动态路由协议
1.以下条件只要有一个不满足,则需要使用动态路由协议:1)网络规模小,2)只有一个连接点用于连接其他网络,3)没有冗余的路由器(一般用作备份) 2.所谓动态路由就是各个路由器与自己相邻的路由器交换各自 ...