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 strategies for best security test strategies for SaaS cloud. Continue Reading
Security and security tools have become more necessary to the application lifecycle, according to recent research. In this response, expert John ... Continue Reading
Expert John Overbaugh defines security as confidentiality, integrity and availability of information across systems and applications. Read this ... Continue Reading