51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2009|回复: 0
打印 上一主题 下一主题

国外测试实践

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2005-11-23 23:01:16 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
The projects that come to me are from 3 countries (a partnership).
Every country has it's own Quality Office and is testing the projects
from the other two (of course with exceptions). Like a circle. We're
doing so just to avoid the "hard discutions" between testers and
programmers. Every project is characterized by an Quality Index that
is showing how well it was programmed, how clean the programmers
worked, if they respected the standards and so on ...

The life of one project follows the line: programmers, testing,
pre-production area and production. The testing part is alternating
with the pre-production untill the project receives the authorization
to enter the production area. In production area there is no room for
bugs, because is the final destination for that project.

When a project enters in Testing I'm doing my job. For each one we
have to do a set of tests depending on the project: code review,
functional check, security check, GUI, profiling (memory, CPU)... etc.
For help we use some tools like: JIRA, Confluence, DevPartner and a
few tools that we developed in time.

Sometimes if a project is very very big and is aproaching the "dead
line" we are spliting the testing part for all the Quality Office
Teams (from all 3 countries). So, one team is doing code review,
another profiling ... and in the end, each team gives an authorization
for what they have tested. If one of the authorization is "denied" the
project returns to the developers, the bugs are beeing resolved and
then it comes back in testing. In this case the developers must
specify in witch parts they made changes so that we know where to
focus our atention. (some tests can be skipped, other tests must be
created...)

The comunication between testers and developers is very good due to
the tools we use. We have notifications programs with witch testers
can assign (open) an issue to the "one in charge to resolve that
issue", and this person can review an resolve the problem and change
the status of that issue into "resolved". When the project comes back
in testing, testers monitor if all the issue were really resolved and
"close" them for good.

Every bug reported can have one of the following priority: trivial,
minor, major or blocker. A "blocker bug" blocks the entering into
pre-production area or producion. A "major blocker" must be resolved
before entering the production.

这个实践介绍中最吸引我的是他们通过Quality Index来判断每一个过程的质量。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-26 04:04 , Processed in 0.063455 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表