×

Loading...
Ad by
  • 最优利率和cashback可以申请特批,好信用好收入offer更好。请点链接扫码加微信咨询,Scotiabank -- Nick Zhang 6478812600。
Ad by
  • 最优利率和cashback可以申请特批,好信用好收入offer更好。请点链接扫码加微信咨询,Scotiabank -- Nick Zhang 6478812600。

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

  • 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.
Sign in and Reply Report

Replies, comments and Discussions:

  • 工作学习 / 事业工作 / 也聊聊软件项目的QA +2

    QA是整个系统上线的最后一道看门人,好的QA得抓住重点,避免陷入繁琐的细节,不好招。做过的PROJECT,一般遵循几个原则:

    - DEV和QA按照3:1 ,如果是公司关键项目,预算照2:1
    - DEV对系统的功能和性能负责,对待自己的代码要像对待自己的孩子一样。
    - DEV提交的线上代码,UNIT要100%测试覆盖每一行,CODE INSPECTION不能有WARNING,包括UNIT的代码,BUG必须写UNIT。
    - DEV需要负责部分IT-功能测试,这部分的要求不太严
    - QA的测试主要面向JIRA,完全INDEPENDENT,包括IT,UAT,具体比例自行决定,QA对是否上线有一票否决权, QA可以负责部分CI,只要不耽误进度可以自由选择。

    混饭多年,积累了一点浅见,肉谭各位大佬见笑

    • 那 QC 是干什么吃的?
      • Developer自己负责了,减少了个环节,预算充裕的项目可以搞个加强配置,也算给就业做贡献啦。
        • 这算不算最大的 conflict of interest?
          • 有一点儿,DEV一般不喜欢别人对自己的工作指手画脚, 所以设几个硬指标,med level可以TDD,senior就无所谓了。很早的一个PROJECT, QA部门按照GOOGLE的理念组织,觉得挺好的,以后基本这样走的。
      • 服装啊芯片啊这种工厂需要的是QC,有很多统计学的知识,怎么减少坏片率。
    • 看来你们公司还挺正规的。qa预算也挺充足。像样一点的公司都应该这样。面试的时候,如果面试官和我介绍的时候说这些,我会很乐意和他们继续谈下去。
    • Is QA required for software development by US laws?
      • 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.
      • 美国一般叫SDET. software development engineer in test.美国developer 叫engineer 。加拿大只有考到证书的才能叫engineer.
    • 请教一下,什么叫面向JIRA的QA? JIRA不是一个项目管理工具吗。我猜想是Agile开发模式里的QA?
      • AGILE具体落实下来,JIRA是QA做测试的依据,BA/PM在创建TICKET的时候是按照一定的格式写清楚,是DEV/QA和BUSINESS之间的CONTRACT。
        • 你的意思是test case BA 写?
          • BA主要写好BRD和TICKET, TICKET更重要一点吧。
            • ticket 是什么, 是test case吗?
              • 还真不知道国内咋叫呢,不过不是test case.
                • 我说的是加拿大,我问的是ticket的内容。
                  • 按照标准格式,除了需求写清楚外,最后一部分是完成条件,一般QA不单独创建TICKET了,直接按流程走。如果公司对QA的OKR有要求另说,和国内大厂有点交流,流程和这里差不多。不过国人多惜字如金。
                    • QA不再单独创建ticket,就是说不用写test case了?acceptance criteria 通常非常high level, 不能用的。
                      • 不对QA有硬性要求,除非在CI里要覆盖,说实话有些功能测试的确挺难写的。做过的项目里面还没有达到日部署的,朋友公司里有这样的要求,他们是必须写功能测试的。
                        • 就是说不用写test case, BA也不写,QA也不写?很多项目里BA写test case,这个很正常,用什么工具去管理,是另一回事,但都不写就没见过了。
                          • 自动测试肯定得写的,
                            多多易善,现在部署了越来越多的AI,对QA是一个挑战,有时候得要求数据组单独写测试,QA可以搞个BASELINE测试,不过难度大,这个必须是独立测试,和双盲实验差不多。还有MOBILE的可用性测试,反正是架一排手机测,BA写测试的我还真没见过,我经历过的项目,BA都偏BUSINESS。
                            • 还是没明白你的项目里QA到底要干什么,写自动测试?
                              • 是的
                              • 现在很少见纯手工的测试了,医疗设备除外
              • user story
          • 不是,是requirement写在Jira里面。Agile的story一般写成这样的BDD requirement
            • 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.
            • 这个就是BA写test case啊,难到不是?
          • dev的user story 的acceptance criteria 是product owner来写。qa以此为依据进行测试,只于什么test case要测试自己想
        • BDD? 挺高级的.
          • 一个项目试过BDD, 挺好的,有点影响开发速度,在DEV里推有点阻力,后来就不做强制要求。
      • JIRA是个项目管理的Tool。有些地方直接用了 DevOps里自带的Tool。
    • 你这是很负责的QA。去过不少地方没见过几个像你说的或接近你说的那样的。我想我们这里就缺你这样的QA,就是rate80多的QA都做不到你说的。
      • lol 同“没见过” 。"unit test code coverage 100%" / "DEV对待自己的代码要像对待自己的孩子一样" ---- 从我 review 的大部分代码来看,得算是 child abuse 了 loooool
        • 唉,也是没办法,习惯了也就这样了,其实谁不愿意偷点懒啊。
      • 呵呵,我是programmer, 心理上是。
    • QA哪有那么大权力,最多多发几个ticket。以前合作的软件开发部门,QA能做到5:1就偷笑了。硬件开发部门能做到10:1就不错了。认得一个芯片公司比例是50:1,几年前公司重组后干脆是设计公司和测试公司分开,dev要自己做很多测试才能交付测试公司。 +1
      • “dev要自己做很多测试才能交付测试公司”,我个人觉得这才是正常的,不然dev太好混了…… +1
      • 如果事关公司的关键业务,得据理力争,也省不了几个钱。
      • QA有很大权力。能不能上production就靠QA的一句话. +1
        • 因公司或产品而异吧?公司的服务/产品面对的市场或客户不同,对产品的质量要求/追求也有所不同...手上找到多少只虫虽然是QA说话的依据,但有时对算不算是虫也有内部争议的,最后还是看客户要求、影响程度及大局而定... +1
          • LOL,bug从某种角度上来说算是feature. DEV都这么说。
            • 呵呵,敝帚也总有自珍的理由嘛,每行代码不是DEV身上的肉就是毛.....
            • 那是bug 太大了,研发的时候完全没有考虑到
    • 就我们公司的经验看,QA没那么大的权利,一般都是PO说了算
      • 我们QA可以raise red flag, 最终的green flag还是PO决定的。
        • 就是说red flag不是真正的red flag +1
          • 不是真正的,不过PO一般对技术细节不太清楚,还是基本听QA的。
            • 我见过的项目,架构师的意见最重要。 +1
              • 架构师的意见在前期比较重要,实施完了 bug 有多少 / 能不能上线和架构师关系不大 ---- 瀑布式一般 QA manager 有一票否决权,agile 一般由 PO 决定。
                • 当然不是架构师的决定,是他的建议权重比较大,如果他评估了一个bug,说不应该上线,PO敢上吗?
              • 看人吧,有的比较倚重架构师,我倾向看重“码农”的作用,DEV可塑性都很大的,其实哪里都有一两个公司倚重的大拿。
              • 构架师的想法很可能与不会coding 的用户想法脱节
                • 这种问题一般不是应该在系统分析/调研阶段由BA搞掂的么?架构师是在BA报告基础上展开设想的,如果BA报告有误导就难说了,当然,在系统框架设计时也应该需要不时核对客户需求的,但前期报告有误导/疏漏那是BA的责任...
                  • 架构师考虑的是non-functional的影响,例如这个bug,会影响performance吗,会造成data corruption 吗?如果上了production再fix,要多少工作量,上下游的系统有什么影响,要做什么对应的改动,等等。 +1