How to work as a "QA Engineer" on a project as opposed to a member of a "Test Driven Development Team" ?

Question

Sincerest apologies if I'm asking this question in the wrong place. (possibly one of the mini-stack overflows specific to career advice and QA) I've spent a significant amount of time recently learning about and implementing unit testing frameworks for our projects.

Prior to the introduction of a unit testing framework, our method was to code, test manually, commit, hope things don't break down or up stream. A very reactive system.

Now, we all understand that things need to be tested and that automated testing is efficient and good. However, the role currently seems to be "you do the testing" and "write automated tests"

Doing manual testing is possible, but feels overwhelming (as there are bugs all the time) and a lot like an underutilization of my skills.

I'm having difficulties in accomplishing the second part of the request. Writing automated tests is difficult if the code isn't designed to be testable.

I've got the responsibility for QA - but - I can only find resources on Test Driven Development.

What methods can I use to become more effective in my QA role where the other developers are not yet writing with concern to creating testable code?

Answer 1

I think the developers should at least write unit tests (possibly using TDD). This is the minimal standard to guarantee that the code they check in is potentially working.

I understand the QA role as someone providing higher level testing, to make sure that the software meets the clients requirements, so you wouldn't really test individual classes but modules or the whole application. Even if the developers don't provide unit tests, you should still be able to automate end-to-end tests (this includes usually automating the set up of test environment, etc.) - your work will be more frustrating though :)

Answer 2

I would think that getting the developers up to speed with unit testing would be your main concern! That way, everyone's a winner.

Until that point, as you are in effect working with legacy code, Michael Feather's book Working Effectively with Legacy Code apparently contains a lot of useful advice on testing such code.

You probably know this already, but also check out Behaviour Driven Development (BDD), which includes a lot about creating automated integration tests, which I think would be of interest to you.

Answer 3

In my experience, people don't turn around over night about writing tests-- convincing them is a process. Programmers will eventually reluctantly try it, but it is still weeks or months before they are advocates and regular practitioners. That doesn't mean you should give up, just recognize that it's an uphill battle, and needs support from above, and some good advocates from within the team.

You can dive into writing tests yourself:

Given that about half of bugs are "regressions" of previous bugs, in your situation I would focus on writing regression tests for new and critical bugs. This will aid you significantly in your normal Q.A. work, but will also be an excellent safety net for future bugs.

Even if you can't convince developers to write tests immediately, you will have some valuable tests that they will soon see the value of. This work may help in the selling the idea of developers writing unit tests.

Answer 4

I was working in a similar role several years ago, so I can understand your troubles. For getting the developers up to speed with unit testing, I suggest mentoring and pair programming sessions. Writing the first unit test for a badly designed class can be a real pain. It is easier and more fun if there is two of you - not to mention lowering the chance of making stupid mistakes in the initial refactorings.

The Feathers book, as already mentioned by @Grant, is an invaluable resource for this. Be patient and persevere through the initial months, before the results (both in test coverage and in team attitude) slowly start to show.

You must have strong management support as well - without this, there is no point trying. The management must understand that building unit tests is an investment, which uses a significant part of your time and energy now, and it will only pay back in the future years. If they insist on keeping up the same deadline pressure as ever, you will inevitably fail. Developers can't learn and practice new skills and ways of thinking if they are highly stressed and/or demotivated.

(The other side of the coin is of course that one must think of whether or not the investment will bring profit. Building unit tests for legacy code is only worth it if the management foresees that the product will be maintained and used for many years to come.)

Answer 5

The problem with the names Test-driven development and unit-testing, is that they imply they're about testing software. They are not. TDD and unit-testing are about design and they are essentially the developers' responsibility.

The QA Analyst's role is still of the utmost importance on any team practicing TDD and it will be a long, long time before you find yourself out of work as a conscientious QA!

Take a look at Acceptance test driven development and consider getting involved more at the requirements stage by writing automated acceptance tests, perhaps using a tool such as FitNesse.

Manual, exploratory testing still has its place, of course. But you should consider repeating regression testing as a contravention of your basic human rights!