Speed or Quality? Why Not Both?
Speed or Quality? Why Not Both?
DevOps and Agile are not just about delivering faster, but delivering high-quality software fast. See how this is baked into DevOps processes.
Join the DZone community and get the full member experience.Join For Free
Can you release faster without sacrificing quality? See how with our free ebook Strategies for a Successful Test Automation Project and a free trial of Ranorex Studio today!
Being a QA guy, you might expect me to answer, "Quality, of course. C'mon, are you kidding me?" But that’s not what I really think. For me, the right answer should be: "Both of them. Why not?"
Obviously, speed without quality doesn’t add too much value. We all know of a "friend of ours" who worked on a project that was out of time. Finally, they made it, but the application was useless! There were so many bugs that the customer couldn’t make it work. And fixing the bugs took ages, or maybe they had to discontinue the project. In the best scenario, the technical debt was so high that the customer was stuck with the IT provider for the rest of their life. Who can maintain legacy code in which every change you make breaks some functionality?
The other way around sounds better, but nowadays, if your time-to-market is not good, you’re dead!
So, the most obvious answer is speed and quality at the same time. But, how can you make it?
I think that Agile has much to say about it. Agile is not about delivering faster, as many people think. It’s about delivering the right thing faster. And Quality Assurance is not just about testing. QA is about quality (what a no-brainer!). So, if you want to improve your TTM, and still deliver a product of quality, then you should perform a shift-to-the-left. But what does it mean, this fancy term?
Until the growing tendency of implementing Agile methodologies (where scrum is "fashionable"), the classic SDLC was known as waterfall. In this model, there were many different phases, but all of them were sequential, and you had to wait to finish one of them to begin with the next one. The latest phase was testing (oh, my goodness!).
That meant that you didn't have a clue about the quality of your product until the very end (after maybe months or years). Even more, if you were running out of time, the testing phase was the first one that was thrown out the window.
Not surprisingly, there was a high percentage of failing projects, as the cost of fixing many of them wasn't affordable.
It's in this context that the concept of "shift left" appears, suggesting that testing should be involved from the very start.
So, first of all, put a QA engineer in your life (or on your team). Scrum encourages this.
QAs participate in sprint planning sessions to ask questions to the product owner, so undefinitions or missing points can be discussed, which ultimately leads to better user stories, definition, and the inclusion of acceptance criteria.
QAs and devs should work together from the very beginning. Some team members can pair with developers to define test cases. In fact, if you can involve business (PO/BA) in what is called the "Three Amigos" approach, the benefits would be much higher.
Testing may still happen at the end, but it will be smaller and faster because of the problems you were able to find earlier on. In fact, only the testing phase should impact your SDLC, as there should be a code freeze before you begin testing. But all the rest of the activities can and should be performed in parallel. And there are quite a few, from the previously mentioned test case definition to preparing test environments or test datasets.
If you are already there, the next fancy word you have to learn is DevOps. What about Continuous Deployment? I’m not telling you that you should be delivering a new version of your product every 11.6 seconds as Amazon does, but do you think they don’t care about quality? They just fail fast. And that’s what you should aim to.
Published at DZone with permission of Adolfo Terrón García . See the original article here.
Opinions expressed by DZone contributors are their own.