| || |
Non-developer functional testing of major packages
We've purchased a major ERP package and are planning for multiple test teams based on functional areas. We have many test scripts prepared based on the manufacturer's user guides. Our business users will go through the testing/learning process and record any deviations in results from each test "script". Of course we will categorize any deviations the business-testers discover into classes of error, including software defects. BUT, the defects will be manually communicated to the developers and the vendor will enter the software errors into their proprietary CMS.
So we are not interested in defect tracking per-se but managing a large body of test cases and any outcomes that deviate from what the business testers consider historically accurate. The test data will be actual historical datasets with known outcomes.
We want to manage data-sets and test case IDs without necessarily storing their contents inside a test tool.
What are the best low-cost Systems QA Validation tools on the market?
Excel is any easy choice for low cost test case management. But there's a few other statements in your post that concern me.
Test scripts based on the manufacturer's user guides? This might be okay for unit/component testing, but you'll also need end to end business scenario tests. An ERP system is a collection of modules, and it will be the integration between those modules end to end for your actual business processes that determines whether or not it works for you.
Defects manually communicated to the developers, and vendors entering errors into their own CMS? Not sure what this means in practise, but it implies that you won't have any central defect management system for your business? Practically speaking, you shouldn't be expecting many vendor defects - in an established ERP product you should be expecting most defects from business-specific config, from bespoke developments and coding, from data conversion issues, and from the design and build not matching the required business processes. You should definitely be interested in defect tracking!
Your test data might be historical datasets with known outcomes, but you'll also need to take into consideration whether or not the implementation of the ERP system has forced a change to any processes, has added any additional fields, changed any field data due to config, and has been mapped correctly through any interfaces.
Multiple test teams based on functional areas are okay for component/unit/string testing in their own functional areas, but sooner or later they're going to have to get together for end to end integration testing, following multiple threads through the system. For example, in a manufacturing ERP you'll need Planning, Procurement, Warehouse, Quality, Manufacturing, Warehouse again, Sales, Distribution (warehouse again...) and Finance to follow through the same scenarios.