Reams and reams of documents, from Technical Specs, to Requirements Documents, no test tools to speak of apart from Excel or the back of cigarette packet (some may call that exploratory testing today 😊), very little collaboration with the development teams, in fact it was a “them and us scenario” where little or no knowledge was shared and everything built up to that final test phase, which always seemed to inevitably get squeezed to try and complete the impossible before “go live”. Well at least that was the way I remember it.
Yep, you may remember that as well, the good old waterfall, well it wasn’t really a waterfall, more like a tsunami when code dropped over the wall into testing, destroying everything around it and then having to take weeks to rebuild the test environment before you could actually run a test! It has been an interesting journey since then. Testing slowly became more structured, and I’ve seen many different models tried, V Model, W Model, BS7925, ISEB (no prizes awarded if you know what any of these are). I could go on! I even recall some of what may have been forerunners to Agile: RAD (Rapid Application Development) & DSDM (Dynamic Systems Development Methodology) to name a couple. They both had the ethos of working in smaller teams, where the “tester” was part of the team and worked in conjunction with the developers, business analysts and the like. Yes this was practiced even back then! In essence though, all of these were waterfall, just with a different name tag applied. But there was a slow move towards where we are today in the Agile world.
Thank goodness, that QA has inevitably had to evolve as we rely more and more on the digital world around us. Imagine trying to launch a new app on an iPhone, or to deploy a new website if we still worked in that fashion, it would take months not days or weeks! QA has become a necessity rather than just an add-on. We now inevitably have to look at everything from the end users’ perspective, testing real user journeys giving the user a real experience that makes them want to use the product. Let’s make their lives easier! Quality Assurance is at the heart of this. We now try to think like a user rather than just a “tester who finds bugs”. We want to be able to deliver a great experience; we want to be able deliver to market quickly, yet we always want to improve the process, and deliver a great Product. We’ve slowly become, guess what, more agile 😊.
It’s been an interesting yet challenging journey; you must have seen it in your organisations? Your boss suggests that we are going “Agile” but what does that mean? “OK, we’ve all done the courses, so now we are an Agile organisation”? Yes, you’ve seen that too, right? Two weeks later your test cycles magically become “Sprints”, your code is slowly drip fed (iteratively) into the QA test environments (agile ☹?) but inevitably you still can’t test anything because the drip feed of code needs all of the code delivered to be able to test a single user journey. There’s no thought of continuous improvement, no thought of continuous integration or continuous delivery, and you are still using that Excel spreadsheet (or back of a cigarette packet) to manage your tests. Recognise that?
Agile is not just a methodology where we can use terms like “Sprints”, but carry on the way we did before (Wagile or FrAgile)? It’s a mindset and organisational change from top to bottom! So how has that journey gone and how do we do things differently in QA at ClearPeople? How do we make sure we don’t make the same mistakes?
Well here in QA at ClearPeople we see Quality Assurance is at the heart of what we do. I believe we are empowered to make the right decisions, we strive to continuously improve and not accept the norm, we engage earlier and strive to push Quality Assurance further to the left in the development cycle. This is not just through the use of test tools, but to be actively part of the Scrum team, engaging in everything from reviewing the product backlog items and the acceptance criteria (are they fit for purpose, are they testable?), to sprint planning, to engaging in the retrospectives and providing input (good or bad) to continuously improve. We genuinely don’t have the “back of cigarette packet” mentality, and we do actually do things like maintaining re-usable test assets, and strive to work smarter not harder (after all who likes hard work 😊?). But most of all we have that agile mindset that makes us stand out from the crowd and we put into practice what we preach.
But let’s not rest on our laurels and continue to do the same thing, we need to continuously evolve and improve, continuously look at how we do things, can we do them better? Are the tools we use fit for purpose? What are the latest trends within QA? Can we upskill our QA Analysts? The list is endless. But that’s what having an Agile mindset really means. So here’s to the ever-evolving world of QA! Long may it challenge us and improve the experiences of our end users.
Yep, you may remember that as well, the good old waterfall, well it wasn’t really a waterfall, more like a tsunami when code dropped over the wall into testing, destroying everything around it and then having to take weeks to rebuild the test environment before you could actually run a test! It has been an interesting journey since then. Testing slowly became more structured, and I’ve seen many different models tried, V Model, W Model, BS7925, ISEB (no prizes awarded if you know what any of these are). I could go on! I even recall some of what may have been forerunners to Agile: RAD (Rapid Application Development) & DSDM (Dynamic Systems Development Methodology) to name a couple. They both had the ethos of working in smaller teams, where the “tester” was part of the team and worked in conjunction with the developers, business analysts and the like. Yes this was practiced even back then! In essence though, all of these were waterfall, just with a different name tag applied. But there was a slow move towards where we are today in the Agile world.
Thank goodness, that QA has inevitably had to evolve as we rely more and more on the digital world around us. Imagine trying to launch a new app on an iPhone, or to deploy a new website if we still worked in that fashion, it would take months not days or weeks! QA has become a necessity rather than just an add-on. We now inevitably have to look at everything from the end users’ perspective, testing real user journeys giving the user a real experience that makes them want to use the product. Let’s make their lives easier! Quality Assurance is at the heart of this. We now try to think like a user rather than just a “tester who finds bugs”. We want to be able to deliver a great experience; we want to be able deliver to market quickly, yet we always want to improve the process, and deliver a great Product. We’ve slowly become, guess what, more agile 😊.
It’s been an interesting yet challenging journey; you must have seen it in your organisations? Your boss suggests that we are going “Agile” but what does that mean? “OK, we’ve all done the courses, so now we are an Agile organisation”? Yes, you’ve seen that too, right? Two weeks later your test cycles magically become “Sprints”, your code is slowly drip fed (iteratively) into the QA test environments (agile ☹?) but inevitably you still can’t test anything because the drip feed of code needs all of the code delivered to be able to test a single user journey. There’s no thought of continuous improvement, no thought of continuous integration or continuous delivery, and you are still using that Excel spreadsheet (or back of a cigarette packet) to manage your tests. Recognise that?
Agile is not just a methodology where we can use terms like “Sprints”, but carry on the way we did before (Wagile or FrAgile)? It’s a mindset and organisational change from top to bottom! So how has that journey gone and how do we do things differently in QA at ClearPeople? How do we make sure we don’t make the same mistakes?
Well here in QA at ClearPeople we see Quality Assurance is at the heart of what we do. I believe we are empowered to make the right decisions, we strive to continuously improve and not accept the norm, we engage earlier and strive to push Quality Assurance further to the left in the development cycle. This is not just through the use of test tools, but to be actively part of the Scrum team, engaging in everything from reviewing the product backlog items and the acceptance criteria (are they fit for purpose, are they testable?), to sprint planning, to engaging in the retrospectives and providing input (good or bad) to continuously improve. We genuinely don’t have the “back of cigarette packet” mentality, and we do actually do things like maintaining re-usable test assets, and strive to work smarter not harder (after all who likes hard work 😊?). But most of all we have that agile mindset that makes us stand out from the crowd and we put into practice what we preach.
But let’s not rest on our laurels and continue to do the same thing, we need to continuously evolve and improve, continuously look at how we do things, can we do them better? Are the tools we use fit for purpose? What are the latest trends within QA? Can we upskill our QA Analysts? The list is endless. But that’s what having an Agile mindset really means. So here’s to the ever-evolving world of QA! Long may it challenge us and improve the experiences of our end users.
