Have you ever wondered how a bunch of codes becomes a flawless app on your smartphone? Yes, any software undergoes a great deal of work before deployment. But how can your development partner promise you a stable, safe and high-quality product? Let’s be honest, in a competitive market like this, quality could be the major ace up your sleeve. No impressive design or innovative concept can cover for errors (that drive away customers). In this case, quality assurance (QA) is a real game changer.
It’s a common fact that many people underestimate QA. But this happens only due to the lack of knowledge on how important QA is in the production cycle and shaping brand reputation. In fact, this process is far more complicated than you could ever imagine. And more important. And gripping. And creative.
The first logical question everyone asks is “Do I really need it?” Well, everyone makes mistakes. And very few (even genius) ideas are perfect from the start. QA helps to prevent and fix any inconsistencies so that your end-user could say “Wow, that’s even better than I expected”. QA is about transforming expectations into reality and exceeding them.
If you still doubt, think what your criteria of a successful project are. Great budget - true. Sticking to deadlines - of course. Original approach - that’s a must. What about quality assurance? That’s what most people try to cut down on. Yet, isn’t that the key factor in making your product look run smoothly, look elegant, function properly and be safe for your customers? Moreover, sometimes miscalculations or incorrect assumptions happen at the business requirements stage when something good on paper can turn into a real fiasco when brought to life. Yes, QA to the rescue.
To put it in real numbers, in 2016, the software failures cost the global economy $1.1 trillion. Such errors were detected at 363 companies and they affected (just imagine!) 4.4 billion users (potential or existing customers). If you wonder how much time was lost, it is no less than 315 years. The most frustrating thing is that most of these incidents could have been avoided if QA had been introduced. Yet, as it often happens in haste, the software was simply rushed to deployment without proper testing.
This article will be the first in our series of articles on QA helping you to figure out what this process stands for and why it is such a big deal in agile development. This time we will focus on the term itself, as well as try to dispel some myths and misconceptions, explain general notions and the phases of QA implementation.
Before we go any further, we need to clarify we are on the same page with understanding the core notion itself. So, to banish some of the most infamous stereotypes connected with software quality assurance, here’s a quick guide to why we need this discussion in the first place. Our top 3-NO and 3-YES answers to the most popular misconceptions.
NO, it’s not a random guy sipping coffee and clicking through the rough version of your app or website.
NO, it doesn’t take an hour or few.
NO, it’s not a good idea to ask your fellow IT spare some time during his lunch break to look through your codes.
YES, you DO need to have special knowledge (and skills, and practice, and tools as well) to carry out a thorough QA investigation.
YES, every digital product benefits from QA.
YES, it’s worth the funds you spend on it (and you will see why once you read further).
QA is not just a single stage or a feature - it’s the whole process aimed at comprehending and maintaining the standards and characteristics used to develop products. And it’s inherent not only to the digital sphere.
Imagine buying a car that has just been produced at a plant. Wow, it’s gorgeous: sleek bodywork, leather seats, pristine tyres… Wait, what? It has not been tested? At all? Well, here a careless person would assume that every single worker and tool at a plant perform their tasks flawlessly. Yeap, that’s sort of a leap of faith. But would you drive such a car and dare take your children with you? Well, that’s the case. QA is the core foundation of the product’s excellent performance, meeting the customer’s needs (or, even better, exceeding their expectations) and building the brand’s reputation.
If we were to name the basic functions of QA in developing IT products, they would probably be:
to secure your business
to save money, time and efforts
to protect your brand’s reputation
to boost your company’s competitiveness
to control the development process
Also to be considered a state-of-the-art software, any digital product should correspond to the 4 basic quality factors:
Performance (executing transactions under a certain workload and desirable response time)
Extensibility (adding functions to the present system harmlessly)
Usability (having a user-friendly interface)
Security (protecting confidential data)
A quality assurance system (yes, as we’ve mentioned, it’s a complex network) is actually the area of production itself. Perceiving it as a separate set of activities that are performed apart from the other development and design stuff is another misconception. Delivering ideal digital solutions compatible with the specifications and requirements means engaging QA from the very first step and making it a part of a production team.
Here, three words come to mind: prevent, detect and ensure. That’s what QA is mostly about. Yet, the quality management system includes more than any customer suspects. It’s invisible to the naked eye (as it should been once QA is performed at its best), but the QA teams cover the product mission and vision, target audience and goals the product aims to achieve, legal and ethical issues and policies, various activities, resources and lots, lots, lots of documentation to bring all the above to life.
See, the whole QA issue seemed easy before you started digging deeper into the basics. Now, it’s time to understand why it’s that much of a fuss and what makes it different from mere testing.
Our anticipation prompts your next logical thought, “Well, it does sound like a big deal. Still, can’t I really do without it?” Sure, you can. Just keep in mind the previous tale of an utested car. You can drive it. No problem. Will it work? Probably. Will it work well? And here’s the point no one can guarantee you anything. Until you test it. The same applies to QA.
To avoid any problems with your software development, the QA team engages all the resources, expertise, tools, experience and creativity to provide you and your digital solution with a competitive advantage. We will not bore you with general ideas which everyone understands on paper, agrees they are quite rational but, eventually, rarely follows through in reality. Instead, we will list the advantages that really matter.
QA saves money. Yes, when it comes to assessing benefits, the best indicator is your finances. Certainly, QA costs itself. And good QA costs even more. Yet, this price becomes reasonable when you see how QA helps you in a number of cases:
it saves money when you don’t need to pay for fixing bugs after the release (and putting all the sales on hold
it distributes your funds more rationally throughout the product life cycle preventing you from unnecessary expenditure on different stages
it builds a positive brand reputation (which transforms into trust and trust transforms into higher sales rates
Indeed, reputation is a very sensitive issue. To be more convincing, look at the story of an infamous 2012 glitch in trading software which cost Knight Capital Group $460 million. Just in one day, their stocks dropped by 75% and this fiasco resulted in the acquisition by the competitor, Getco LLC. In fact, the whole problem was caused by a code change missed by one of the servers. This minor defect generated millions of orders and the price of retribution exceeded the company’s profit almost four times.
QA saves time. Once the processes are improved continuously, the workflow itself becomes more efficient and you get your dream product in a shorter period of time. Moreover, the sooner you engage QA in digital product development, the better. "The Journal of Defense Software Engineering" analyzed the number of hours needed to fix some problems at different stages of the development cycle and the results are jaw-dropping. If you think it’s cheaper to involve QA at the production stage, be ready to wait (and, obviously, pay) up to 150 times longer to deal with a bug that could have been detected at the discovery stage.
Time spent on fixing an error on different stages of production
As you can see, the earlier you find an error, the cheaper and faster it is to fix it. You might still wonder why QA should start at the very first - discovery - stage. At LinkUp Studio we see testing as an essential component of the initial phase. Some companies may convince you to ignore it at this point to “save your money” so far. However, think of all the money wasted later once the bug you missed at the requirement analysis stage starts to expand and prevent your app from functioning properly.
After deployment this turns into a big issue you have to solve (and pay for again). If you want to know more, check out this article. It will provide certainty whether it is really a must to engage testing that soon. After all, the discovery stage itself is no less important or underestimated than QA.
Thus, prevention is the key notion in this case as proper planning eliminates such a waste of time (and money, again). The QA expert involved from the very beginning can foresee and reduce risks, select proper tools and make any changes during the discovery stages not as painful and lengthy to make as those that manifest themselves later.
QA enhances customer experience, customer satisfaction and confidence. The QA team ensures your customer will get not just tolerable or satisfactory, but exceptional experience by usability and UX testing. At this point, QA experts see the product from the perspective of your potential client which is sometimes a difficult task for developers who each make only a definite part of the code and don’t see the larger picture or designers who might be influenced by trends and not take certain details into account.
Thus, when QA efforts result in customer satisfaction, it boosts customers’ confidence = loyalty = bigger and more stable customer base = more sales = more profit (again!)
QA promotes productivity and prevents corporate emergencies. Fixing bugs once the product is launched is not just challenging. Let’s call it the way it is: troublesome and stressful. For any and every company and its customers. Moreover, hurried fixing might make things even worse.
The stakes are high once a minor error may cause a system blackout, missing or mixed data, lost orders (= customers). Can you see where this is going? Right, lost money. And yes, it all comes down to that.
QA shapes a stable and competitive product. First impressions are always crucial. After all, this could be all you get. Who wants to use an app which crashes half the time, works on your smartphone but refuses to log you in on your PC and is not ready to check you out after an hour of product selection? You probably know what angry customers do: they write bad reviews, delete your app and, even worse, turn to your competitors and ... right, see point.
Bear in mind that a good QA team doesn’t only look for and detect errors - it creates a continuous, stable process which prevents you from fixing the same defects over and over again. There you get a competitive product.
QA helps ensure safety. The company that respects its customers always takes care of their data protection. Thus, vulnerability testing, for instance, prevents your clients from hacker attacks. Another big issue is direct harm you can cause due to any errors in sensitive areas like health care or education. This is where there is no room for mistakes.
QA gives a fresh perspective on your project. The team who knows all the errors can also see new possibilities, unexpected solutions and ways towards resource optimization.
So, whether you launch new software or upgrade the existing one, think of QA as your best work partner in delivering a truly better, error-free version of what you expected.
At this point you probably think “OK, I get it: QA is important. But then, again, is it really that complicated? Why not just call it testing?” You are partially right (and many people still think these two notions are interchangeable), testing IS a big part of the whole QA process. But that's not what it all comes down to. And remember: a QA team or a QA expert who works for you and just looks for bugs fulfill only 30% of their actual task.
QA is more about giving a thorough view of the software, making sure it corresponds to your requirements, quality standards and the customer’s needs and whims, performs its functions as you need and expect it to, as well as ensuring proper user interface and intuitive workflows. So, never expect, and, more importantly, accept simple testing instead of a complex vision of your desired product.
To be more precise, let’s compare these two terms to avoid further confusion.
a phase in the QA cycle
a broader concept, includes testing
the product itself
the process of creating and implementing the product
finding bugs, checking the project by using test-cases
the testing phase
each and every stage of software development (the sooner, the better) from discovery stage to the post-release phase and maintenance
product inspection carried out by a tester other than the code author to detect bugs and get rid of them
design inspection to see how the interface behaves, if there are any issues within the product and how to fix them etc as well as to check if the performance rate is what you expect it to be
documentation to describe every process for the team to know what to do and how to do that
audits at the end of each process to see what needs improvements now and how any drawbacks may be avoided in the long term perspective
tests themselves (They are a part of this concept. Remember?)
The key takeaway at this stage is to understand that both notions are aimed to ensure quality. Yes, they do have different functions and tools. Yet, their relationship is so close that to succeed you need to employ them as a whole. Certainly, you may try applying testing separately but it would prevent you from seeing the source of the problems and improving the development process at its core.
On the contrary, QA is capable of addressing such issues from a long-term perspective and making sure any process is carried out properly. So, the best option possible is not to waste time choosing between QA and testing but to focus on the former as a more powerful quality management approach (as it includes testing by default).
Once you take a look at the previous term explanation, you might get the idea that testing is just a miiiiiinor technical part i.e. not such a big deal after all. Yet, you should bear in mind, it also takes lots of time, skills, efforts and resources. In fact before testing itself is performed, there are: test analysis, test planning, composing test cases, data and environment. And only after that the actual testing takes place. Impressive, huh?
Now, raise your hand if you can describe what tests should be carried out to test your very app or website. That's tricky, right? The notion itself seems quite understandable to any school-child and even predictable once you start analyzing the whole process. However, the types of tests applied in QA are much more complex than you can imagine. And that is because the techniques and tools involved vary depending on the stage of the software production and the area of application.
Firstly, you may come across such a division as functional and nonfunctional testing. The easy part is that the difference between these two massive notions is very clear. Functional testing determines what the software does and is based on the project requirements while nonfunctional testing determines how the software does it and checks the actual performance and suggests improvements.
While some of the actual test names speak for themselves (like performance testing, load testing, or compliance checking), others (like regression testing or smoke testing) require at least a bit of further explanation. Yet, we are not determined to describe all of them here and now (as these lists are just the tips of the iceberg). After all, the aim of this article is to clear up major issues, not to complicate them, right? Still for those seeking more knowledge on this topic, we will be more than thrilled to go backstage in our future articles and spill some beans showing what a variety of tests are done and what for.
Going back to more global issues, there is one more point that needs clarification. We have already mentioned tests can be performed either manually or automatically. The terms seem to be quite obvious judging from their names. Still, we feel we owe you a more detailed explanation of the difference between these two methods.
automated (scripted testing)
who\what performs testing
a real user (a QA expert) who knows your requirements
automation testing tools
are sometimes less reliable due to the human-error factor
UX, Usability, ad hoc testing
smoke, performance, security testing
Certainly, automated testing is much more efficient when you are looking for a “needle in a haystack”. It does save time for bigger software projects when manual testing turns out to be a waste of human resources and is still not thorough enough. Yet, there’s no absolutely no need to automate every single step.
To give you a more transparent vision, automated testing is a great idea if:
On the contrary, automation is not necessary if:
As you see, automated testing is a rather intricate issue and we will need one more article to uncover all the tricks and help you stay on the same page with your future development partner.
At this point it is important to understand that in the end, the choice of test types falls on the QA team who have sufficient expertise and take all the factors into consideration before planning any particular steps.
“A good QA expert is not the one who knows 100 types of testing in theory. It is the one who knows how to use those really essential to the project correctly.”
Taras Lirko, Head of Quality Assurance at LinkUp Studio
What should be really stressed is whatever the tests are, they always undergo some sort of documentation: be it a checklist, a mind map, a test-case or a traceability matrix etc. These are fundamental elements that ensure we choose the correct strategy and stick to it. They help not to miss significant details and see the bigger picture at the same time.
You could guess that it's impossible to document every action (to tell the truth, sometimes it IS needless). However, with QA it’s a must and to perform our work at our best we learn to be both flexible and accurate, focus on making your software a real masterpiece. We will uncover some of our tricks and tips on documentation in our following article to help you grasp the whole idea.
Now that you are aware of all the term differences and can fully understand the scope of work QA is responsible for, let’s clarify what the proper order of actions should be and what the logic of all the stages is. In other (proper IT) words, we’ll describe Software Testing Life Cycle, i.e. the process followed to deliver quality digital solutions to the customers in a timely and cost-effective manner. The presence of such a notion may seem to complicate things even more. On the contrary, it helps to sort them out as it improves the quality assurance itself and test process in particular, making them gradable, deliverable and achievable. Here come the stages we undergo at LinkUp studio:
Note: After each phase is completed our clients may (upon request) receive a report to see what has been done, what features have been or are still being added, edited or completed and what requirements should be changed if necessary. This can be done to make sure both the customer and the QA team are on the same page.
The names of the stages seem to be rather transparent. Yet, as it usually happens with digital projects, there’s always more to know to be in the catbird seat. So, we promise to write more on the matter in our series of articles on QA.
By this time, you probably feel that QA is
a hell of so much work and so much responsibility. So, who is behind all that? If it’s not that guy you imagined it to be initially… It’s a bunch of great guys working to improve your future app. In our case they are:
Manual/Automation QA engineers. Yes, the slash is important here. We choose to engage versatile experts able to do both so that they could evaluate the pros and cons and decide which is the best option in each particular case. They are capable of writing scripts for automated testing as well as checking the product as prospective end-users covering both functional and nonfunctional testing. Also, they are involved at different stages of the product life cycle to make sure your software meets all the requirements before the development starts and, more importantly, even after deployment.
QA team managers. The term speaks for itself. Managers oversee the whole process and the team ensuring the efficiency and sticking to the schedule in a timely manner. They are also in charge of auditing and monitoring documentation, training and guiding, planning the routine and much more (which is not surprising for any manager).
Maybe, you have one logical question in mind, “Why don’t developers do the testing and we’ll do without a separate team of IT-guys?” While there are some people who support the idea, we are aware of the fact that the role of a QA engineer is much more than that. Imagine, what happens if a regular developer starts testing his/her own code:
Testing takes a lot of their time that could have been more useful when spent on new features or functionality.
Proper testing in this case is a rarity as the authors often miss obvious (or hidden) mistakes as they assume the code is already perfect.
Developers working on separate sections may be able to (and in fact, should, on a regular basis) test them well but how will they see if the whole product works as intended? What seems to function as the perfect part of a future app, may turn out to be a real bottleneck for the project.
To conduct thorough testing developers need a whole new bunch of skills. This is just a matter of convenience if you want to obtain them, to dig deeper into project requirements, provide sufficient data about all the weaknesses and quality levels as well as get involved in every stage of a product life cycle. In this case being a Jack of all trades may result in losing balance in software production.
Thus, the success of the QA process is taking it seriously, creatively, and with a pinch of salt. What else is valued? Collaboration. The QA team needs to be able to work very closely with developers to see what should be fixed and why this has become an issue. We understand that the current global situation is challenging enough. Yet, every cloud has a silver lining and we can prompt you how to find it in 2021 in our previous article on outsourcing services.
At this point we would strongly recommend engaging not the independent software testing services, but the QA team which your software development company already has. This would help you avoid any misunderstanding in communication, work process arrangement and provide you with the most thorough analysis possible.
Certainly, responsibility and flexibility are a must in any team, so the rest of the qualities are quite obvious. However, whether you choose the team your IT-partner suggests or a completely different one, always opt for value-oriented people who aim not to prove their coders to be perfect but to make your product better.
All in all considered, our major message is that QA, when properly and timely applied, is sure to become your most effective tool in enhancing the product performance and, thus, winning your customers’ loyalty. What may be initially seen as additional expenditure, turns out to be a priceless asset in creating a valuable solution in the long term. Just think of how much invisible errors may cost you once your actual users get their unsuccessful experience. Yes, the profits from investing your funds in QA may not be seen immediately. But they are sure to eliminate huge losses on a daily basis once the app/website is deployed.
When it comes to custom software development, there is no such term as too much QA. On the contrary, the sooner it is engaged, the better your chances for success are and the more time and money resources you are sure to save. The matter is QA should not be perceived as a single stage in the product life cycle but as a background for its performance and an ongoing process that guarantees the stability of the whole idea.
Also, involving QA does not mean lack of trust, experience or skills. It means giving your project a fresh perspective, discovering both faults and new possibilities. However, only a strong and skillful QA team is capable of choosing the best strategy, tools and tricks for each particular project to ensure exceptional quality of your dream product. At LinkUp studio we are happy to share our expertise and help make your customers feel you really care. To get more details on QA and your future project, please, contact us.