Courtesy: TaranRampersad
Web based applications have become the standard if you want to put anything on the web. I’m using one right now to post this blog. You’ve probably used one to check your email or if you check your bank account. These are all examples of a web-based application, and a lot that I didn’t mention.
Content Management Systems make up a good majority of them that you see everyday. Whether you’re reading the news or a blog. These web applications allow for the easy storage or media, creation of pages, and publish abilities that big and small users require to create content and then share it publicly. Besides, it sure beats creating files for each page and all the complications associated.
Wikipedia describes web based applications:
“In software engineering, a web application or webapp is an application that is accessed via web browser over a network such as the Internet or an intranet. It is also a computer software application that is coded in a browser-supported language (such as HTML, JavaScript, Java, etc.) and reliant on a common web browser to render the application executable.”
Since this isn’t a “How to test” post, I’m going to skip the portions of setting up usability tests, feature tests, and regression tests. These are standard test cycles for hardware, installed applications, and web applications.
Toolset
(If you want to skip this portion, click here)
Firebug: http://getfirebug.com/releases/:
- Firebug is a necessary tool for testing the front end of webapps. This Firefox add-on parses the page source for you and allows you to view it in more detail than a CTRL+U with a find can do. Some of the features are an inspect tool to look at the source for a specific element on the page, a CSS browser, and a JavaScript Degbugger.
FireCookie: https://addons.mozilla.org/en-US/firefox/addon/6683
- FireCookie is an extension for FireBug that will give you the same abilities with cookies that firebug does with your page source.
Xenu: http://home.snafu.de/tilman/xenulink.html
- Xenu is (unfortunately) a Windows only program that will click your links for you on your site. This is a very effective tool to ease the pains of checking for broken links. There are multiple settings (some default) that allow you to tell Xenu what it shouldn’t click on. For example, one default link that it won’t click on is: ‘Logout’, ‘Signout’, or similar links. If you’ve had success getting this working with Wine, let me know. Some other link checkers have un-editable settings that limit the speed of the test. This setting won’t allow the checker to possibly do a Denial of Service attack on the site you are testing.
Web Developer: https://addons.mozilla.org/en-US/firefox/addon/60
- This Firefox add-on has a wealth of tools, settings, and information that make a developer’s (and tester’s) life much much easier. From disabling javascript and cookies with a dropdown selection instead of going into Firefox’s menu’s to do it. I use the Delete Domain Cookies function most often. There is also an HTML, Javascript, and CSS validator which links to the W3C validation tool.
Live HTTP Headers: http://livehttpheaders.mozdev.org/
- This tool lets you view (in real time) the information that Firefox is receiving and sending from the webserver. If you’re having problems with sessions and Get/Post functions this is a really good tool to use.
YSlow: http://developer.yahoo.com/yslow/
- This tool will time the display of a page. It is an extension to Firebug. Also, it grades your site on certain specs like: HTTP Requests, Location of Javascript and CSS, and a great stats page for things like page size broken down into components.
Browser Compatibility
One of the most frustrating things for a web designer is to setup your page perfectly in one browser only to see an epic fail in another. As you are testing this same page, you need to keep in mind that all browsers were not created equal. Internet Explorer is one of the biggest culprits for being different. I’m not going to get into the details, but just know, you need to test in the browsers that your company (or you) have deemed most popular with your user set. As a tester working for a company, your front end development staff should have done the research to determine what your user-base is using for it’s browsers.
Load Testing
One of the unique parts of web applications compared to installed software is the fact that a good majority of the processing is done on the server end. Installed software depends on the user’s machine to render screens as well as the supporting information to display on those screens. While your server may be able to handle 1-2 users accessing your application at the same time. What happens to performance when 5-10 or 5,000 – 10,000 users access your application? Keep in mind that if you’re serving a news site or a popular blog, you could very easily be hosting traffic to 5-8,000 visitors per second. The development group should have already taken this into account before letting the project get to the test cycle. This is a great time to mention that Software Testers should be included in the project life-cycle as soon as feasible. Usually the best time is after development has had a chance to draw up a rough-draft plan. This allows not only another brain to throw at the goal, but also gives another viewpoint to finding the right solution for the project.
Documentation, Documentation, Documentation
Ok, I know I said that I wasn’t going to cover the parts of the test cycle that are common across all types of applications and hardware that need testing, but I really don’t think that anyone can over-state the importance of well-written, formatted, versioned documentation. Why versioned? The one big mistake that a lot of people/companies make is keeping the latest version of a document in the project manager’s email inbox. Your development process should already include the use of a versioning system (like svn or cvs). Why not use that system to keep versions of your project documentation?
Automated Testing
There are many dozens of tools out there to automatically test webapps. One of the more popular no-fee solutions is Selenium. This is a very powerful testing application, however since it is an open-source project with so many different ways to accomplish automated testing using it, help is somewhat hard to come by. There are applications out there that do require a license to use. WinRunner (sorry, I mean QuickTest) is definitely the standard in the industry. It’s also very spendy for a license and then additional user licenses. However, it deserves to be.
Moving on… If you have the bandwidth to setup a good suite of automated functional and regression tests, I would suggest doing it. The ability to put the latest commit/build to a specific trunk or branch of your code against a suite of tests every night or multiple times during the day is priceless for a living app (*an application that is constantly under development, which pretty much describes every good webapp). You can setup tests for each bug that is found in your software and have it tested against for the life of the application. Don’t get cocky about your test suite though. If your application is a living one, so should be your test suite. Proper maintenance is required to keep this solution relevant.
Manual Testing
Now that you have this amazing, relevant, living automated test suite, you can’t get lazy. Make sure you’re still clicking through your application and making sure that everything looks/works as designed. There isn’t an automated solution out there that will tell you that yellow text on a white background doesn’t work well. Manual testing is extremely important from the stand-point that humans aren’t perfect, they click things differently. They can stop and go back with just a thought. Your automated suites can’t fix themselves. They can’t ‘wonder’ what happens when specific steps are followed that go off the beaten path. Your users are not going to always do things the way they are ‘supposed’ to. As a tester, you need to be an educated user. Make sure that the designed path is working, but go off the path and try to make the same things happen doing it a different way, or from another screen.
Security Testing
Is User A able to access pages or information that only User B should be able to access? This is one of the biggest concerns regarding web applications. Does your application contain personal user information that isn’t supposed to be public? Can a cunning visitor figure out a way to get that information through your application as designed or by getting past your defenses? What visitors submit to your application should never EVER be trusted. Only by adhering to this idea can you start security testing. There are multiple ways to try to get around an application. using apostrophes in form fields is a great way to see if your app is escaping inputed values correctly before it hits the database or is displayed elsewhere to another user. Also, inserting some javascript code in form fields that aren’t expecting it is absolutely necessary to make sure that the user isn’t allowed to do it.
Submitting Bugs
As with any testing process, the submission of bugs is extremely important. The language of the bugs should have a standard, or you could find yourself with a bunch of duplicate bugs that you didn’t see because you were searching for what you were calling that “one thing, in that one place”.
Reviewing Bug Fixes
I’m going to be strung up for this but… Developer’s shouldn’t be trusted with their commits. OK, that’s a bit harsh, but as a tester you need to assume the worst. And your development staff should accept the fact that they aren’t perfect. At the same time, they should be communicating through commit notes or on bug resolutions what exactly they fixed (which usually makes their commits better anyways if they’re writing about it). As a tester you should not only be reading those notes, but also checking the diff for the fix. Whether it’s a text change (make sure it reads well), or its a functional change to the flow of a feature, it still needs to work.
Keep Your Head
I think any tester who has been in the job long enough has had those days where clicking that next link or looking at that next screen is the hardest thing to do in the world. Let’s face it, testing can be boring. In fact, it usually is. Make things fun. Do you have a HUGE list of tests that you need to run through, and this specific section is taking forever? Skip to a different test section. One of the worst things you can do is allow yourself to get lax on testing an area of your application. Let’s face it, your eyes are going to get tired. Get up and take a 5-minute break that doesn’t involve looking at your computer screen. This will help you keep your focus when you are performing your testing.
Get Your Time
One of the first places that project time is cut from is the testing portion. Development is going to go long. Make sure you vocalize your needs and the possible risks involved with cutting testing time on a project.
–dez
