Part-time Agile QA - What to Focus On?

Well, it’s been quite a while since I posted anything and in that time I’ve since entered a new software producing environment. It’s working with agile again, which is great, but has a change to my existing experience in the area as there are multpile projects producing multiple products.
At the moment numerous teams (containing the usual mix of product owner, scrum master, developers and user experience personnel) are working on their product. There is a Outsourced software testing services team who’s task is to provide resources to all - and yes, the usual story persists in that there aren’t enough of us to go round!
So this raises the question, how to provide the best possible QA services when you can’t work on a project 100% of your time?
I know, one of the key rules of agile is being broken here i.e. the project team can not be interrupted during sprints. In an ideal world we would simply add sufficient QA people to be able to maintain the continuous creation and maintenance of automation test suites and provide QA input on all the user stories. The problem is that the ideal world doesn’t exist (or not yet anyway - I still haven’t retired as a millionaire :-)).
A way to tackle this problem is to change the priority of tasks that QA people will do. Instead of focusing on the test automation services, use what precious time is available to ensure the other required work with the developers is as thoroughly completed as possible.
This means performing the usual informal chats to learn about the product, provide verbal input on scenarios you’d like to see unit tested and put into the CI builds, be super-thorough on explicit completion criteria for the User Stories … basically attempt to influence the mindset of the team to focus even more on QA. Yes, this is already the role of an agile QA person, but spending time frantically writing the correct amount of automation tests (and ultimately failing!) is not what I see as making the best use of the resource.
Depending on the time available after performing the QA tasks, automation of UAT testing team will assist the team greatly. Focusing on the completion criteria or other scenarios stipulated by the product owner, these scripts will ultimately provide the high level regression suite and give the rest of the team confidence and visibility that the product is indeed developing sprint after sprint.
This QA task prioritisation is a good way to ensure the load of work doesn’t bring the person to breaking point and working nights and weekends - rushing the verification of code and practices always results in poor quality.

So, anyone agree/disagree with this? It is a bit ‘controversial’ to not attempt to complete full automisation of testing for each sprint but until such times as testers have 3 pairs of hands or cloning machines, limits to what can be achieved need to be set.

Comments

Post a Comment

Popular posts from this blog

How can product quality improvement be tracked from sprint to sprint?

I’m interested in defining the best metrics to use for checking whether the product quality is improving as time, and sprints, pass by. One obvious factor is the number of automated tests passing in the continuous integration builds related to the coverage of functions in the code. Or is it? Do the tests literally show the product quality? What if the finished article isn’t what the customer wanted? There are then a suite of tests making sure that the software does something it’s not meant to. Number of defects? Measured against what? The list of possibilities goes on, what I’d like to find out are tried and tested measurables. Does anyone have a list they use in every project? Update by Kenny 08/11/09 :- Ok, I’ll try and answer my own question here (the power of reflection!). There are two scenarios in projects which require different solutions in relation to metrics gathering. They are :- 1) A project run using mature agile methodologies from day 1 2) A project which ...
Read more

Agile v Waterfall - Which Is The More Risky?

I still find it strange that companies unfamiliar with Agile automatically view it as being a methodology that pays no heed to process or ensuring quality of output. From my experience the quality is actually a lot better, the timescales set are achieved more readily and everyone involved has a much greater understanding of the product and its development status at any one time. At present I´m working on a project where I´ve had to split the test team into two due to several companies working to build a complex product together. One team is performing agile QA in a sprint team, the other is working ´the old way´. It´s very interesting to note that all the worry and uncertainty is coming from the team working with the traditional model due to the fact that timeframes having been guesstimated months ago about environments, data and functionality that no-one knew about then. As time marches on we appear to be spending more time in meetings discussing what we once thought was go...
Read more

Details, Fiction and Software testing services

  No matter what DevOps processes, models and applications corporations use, testing is a vital Component of the general DevOps procedure — don't just to be sure code alterations work as envisioned and integrate well — but to make sure the necessity improvements do break the performance.” – How DevOps Transformed Software Testing Whether or not your web site is still in improvement or out inside the wild, we are able to get the job done with any surroundings. Our testers can collaborate along with your developers and task administrators, and in some cases be part of your Jira, Slack, and standup calls. Find out more about our Site testing services. For that reason, the workforce has to analyse the code on the continual foundation to keep the code foundation in a great maintainable state. This will protect against uncovered complex debts, process crashes and highly-priced fixes.” – Sergey Terekhov, Defining and monitoring the code top quality Most of these tests are more expens...
Read more