Energy Trading QA Challenge

Užduoties instrukcijos

Jūs testuojate eksperimentinę elektros prekybos sistemą. Jūsų tikslas – patikrinti, ar aplikacija atitinka nurodytus acceptance criteria.

Užduoties metu:

Susipažinkite su reikalavimais.
Išbandykite funkcionalumą.
Suraskite ir dokumentuokite defektus.
Atlikite SQL užduotį.
Įvertinkite API, saugumo ir AI scenarijus.

Vertiname ne tik rastų bugų skaičių, bet ir jūsų mąstymą, testavimo kokybę, gebėjimą suprasti verslo logiką ir aiškiai komunikuoti problemas.

Rekomenduojamas laikas – 60–75 minutės.

Užduoties dalys

Dalis	Turinys	Rekomenduojamas laikas
1 · Light Controller	Įvadinė užduotis (warm-up)	5–10 min.
2 · Energy Bid Calculator	Dviejų prognozių apjungimas, pirmas bidas ir delta	15–20 min.
3 · API Release Investigation	API v1.1 vs v2: kontraktas, autentifikacija, validacija, suderinamumas, idempotency	15–20 min.
4 · SQL, Security & AI	Trumpi praktiniai klausimai	10–15 min.
5 · Export Answers	Atsisiųskite atsakymų failą ir išsiųskite jį vertintojui	2 min.

Svarbu

Visa aplinka yra simuliuojama naršyklėje. Nėra tikro serverio ar biržos ryšio; API Request Replay tik imituoja HTTP elgseną.
Kiekvienoje užduotyje yra laukai My Test Cases ir My Notes – rašykite atsakymus tiesiai ten. Bug reportai neprivalomi.
Defektus registruokite skiltyje 🐞 Report a Bug. Atsakymai saugomi šioje naršyklėje (localStorage).
Mygtukas Reset environment atkuria pradinę sistemos būseną (lemputė, bidai, API sandbox). Jūsų atsakymai, test case'ai ir bug reportai nėra ištrinami.
Pabaigoje atidarykite skiltį 5. Export Answers, atsisiųskite failą ir patys išsiųskite jį vertintojui – atsisiuntimas nėra pateikimas. Asmens duomenų nereikia.

1 Instructions2 Acceptance criteria3 Test environment4 My Test Cases5 My Notes6 Report a Bug

📄 Task instructions

Read the acceptance criteria and test the Light Controller.

Write at least 2 test cases describing how you would verify the functionality.

If you find a defect, create a bug report.

You may also leave notes about your observations.

Warm-up exercise: 5–10 minutes.

Acceptance criteria

LC-AC-01: When the page loads, the light bulb is OFF.
LC-AC-02: Clicking Turn ON switches the bulb ON, and it becomes yellow.
LC-AC-03: Clicking Turn OFF switches the bulb OFF, and it becomes grey.
LC-AC-04: The displayed state text must always match the actual visual state.

Test environment · Light Controller

Status: OFF

✍️ My Test Cases

📝 My Notes

Optional – only if you found a defect.

📄 Task instructions

You are testing a simplified electricity bid calculator.

Two electricity forecasts are combined into a single trading position for each 15-minute interval.

Check the calculations and investigate how the system behaves before and after submitting a bid.

Write your test cases and observations. If you find a defect, create a bug report.

Suggested time: 15–20 minutes. All times are local (Europe/Vilnius, 2026-11-04). All quantities are MW unless stated otherwise.

Acceptance criteria

AC-01 — Data selection. Use the latest available Consumption and Generation forecasts at the selected calculation time. Data received after that time cannot be used. When multiple versions of the same forecast exist, calculations must use the newest record available at the calculation time.
AC-02 — Calculation. For each 15-minute interval:
Target MW = Consumption MW - Generation MW
Target MWh = Target MW × 0.25
AC-03 — Bid calculation. Before the first submitted bid, Bid MW equals Target MW. After a bid has been submitted, calculate only the delta between the new target and the total previously submitted MW. Negative and zero values are valid.
AC-04 — Submission. Clicking Calculate Bid must not change the accepted trading position. Only Submit Bid changes it. Recalculating with an unchanged target after submission must produce a zero delta.

Delta MW = New Target MW - Previously Submitted MW
First bid = full calculated amount. After submitting a bid, only the difference is submitted.

Test environment · Input forecasts

Calculation

Calculation time

Select a time and click “Calculate Bid”.

Submitted bids

✍️ My Testing Notes & Test Cases

Document your thinking while testing: manual calculations, data selection, delta checks, business-rule questions, edge cases.

My Test Cases

My Notes

Optional – only if you found a defect.

📄 Business scenario

