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
- Coding and testing in the same sprint
- Dilemma of QA vs. iterations
- Viability of a Development Team with no *dedicated* Tester role
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.
8
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.