QA in an Extreme Programming Agile Environment

Question

I've been a QA in an agile environment before, but I've now found myself at a company that practices Extreme Programming to the T. I was wondering where you guys think that a somewhat traditional tester might fit into such an environment or development cycle. In particular, all of the devs here are iterating with TDD and writing their own automated tests and pushing to their CI as soon as they are done.

I was hoping someone might direct me to some literature on the matter or share some of their experience.

Answer 1

The short version: regardless of the development methodology, your role is to provide information about the overall quality of the application. You do that via testing anything that isn't included in the developer-maintained automation, and reviewing the developer-maintained automation.

The long version: This question and its answers is a good starting point. Moving beyond that, you've got several directions you can go with testing in this environment:

• Test the requirements/user stories/use cases - whatever the requirements documents are called, the dev team is working of something that says what to build and possibly what the user acceptance tests are. Part of your role is to review these in context with the rest of the application and look for hidden assumptions, missed or invalid conditions, and other such things. With a large, complex product, that means you'll need a lot of knowledge about the product and the customer/user base.
• Test the tests - If you've got any experience with automation, review the dev automation code, and see what, if anything, you can find that's been missed. Even in the best environment with the best developers, something will be missed. In a large, complex product, it's a guarantee that some conditions will be overlooked.
• Test the user interface - there are no automation tools that can substitute for an intelligent human interacting with the application and finding places that are awkward, ugly, or just plain counterintuitive. If you want to really have fun, you can play with personas here and mimic different user profiles (including the unexpected ones, like the CEO's bored 3-year-old who likes the pretty pictures and flashy lights). This is also where you find if form fields have been protected against illogical inputs (negative ages and so forth), cross-validation (birthdate is later than hire date, configuring on-sale periods that can never occur, being able to configure a setting that's incompatible with something you've already selected, and so forth).
• Test the end-to-end processing - It's almost guaranteed that the full process flow was developed in separate slices. If the developers didn't have the full flow in mind while they built, there will be gaps (there may be gaps anyway).

Answer 2

It sounds like they might be looking for more of a Test Analyst.

You have the expertise to know what tests should be performed even if you aren't performing writing the tests yourself, and crucially you should know what tests cannot or should not be automated.

Answer 3

One of our software suppliers operates in this manor but we still found 39 bugs when testing their latest delivery.

Mark Smith.

Answer 4

I think Kate Paulk's answer shows that there is still space for some manual testing and quality assurance oversight even amongst a team with effective automated practices.

However, it is a shrinking space to occupy. I would try my best to take on a more 'T-shaped' role. I think a technically minded tester could really add unique value to that team by stepping out of the strict boundaries of manual testing.

• Take responsibility for more technical tasks. We can all think of a host of miscellaneous technically activities that are done by developers. Not because these tasks are programmer things per se, but it's hard and developers are usually the best technical problem solvers. "T-shaped" testers are already pitching in here.

• Extend the automated tests. I'm sure you've found the tests developers write leave out a lot of the edge cases you have patiently been recording. Good. Add them in. Adapt the user input test for your extra long string or your extra horrible clump of unicode. I think this is one of the most valuable things a tester can do, but it is a road that cannot be traveled very far without investing some effort in learning how to understand and write code.

Incidentally, the developers can make my second suggestion easier for you with parametrised tests and test orchestration tools like Cucumber. Talk to them about this and make sure when you do start change tests that they're code reviewing your stuff.