The process of testing a product
alone is not a wide area to discuss about, and it requires no knowledge in rocket
science to execute such a process. Nevertheless the integration of a Quality Assurance
process to a normal testing process will answer the rhetoric question I brought
up as the topic and also it requires great effort and knowledge to combine the two
things. The main key areas to consider when executing the above said combined
processes and the challenges that one will encounter will be discussed here.
The major challenges which hinder the
QA process can be pointed out as follows,
·
Lack
of resources. (Human, machine etc)
·
Tight
release schedule.
·
Unclear
requirements.
·
Miniscule
margin for error.
Most of the time we fail to create the
real environment that our client has. Therefore such failures will lead to
results that differ from actual test results. In addition to that if the tester
fails to recreate the business process in their QA environment due to lack of
knowledge about the business requirements, it is
certain that the end user will not be satisfied with the final product.
The next big thing that every tester
will encounter is a very tight release schedule and most of the time only a
smoke test is carried out on the product. In my experience this can happen
owing to several reasons, If the product developer consumes more time than the
allocated time period it will impact the time allocated for testing and
implementation, On the other hand, although the developer releases on time, if the
number of bugs are high on the QA released product, the product will ultimately
have to iterate several times in the Software life cycle process which consumes
more time and resources. This results in the tester having
to re-execute the same testing which can be considered as a re-work. Also the
poor project planning can also be another minus point on the product delivery
dates. All the above mentioned factors have a high impact on the first point I
have mentioned as challenges.
Nevertheless most companies have adopted
‘Agile’ life cycle process. In this software life cycle,
the requirement analysis has a tendency to weaken in its initial stages,
therefore developers and project managers are more likely to implement
premature decisions on the half-baked requirements gathered from the client.
This also leads to iteration of the development – testing process, and this
will enter a very risky position if such product releases bypasses the tester.
So this is the exact place where the tester needs to be equipped with the so-called
weapon named ‘Quality assurance’.
The next challenge ‘Miniscule margin
for error’ can be simply explained,
“When a developer makes a mistake, it is a BUG...
But when QA makes a mistake, it’s a
RECALL”
A QA mistake can affect the whole
project because QA can be described as the last line of defense, so we as QA engineers
should ensure no recalls!
To overcome the said challenges, QA
engineers should work according to a plan and also reviewing all specifications
and documents for a project as early as possible will save both time and money.
If an urgent release is to be done,
the pre-written test cases using automation tools like Soap-ui, Load-ui or
whatever the automation tool that suits the relevant QA process and the
software architecture of the company can be executed to get maximum results
with no effort. So as mentioned earlier no tool can check for the quality of
software, they may succeed in testing performance, Scalability, functionality,
etc but a real professional QA is the person who should define the limits and
boundaries of a product.
In my opinion we as QA engineers
should not be restricted to one or two technologies that we use in our QA
process but we should always explore more so that we can use them to automate
the process in such a way that it gives the accurate test result. And also
being restricted to a set of rules and regulations in testing will only make
you act as a traditional tester who reports bugs to a developer but being a QA
who thinks out of box with a free mind and in different ways will satisfy both
the company and the customer.
Even though the mentioned precautions
do not guarantee success, it will certainly be a step in the right direction!
But remember to ask yourself the
question always;
“Are we building the product
right? And are we building the right
product?”
R. Marlon Abeykoon-
Quality Assurance Engineer
DuoSoftware (pvt) Limited
