Question: Traditional tester (QA)'s role in TDD?

[Chengwei Lin]

Hello everyone,

If I understand it correctly, in TDD all the automated tests are written by developers themselves, whether they be end-to-end, integration, or unit tests. So my question is - what would be the traditional tester (QA)'s role in TDD? What would they do if most of the tests are written and automated by developers?

I ask this because when promoting TDD in an enterprise, one of the challenges seems to come from the worries of traditional testers. I tried to explain that, in addition to functional tests that TDD covers, there are other areas of tests that need traditional tester's involvement, such as performance tests, stress tests, exploratory tests, etc, which may not be covered by TDD.

I was wondering if what I said is correct and persuasive, and if you have some thoughts or experience about this?

Thanks,

Chengwei

[Steve Freeman]

This is a long-standing question in the "Agile" world. First, TDD  is a design/coding technique that is about fast feedback at multiple levels, which also generates a suite of regression tests. The role of QA should become more interesting with this in place because much of the mechanical work of script-following will have been automated, leaving time for the deeper investigations you mention--and the systems should be easier to test as a side-effect of full TDD. Some QA people are up for this and some aren't. There's an understandable fear for some QA that getting too close to the developers means that assumptions won't be tested properly. That needn't be the case and good QA people and move to an expert/advisory role during the requirements and development process to make sure that everything is considered, and to educate the developers.

There's a lot of material out there on this sort of thing.  A good start is Janet Gregory and Lisa Crispin's "Agile Testing" book.

S

[Chengwei Lin]

Thanks for quick feedback, Steve.

In addition to the fear that assumptions won't be tested properly, it feels to me that there is also a fear of "job security" for the QA people, and that fear becomes an obstacle when trying to promote TDD in an enterprise.

I will take a look at the book you recommend and see if I can find a win-win solution for both parties.

Thanks,

Chengwei

Steve Freeman 在 2021年10月23日 星期六下午3:32:13 [UTC+8] 的信中寫道：

[Steve Freeman]

Yes. That's also a problem for people who've built their careers doing one thing and are now being asked to do something else. This is an interesting take
https://dhemery.com/articles/resistance_as_a_resource/

I don't know what your role is but, if you don't have the necessary senior commitment, you might consider trying to make things work locally for you before trying to change the world. You risk creating a bubble but you can also create some evidence of results.

Good luck.

S

[Chengwei Lin]

Thanks for the interesting article and the advice. The article is a bit long but I will surely read it.

I'm a senior staff engineer and have been a TDD advocate in my company for some time. I did get the senior management's attention and had GOOS study groups department-wise. We conducted some small local pilots which were not very successful but were rewarding. Unfortunately, things came to a halt after a company-wise reorganization.

Nevertheless, I'm still a believer of TDD, and trying to make myself more learned on it.

Thanks,

Chengwei

Steve Freeman 在 2021年10月25日 星期一上午1:28:51 [UTC+8] 的信中寫道：

[Steve Freeman]

That all sounds very familiar. I'm now at a point where I don't try to "sell" TDD to people who aren't interested any more, it wastes everyone's time, but I'm happy to support anyone who is looking for help.

Good luck.

S