3

I'm currently working in a small internal software development team of four people. Having had a lot of success with Agile in the past (which none of my colleagues have used before), I'm keen to try and move toward a more Agile process.

The problem is that we have no dedicated QA resource. This isn't as dangerous as it sounds: 90% of the work we do is on internal projects and the "test team" ends up being the users doing UAT. Obviously it's not ideal - they're not as fast or as thorough as dedicated QA, but in essence, it works.

We currently do incremental releases and demos, after which the users do some testing and mark stuff as done. However, I'm struggling to see how we could fit this process into the traditional Agile framework.

I understand the importance of finishing a task within a sprint, and of not marking a feature as complete until its been tested. I also appreciate we can do a lot of automated testing but, in my experience, there are often a lot of requirements that aren't suitable for an automated test and need some sort of QA.

As it stands, we can't have any testing done until after release. And we can't have any control over when that testing gets done (the users have other jobs to do). And we can't have a dedicated QA resource (I have asked, but I'm in a chicken and egg situation of needing to prove this works before we get budget).

What can I do? Is it good enough just to do our meager internal/automated tests and mark things as "done" for now, with UAT being a separate stage? Or is there any way we can better integrate UAT into sprint cycles?

There are other questions

These appear similar to the issue central to this one, however, those answers all presume an existing QA team, just one that doesn't work in sync with the developers. In this situation there is no QA. In effect, the usual middle layer of testing is entirely absent.

Community
  • 1
Bob Tway
  • 3,606
  • 3
  • 21
  • 26
  • possible duplicate of [Coding and testing in the same sprint](http://programmers.stackexchange.com/questions/246153/coding-and-testing-in-the-same-sprint) – gnat Mar 05 '15 at 12:14
  • see also: [Dilemma of QA vs. iterations](http://programmers.stackexchange.com/questions/183743/dilemma-of-qa-vs-iterations) – gnat Mar 05 '15 at 12:15
  • Thanks for those suggestions - I had seen both, but I felt this justified a new question. The important difference is that those questions and their answers all presume an existing QA team, just one that doesn't work in sync with the developers. This is different, because there is no QA. In effect, the usual middle layer of testing is entirely absent. – Bob Tway Mar 05 '15 at 12:30
  • 1
    http://meta.stackexchange.com/questions/194476/someone-flagged-my-question-as-already-answered-but-its-not/194495#194495 – gnat Mar 05 '15 at 12:40
  • 2
    Is your development team sufficiently knowledgeable about how the users use the software to perform UAT? It would reduce velocity, since someone would perform acceptance testing for each story rather than just moving on to more design and development tasks. – Thomas Owens Mar 05 '15 at 14:35
  • @ThomasOwens Sometimes. But now you come to mention it, I can see this being a helpful additional task to take on board. If we can understand the end-user process sufficiently it should help us deliver quality software. – Bob Tway Mar 05 '15 at 14:40
  • @MattThrower I'll expand into an answer. – Thomas Owens Mar 05 '15 at 14:44
  • 1
    related: [Viability of a Development Team with no \*dedicated\* Tester role](http://programmers.stackexchange.com/questions/230163/viability-of-a-development-team-with-no-dedicated-tester-role) (see also questions linked to this one) – gnat Mar 05 '15 at 15:07

1 Answers1

2

I would recommend having your development team try to take on the role of user acceptance testing, at least to the extent possible. It may not be as effective as the actual users, at least until the developers have a strong understanding of the domain and how the users carry out their work in the software, but it will help catch the big things before you get your users involved and will help drive an understanding of the domain.

As a story is complete, someone on the development team can take on the role of testing that story. Depending on your development process, perhaps even someone who wasn't previously involved in the story previously could be responsible for the final UAT. This would allow the development team to gain some insight into how the users are actually using the software and will drive design decisions.

There are some downsides, though. Your velocity will be reduced as you will need to allocate developers to perform this UAT role. However, I think that the increase in understanding of the users roles and needs and the ability to deliver higher quality software will outweigh the reduced velocity.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283