The trading company has just released Bid Management API v2. v2 introduces breaking changes to the request contract, but existing clients using API v1.1 must continue working without modifications.

Investigate the release: contract compliance, HTTP semantics, authentication and authorization, validation, backward compatibility, idempotency and the business risks of incorrect behaviour.

Decide yourself which scenarios to test. Document test cases, notes and questions below the console; report confirmed defects via “Report an API Bug”.

Acceptance criteria

Authentication & authorization

API-AC-01: All POST bid requests require a valid X-API-Key.
API-AC-02: Missing or invalid API key must return HTTP 401 Unauthorized.
API-AC-03: A validly authenticated trader can submit bids.
API-AC-04: An authenticated viewer is not allowed to submit bids and must receive HTTP 403 Forbidden.
API-AC-05: Authentication and authorization rules must be enforced in both API versions.

Request validation

API-AC-06: A successfully created bid returns HTTP 201 Created and a JSON response containing bidId, intervalStart, deltaMw and status.
API-AC-07: Missing required JSON fields return HTTP 400 Bad Request.
API-AC-08: Invalid JSON syntax returns HTTP 400.
API-AC-09: Only valid 15-minute delivery intervals are accepted.
API-AC-10: Negative and zero deltaMw values are valid numeric inputs.
API-AC-11: Non-numeric deltaMw values must return HTTP 400.
API-AC-12: Requests must use Content-Type: application/json; unsupported media types return HTTP 415.
API-AC-13: Rejected requests must not modify bid history or confirmed trading positions.
API-AC-14: Each API version must accept only its documented request schema.

Backward compatibility

API-AC-15: API v1.1 must continue accepting valid legacy requests after the release of v2.
API-AC-16: API v2 must accept the new request schema.
API-AC-17: API v1.1 and v2 must both apply the same authentication and authorization requirements.
API-AC-18: The release of v2 must not modify the behavior or response contract of v1.1.
API-AC-19: Unsupported API versions must return HTTP 404.

Idempotency & duplicate protection

API-AC-20: Every POST bid request must include an Idempotency-Key header.
API-AC-21: The first valid request with a new Idempotency-Key creates a bid and returns HTTP 201.
API-AC-22: Repeating an identical request with the same Idempotency-Key must not create another bid and must return HTTP 200 with the previously created bid.
API-AC-23: Reusing the same Idempotency-Key with different request content must return HTTP 409 Conflict.
API-AC-24: Missing Idempotency-Key returns HTTP 400.
API-AC-25: Rejected and repeated requests must not incorrectly modify the cumulative accepted bid position.

📘 API documentation

Browser-side simulation only – no network requests are sent. All data below is API sandbox data, isolated from the Energy Bid Calculator.

Endpoint	Description
POST /api/v1.1/bids	Legacy bid submission (v1.1 schema).
POST /api/v2/bids	New bid submission (v2 schema).
GET /api/{version}/bids	Sandbox bid ledger and cumulative position, in the field names of the requested version. Requires a valid X-API-Key (trader or viewer).

Request schemas (bid = delta, not absolute position)

v1.1 field	v2 field	Type / rule
period	intervalStart	ISO-8601 with offset; 15-minute boundary; delivery day 2026-11-04 (Europe/Vilnius)
volumeMw	deltaMw	JSON number; negative and zero allowed

Both fields are required. Unknown or extra fields are rejected with HTTP 400 (strict schema) – this includes sending v1.1 fields to v2 and vice versa.

Responses

Version	201 / 200 body
v1.1	{ bidId, period, volumeMw, status }
v2	{ bidId, intervalStart, deltaMw, status, exchangeStatus }

Errors: { error, message, details? }. status: "SUBMITTED" means the bid was accepted by the internal API and queued for the exchange. It is not an exchange confirmation. exchangeStatus is PENDING_CONFIRMATION until the exchange (not simulated here) confirms the bid.

Headers & identity

Header	Rule
Content-Type	`application/json` (optional `; charset=…`)
X-API-Key	Identity and role are resolved server-side from the key: `demo-valid-key` → trader-01 (trader), `demo-viewer-key` → viewer-01 (viewer).
Idempotency-Key	Required on POST, non-empty string.

Idempotency

Scope: authenticated identity + API version + Idempotency-Key, kept for the simulated session (until Reset API / Reset environment). “Identical request” = same JSON content (whitespace and field order are ignored).

Processing order

version (404) → method (405) → authentication (401) → authorization (403) → Content-Type (415) → JSON syntax (400) → Idempotency-Key (400) → schema (400) → idempotency (200 / 409) → create (201).

Test environment · API Request Replay (simulated)

Method

API version

Endpoint (editable)

Request headers

Send	Header	Value
	Content-Type
	X-API-Key
	Idempotency-Key

