INGenious Playwright Studio is a codeless test automation studio. It is a Java desktop application in which each test case is a table of keyword driven steps rather than a program you write by hand. You describe what a step should do, which object it acts on and what input it takes, and the engine carries it out. It is aimed at testers who want to build automated checks without writing code, while still running everything from a pipeline.
How it works
A test case is a CSV table. Every row is a step with columns such as Step, ObjectName, Description, Action, Input, Condition and Reference. For API work the steps act on a built in Webservice object, using actions like setEndPoint, addHeader, postRestRequest, getRestRequest, assertResponseCode, storeJSONelement and assertJSONelementCount. A protected flow captures a token in one step and reuses it in a later step through a variable:
Step,ObjectName,Description,Action,Input,Condition,Reference
4,Webservice,"Assert Response Code ",assertResponseCode,@200,,
5,Webservice,Store JSON Element,storeJSONelement,@$.access_token,%token%,
7,Webservice,"Set End Point ",setEndPoint,@https://api.practicesoftwaretesting.com/invoices,,
8,Webservice,"Add Header ",addHeader,@Authorization=Bearer %token%,,
9,Webservice,"GET Rest Request ",getRestRequest,,,
10,Webservice,"Assert Response Code ",assertResponseCode,@200,,
The %token% variable holds the value pulled from the login response, and the invoices request sends it straight back as a Bearer header. Under the hood the studio runs on a Java engine built with Maven. You build test cases in the graphical studio, group them into a test set, and run that set from the command line, which produces an HTML report.
Benefits
The obvious win is that no programming is required. Steps read in plain language, so a manual tester can build and maintain checks without learning a language or a framework. Because a test case is just a CSV table, the definitions are still text and can be stored in Git. The same test set that you built in the studio runs headless in a pipeline, so codeless does not mean stuck on someone's laptop.
Downsides
Keyword driven tables trade flexibility for approachability. Anything the built in actions do not cover is harder to express than it would be in code, and complex logic can turn into long, fiddly tables. The tool is specific to this studio, so the skills and the assets do not carry over to other frameworks. The CSV format is friendlier than a binary file, but a large table is still harder to review than a few lines of a real language. It suits teams who value a low barrier to entry over maximum control.
What the example project tests
The repository at github.com/testsmith-io/api-test-automation-ingenious-playwright-studio tests the Practice Software Testing API at https://api.practicesoftwaretesting.com, the ToolShop backend used across this series. The endpoints are written straight into the steps.
Three test cases sit under a ToolShop project. One calls GET /brands and asserts a 200 response. One posts to /users/login with a JSON body, asserts 200 and checks the access_token element. The third logs in, stores the token, then calls the protected /invoices endpoint with the Bearer header and asserts 200. A GitHub Actions workflow sets up a JDK, builds the engine with Maven, runs the test set on Ubuntu and on a weekly cron, and uploads the reports. It is the same three scenarios as the code based examples, expressed entirely as tables.