jeudi 5 mars 2015

Agile: QA without dedicated test resource


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?





Aucun commentaire:

Enregistrer un commentaire