In the last decade, performance testing and related stuff
are working as the sub functions and maybe they are not that much considered as
the main activities in the life cycle of the software product. But due to factors such as increasing of the cyber users, rapid development of the different technologies and modern comparative business goals, software product venders had to change their
mind set towards performance testing and engineering aspects. If they couldn't
predict and change their product according to the end user needs and if they couldn't retain the regular users then definitely that business or industry
will go down and die out soon.
Then, after the industry
identifies the importance of the Performance
optimization, performance testing
and tuning is came in to the screen with different strategies. First,
performance testing methodology was introduced to the product development. In
this approach software product is tested by a dedicated performance testing resource and tuned by the help
of development team in the later part of the SDLC or after product is 80-90% completed.
So this was a collaborative approach among the team members to get the maximum
out of it. But there is a hidden failure in this approach.
As I have mentioned in the last
paragraph, all the testing mechanisms,
strategies were fired after the major
features of the product are almost completed or very next to the alpha or beta releases. But one can argue that if they can find any
performance related issues before go live would be a great achievement since
the cost of the production site issues were reduced. Yes, true but product
owners and developers/QAs cannot concentrate only at the external failures (production issues) thus we have to give the
equal attention for the internal failures
since both items are contribute to reduce the Cost of Quality of a software product.
Now, all the parties come to the ultimate
situation where they need to change their mind set and strategies they have practiced
earlier to find the performance bottlenecks. So this is the time that the Performance Engineering attribute or mechanism
was introduced and begin to spread the horizon. The main advantage of this
engineering practice was the knowledge and the confidence that the team can
generate on top of the product which going to release. So lets' find out how the
industry gonna build this or how they adapted to this practice.
Nowadays, agile (scrum) practices are very popular among the software people
instead of the waterfall method. Whatever
the software development methodology
used, practicing of the performance engineering
aspects are not that much easy since its required thorough knowledge regarding
what and when we need to do things which aligned with the SDLC. For an example good understanding of the current technologies, knowledge of the DB entities, network
related awareness, testing tools
expertise, knowledge of the performance
testing attributes, testing types,
capacity planning and workload modeling etc among them. These
practices are more sharpen with the different project experience. So in this
approach, we start our performance testing engagement from the sprint 0 or requirement analysis phase. In this early phases, performance test
engineers can go for the requirement review and designing meetings with the development
team. Likewise performance test team members or specialist can gather, test and
examine the results and help to resolve the performance bottlenecks throughout
the each sprint or life cycle phase. In other words, performance related issues
of the back end and front end of the Application
Under Test (AUT) can be identified as early as possible and not the final
stages of the software product.
Following Graph will depict the core
and performance engineering phases:
Finally, by using this
methodology or approach, we can find both external and internal performance
related issue early to reduce the 'Cost of Quality' and optimize the customer solution
to gain the ultimate hope of 'Confidence'
to say 'Our Product is OK for go live'.