Request body (JSON)

Response

—

// response will appear here

Request history

Selected request / response

// click “View” in the history

API sandbox bid ledger

API sandbox data – not shared with the Energy Bid Calculator.

✍️ My API Test Cases

You are testing a new release of Bid Management API v2.

Based on the provided acceptance criteria and API documentation, design at least 6 additional test cases that should be executed before this API is released to production.

For each test case, include: test case title, preconditions, HTTP method and endpoint, request headers, request body (if applicable), test steps, expected HTTP status, expected response or system behavior.

Include positive, negative and boundary scenarios.

If requirements are unclear, explicitly document the questions you would ask the Product Owner or developers.

Fields are optional – write as much as is useful.

📝 My API Notes & Questions

Tip: use “📎 Evidence” in the request history to attach request/response pairs to your export.

🤔 Critical thinking scenario

A bid submission request was sent to Nord Pool, but the external API timed out before the trading system received a confirmation. It is unknown whether the bid was accepted or rejected.

1. What risks do you identify? 2. What additional information or requirements would you ask for? 3. What test scenarios would you design to avoid duplicate bids or incorrect trading positions?

🗄️ SQL užduotis

SQL nėra vykdomas – atsakymai vertinami rankiniu būdu. Galite naudoti bet kurį standartinį SQL dialektą (nurodykite, jei naudojate specifinį).

`forecast_values`

id	source	interval_start	received_at	mw
1	consumption	2026-11-04 12:00	2026-11-04 08:30	12
2	consumption	2026-11-04 12:00	2026-11-04 09:00	13
3	generation	2026-11-04 12:00	2026-11-04 08:45	5
4	generation	2026-11-04 12:00	2026-11-04 09:10	7
5	consumption	2026-11-04 12:15	2026-11-04 08:30	14
6	consumption	2026-11-04 12:15	2026-11-04 09:00	15
7	generation	2026-11-04 12:15	2026-11-04 08:45	8
8	generation	2026-11-04 12:15	2026-11-04 09:10	9

`bid_events`

id	interval_start	accepted_at	delta_mw	status
1	2026-11-04 12:00	2026-11-04 08:50	6	ACCEPTED
2	2026-11-04 12:15	2026-11-04 08:50	5	ACCEPTED
3	2026-11-04 12:00	2026-11-04 09:02	1	ACCEPTED
4	2026-11-04 12:15	2026-11-04 09:02	1	ACCEPTED
5	2026-11-04 12:00	2026-11-04 09:05	3	REJECTED
6	2026-11-04 12:00	2026-11-04 09:15	-2	ACCEPTED

Pastaba: accepted_at pildomas ir atmestiems įrašams (sprendimo laikas).

1. Grąžink kiekvieno 15 minučių intervalo bendrą patvirtintą prekybos poziciją iki 09:12, atsižvelgiant į tai, kad kiekvienas bid įrašas yra delta, o ne nauja galutinė pozicija. 2. (Papildomas) Kaip SQL pagalba atrinktum naujausią kiekvieno duomenų šaltinio snapshotą kiekvienam intervalui, neįtraukiant duomenų, gautų po skaičiavimo momento?

🔐 Security užduotis

Skiltyje 3. API Release Investigation galite keisti API raktą (trader / viewer profilį) ir antraštes. Patikrinkite, ar sistemoje veikia tinkama autentifikacija ir autorizacija.

1. Ką patikrinote dėl rolių / autorizacijos ir ką radote? (Defektus taip pat registruokite Bug Report skiltyje.) 2. Kokias dar dvi saugumo rizikas tikrintum realioje prekybos API sistemoje ir kodėl?

🤖 AI užduotis

AI asistentas sugeneravo tokį testavimo pasiūlymą:

„Po naujos prognozės gavimo reikia iš naujo išsiųsti visą apskaičiuotą bid kiekį.“

Ar šis AI pasiūlymas teisingas? Kokią riziką jis sukeltų ir kaip patikrintum jo teisingumą?

🐞 Report a Bug

Bug reports are optional. Zero, one or many bugs are all valid outcomes.

Your bug reports

📤 Your Submission

Your answers are saved in this assessment. When you finish, click Export Answers to download your submission file.

IMPORTANT: Downloading the file does NOT submit your answers. You must send the downloaded file to the person who gave you this assignment.

You must submit the file even if you did not find any bugs.

After downloading, attach this file to your reply to the recruiter or hiring manager.

File: energy-qa-challenge-answers.md (Markdown). Optional secondary format:

General notes / testing scope (optional)

Submission overview

No bugs found? That's OK. You can still export your test cases, observations and other answers.

Start over

Deletes everything you wrote in this browser. Not needed for submission.