From keyboard to your screen in Kenya. No magic -- just files moving through pipes.
The QA Dashboard is now behind a real login. When you open /testing, you'll be redirected to a login page. This is Keycloak, our authentication system. It knows who you are and what you're allowed to do.
1. Go to the QA Dashboard. You'll see a login page with a blue "Log In" button.
2. Click Log In. Keycloak's login form appears.
3. Enter anne as username and helix_pass as password. Click Sign In.
4. You're back on the dashboard. Your name appears in the top-right corner of the nav bar.
Session expires after 30 minutes. If you see "Session expired" or get sent back to the login page, just log in again. Your work (bugs, tests) is saved -- you don't lose anything.
Logout button is in the top-right of the nav bar (small door icon). Use it when you're done for the day.
Training and How to Report pages are public -- they don't require login. Only the dashboard (where you mark tests and file bugs) needs it.
Your role gives you access to the QA Dashboard and Bug Tracker. You do NOT have access to business data (vehicles, jobs, invoices) -- that's intentional. Testers test the system, they don't manage the business data.
If the login page does not appear, if you get a blank screen, or if you see an error after clicking Log In, screenshot it and send to Angel on Telegram. It might mean the server needs a restart -- not your fault.
1. Log in to the QA Dashboard using your credentials above. Confirm your name shows in the nav bar.
2. BUG-009 (Invoice Details button) has been marked "Fixed" and assigned to you. Please test it: open a job with an invoice, click the Details button. If it works, change the status to "Verified." If it's still broken, change it back to "Open" and add a comment.
3. Read the How to Report Bugs guide -- it shows you step-by-step how to use the new bug form with examples for each type of problem.
These are real workflows on the live Camper & Tour system. Follow each one step-by-step.
The camper system has 3 test users. Log in at /camper using any of these:
Goal: A campervan arrives. Register the customer and vehicle.
1. Log in as pam. You should see the Camper Dashboard.
2. Click Check-In in the nav.
3. Search for an existing vehicle by plate (try ZH-123456 -- Angelo's MAX). If found, confirm the details are correct.
4. Now try a NEW customer: enter a made-up name, phone, email, and plate number.
5. Fill in: mileage in, vehicle condition notes (e.g., "scratch on left side").
6. Describe the problem: "Water leak from bathroom window seal"
7. Submit. A new service job should be created automatically.
What to check:
- Did the customer and vehicle get saved?
- Did a new job appear on the Jobs page?
- Is the job status "Quoted" or "Open"?
- Can you find the customer in the Customers page?
Goal: Give the customer a price estimate before starting work.
1. Go to Jobs and click on any job.
2. Look for a Quotation section or button.
3. Add line items:
- "Seal replacement" -- 2 hours labor at EUR 45/hr = EUR 90
- "Window seal kit" -- 1 unit at EUR 35
4. Check: Does the system calculate VAT at 22% (IVA)?
5. Check: Does it show a 25% deposit amount?
6. Send the quotation.
What to check:
- Do the totals add up correctly? (subtotal + 22% IVA = total)
- Is the deposit 25% of the total?
- Did the job status change to "Quoted"?
Goal: A mechanic works on a job and logs their hours.
1. Log out, then log in as ralph.
2. Go to Jobs. Find a job with status "In Progress" or "Approved".
3. Open the job details.
4. Add a work log entry: "Removed old seal, cleaned frame, applied new sealant" -- 2.5 hours.
5. Try adding another entry: "Waiting for sealant to cure" -- 0.5 hours.
What to check:
- Can Ralph see the work log entries after saving?
- Can Ralph edit or delete a work log? (He should NOT be able to -- audit trail!)
- Do the total hours add up correctly?
Goal: Manager inspects, approves, and generates the final invoice.
1. Log out, then log in as nino.
2. Find a job that is ready for inspection (status "Inspection" or "Completed").
3. Run the inspection -- pass or fail it.
4. If passed, look for an Invoice button or section.
5. Generate the invoice.
6. Check the Invoices page -- does the new invoice appear?
7. Click the invoice Details button (this was BUG-009!).
What to check:
- Does the invoice show the deposit already paid?
- Is the "Amount Due" = total minus deposit?
- Does the Details button actually open? (BUG-009 fix)
- Can you record a payment?
Goal: Walk one job through the entire lifecycle from arrival to pickup.
This is the big one. Do scenarios 1-4 in sequence on the SAME job:
1. Pam checks in a new customer + vehicle
2. Pam/Nino creates a quotation with line items
3. Customer "accepts" the quote, deposit is recorded
4. Ralph logs work hours across multiple entries
5. Nino inspects and approves the work
6. Pam logs the mileage out and vehicle condition
7. Nino generates the final invoice
8. Payment is recorded, job status goes to "Invoiced"
What to check:
- Does the job status move correctly through each stage?
- Expected flow: Quoted → Approved → In Progress → Inspection → Completed → Invoiced
- Are all the numbers consistent? (quote total = invoice total)
- Can you find this job in every relevant page? (Jobs, Invoices, Customer history)
That's the point! You're here to find the breaks. When you hit one:
1. Note which scenario and which step you were on
2. Screenshot the error or unexpected behavior
3. Go to the QA Dashboard and click Report Bug
4. Or message Angel directly: Telegram @BigKingFisher
Think of it like a kitchen, a recipe book, and a restaurant
Where code is written and edited. Angel and Tigs build here.
Where every version of every file is stored. The history book.
Where the live app runs. This is what YOU test, Anne!
Every change follows this path:
Following BUG-009 from your report to the fix on your screen
Open QA Dashboard, click "Report Bug", describe what happened. Saved to the database on Hetzner.
Read the code, find the root cause. In BUG-009: modal was opening and closing instantly due to a timing race condition.
Edit the file on Angel's laptop. At this point, ONLY the laptop has the fix. You can't see it yet.
Take a snapshot of the change, give it a message and a unique ID (SHA), send it to GitHub. The warehouse now has the fix.
Connect to Hetzner, download the latest code (git pull), rebuild the application (docker). Takes about 30 seconds.
Refresh the page. The new code is running. Test it. If it works, mark the bug "Verified." You have the final word.
The building blocks -- no jargon, just clarity
A time machine for files. Every time someone makes a change, Git takes a snapshot called a commit. Each commit has a unique ID (the SHA -- like 1fe510a), a message, who made it, and when. You can go back to ANY previous version. Nothing is ever lost. GitHub is just a website that stores these snapshots in the cloud.
Code files are just text -- they can't DO anything by themselves. It's like having a recipe but no kitchen. Docker is the kitchen. It reads the code and builds a container -- a complete running application. When we rebuild, the old container is replaced with a new one in about 30 seconds.
Code = the building (walls, doors, layout). Database = everything INSIDE the building (your bugs, test results, customers). When we rebuild the app, we rebuild the building. Your data stays exactly where it is. Sometimes we add "new shelves" -- that's called a migration.
It gets a number (BUG-001) and goes into the system
Assigned to Angel or Tigs, status changes to "In Progress"
Status: "Fixed", SHA attached (e.g. 1fe510a), reassigned to YOU
Test it. Works? Mark "Verified." Still broken? Back to "Open" with a comment.
Quick reference for terms you'll see in the system
| Term | What It Means | Analogy |
|---|---|---|
| Repository | A folder of code tracked by Git | A recipe book |
| Commit | A saved snapshot of changes | A dated entry in the book |
| SHA | Unique ID of a commit (e.g. 1fe510a) | A receipt number |
| Push | Send commits to GitHub | Mail recipes to warehouse |
| Pull | Download commits from GitHub | Warehouse delivers to store |
| Deploy | Make new code live on server | Stock new products in store |
| Docker | Turns code into a running app | The kitchen that cooks recipes |
| Container | A running instance of the app | The meal being served |
| Database | Where your data lives | The filing cabinet |
| Migration | Changing database structure | Adding drawers to the cabinet |
| API | How frontend talks to backend | The waiter between you and kitchen |
| Frontend | What you see (buttons, forms) | The restaurant dining room |
| Backend | What runs on server (Python) | The kitchen |
The international standard for software testing -- your reference dictionary
ISTQB (International Software Testing Qualifications Board) is the global standard for software testing. You don't need to read the whole thing -- but knowing these core principles makes you a sharper tester. Think of it as a dictionary you check when you need the right word.
These are the rules professional testers live by. You're already doing most of them.
Use this as a reference, not a textbook. Look up terms when you need them. The best way to learn testing is by testing.
The questions everyone asks but nobody asks
No. Testing is reading and clicking. You cannot damage the system. We WANT you to try to break things -- that's how we find problems before real customers do.
Report it again. Maybe the first fix didn't work. That's valuable information -- it means the fix needs to be better.
Check the QA Dashboard. If it says "Fixed" with a git SHA, the code change is deployed. Test it yourself. If it works, mark it "Verified." If it doesn't, change it back to "Open" and add a comment explaining what's still wrong.
It's the unique ID of the exact code change that fixed the bug. Like a receipt number -- it proves WHAT was changed and WHEN. Example: 1fe510a
Before, the QA dashboard was open to everyone. Now it knows who you are. When you report a bug, your name is on it. When you verify a fix, the developer knows YOU confirmed it. It also means only people with the right role can access testing -- no accidental edits from other users.
Tell Angel immediately. It could be a server issue, not something you did wrong. Your username is anne and password is helix_pass. If it shows an error page or a blank screen, take a screenshot and send it on Telegram.
Your session expires after about 30 minutes of inactivity. Just log in again. Your bugs, test results, and comments are all saved on the server -- nothing is lost. Think of it like a door that locks behind you after a while. You still have the key.
Ask. There are no stupid questions in software engineering. The only stupid thing is staying confused and not asking.