The following is an excerpt from Chapter 22 of The Digital Quality Handbook: Guide for Achieving Continuous Quality in a DevOps Reality.
Quickly gaining the lion's share of digital activity, mobile apps are a growing market for load and performance testing.
Websites need a mobile app version, while many products are only available through mobile apps. Today mobile is at a point of no return.
Take a look at some Black Friday statistics ... In 2015 mobile traffic was 57% of all online traffic, growing from 49.6% the year before and 39.7% the year before that. The percentage of sales coming from mobile is growing as well.
This is the general trend. According to comScore, between 2010 and 2014 the use of digital media time on smartphones grew by almost 400% and on tablets by more than 1,700%. In comparison, the digital time on desktops grew by just 37%. Impressive, isn't it?
The conclusion is clear: once you go for the first release of a mobile app, you commit to its perpetual evolution. It is really a never ending story. You cannot fire and forget a native app into the wild just like that, as it is so much intertwined with the core product offering. In many cases it is the product minimizing the relevance of other entry points for end-users such as flavors for desktops and websites.
A crashing app might be a deal breaker, no matter how heavy the load that an alternative website entry point can handle would be. Therefore, the software development lifecycle (SDLC) for mobile apps is often significantly shorter and more demanding than what we are used to for the desktop.
Fast, accurate, and reliable feedback cycles among business, development, and test teams is a must-have. Essentially, the techniques that help us manage the increased complexity would be smart testing and automation.
Yes, it is all about quickly verifying compliance against key functional and non-functional requirements in order to meet aggressive release schedules as part of the Go-to-market strategy. This means positioning unit testing, UI testing, API testing, and, of course, performance and load testing — as pillars of SDLC.
What Are Performance and Load Testing?
Performance testing is the general name for a testing practice performed to determine how the system behaves and performs in regards to different workloads. It examines a number of important quality attributes, such as responsiveness, stability, scalability, reliability, speed, and resource usage of software and infrastructure.
Load testing is a flavor of performance testing that checks how systems function when a high number of concurrent virtual users perform interactions over a certain period of time. In other words, it reveals how systems handle load in different volumes. Poor performance, which results in app crashes or slow loading times, has an immediate and long-term business impact, diverting customers to competitors and damaging the brand ...
Continuously Testing Performance
Not so long ago load testing immediately before releases was enough. Now testing practices are changing — load tests are moving to an earlier point of development, often being implemented and run by software developers. Instead of testing before releases, which is on the right side of the waterfall, developers are leaving the waterfall, “shifting left”, and testing automatically each time they commit a new change in the source control system. The essence of this trend is explained by the diagram in
The advantages of ongoing earlier load testing are, in short, making developers' lives easier and the product better. To be specific, testing earlier on in the SLDC reduces the risk of performance degradations whenever adding a new feature or fixing a bug in the product. By identifying errors, issues and bottlenecks earlier development teams and product managers could plan enough time and resources to resolve them “before the flood” ie. before such defects reach end users. This also saves the avoidable effort of deploying with problems and makes debugging easier.
Shifting left also lets us integrate performance and load testing into the continuous integration (CI) cycle through open source tools ... CI systems monitor source code repositories, trigger builds whenever code changes are detected, run tests against compiled software (unit, acceptance, automated, performance, integration, etc.), and generate artifacts (binaries, documentation, installation packages, etc.).
A CI cycle is the automated process of building, optimizing, testing, and packaging source code and other content as a software unit that could either be executed as a program or integrated as a component of larger systems. CI platforms play nicely with testing tools … making the software build, test and deployment process automated and efficient.
