Three ways BugLight looks at your software.
One reads your API specification and works from the contract. One opens your application in a browser and works from what it finds there. One works the security surface from the outside. All three generate their own test scenarios rather than executing scenarios you wrote.
- GET/invoices
- POST/refunds
- GET/invoices/{id}/pdf
- PATCH/subscriptions/{id}
- GET/subscriptions/{id}
- DELETE/payment-methods/{id}
API testing
This is the more mature part of the product. You give BugLight an OpenAPI or Swagger specification and the URL the API runs at. It reads the specification, works out which endpoints exist, generates scenarios against them, executes those scenarios, and validates what comes back.
The point is not that BugLight writes API tests faster than you would. It is that a specification already describes far more cases than a team has time to write by hand, and most of them never get written at all.
Request
{
"customerId": "cus_8134",
"items": [{ "sku": "NW-2281", "quantity": -4 }]
}Assertions
- failedstatus is 4xx for an invalid quantity201 Created
- passedresponse body matches the Order schemamatched
- passedresponse time under the documented timeout312 ms
- failederror body documented for this caseno error body
What a generated run looks at
- Status codes
- Whether each endpoint answers with the codes its specification claims, across the cases the specification describes and the ones it leaves implied.
- Response schemas
- Whether the body that comes back actually matches the documented shape, including fields that are present but wrong and fields that quietly went missing.
- Error handling
- What happens on malformed input, absent fields, wrong types, and the requests a client should never have been able to send.
- Boundaries and edge cases
- Values at the edges of what an endpoint accepts: empty, zero, negative, oversized, and the ones just outside the documented range.
- Rate limiting
- Whether the limits behave the way they are documented, and whether the response tells a client what to do next.
- Timeout behavior
- How the endpoint behaves when a request runs long, and whether the caller is left with a usable answer.
Opened the storefront and read the page
Found 9 interactive elements and 3 navigable regions.
Signed in with the supplied test account
Session established. Cart restored from the previous visit.
Added two items to the cart
Cart badge updated to 2. Subtotal recalculated.
Applied the promotion code SPRING25
Discount applied. Subtotal dropped by a quarter.
Changed the quantity of the first item to 0
Line item stayed in the cart, subtotal recalculated to 0, and checkout stayed enabled.
Continued to checkout to confirm the behavior
Checkout accepted an order with no purchasable items. Evidence collected.
Exploratory interface testing
An AI-driven browser agent opens your running application and explores it. It navigates, discovers the flows a user could take, interacts with the interface, notices behavior that does not fit, and collects evidence as it goes.
This is deliberately not a script generator. A script only ever checks the path someone already thought of. The trace beside this is one such run against a sample storefront, in the order it happened, ending at the step that produced a finding.
Exploratory testing works today and is earlier in its life than API testing. We would rather tell you that now than have you discover it in a demo.
Security testing
The same autonomous approach, turned on the security surface. BugLight decides what to probe, runs it, and writes up what it finds in the same format as every other method.
The reason it belongs in this platform rather than beside it is where the results land. Security findings arrive in the same place as a failed schema assertion or a broken checkout flow, with the same expected-against-actual structure and the same evidence attached, instead of in a separate tool with a separate backlog that somebody has to reconcile later.
It is the newest of the three methods. If there is a specific surface you need covered, bring it to the demo and we will tell you plainly what BugLight does with it today.
Where BugLight stops
It does not replace your judgment
BugLight finds behavior that looks wrong. Deciding whether it matters, and what the software should do instead, is still the team’s call.
It does not know your company yet
Today it evaluates whether software works. Evaluating whether it works the way your organization defines correct is the direction we are building toward, not a feature you can use.
It is not a compliance product
BugLight holds no security certifications and running it does not, by itself, satisfy an audit. It finds problems; it does not sign anything off.
Bring us something you have not had time to test.
An API with a specification, or a web application we can reach. We will run BugLight against it and walk you through whatever it finds, including the runs where it finds nothing.