You have a new code release and two weeks for performance testing. What tests do you run? One common answer is to run the same tests you used on the last release (after fixing your scripts, of course). This is a good way to make sure the new release can handle the same load as the last one. However, this approach ignores a key fact: loads change.
Web services—software code that enables the client application and the services to interact successfully—are literally the building blocks of application function. To ensure application performance and minimize user problems in production, each web service should be tested—and its functionality and connectivity trusted—before the developing organization integrates it into the application.
As someone who preaches requirements across the country, I can honestly tell you, “What stakeholders want is not important. What matters is what they need.”
It simply isn’t feasible to test every possible user scenario with a new app, and the testers who already know how the app should perform can’t approach using it the same way as someone unfamiliar with the process. Enter crowdsourced testing, where you gather a customizable pool of people from outside your organization to test your apps for defects and usability.
Ways to start achieving more “people integration” while gaining a better product and a less stressful work environment in the process.