Automating tests in EPOS systems

Question

I have recently started working in a team that tests Retail applications such as EPOS (end point of sale - tills) I would like to automate this testing and would like to ask if anyone has any experience in this area and if any has any ideas/comments on this? I am in the progress of setting up a virtual environment to make automation possible, and am now at the stage of thinking which automation tool to use and how long this is going to take etc. I'm thinking currently of Selenium Webdriver if possible as this can be coded in Java which will make everything much more user friendly and editable by less experienced testers. Any ideas/help welcome. :) Thanks,

Answer 1

I spent about 7 years testing a large, complex application that included point of sale with tills in its feature set so I have some experience in the area.

Here's some things I'd consider in your situation:

• Does the tool you're considering allow you to get past the interface to either an API or the components on the screen? If not, it will be much more difficult to build robust automation.
• Is the POS software reporting sales to a database? If it is, you will definitely want to include database checking to ensure that the sales are correctly reported. You may also need to include checking of generated sales reports.
• Does the POS software handle its own credit card authorizations, or is that done by a third party? If the software handles its own authorization, you're going to need to include credit card testing in some form (and depending on where you are, compliance testing as well to ensure that storage of credit card data meets the rules of your region).
• If the software stores sensitive or personal data (names, addresses, social security... anything that can be used to identify the person who made the purchase) there are additional compliance rules you'll want to cover.
• Tax calcs. If the application does its own tax calculations, you'll need to test them.

Virtual environments are great for this kind of thing, provided you have the server and/or cloud space for them. The thing to watch for is that automation can be very I/O intensive, which tends to be a bottleneck in automation at the best of times.

My advice is to start by automating basic transaction processing in POS software - start the software, select something, pay for it, check database and wherever else information gets stored, shut everything down. This kind of thing grows exponentially depending on the different kinds of sales supported (does everything have a single button, menu navigation in the POS system, is there extra data being entered like weight for produce sales), the complexity of the tax support, the number of ways the system can be configured, and so forth.

I'd strongly suggest data driving and modularizing your tests:

• have a setup routine that populates the system with a known starting data set
• a logon routine that can take parameters so you can log in as a cashier or a supervisor (who will have access to different functions but start with a cashier view and make it possible to pass in user name/password to log in)
• an item selection routine you can give the hook to pick the item on the screen
• a payment routine you can upgrade to handle all the interesting combinations of payments that are likely to occur
• an end-state data check that covers any changes your tests will have made (this is less useful than checking after each transaction, but it's also typically a lot easier to implement because you can just pull everything from every data store that's been impacted and run a line-by-line or cell-by-cell comparison. Ultimately you'll want both)
• a tear-down that exports your results and leaves things in their ready-for-test state.

This is going to take you a long time to make it work. I can offer a starting point in the form of a test data management app (which is still very much in alpha but will let you create all your test data in a database with semi-decent web front-end. I'm using it to drive the tests I'm writing with a bastardized framework that starts with Microsoft Coded UI testing - environment requirements are SQL server 2008 (express will work) and dot net 4.5) (In case you hadn't noticed, I'm a BIG fan of data driving tests so that new tests are a case of adding data, not adding code).

You mention being concerned that your less experienced testers be able to create new tests - in my view the best way to do this is to have a data framework that your automation consumes. It takes a lot more time up front to set up, but can be done with most automation tools, and once it reaches a reasonable maturity level, adding new tests requires little if any coding. The framework I'm developing is coupled with data to the extent that to add a new test involving data entry to a web form the only technical knowledge required is how to find the text field ID and the button ID (I'll get to other types of web component...) - basically right-click on the page, pick view source, and find the field I'm looking to automate, then put its ID into the database and I've got my automation. The coding I'm doing to support this is pretty... interesting (and would probably give programmers fits - but it's a start, and I'm doing this part time).

That's my advice for what it's worth - if your tested apps are simpler than the things I've had to deal with, feel free to ignore all of it.