Copyright © THE FAS SOLUTIONS 2018 All Rights Reserved.
Many people think that Quality Assurance is just testing and it is easy and straightforward and that anyone can do it. Testing most certainly is an integral part of the Quality Assurance Process and to excel you must have a thorough knowledge of the How-To’s of testing. Well, you can’t accurately test without requirements. Testing and requirements are closely related. Sometimes automatically generating tests directly from requirements helps solve those problems.
A Best Practice provides a clear description of a set of procedures and guidelines, that when practically applied to an operation brings the business on clear advantage. Remember following four points and you are on course to best quality assurance practices:-
- Clearly State the Objective – Many organizations creates test plans and assumes that testing is over when every single test condition passes their expected results. In reality, this is a very difficult bar to meet. Often, some requirements turn out to be unattainable when tested against production information. Some business rules turn out to be false or incredibly more complex than originally thought. Collaboration between IT and the business will help identify the reasonable issues versus the issues that cannot be resolved for the current release of the data warehouse. Prioritizing the test plan can help the testing team make these trade-offs.
- Automation is the key – We have all heard, “This is a one-time thing” far too often to ever believe it again, if we ever believed it in the first place. Through the automation of QA procedures, organizations can gain efficiencies while increasing the quality of complex applications. Many organizations have adopted QA frameworks to help standardize the approach to QA and provide the proper tools and processes for QA professionals. For testing customer intelligence applications, there are three aspects to QA automation:
- Ensure tests are repeatable;
- Tests must have easy to interpret results; and
- Build every test within the same framework.
- Ownership and Accountability – It seems that ownership of the process and accountability of the results is one of the most debated topics in quality assurance. It is easy to say that a developer is responsible for unit testing one’s own work, but it becomes blurry when delineating whether the business or technical owners should create and execute a user acceptance test (UAT) plan. While is it critical to have end users involved, having them be the sole owner can sometimes greatly lengthen the UAT period and create a divide between the teams that does little, if anything, to help adoption – which is truly the goal.
- It’s All in the work force – Balancing the workload across your organization is always a challenging endeavor. As QA becomes more important to the success of all applications, this task becomes even more complicated, especially with the many options available. Offshore firms provide outsourced QA solutions as well as blended solutions integrating staff with offshore developers. Finding the right mix and determining the right allocation of your top talent between architecture, design, development and QA is the key. Some firms have even developed programs that provide their employees with rotations in various roles, which seem to help retain key employees, allowing them to understand the various roles.
3 Comments
Bakkum
hey i found your blog today and I have read some awesome articles over here. I just wanna thanks you for publicing it so we all can learn about it!
Allscheid
hello i found your site today and I have read some awesome information over here. I just wanna thanks you for sharing.
Mamah
It seems to me that BOTH titles are out of sync with what we are and/or lsuohd be doing. They both come from manufacturing. QA is the process police: If you just follow the process, you can’t go wrong. Testing (like Quality Control) is about inspecting the final product: report measurements and deviations. We are NOT software manufacturers. Little of what we do is governed by statistical sampling and analysis. Quality Assurance is a process monitoring set of activities. If you re-read the initial post, and replace QA with Project Management, it kind of works, don’t you think. Many of the tasks described fall into the realm of what we now call the Software Program (or Project) Manager. So clearly, Testing is NOT QA/PM.Testing, as described above, is the act of executing test cases THAT’S what I don’t like about: the Testing label. It encourages over-the-wall thinking. Where do the test cases come from? It s not ready for testing, we are still writing code and trying to get it to build.. We all know that the sooner we find (or better yet, prevent) bugs, the cheaper it is to fix them. Well, if testing waits until the code is in place, what do we call the other activities we lsuohd be doing? You know; critically analyzing requirements (acceptance criteria, if you are of the agile ilk), assessing design for weaknesses, suggesting additions changes for testability, designing test scaffolding and programs (we don’t just manually test, do we?), developing and debugging test programs This smells of an engineering process, not just execute tests .So, I have to agree with you: QA and Testing are NOT the same thing. Neither term is sufficient.