For those who are not up to date with the latest buzzwords SaaS stands for Software as a Service; it means that the software platform is hosted and managed by the vendor and users simply open their browsers and connect to the application from anywhere in the World.
Part of my daily activities include being in charge of the QA and Testing for PractiTest, a SaaS QA Management System used by QA and Testing Teams to manage their Test, Bugs and Process.
One of our customers asked me how is testing a SaaS platform different from testing any other project or product?
In principle I don’t think it is different, but it requires us to merge various types of tests that up to now I’ve only used on isolated projects.
To give a better explanation, here is a very quick list of the types of tests we constantly run on PractiTest:
Functional Scenarios – As with any other application we make sure that the functionality works as expected.
For this we use the regular testing techniques such as:
– Manual test scripts
– Exploratory charters
– End-to-end scenarios
Apart from manual testing we are also starting to *play* with selenium in order to create an automated regressions testing suit.
Multi-platform support – We use a combination of physical and virtual machines to make sure PractiTest users can work on Windows, Mac and Linux; an also on the IE, Firefox, Chrome and Safari Browsers
Load and Stress – PractiTest needs to handle large amounts of users and we don’t have the luxury of re-booting or going down once in a while.
Remote Access and Usage – Simply put, we make sure that all users regardless if they come from the US, Holland, India, Argentina, or Australia can work with the system with good response times.
There are many emulators (such as Shunra) that can help test this in your lab, but there’s nothing like the real thing, and for this we have a number of local collaborators that are willing to perform a set of tests and report their results from their locations.
Security – We make sure no one can harm (consciously or by mistake) their system or the platform. For this we test that things like cross-site scripting and other security loop-holes are blocked.
Live updates and deployments – Here is something we seldom think about in regular applications: How do you deploy the system while it is still running, and if needed how do you minimize down-time for the users?
This is something that is developed and handled by our IT department, but since the delivery and update of the product is part of the overall user experience we test it constantly.
Disaster recovery & rollback procedures – Another testing task coming to us from the IT side of the house.
Here we run 2 main scenarios:
1. System down that needs to be brought up quickly (with the same machines or with new ones that require installation and configuration)
2. Rollbacks to the last known stable version, including data.
I18N – Since our platform is used by people around the world we make sure that we support the use International Characters.
There are additional tests and activities we are constantly adding to our testing suites; but the main principle is that we’ve learned to see our AUT (application under test) as the complete end-to-end user experience and not only the functional application where testers (our users!) do their work.
We understood that we don’t test only to make sure the functionality works. Our testing objective is that users get the best possible APPLICATION AND SERVICE from our company.
Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.
Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.
With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.