Sometimes, tasked with testing a piece of software for which there are no requirements, a tester will resort to white box testing. Are there times when that is inappropriate?
Here is an example. At a prior job, we had some loosely-worded requirements for some reports and a general requirement for a datamart (a reporting database) for running ad-hoc reports. The developer chose to implement the (loosely-specified) reports on top of the datamart.
The datamart had a different schema from our transactional database. There was a tool for transferring data from the transaction database into the reporting database. The tool ran on a server and was not user-facing. The tester was tasked with testing the tool, not the reports.
The tool was driven off of SQL queries. The tester's strategy was to read each query, figure out what it was supposed to do, and write a set of tests that tested the behavior of that query. So for example, say the goal of a query was to read rows from table X in the transaction database, fiddle with the data, and write the results to table Y in the report database. The tester would write a test that inserted some rows in table X, calculated what the expected results should be, ran the tool, and then verified that the expected rows showed up in table Y.
I always wondered what would happen if a test failed: would the tester question whether there was a problem with the tool, or would he assume his test was wrong? After all, the tool had no explicit requirements. This seems like a risk for any type of white box testing, and I wonder whether the maintenance costs of this kind of test justify the effort.