There aren't many steps I take which are unique to or special for Web application testing. The bigger key in selecting cases is to be familiar with your application and your development team. Know what their biggest weaknesses are -- not so you can accuse them, but because you need to test around those weaknesses. For instance, if a team has solid coding skills but is haphazard in packaging and deployment, gauge your regression test to spend time investigating the nuances introduced when your package is built and/or deployed.
One topic which comes up often in Web application regression is the browser platform. As new browser versions are introduced, compatibility can be affected. Typically, support for a new browser platform is considered a release work item, but what about backwards compatibility? If your team is adding the latest, greatest browser version to your test list but NOT removing anything, you'll need to keep that in mind. Often, changes between browser versions have backwards compatibility issues. Yet you can't regress every platform all the time. I take three steps to address this: first, I encourage my teams to rotate browsers during their day-to-day testing. Secondly, I select an older browser version with which to perform a deep dive regression during the regression pass. Finally, I "tune" my cases to my development teams' skills. If they're notoriously neglectful of a certain version of Internet Explorer, for example, I'll be sure to touch that browser version during my testing.
Dig Deeper on Topics Archive
Related Q&A from John Overbaugh
Learn what's behind AWS outages and how to fix failures before they happen. Continue Reading
Learn strategies for best security test strategies for SaaS cloud. Continue Reading
Expert John Overbaugh identifies the three top concerns of the test manager and offers advice on how to stay ahead of the curve when it comes to ... Continue Reading