This document discusses the relationship between testers and developers and how to improve interaction between the two roles. It notes that while they sometimes have a "love-hate" relationship as they have different expertise and goals, they ultimately depend on each other to ensure high quality software. The document provides tips for when testers and developers should interact, such as during design, test case reviews, and bug fixing. It also recommends ways to build trust between testers and developers through clear communication and establishing processes for quality control.

1. Tester and Developer
Interaction
Liang Gao
Sigma Resources & Technologies, Inc.

2. Agenda
 Tester and Developer relationships development
 Which point tester and developer should interact during
the release process
 Test team and development team interaction
 Quality and process control

3. Tester and Developer
 A love and hate relationship
Test
Manager

4. Tester and Developer - Hate
 Testers are confused, do you want me to find more
bugs, or do you want me to find less bugs.
 Developers don’t want to be bothered: “Stay away from
me, can I just focus on coding?!”

5. Tester and Developer – Hate -2
 Developers don’t want to do any test
 Testers don’t know how to test – How can I know what
to test?

6. Tester and Developer – Love
 It is not actually love, it is that we depend on each
other to get our work done
 We both have one goal: less bug on the customer side.

7. Tester and Developer – Love - 2
 Tester need to get testing requirement from developer
 Tester need to confirm bugs from developer – Junk
bugs are counter-productive.
 Developer need tester on the system level view, on the
module dependencies
 Developer need tester to know how customer use the
system (a good tester is equal to a good system
designer)

8. Relationship Development
 Unlike us, developer is a subject expert lacking a
system point of view.
 Developer talks with different languages (white box
language)
Us Developer
系统屏幕上有乱码 我那个对象创建以后里
面有一个函数的输入验
证的不对
系统当机了 用 GDB 看了，那个
API 传出来的时候给我
的就是空指针， 这个问
题不是我需要解决的！

9. Communication is hard because
 Our technical expertise are different
 Engineers are good at doing, bad at talking
 Engineers are stubborn
 We like Ping Pong things, if not, we lose our patience
very quickly
 The result: we don’t trust each other

10. Communication is hard because
 GOOD TESTERS
 Get up to speed quickly
 Domain knowledge
 Ignorance is important
 GOOD DEVELOPERS
 Thorough understanding
 Knowledge of product internals
 Expertise is important

11. Communication is hard because
 GOOD TESTERS
 Model user behavior
 Focus on what can go wrong
 Focus on severity of problem
 GOOD DEVELOPERS
 Model system design
 Focus on how it can work
 Focus on interest in problem

12. Communication is hard because
 GOOD TESTERS
 Empirical
 What’s observed
 Skeptics
 GOOD DEVELOPERS
 Theoretical
 How it’s designed
 Believers

13. Communication is hard because
 GOOD TESTERS
 Tolerate tedium
 Comfortable with conflict
 Report problems
 GOOD DEVELOPERS
 Automate tedium
 Avoid conflict
 Understand problems

14. Tester should take the responsibility
 Because we understand customer
 Because we have more interface within the company
Tester Customer
Development
Manager
Documentation
Team
Product
Manager
SE/Support

15. Build Trust with Developer
 Be polite
 Response fast
 Emails
 Bugs
 Request/helps
 Speak up
 Design and Review meetings
 Email threads
 Show your technical expertise to impress them

16. 3 Occasions to interact with Developer
 Getting test requirement
 Control test case quality
 Bug

17. Getting Test Requirement
 Tester join the design phase review meeting
 Give design feedbacks from customer/system point of
view
 Easy of use
 Corner case user scenarios
 Give testability feedbacks
 Testability for faster and easy of debugging and
reproducing bugs
 Testability for automation consideration

18. Control test case quality
 Developer’s checklist
 Invite developer to attend test case review meeting
 Increase code coverage

19. Bug
 The universal language between tester and developer
 Reproduce
 If possible, face to face
 Fix verification
 Bug fix code check in code branch control

20. Interaction between Managers
 Pre-communication on acceptance testing
 转测试 check up
 Accept new version update

21. Pre-communication on acceptance testing
 Communicate with Dev manager, if those test cases
fail, testing team has the right to reject release
 Need to be blocker test cases, if fail, majority of the
test case can not run.

22. 转测试 check up
 Unit testing done?
 Auto regression done?
 Static code analysis done?

23. Accept new version update
 When can a testing team accept a new updated
software version?
 Is it an Agile development (XP programming)?
 Frequent update increase regression work load, and
introduce regression bugs
 Need to be firm on when to accept release – reduce
your engineers repetitive work

24. Process and Quality control
 Goal:
 reduce the developer and tester interaction time
 Increase the developer and tester interaction quality

25. Process and Quality control
 Tester attend design meetings
 # of accepted suggestions tight to KPI
 Developer attend test case review meetings
 # of accepted suggestions tight to KPI

26. Process and Quality control
Check out 私有代码库
代码同行评估
内测
Bug 修复
代码 Check in 评估会
研发 测试
新特性代码 Check in 流程
转测试
测试人员参加
同意否决
反馈意见
开发

27. Process and Quality controlBug 修复代码 Check in 流程
代码 Check in 流程
研发 测试
Check out 私有代码库
Bug 修复
代码同行评估
Bug 验证
代码 Check in
不通过 通过
修改意见
测试人员参加

28. Process and Quality control
代码库 开发 测试
反馈意见
手工第一轮
手工第二轮
手工第三轮
手工第四轮
开发新
特性
允许新特性代码 Check
in
发布日期
只允许 Bug 修复 Check in
只允许重大 Bug 修复 Check in, 中
等以下 Bug 不修复，会放在 Release
note 中

29. Tips for Testing and Dev Manager
 Need to both agree goal is to release the product on-
time with Quality
 Need to know outside the product organization, they
don’t know the difference between us
 Need to know and understand each other’s working
flow and process
 Dev manager need to let your team understand the
important of unit-test

30. Tips for Boss
 When do scheduling, give enough testing time
 Quality VS time to market, give the guidance of the
whole team what to balance.
 Use testing group as tool and service to the overall
product quality, not a service to the dev team.

31. Summary
 Have developer friends makes your life easy
 Tester should be pro-actively build trust with developer
 Put your smile on! And communicate….

32. Summary

33. Thank you!
Any question, please contact Liang Gao
E-mail: lgao@sigma-rt.com