Skip to main content

3 Steps to Make Testing More Agile!

It's been a while, here is a great post I have found... More to come!

If you have a large dev team in your software testing company, you communicate closely and cooperate with other team members often, it’s time for you to acquire an agile style of the testing process. The agile development methodology is widely applied today as it gives much better results if organised properly.

Here are 3 keys to making the testing part of development projects agile and more value-driven as well.

  1. Look outside your QA bucket

Try to get behind the QA boundaries. Take part in the analysis stage by attending meetings, helping to review user stories, etc. During such meeting sessions make a rule of giving your feedback and setting your testing expectations. Once you try to look outside your immediate QA role, you’ll understand the true purpose of both the stories and the project indeed and ensure that the features meet their purposes better. Grasping the business value of each story will let you find more bugs appearing outside purely functional requirements or even stop bugs from coming up.

  1. Focus on the technical core

The above step speeds up stories going through testing significantly, but it doesn’t handle the core of the problems you may have. To take the bull by the horns, in most cases it’s necessary to change your tech stack moving away from the undeveloped test suite built in CMS towards a proper and straightforward testing pyramid. Many software testing companies choose Ruby for a new language as it has its mature active community as well as testing built into the DNA. The testing framework should be evolved with the changing application needs to ensure better test coverage and faster feedback.

  1. Encourage the QA culture in your team

While the two previous steps help you improve the testing process indeed, they don’t change a tester’s role as the “QA gate”. The key to the agile model is cross-function organisation of your team where nobody is strictly bound to one aspect of the product development. That’s why you have to advocate quality in every project aspect to create your team culture responsible for the software quality. Probably, the most effective method of all is excluding the QA column from your agile board. Thus, developers no longer have their safety net that it’s testers’ role to ensure the code works as expected, and learn to take more responsibility for the quality of their code. These steps may be difficult to apply in start-ups, but large IT companies already benefit from the agile model of processes. If agility implies greater success, why not try it?


Popular posts from this blog

My Testbash Brighton 2017 Notes

This was my second Testbash... if you ever get the chance in the future these conferences are a must!
I took copious amounts of notes from the 9 talks and tried to highlight my key takeaways here... hope they make sense but please comment if you have any questions :-)
Amy Phillips - Continuous Delivery
A survival guide to joining a fast paced environment/project…
Where does testing fit within Continuous delivery:

As highlighted, basically from start to finish…
There are lots of things we can do when joining a project that is using Continuous Delivery but one of the main points from this talk was to do your research! There should be an element of "Continuous" in every aspect of the project.
·Learning the ling, what's the difference Continuous Delivery, Continuous Deployment, Continuous Integration, Continuous design, Continuous Improvements etc.? ·Understand what your role in the project is going to be ·Understand the teams values, What's going well and maybe what the team p…

Is TestBash an Invaluable experience?

Over the last few years, I’ve attended four single track conferences at TestBash Brighton and Manchester. Most recently, September 2018 and April 2019.

One of the most common questions I get after the conference is, Was it worth it? Especially now given, I’m a contractor, and I attend at my own expense.

In short, Yes It’s definitely worth the trip!

That leads me into my question; does a single-track conference work for me, or could I get more out of TestBash?

Of course, there are pros and cons, some talks may not be as engaging, but this is no disrespect to the speakers, for me, it’s because I probably favour certain subjects and I’m pretty sure others will think the same.

Do I make the most of what’s on offer at TestBash? It pains me to say, No! I don’t make the most of the events leading up to and post the single-track conference so I could get more from the week.

TestBash offers master classes on automation. A full day of workshops. Test.bash() with talks on automation and technica…

The way we work shouldn’t be ‘Alien’ anymore, Should it!?!?

It’s been a good while since I have written anything (Mainly because I’m not that good a writer) but given my 16 months in the public sector I thought it was time… 
For a good number of years now the DevOps trend has given rise of buzzwords and methods aiming to speed delivery and it’s now an assumption of mine that most organisations are au fait with the term ‘Continuous Delivery’.
I was wrong…
Within the organisation that I am currently placed I believe I have a high-functioning collaborative team who work flexibly and in continuous cycle. We also involve the users which is a huge benefit to the development teams, but that’s not saying we get everything right 100% of the time! Teams must continue to learn and evolve to remain productive.
Our team work in one of several delivery groups and with this comes multiple challenges; Silos No single environment strategy lack of communicationsVaried ways of working.  And thats just to name a few, which is interesting when all delivery groups …