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.