Quality Assurance vs Quality Control – How Agile Methodology Strikes the Right Balance.
This is a guest post by Juri Vasylenko of Ramotion – one of the most skilled interface design and icons creation studios out there.
As our company Ramotion, have developed our first few applications using Agile Methodology, we have realized it is not enough to be proactive about quality control to get a quality product.
The first step is to provide the right conditions to obtain a quality product. Ramotion stress the utmost importance that all conditions which the application is developed in, are the highest quality themselves! Like the saying goes…
“You are only as strong as your weakest link”
… so make sure your processes aren’t weakening your app development.
Psychologically, it is conflicting to frame your mind around two opposite ways of thinking at the same time. More to the point, you cannot be “trying to find errors” and “looking to reduce or eliminate errors” simultaneously.
“Looking to reduce or eliminate errors” though fits in well with the ideology of Agile development that we use to develop our projects. This way, we can focus on “trying to find errors” while the Agile ideology “reduces or eliminates errors” in an organic way at the end and beginning of the project lifecycle.
The problems of testing in Agile
The two strongest variables in Agile are time and flexibility. A sprint deadline is unbreakable, while the software product itself needs to be flexible for changing for future sprints.
The traditional approach of “waterfall” for testing threatens the first rule. If QA engineers wait until developers finish their work to start testing the application, there is a chance that the app will not be 100% tested. If this happens, releasing of a new version of the application is too risky as it could be bug ridden.
What we are doing to avoid all these problems?
When I remember my math lessons in high school, whilst solving equations that the teacher delegated to us, we had to look for the range of values that were permitted and to also check if the result matches these values. At the time like any of us as student, we don’t value such information as being useful in the future, but as it turned out it was my first “Unit” tests.
Verifying that the code works as a programmer plans, is the basis for quality assurance in an Agile team. Any sophisticated system is composed of smaller blocks – “Units”, and ensuring that each unit is working properly, conversely increases the probability of the entire system working 100%.
Once the developer is convinced that the developed module is working correctly, you need to make sure that the system in which adopts it behaves properly as well. For that, there are integration tests that are also being developed by programmers and designed to test the system’s behaviour after the implementation of the new module.
Any module which a developer works on, is intended to perform a specific function (user story), and to make sure that the function works as a user or a customer expects is the responsibility of a QA tester.
Usually, the development process is ongoing until the end of the sprint, so the testers start their work with testing requirements & compiling (and automating) acceptance criteria from the beginning of the sprint. This is very important because it allows the developers to specify the correct direction and decrease the number of possible errors.
At the vertex of the pyramid of testing is the UI testing. Due to the fact that our designers are engaged in ergonomic and aesthetic problems, at this stage, the goal of tester’s work is to check that the random user actions (orientation changing, simultaneously pressing a few buttons) and outcome variables (cell calling at run time, or transition from one type of Internet on the other) are doesn’t violate the logic of the application work.
Overall, this is how Agile methodology allows us to develop an app quickly and accurately so that the application can be easily adapted for users needs.