QA’s work way in TDD

红太狼 2021-11-29 09:40 144阅读 0赞

Recently I am studying TDD. When had some discussion with other people, I has been asked about some questions about what QA could do in a team which approach TDD, especially for those manual QA members. Initially I didn’t consider this was a problem. After several free discussions, I understood that the concern behind of this question was that if QA was still needed if the team adopts TDD.

TDD will require the engineer to write test case first before write any implementation codes. The whole team will discuss with product owner about the story DONE criteria and create the acceptance test case based on that. Most of the teams will use Fit as acceptance test tool. Then after that, team will try to write the backend codes of those acceptance test cases, then implement some function codes to pass the test. During function codes implementation, engineer will implement some unit test code first, then write the function codes to pass the unit test.

So, TDD needs high programming skills for test as well as development. Those may not available for QA members, especially for manual QA members. So, dose it mean that we don’t need QA in a team which adopted TDD?

Of cause it is not true. Although TDD will drive the team to automatic most of the test (unit test, integration function test, system test, performance test, etc), but it still cannot cover all of the quality criteria, for example, the UI layout, user experience and etc. We still need QA to help on those validation, and not only these. Actually, in a team that use TDD, QA’s responsibilities have been changed a lot.

For my personal experiences, QA will be the person who is more familiar with the whole system than DEV because they need to test it as a whole but DEV will only focus on part of the system functions at most of cases. So QA will understand the whole business better. Another strength is that QA always has more knowledge about how to do the test. So they can design better test cases. Thus, QA may act as bridge between PO / customer and DEV to help them to understand each other better. Also they will be very helpful for the DONE definition setup.

So the possible QA’s work way in a team that use TDD may like this. During the planning meeting, QA will be the driver to ask PO about the acceptance criteria of each user story. Then they work with DEV and PO together to figure out the test case based on Fit which will define DONE definition clearly for everyone. After the planning, the team will start to implement sprint. They will pick one user story according to the priority. Automation test QA will start to write the test fixtures pair with Dev, these may include function test fixture and unit test fixture. Of cause, Dev can do this as well. Actually in this phase, automation QA is part of development group as well as Dev. And manual test QA will continue to design more test cases in order to cover the whole scope. Some of these test cases will be automatically also and some of them will be able to be manual executed only. All of the test cases should be passed as the most important signal for Sprint DONE. The process like bellow,

![image][]

![2009102319212113.jpg][]

Above all, in the team that adopt TDD, the role of QA is do needed and is required for more responsibilities. They need more skills include knowledge of business, programming, testing, communication and etc. They need to embrace this change to contribute more in a team.

转载于:https://www.cnblogs.com/RelaxTintin/archive/2009/10/23/1588863.html

[image]: /images/20211129/278753ae5d6f4b11be168fbc67ceb3d1.png
[2009102319212113.jpg]: /images/20211129/bc5150b7cd4c4eec9289af775c76f08a.png