Recommendation for Test Management tool for manual web testing
Previously, I posted a question regarding the best tool for the job. Currently I'm trailing TestRail, however I do have some impediments with the plan of attack when planning on how to create test suites/cases for work.
I'm testing a web application which is a BackOffice and Point of Sale.
What I'm finding difficult to achieve is, what is the best approach to structure my test suites and cases?
Given that the end result should be easy to manage & maintain, easy to derive test plans/runs from.
1. Would you recommend on structuring test cases based on the UI structure or functionality?
2. After a decision is made, would you still recommend TestRail for it?
I can't speak to TestRail because I don't know the tool, but I can give you some thoughts on your first question.
My short answer to that would be "yes".
The slightly longer answer is "it depends".
The expanded answer is that I will structure test cases on what makes the most sense for them. Some test cases will be structured according to function within a page, some according to UI structure, some according to a process flow through the system, depending on circumstances.
At the page + functionality level, I'd cover things like saving and server validations, such as in setting up a product, log on, log out, session management and the like. This usually involves checking that the database contains the data I'm expecting it to contain as well as that the results I should see on the next page in the sequence are present. It can also include checking logs to ensure that communications between stations or with third parties do what they should (such as credit card payment gateways).
Finally, at the process flow level, I'd look at common sequences of use. In a point of sale system, there's likely to be a flow along the lines of "sales person logs in at the start of shift, makes a number of sales, closes the shift and logs out" and within that a number of sales consisting of "select one or more products, make payment", possibly with "select a product return and pay the customer", "select a product exchange and process it", "take a phone order and prepare for invoicing" and so forth. I'd be looking at each scenario and ensuring that after each step all the totals were correct, that subtotals and tax amounts were correct, that payments processed correctly for all supported payment types, that the entire transaction recorded correctly, and that the amounts reported to the customer and sales person were correct. (I worked for seven years testing point of sale and back office software...).
As a general rule, I'd focus most on the features and functions getting the most use - in a POS/Back office system that's going to be sales transactions and reporting - those with regulated requirements - such as credit card payments and tax calculations - and the features that have a financial impact on customers - the recording of transactions. Functions and features supporting the focused areas get attention as they're developed and modified, but not as much attention in regression because those tend to be once-and-done things (such as product configuration) or happen all the time anyway so they'll get tested as other tests are performed (log on, log off, session management, access permissions). In addition, general-public facing parts of the system get extra attention (such as web stores) for usability and how clear they are to a casual user; and areas that get heavy use from trained users (such as a point of sales interface) get extra attention focused on power-user features like keyboard shortcuts and streamlined process flow (the POS system I tested could, if configured that way, complete a transaction in two steps. Select the product shortcut key, swipe the credit card, and the transaction is done).
Wow, thank you for the detailed reply. You've been very helpful! Reading your comment, did make sense when I view our product and seems I will follow up on how you described your approach.
I'm starting to build the high level test cases just to get some basic coverage for starters and then see how I can leverage from testrail as I add more and more to it while integrating with Jira.