 |
“Quality is never an accident; it is always the result of intelligent effort.”
There are many opinions about what QA is, what it does, and what it should look like. These expectations or myths about QA can prevent you from making the most of testing. Here are some popular QA myths that tend to influence the mindset of team members and executives.
Let us find out how to bust these myths and follow quality in the true sense.
Myth #1: More testing always means better quality
On the surface, it seems logical: more testing equals more chances to find bugs. Project stakeholders often think that by running more tests, they’re covering all bases, leaving no room for issues to slip through.
The reality
The quantity of tests doesn’t guarantee better quality. It’s the quality – the relevance, depth, and efficiency of the tests that matter. Performing more tests can hurt you as they lead to diminishing returns, wasted effort, and unnecessary delays. There’s a point where additional testing doesn’t provide significant new insights or value and instead becomes a time-consuming exercise that distracts from focusing on the high-risk, high-value areas of the product.
Over-testing can introduce noise, lead to longer feedback cycles, and may even create a false sense of confidence that distracts from important issues that haven’t been addressed. As the application grows, so will your test suites. If these tests are not well-planned, then the test maintenance efforts will be too costly.
Example: How the myth backfires
Consider a project with a web application undergoing regression testing. The team creates a massive test suite of 5,000 automated test cases, testing every possible scenario. The tests take several hours to run, and after a week of execution they reveal only a handful of minor bugs, most of which are related to edge cases that users are unlikely to encounter.
Meanwhile, a critical performance bug that causes the application to crash under high traffic is missed. This bug affects many users and is only discovered when the application goes live. The time spent running thousands of low-impact tests distracted the team from focusing on performance testing or investigating high-traffic use cases.
What should be done instead?
Rather than testing as much as possible, QA teams should focus on risk-based testing or prioritizing high-value test cases. This means identifying the most critical functions of the application – those that have the highest risk or most significant user impact – and allocating testing resources accordingly.
For instance, in the example above, prioritizing load and performance testing for an e-commerce site that expects high traffic would have been more effective. It’s about smart testing, not more testing – maximizing coverage and insight without wasting time on redundant or irrelevant test cases. This way, the team can likely discover critical issues early and prevent costly bugs from reaching production. Read: Future of E-commerce and Automation Testing.
Myth #2: Only testers are responsible for quality
This myth is quite prevalent, especially when bugs are identified in production! It suggests that developers, product managers, designers, and other stakeholders are not directly accountable for quality. Instead, it is the job of testers to identify defects and ensure the product is in good shape before release. This thought could be due to the traditional siloed structure where developers build the product and testers act as gatekeepers.
The reality
Quality is a shared responsibility across the entire team. Every person involved in the software development lifecycle, from product managers to developers to designers, plays a crucial role in delivering a quality product. Developers are responsible for writing clean, maintainable, and bug-free code; product managers are responsible for clearly defining user needs and acceptance criteria; and testers provide a final layer of validation.
When the responsibility for quality is pushed solely onto testers, it leads to inefficiencies, delays, and often lower-quality output. If developers or other team members don’t prioritize quality in their work, the QA team may become overwhelmed with defects or spend more time than necessary fixing preventable issues, which slows down the release process.
Example: How the myth backfires
Imagine a scenario where a development team builds a new feature for a mobile app without considering potential edge cases or writing unit tests. The team believes that QA will catch all mistakes, so they prioritize speed over careful coding practices. Once the feature is passed to the testers, they uncover multiple defects, including bugs related to data handling, user input validation and performance.
The result is a large number of issues requiring rework by the developers, which causes delays in the release and frustration across the team. Because the developers did not take ownership of the quality in the first place, the entire process suffers. This leads to increased costs, missed deadlines and a potential loss of trust between teams.
What should be done instead?
To avoid this, you need a culture of shared responsibility for quality. Developers should adopt best practices like writing good unit tests, integrating code reviews, and following coding standards to catch issues early in the development process. Testers should be involved throughout the development lifecycle, helping define acceptance criteria and ensuring quality is built into the product from the start rather than tacked on at the end.
In the example above, if developers had written unit tests and conducted code reviews, many of the bugs would have been caught early which would have reduced the load on testers. Additionally, collaboration between developers and testers through methods like shift-left testing (where testing happens earlier in the process) ensures that quality is a continuous focus, not an afterthought. This results in a more efficient workflow and a higher-quality product.
Myth #3: You can achieve perfect testing
This suggests that it is possible to test every aspect of a software system thoroughly enough to catch all bugs and ensure a flawless product. The belief here is that if enough time, effort, and resources are dedicated to testing, one can achieve “perfect testing” where no defects remain, and the software will work under all conditions.
This myth exists because people often equate testing to finding every potential defect. Additionally, project stakeholders and clients may expect perfection in testing, driven by the fear of missed bugs causing costly failures post-release.
The reality
In reality, perfect testing is impossible. There are too many variables, conditions, and edge cases in any complex software system to be completely tested. Even with extensive testing, it’s impractical to test every possible user interaction, data combination, hardware configuration, or environment.
Moreover, as systems evolve with updates and new features, previously undiscovered issues can emerge. Testing is based on prioritization – focusing on the most critical and high-risk areas of the application because testing everything exhaustively would take an impractical amount of time and resources.
The goal of testing isn’t perfection but risk mitigation. Testers aim to find and address the most critical issues while recognizing that some level of risk will always remain.
Example: How the myth backfires
Consider a financial application in development where the team spends several months attempting to test every single feature and scenario. They write exhaustive test cases, covering obscure edge cases and rare conditions. Despite their effort, they spend so much time trying to achieve this “perfect testing” that the project timeline is pushed back which leads to significant delays in the release.
Even after all this effort, once the application is deployed, users find a critical defect in a commonly used feature related to currency conversion. The bug wasn’t caught because the team focused too much on rare conditions and didn’t prioritize the core business functionality that most users interact with. The testing team spent excessive time trying to achieve perfection, which not only delayed the project but also resulted in missing a significant issue that could have been addressed earlier with proper prioritization.
What should be done instead?
Instead of aiming for perfect testing, teams should adopt a risk-based testing approach. This involves identifying the most critical parts of the application – those that have the highest impact on users or are most likely to break – and focusing testing efforts there.
In the example above, the team should have prioritized the most used features of the financial application such as currency conversion over obscure edge cases. By doing so, they could have reduced the risk of critical defects while maintaining an efficient timeline.
Additionally, implementing test automation for repetitive tasks and combining it with exploratory testing can help testers balance depth with efficiency. This ensures broad test coverage without overextending efforts on low-priority areas. Ultimately, the focus should be on smart testing, not perfect testing, where risks are minimized, and resources are used effectively to ensure the highest quality in the most impactful areas.
Myth #4: Testing is about “breaking” software and finding bugs
This idea implies that testing is a destructive process, with testers trying to identify where and how the software fails, almost as if they are adversaries of developers. This myth exists because finding defects is a visible and tangible outcome of testing. Project stakeholders and even developers may view the success of testers through the number of bugs found.
The reality
In reality, testing is about ensuring quality, not just finding bugs. While discovering defects is an important aspect, testing encompasses much more. It involves verifying that the software works according to requirements, validating that it meets user expectations, and assessing aspects like performance, security, and usability. Testing is a constructive process aimed at improving the overall product quality to ensure that it functions correctly and efficiently under expected and unexpected conditions.
Testers are not just bug hunters; they are quality advocates who help ensure that the product delivers value to users. Their focus should be on understanding the product from a user’s perspective so that it solves the intended problem and identifies potential improvements, not merely “breaking” the system.
Example: How the myth backfires
Imagine a project where testers are solely focused on finding bugs. They identify numerous defects related to UI glitches and minor edge cases, which, although important, are low-priority issues. The team celebrates finding these bugs, believing they are improving the product’s quality.
However, once the software is released, users begin complaining about poor user experience due to slow performance and confusing navigation. While the testers were busy “breaking” the software by finding small bugs, they missed the bigger picture: verifying whether the software provided a seamless and enjoyable user experience. The result is a product that works functionally but fails to meet user expectations.
What should be done instead?
Instead of focusing solely on finding bugs, testing should be seen as a collaborative, quality-focused activity. Testers should work closely with developers, product managers, and designers to understand the software’s requirements and user goals. By adopting a holistic testing approach, they can ensure that the software meets both functional and non-functional requirements, such as usability, performance, and security. Read about Functional Testing & Non-functional Testing.
In the example above, if the testers had approached their work with a broader perspective such as validating that the software met user needs, they would have prioritized testing for performance and usability. This would have led to a better overall product rather than simply fixing a long list of minor bugs.
A better approach is to focus on user-centric testing, which involves simulating real-world scenarios, understanding user expectations, and ensuring the product performs well in those contexts. Testing is not about breaking the system; it’s about making the product better for users.
Myth #5: Test automation is set-and-forget
Automation is often viewed as a one-time setup that frees testers from repetitive tasks, allowing them to focus on other areas. The belief is that automated tests will continuously run, find issues, and ensure the system is working as intended without any further effort from the team. The idea that automated tests can run by themselves without ongoing attention appeals to teams who want to save time, especially in fast-paced development environments.
The reality
In reality, test automation requires ongoing maintenance and monitoring with In-Sprint Planning and Automation Testing. As the software evolves with new features, updates, and changes to the codebase, automated tests need to be updated to reflect these changes. If automated tests are left unattended, they can quickly become outdated which results in false positives (tests failing when they shouldn’t) or false negatives (tests passing when they should fail).
Moreover, even well-designed automated test suites can suffer from “test flakiness” or intermittent failures caused by timing issues, environmental factors, or other variables. Over time, automated tests may need to be refactored to maintain efficiency and accuracy, as continuously growing test suites can slow down and become more difficult to manage. Know more about how to Decrease Test Maintenance Time by 99.5% with testRigor.
Example: How the myth backfires
Consider a team working on an e-commerce platform that invests heavily in automating all of its regression tests. Initially, the automated tests run smoothly to catch bugs and reduce manual testing effort. Believing that the automated suite will handle everything, the team stops paying close attention to it.
Months later, the platform undergoes significant updates – new features are added, UI elements are changed and the backend is refactored. As the automated tests haven’t been updated to reflect these changes, many of the tests begin failing or provide inaccurate results. However, the team is unaware of these issues because they assumed the tests would continue to function as they did at the outset.
As a result, critical bugs slip through the cracks and make it to production, impacting users. The once-trusted automated suite has become unreliable and requires a significant investment of time and effort to update and fix.
Another example is ERP and CRM systems such as Salesforce. These systems receive frequent updates, and your test automation should stay relevant to these changes. Read more about Salesforce Testing.
What should be done instead?
Instead of treating automation as a “set-and-forget” tool, teams should approach test automation as a living system that evolves alongside the software.
- Regularly maintain and update tests: Automated tests should be updated whenever there are changes to the codebase or UI. This ensures that the tests continue to provide meaningful and accurate results. Know How to Write Maintainable Test Scripts.
- Monitor test results closely: Automated test results should be reviewed consistently to detect patterns of failures, flakiness, or inefficiencies.
- Prioritize automation strategically: Not all tests should be automated. Focus automation on high-value, repetitive tasks like regression testing, but always combine it with manual and exploratory testing for areas that require human intuition, such as UI/UX testing or tests for new features. Read: Which Tests Should I Automate First?
- Adopt good test automation tools: Consciously invest in test automation tools that offer good ROI. You can use generative AI-based automation tools like testRigor that smartly take care of test creation and test maintenance.
Myth #6: Agile eliminates the need for QA
This myth implies that in an Agile environment, the role of a dedicated QA team is no longer necessary because developers take over all testing responsibilities. The belief is that developers and automated tests will handle all aspects of quality. This myth exists because Agile methodologies promote cross-functional teams where every member is responsible for quality. Since Agile encourages more rapid development cycles, with frequent releases and continuous feedback, many assume that there is no room for traditional, formal QA processes or roles.
The reality
In reality, QA is crucial in Agile environments. Agile does not eliminate the need for QA; rather, it redefines the role. QA is integrated earlier in the process and becomes part of a continuous testing effort that involves collaboration with developers, product owners, and other team members.
Agile teams still need dedicated QA professionals who bring specific expertise in testing, risk assessment and quality assurance. While developers may write unit tests and some automated tests, QA ensures that end-to-end testing, exploratory testing, usability testing, and non-functional testing (such as performance and security) are not overlooked. QA professionals also help define acceptance criteria, ensure continuous integration testing, and assist in creating a shared understanding of quality across the team.
Agile’s focus on faster iteration cycles actually makes QA involvement even more critical to ensure continuous quality at every stage of development.
Example: How the myth backfires
Consider a scenario where an Agile team decides to forego dedicated QA. They assume that developers can handle all testing. The team relies heavily on unit tests and automated tests, believing that this will catch any major issues. For several sprints, development progresses smoothly and the product is released to users with few bugs reported initially.
However, after a few releases, the users begin to encounter significant usability issues and performance problems that weren’t caught by the developers’ tests. Some major defects are also reported in edge cases that the automated tests didn’t cover. The lack of exploratory testing, usability testing, and a broader focus on quality leads to customer dissatisfaction and requires urgent rework from the development team.
In this case, by eliminating QA, the team sacrificed a critical layer of quality control, which caused issues to pile up and erode user trust over time. What seemed like a time-saving measure ended up creating more work and longer delays as issues had to be fixed retroactively.
What should be done instead?
Rather than eliminating QA, Agile teams should integrate QA throughout the development process. QA professionals should work alongside developers, product owners, and other stakeholders to:
- Collaborate on defining acceptance criteria: QA should participate in the planning stages to help define clear acceptance criteria that ensure product quality meets business needs.
- Perform continuous testing: QA should focus on continuous testing throughout the development cycle, including automated testing, exploratory, usability, performance, and security testing, which are basically areas that developers may overlook.
- Encourage a quality-first mindset: While quality is everyone’s responsibility in Agile, QA professionals help foster a quality-driven culture that ensures that quality is considered from the beginning of development and not just at the end.
Myth #7: Testing delays project deliveries
The belief is that testing, especially thorough manual testing or extensive test automation, slows down the delivery of the product because it takes significant time to find, document, and fix bugs before the product can go live.
This myth exists because testing often occurs near the end of the development cycle in traditional workflows. When a release is imminent, testing is sometimes viewed as a last-minute hurdle that could potentially delay shipping if defects are found. As a result, testing is seen as something that slows progress rather than a process that enhances the product.
The reality
Testing doesn’t delay project deliveries. Untested or poorly tested software does. Proper and well-planned testing can actually accelerate project deliveries in the long run by identifying defects early, reducing rework, and improving overall product stability. Testing prevents costly and time-consuming fixes down the road by detecting issues before they make it into production.
When teams skip or rush testing to meet deadlines, they often end up releasing software with critical bugs, leading to customer dissatisfaction, emergency patches, and even larger delays as developers are forced to fix issues after release. Testing, when integrated continuously throughout the development process (e.g., in Agile or DevOps workflows), prevents bottlenecks by addressing quality concerns incrementally. Effective testing also helps mitigate risks, ensure better alignment with business requirements, and lead to smoother releases with fewer unexpected problems.
Example: How the myth backfires
Imagine a team working on a new feature for an online banking application. Under pressure to meet a tight deadline, the team has decided to limit the time allocated to testing. They think it will speed up delivery. The feature is released to production on time, but within days, users start reporting issues with incorrect transaction records, which causes panic and frustration among customers.
The development team must now halt work on new features and urgently address the bug, which requires more time to diagnose and fix because the root cause wasn’t caught earlier. In addition to delaying other planned releases, this rushed approach damages the product’s reputation and user trust. Had the team allocated proper time for thorough testing, they could have caught the defect early, ensured the feature met user expectations, and avoided costly post-release fixes.
What should be done instead?
Rather than viewing testing as a roadblock, teams should integrate testing early and continuously throughout the development process to catch defects before they become major issues. Here’s how to avoid delays caused by inadequate testing:
- Shift-left testing: Incorporate testing from the beginning of the development cycle rather than waiting until the end. Developers can write unit tests, and QA can perform early exploratory or integration testing to catch issues sooner.
- Automated testing for faster feedback: Automating repetitive tests (such as regression tests) allows teams to quickly verify that new changes haven’t broken existing functionality.
- Adopt continuous integration/continuous testing: By continuously testing and integrating small code changes, teams can identify problems earlier and in smaller, more manageable chunks. This prevents the accumulation of major defects that could delay delivery.
Myth #8: 100% automated testing is possible and needed
The idea is that with enough investment in automation, all aspects of testing, including functional, regression, and even exploratory testing, can be covered without any manual intervention. This is thought to lead to faster releases, fewer bugs, and an overall increase in efficiency.
This myth exists because automated testing promises speed and consistency. Automated tests can be run frequently and quickly without human error, and organizations often see it as a cost-saving measure. As a result, there’s a belief that the ultimate goal should be complete automation to eliminate the need for manual testing.
The reality
100% automated testing is neither possible nor necessary. Automation has significant benefits for repetitive tasks like regression testing, but it also has limitations. Automated tests cannot handle subjective areas such as user experience, visual aesthetics, or exploratory testing. These require human intuition, creativity, and an understanding of user behavior, which automated scripts cannot replicate.
Furthermore, as systems grow in complexity, maintaining and updating 100% automated test coverage becomes impractical and costly. Automated tests can become fragile or obsolete as code evolves which leads to a high maintenance burden. Also, automating every possible scenario leads to diminishing returns, as the effort and cost to automate complex edge cases often outweigh the benefits.
A balanced approach is far more effective – one that combines automation for repetitive and predictable tasks with manual testing, where human insight is essential. Here is a Manual Testing: A Beginner’s Guide.
Example: How the myth backfires
Consider a company that decides to automate every aspect of testing for its e-commerce platform, from functionality to performance to edge case scenarios. The team invests heavily in building a massive automated test suite. Initially, this approach seems successful, as automated tests run quickly and provide frequent feedback.
However, as the platform grows with new features and UI updates, the test suite starts to fail frequently due to changes in the application’s structure. The team spends more time fixing broken tests than developing new features. Moreover, because they focused solely on automation, no one notices critical usability issues with the product’s checkout process, which negatively impacts the user experience and leads to a loss of sales.
Had they included manual testing, particularly for areas like user experience and edge cases that automation struggles with, these issues could have been caught early, and the excessive maintenance overhead could have been avoided.
What should be done instead?
Instead of striving for 100% automation, teams should aim for selective automation: automating high-value, repetitive tasks while leaving complex or subjective testing to human testers. Here’s how to create a more balanced approach:
- Prioritize automation for repetitive tasks: Focus automation on areas like regression testing, smoke tests, and API testing, where the same scenarios need to be tested frequently across releases.
- Leave exploratory and user-centric testing to humans: Exploratory testing, UI/UX validation, and usability tests require human intuition and adaptability, which are difficult to automate effectively.
- Maintain a flexible test strategy: As the application evolves, automated tests need to be reviewed and updated to stay relevant. Balance your resources between maintaining automated tests and performing manual tests for new or rapidly changing features.
- Choose good test automation tools: Make use of automation tools that are proven to deliver results. These days, AI-powered tools like testRigor are also available, making test automation way more efficient and manageable than traditional alternatives.
Myth #9: Leaked bugs are tester’s fault
It is seen that if bugs make it into production, the responsibility and blame fall solely on the testers. The idea is that testers are the gatekeepers of quality, and if a defect escapes into the live environment, it’s because they didn’t do their job properly. This notion leads to the assumption that testers are directly responsible for any issues that users encounter after a product release.
It stems from the belief that testers are supposed to “catch everything” before the product is released, and if something goes wrong, it’s seen as a failure in the testing phase, ignoring other factors that contribute to quality.
The reality
In reality, leaked bugs are not solely the fault of testers. Quality is a shared responsibility across the entire team, including developers, product managers, and testers. Bugs can be the result of many factors, such as unclear requirements, miscommunication, incomplete feature development, or even unexpected interactions with third-party systems.
Testers operate within certain constraints – time, resources, and priorities. No testing process can guarantee that every possible issue will be caught, especially in complex systems with countless potential use cases. If the development process is rushed or there are gaps in understanding the requirements, bugs can slip through even if the testers have done their job thoroughly.
Rather than blaming testers for leaked bugs, teams should view quality as a collective responsibility and work together to minimize the chances of defects making it to production.
Example: How the myth backfires
Consider a scenario where a mobile app is developed and tested over a tight timeline. The testers are given only a limited amount of time to validate the new features, but due to pressure to release on schedule, the team agrees to move forward without thoroughly testing some edge cases.
A few days after the release, users report a critical bug that causes the app to crash when accessing a certain feature on specific devices. The management team’s initial reaction is to blame the testers for not catching this issue. However, the reality is that the bug was related to a hardware compatibility issue that wasn’t clearly documented or considered during the development phase. The testers weren’t aware of this specific scenario and didn’t have enough time to test on all possible device configurations.
In this case, blaming the testers ignores the fact that the development process lacked proper planning, communication, and time allocation, which were contributing factors to the bug being leaked.
What should be done instead?
To avoid this situation, teams should embrace collaborative quality ownership and ensure that everyone contributes to building a high-quality product. Here’s how:
- Shift-left testing: Incorporate testing earlier in the development process, where developers and testers collaborate to understand requirements and potential risks.
- Improve communication and planning: Ensure that everyone – from product managers to developers to testers – has a shared understanding of the scope, priorities, and risks. Clear communication about the environment, use cases, and user expectations can prevent misunderstandings that lead to leaked bugs.
- Focus on risk-based testing: With limited time and resources, teams should prioritize testing based on high-risk areas rather than aiming to test everything. This ensures that the most critical parts of the application get the necessary attention.
However, with testRigor, you can minimize the production bugs. The test creation speed is considerably high because it allows you to create/generate test cases in plain English. Also, your manual testers, product managers, BAs, and SMEs can contribute to covering complex test scenarios in simple English to achieve greater test coverage in less time. You can build 15X more automation tests than Selenium/Playwright. Your manual testers can build 4X more tests than Selenium QA automation engineers.
This helps reduce production bugs, and by integrating with CI/CD, parallel testing, and 24×7 test runs, you can achieve quality faster and better.
Myth #10: Writing good code means you don’t need testing
Some see testing as redundant or only necessary when code quality is poor. The belief here is that skilled developers can anticipate all possible issues and their expertise in writing high-quality code should eliminate the need for thorough testing.
This myth exists because there is often a focus on developer craftsmanship and the use of modern tools and techniques like code reviews, static analysis, and linters, which help ensure code quality. As a result, some developers or stakeholders may believe that “good” code doesn’t require further validation through testing, especially when deadlines are tight or resources are limited.
The reality
Even well-written code needs testing. No matter how clean or well-structured, code doesn’t exist in isolation – it interacts with other parts of the system, external components, different environments, and real-world data. Bugs often arise not from the code itself but from unexpected interactions between components, edge cases, or integration issues that developers cannot foresee during coding.
Even the best developers make mistakes, miss edge cases, or overlook unexpected user behavior. Testing provides an additional layer of validation and ensures that the system as a whole works as intended under various conditions. It is especially important to test for non-functional requirements like performance, security, and usability, which may not be immediately apparent from code quality alone.
Example: How the myth backfires
Consider a team developing a new feature for a high-traffic e-commerce website. The lead developer is experienced and writes clean, efficient code using the latest best practices. Confident in the quality of their work, they push the feature directly to production with minimal testing, relying on the fact that their code should perform well.
However, once the feature is live, users start experiencing issues with the checkout process during high traffic. It turns out that while the code was written well, it wasn’t optimized for concurrent users at scale, which led to performance bottlenecks. This oversight causes slowdowns and occasional crashes, leading to a poor user experience and lost revenue for the business. If the code had undergone proper performance testing, these issues would have been caught before release, and the team could have optimized the feature for scalability. Read more about Scalability Testing.
What should be done instead?
Rather than relying solely on “good code” to ensure quality, teams should adopt a holistic approach that combines strong coding practices with comprehensive testing. Here’s what can be done:
- Incorporate automated and manual testing: Even for code that is well-written, automated unit tests, integration tests, and manual exploratory testing help ensure that the code works as expected in the real world across different scenarios and environments.
- Test for edge cases and non-functional requirements: Developers should not only focus on functionality but also on performance, scalability, security, and usability. These aspects often cannot be fully addressed by writing good code alone and need specific test coverage. Know more about Automating Usability Testing.
- Use continuous integration and testing pipelines: Integrating automated testing into the development process ensures that every change, no matter how well-written, is validated in a controlled environment. This catches potential integration issues early.
Conclusion
These are just a few of the many myths that exist in QA. You need to get your hands dirty before assuming what works and what doesn’t work because experience will be the best and most reliable teacher. Understanding that, like any other activity in the development cycle, software testing is also nuanced and needs skills to help you form better concepts about QA.
| Achieve More Than 90% Test Automation | |
| Step by Step Walkthroughs and Help | |
| 14 Day Free Trial, Cancel Anytime |
