We're in the process of shifting our datasource from Mongo to MS SQL Server. Our challenge is that we have two testers who are green. As a team, we're trying to work through the most sensible test approach.We have two datasources (one MS SQL, one Oracle) that are integrated via flat file feed to a MongoDB, which is used to present product data on a website. Our endpoint is to convert the MongoDB to MS SQL.We have two pieces to test.Datasource comparison. The data feed is loaded into both sources. Our DBA installed Simba MongoDB ODBC with SQL Connector driver to allow us to make side-by-side comparisons using SQL. It seems to me the biggest risk here is that the driver does its own set of interpretations about the underlying structure of documents in the Mongo source in order to present the data as tables, and on top of that, our queries also need to reshape the data to make sure we can compare SQL and Mongo sources.Display logic comparison. The data objects that drive the product pages are theoretically source-agnostic, but there is display logic in the front end that could be impacted if the SQL data model and the Mongo data model aren't aligned exactly -- and they aren't. We've installed HtmlAgilityPack in order to compare elements on the product pages using C#. I'm not sure what the risks are here.Given the additional considerations that:We are moving the Oracle DB to MS SQL this year and will use this test approach for that project.We are in desperate need of automated testing for our product pages.We have a plan to normalize the SQL DB source in phases after the cutover, and then to eliminate the data feeds, all of which will require robust datasource/display logic comparisons. Our testers have exactly zero experience with testing data and web interfaces, and also have no development background that will enable them to write code for automated testing.My concerns are that we may be considering the wrong approach because the testers do not have sufficient experience to tell us what they can do. The dev group knows how to test this way, so that's the way we're designing it. I don't know if this approach will work and be maintainable through next year's releases without significant investment of non-tester time and resource, and if it does require non-tester time and resource, if that continued investment worth it if it means the testers end up doing work that requires no thinking. Is there another way to do this that could be used by our testers, to enable them to have more ownership over the test process, support their skill development, and also provide automation for future releases?
How do we design a test approach for inexperienced testers?
testing;test coverage;test automation