Well, I can't post that much info on here, and none of it is available externally, so I will probably just have to describe it and post screen shots.
However, before I do, let me state that I do not do test automation the way most people do. I approach it like a software development project. Most people who move from manual testing into automation try to do exactly the same thing with automation that they do with manual tests. They structure the tests the same way, they organize their data the same way (Excel, anyone?? I hate Excel, by the way, I think it is a blight on the testing process...
). I also very heavily (maybe overly!!
) embrace data-driven testing.
So, let me describe the systems I test, and then I'll layout some info about my test architecture.
I work for The Container Store (look us up, we sell great stuff, and we're #14 on Forbes' "Top 100 Places to Work in the US"). We have approximately 90 stores across the continental US. We build all of our Point-Of-Sale (POS) and eCommerce (web) software in-house. The POS software also includes a custom closet design application ("CDC" : a semi-CAD system) and is built on Java, using a REST middle tier with Oracle (and some MS SQL Server) backend. eCommerce is standard stuff and uses the same middle tier.
I write tests mainly for the POS/CDC system, although I have been recently re-tasked with writing IE 11 web tests since Selenium seems to have issues with IE (or that is what I was told).
Our POS system allows customers to make orders. These orders can contain multiple fulfillment groups. A fulfillment group is just a collection of items that are going to be given to the customer a certain way:
"TAKE" - customer carries the items out of the store at the time of purchase
"SHIP" - customer wants the items shipped from our distribution center (DC) directly to their home/business/etc.
"PICKUP" - like TAKE, but they will get the items at a different time, or from a different store
"DELIVER" - like SHIP, but comes from a store, using a deliver service, mainly in large metro areas (NYC, DFW, LA)
"RETURN" - customer returns an already purchased item to a store
The last 2 can be combined with an installation service depending on which items are purchased.
The last 3 can be placed over the phone, online, or in the store.
All of this sits on top of a REAL-TIME inventory tracking system (we were one of the first in the industry to do this) that tracks how much stock each store as well as the DC. In addition, it also tracks what is on trucks to the stores, and projects what we expect to get into the DC on any given day from our suppliers.
In addition to all of this, the POS/CDC also allows a user to go into an existing order (anything but TAKE) and change it (say the customer calls back and wants a different color of the item they originally ordered, or quantity, or ship location, or payment, or really just about anything in the order...).
ANNNDDD... The CDC allows the user to create and customize closet systems (elfa is our big one, it's great stuff!!) and purchase those fully complete designs.
Sooo.... How do you test all of that with a flat system? How do I get to point M in the system without going through A,B,C,D,E, and J first (or any other combination that may be appropriate)??
On top of that, how do I allow the manual testers to be able to define test scenarios without them having to learn SQL and Ranorex the way I know it? Even to do simple test cases with a flat structure, like most people do, I would then have thousands of test case to manage individually. I'm not gonna do that...
So, I came up with a model in the DB to handle almost every situation that can occur in our system. Basically it mirrors the structure of our Oracle back-end.
Here it is (* => each parent may have many of these):
Code: Select all
CustomerOrder has -
- *FulfillmentGroup (SHIP, TAKE, etc) has -
- *Closet design (all the items that are being purchase to make that closet system)
- *Detail (the item list) has -
- *Quantities (this allows for changing the quantity during a test, to check that the system handles that)
- Customer (email, name, etc.)
- *Address
- *Phone
- *Store (the store or stores that this order will be purchase in, allows for the same purchase shape to be placed in multiple stores so we can test different tax rates, etc.)
This isn't all of it, but you get the point. Returns are handled in a different structure, but each return is linked to a specific Order/Store combination (or to multiples, so we can return from multiple orders at the same time).
Do you get the sense of how complex our system is yet??
That is why I prefer to use a more complex test architecture. It better mirrors actual use and because each base test is fully-featured, I don't need to maintain as many cases.
More next...