不是，是requirement写在Jira里面。Agile的story一般写成这样的BDD requirement

tracyd(等待明天)

Given: tracyd access rolia.net to input the username and password
When: click "login" button to login successfully on rolia.net
Then: she is able to reply someone's post with short text on title only or long text in both title and body by clicking submit button.

https://cucumber.io/docs/gherkin/reference/

(#14078049@0)
Last Updated: 2021-10-30

那 QC 是干什么吃的？ -troyd(小C); 2021-10-30 (#14076152@0)

Developer自己负责了，减少了个环节，预算充裕的项目可以搞个加强配置，也算给就业做贡献啦。 -ff2021(ff2021); 2021-10-30 (#14076175@0)

这算不算最大的 conflict of interest？ -troyd(小C); 2021-10-30 (#14076325@0)

有一点儿，DEV一般不喜欢别人对自己的工作指手画脚，所以设几个硬指标，med level可以TDD，senior就无所谓了。很早的一个PROJECT, QA部门按照GOOGLE的理念组织，觉得挺好的，以后基本这样走的。 -ff2021(ff2021); 2021-10-30 (#14076542@0)

服装啊芯片啊这种工厂需要的是QC，有很多统计学的知识，怎么减少坏片率。 -drmf(1234); 2021-10-31 (#14078192@0)

看来你们公司还挺正规的。qa预算也挺充足。像样一点的公司都应该这样。面试的时候，如果面试官和我介绍的时候说这些，我会很乐意和他们继续谈下去。 -tracyd(等待明天); 2021-10-30 (#14076306@0)

Is QA required for software development by US laws? -111111(快乐老家); 2021-10-30 (#14076482@0)

Depends on the industry, if your prod if bundled with hardware, eg medical equipment, yes you need to follow. Not what I'm aware of in most cases. -ff2021(ff2021); 2021-10-30 (#14076572@0)
美国一般叫SDET. software development engineer in test.美国developer 叫engineer 。加拿大只有考到证书的才能叫engineer. -drmf(1234); 2021-10-31 (#14078195@0)

请教一下，什么叫面向JIRA的QA? JIRA不是一个项目管理工具吗。我猜想是Agile开发模式里的QA? -fourseasonscan(有话直说); 2021-10-30 (#14076604@0)

AGILE具体落实下来，JIRA是QA做测试的依据，BA/PM在创建TICKET的时候是按照一定的格式写清楚，是DEV/QA和BUSINESS之间的CONTRACT。 -ff2021(ff2021); 2021-10-30 (#14076636@0)

你的意思是test　case　BA　写？ -sxffff(lookingforjob); 2021-10-30 (#14076671@0)

BA主要写好BRD和TICKET， TICKET更重要一点吧。 -ff2021(ff2021); 2021-10-30 (#14076811@0)

ticket 是什么，　是test　case吗？ -sxffff(lookingforjob); 2021-10-30 (#14076884@0)

还真不知道国内咋叫呢，不过不是test case. -ff2021(ff2021); 2021-10-30 (#14076901@0)

我说的是加拿大，我问的是ticket的内容。 -sxffff(lookingforjob); 2021-10-30 (#14076934@0)

按照标准格式，除了需求写清楚外，最后一部分是完成条件，一般QA不单独创建TICKET了，直接按流程走。如果公司对QA的OKR有要求另说，和国内大厂有点交流，流程和这里差不多。不过国人多惜字如金。 -ff2021(ff2021); 2021-10-30 (#14077039@0)

QA不再单独创建ticket，就是说不用写test　case了？acceptance criteria 通常非常high　level，　不能用的。 -sxffff(lookingforjob); 2021-10-30 (#14077065@0)

不对QA有硬性要求，除非在CI里要覆盖，说实话有些功能测试的确挺难写的。做过的项目里面还没有达到日部署的，朋友公司里有这样的要求，他们是必须写功能测试的。 -ff2021(ff2021); 2021-10-30 (#14077082@0)

就是说不用写test　case，　BA也不写，QA也不写？很多项目里BA写test case，这个很正常，用什么工具去管理，是另一回事，但都不写就没见过了。 -sxffff(lookingforjob); 2021-10-30 (#14077124@0)

自动测试肯定得写的， -ff2021(ff2021); 2021-10-30 {254} (#14077730@0)
多多易善，现在部署了越来越多的AI，对QA是一个挑战，有时候得要求数据组单独写测试，QA可以搞个BASELINE测试，不过难度大，这个必须是独立测试，和双盲实验差不多。还有MOBILE的可用性测试，反正是架一排手机测，BA写测试的我还真没见过，我经历过的项目，BA都偏BUSINESS。

还是没明白你的项目里QA到底要干什么，写自动测试？ -sxffff(lookingforjob); 2021-10-30 (#14078045@0)

是的 -ff2021(ff2021); 2021-10-30 (#14078123@0)
现在很少见纯手工的测试了，医疗设备除外 -drmf(1234); 2021-10-31 (#14078198@0)

user story -drmf(1234); 2021-10-31 (#14078197@0)

不是，是requirement写在Jira里面。Agile的story一般写成这样的BDD requirement -tracyd(等待明天); 2021-10-30 {367} (#14078049@0)
- Given: tracyd access rolia.net to input the username and password
- When: click "login" button to login successfully on rolia.net
- Then: she is able to reply someone's post with short text on title only or long text in both title and body by clicking submit button.
https://cucumber.io/docs/gherkin/reference/

这个就是BA写test case啊，难到不是？ -sxffff(lookingforjob); 2021-10-30 (#14078062@0)

dev的user story 的acceptance criteria 是product owner来写。qa以此为依据进行测试，只于什么test case要测试自己想 -drmf(1234); 2021-10-31 (#14078196@0)

BDD? 挺高级的. -fourseasonscan(有话直说); 2021-10-30 (#14076720@0)

一个项目试过BDD，挺好的，有点影响开发速度，在DEV里推有点阻力，后来就不做强制要求。 -ff2021(ff2021); 2021-10-30 (#14076826@0)

JIRA是个项目管理的Tool。有些地方直接用了 DevOps里自带的Tool。 -hutuhao(忙!); 2021-10-30 (#14076732@0)

你这是很负责的QA。去过不少地方没见过几个像你说的或接近你说的那样的。我想我们这里就缺你这样的QA，就是rate80多的QA都做不到你说的。 -hutuhao(忙!); 2021-10-30 (#14076739@0)

lol 同“没见过” 。"unit test code coverage 100%" / "DEV对待自己的代码要像对待自己的孩子一样" ---- 从我 review 的大部分代码来看，得算是 child abuse 了 loooool -xmlhttprequest(build5381); 2021-10-30 (#14076834@0)

唉，也是没办法，习惯了也就这样了，其实谁不愿意偷点懒啊。 -ff2021(ff2021); 2021-10-30 (#14076865@0)

呵呵，我是programmer, 心理上是。 -ff2021(ff2021); 2021-10-30 (#14076848@0)

QA哪有那么大权力，最多多发几个ticket。以前合作的软件开发部门，QA能做到5:1就偷笑了。硬件开发部门能做到10:1就不错了。认得一个芯片公司比例是50:1,几年前公司重组后干脆是设计公司和测试公司分开，dev要自己做很多测试才能交付测试公司。 -projects(pj); 2021-10-30 (#14076866@0) +1

“dev要自己做很多测试才能交付测试公司”，我个人觉得这才是正常的，不然dev太好混了…… -guestagain(guest again); 2021-10-30 (#14076903@0) +1
如果事关公司的关键业务，得据理力争，也省不了几个钱。 -ff2021(ff2021); 2021-10-30 (#14076911@0)
QA有很大权力。能不能上production就靠QA的一句话. -hutuhao(忙!); 2021-10-30 (#14076915@0) +1

因公司或产品而异吧？公司的服务/产品面对的市场或客户不同，对产品的质量要求/追求也有所不同...手上找到多少只虫虽然是QA说话的依据，但有时对算不算是虫也有内部争议的，最后还是看客户要求、影响程度及大局而定... -see1see(Isee); 2021-10-30 (#14076972@0) +1

LOL，bug从某种角度上来说算是feature. DEV都这么说。 -ff2021(ff2021); 2021-10-30 (#14077052@0)

呵呵，敝帚也总有自珍的理由嘛，每行代码不是DEV身上的肉就是毛..... -see1see(Isee); 2021-10-30 (#14077137@0)
那是bug 太大了，研发的时候完全没有考虑到 -drmf(1234); 2021-10-31 (#14078200@0)

就我们公司的经验看，QA没那么大的权利，一般都是PO说了算 -legend23(课长); 2021-10-30 (#14076875@0)

我们QA可以raise red flag, 最终的green flag还是PO决定的。 -ff2021(ff2021); 2021-10-30 (#14076895@0)

就是说red flag不是真正的red flag -sxffff(lookingforjob); 2021-10-30 (#14076977@0) +1

不是真正的，不过PO一般对技术细节不太清楚，还是基本听QA的。 -ff2021(ff2021); 2021-10-30 (#14077024@0)

我见过的项目，架构师的意见最重要。 -sxffff(lookingforjob); 2021-10-30 (#14077401@0) +1

架构师的意见在前期比较重要，实施完了 bug 有多少 / 能不能上线和架构师关系不大 ---- 瀑布式一般 QA manager 有一票否决权，agile 一般由 PO 决定。 -xmlhttprequest(build5381); 2021-10-30 (#14077431@0)

当然不是架构师的决定，是他的建议权重比较大，如果他评估了一个bug，说不应该上线，PO敢上吗？ -sxffff(lookingforjob); 2021-10-30 (#14078051@0)

看人吧，有的比较倚重架构师，我倾向看重“码农”的作用，DEV可塑性都很大的，其实哪里都有一两个公司倚重的大拿。 -ff2021(ff2021); 2021-10-30 (#14077716@0)
构架师的想法很可能与不会coding 的用户想法脱节 -drmf(1234); 2021-10-31 (#14078203@0)

这种问题一般不是应该在系统分析/调研阶段由BA搞掂的么？架构师是在BA报告基础上展开设想的，如果BA报告有误导就难说了，当然，在系统框架设计时也应该需要不时核对客户需求的，但前期报告有误导/疏漏那是BA的责任... -see1see(Isee); 2021-10-31 (#14078441@0)

架构师考虑的是non-functional的影响，例如这个bug，会影响performance吗，会造成data corruption 吗？如果上了production再fix，要多少工作量，上下游的系统有什么影响，要做什么对应的改动，等等。 -sxffff(lookingforjob); 2021-10-31 (#14078643@0) +1

不是，是requirement写在Jira里面。Agile的story一般写成这样的BDD requirement

Replies, comments and Discussions:

More Topics