As with any testing project, this one starts with determining expected behaviour. Bugs are defined by their difference from expectations, so to find bugs we must first have expectations.

Reading through the Omni Converter documentation, I would describe it as a REST API service with the purpose of storing Directed Acyclic Graphs (DAGs) in various file formats. DAGs can be created, stored, replaced, retrieved and deleted. There are also some informational commands for API version, supported file formats, etc.

So, if OC is a REST service, then its expected behaviour lies in how it responds to HTTP requests, sent to specific endpoints. Valid requests sent to valid endpoints should receive a predictable response, and the effects of a valid request should persist to the next valid request. Invalid requests at valid endpoints should produce an error and have no lasting effects. Requests to invalid endpoints ought to produce an error as well, regardless of the contents of the request.

At this point I would normally try to compile a quick-reference list of useful data (valid request types, endpoints, error messages, etc), but Palantir seems to have done that work already in their documentation. I suppose it could've been expected from a training showpiece, but OCC's documentation is very short and clear, and I see little room to improve upon it.

So, with some test ideas in my head, and a good reference document to build tests from, it's time to get my own instance of OC and start exploring.