• 瞬联软件--web 测试 at 2017年12月14日

    是否需要英文简历啊

  • 瞬联软件--web 测试 at 2017年12月14日

    工作地点在哪?

  • 问题已解决 at 2017年11月03日

    目前我们也是这样的模式:
    1、产品和开发过需求的会议,是让开发评估需求的可行性,其中还包括实体和数据流转的细节。
    2、可行性会议通过后,产品需要按会议结果修改然后发布需求。
    3、在需求发布出来后,测试需要看需求&理解需求。这时候分为2种情况:
    a、需求文档足够详细,测试可以直接按现有需求文档写用例;
    b、需求文档存在细节的疏漏,测试需要汇总然后发布给产品/开会讨论,让产品完善需求。
    产品修改的需求都需要邮件通知给开发。
    c、需求存在设计疏漏(毕竟测试是最了解现有系统的人),这个时候产品、开发、测试都需要开会讨论了。
    在会上定下来最新的需求。

  • (1)年龄:25
    (2)测试从业时间:2年
    (3)目前的瓶颈:公司现状无法支撑自动化+自己私下弄力不从心
    (4)职业规划:如上,对技术没那么热衷,在考虑要不要转行/换方向。具体未定
    (5)所属公司类型:小型互联网
    (6)对小编的批评:
    对小编文中的比例来源很感兴趣,如果能说明一下来源可能会更好
    (7)畅所欲言:
    个人感觉,对于做产品的公司,产品终归是要人去测试的。未来即使AI运用于测试行业,功能测试还是免不了的。
    当然,有极大可能性是产品团队做功能测试,测试团队根据算法、工具等测试代替人工的功能测试。

  • 坏处就是,某段时间跟需求人员的关系很紧张,会议室里面经常会撕起来。。。

  • 日常还有一个策略:
    交付的需求存在大量不清晰的时候,测试评审的时候就会自己列出一个表格,统计所有不清晰的点。
    然后发给需求人员,抄送给全项目组的人。
    必要时,要进行会议讨论的。

    这种模式下,需求评审占了很多时间😂

  • 目前产品迭代到第三期了,没楼主问题那么久远,但是也有很多问题。
    目前我采取的策略就是:从需求评审到测试结束,过程中就是不断不断不断不断给需求提bug,不懂的全给他们提,提到他们不耐烦把需求补清楚为止😂

  • 如何量化测试覆盖率 at 2017年09月13日

    厉害了👍 👍 👍
    三条回复的每一条都要再仔细消化消化

  • 据说发布会他们自己试了一次都解锁失败了😂

  • 如何量化测试覆盖率 at 2017年09月13日

    还是要灰盒测试甚至白盒测试啊
    黑盒这些都没法弄

努力成为不一样的烟火!