a Techtorial Academy program
AI for test engineers, in your framework.
Live, instructor-led training that gives your QA team one shared way to use AI, from test design to CI. In your own framework, with the AI tools you’ve already approved.
Not prompt training. Not generic AI demos.
Same task, two ways
Without a shared workflow
- prompt
- generic draft
- rework, retry
- stuck in rework
With a TestHubble workflow
instructor-led, in your repo- context
- review vs. standards
- green in CI
- PR ready for review
- Private cohort
- Your approved AI tools
- Your repo
- No production data
- NDA before we see your code
The problem
Your company bought AI tools. There’s no shared workflow.
Engineers are experimenting, each in their own way. Does any of this sound familiar?
Everyone uses the AI tools differently, and nobody can say what changed.
The automation backlog grows faster than the team can work through it.
Flaky tests and broken locators eat part of every sprint.
AI output lands in pull requests, and reviewers can’t tell what was checked.
Nobody has written down what’s allowed: which tools, which data, who reviews what.
The people are capable. The shared workflow is missing.
That’s what we build with you
Already paying for AI? We train your team to use it well.
We don’t sell another license. We train your team on the tools your company already approved, and set up the habits that make them useful: shared instructions, review standards and CI, inside the framework you already run.
In your framework
- Playwright
- Cypress
- Selenium + Java
- GitHub Copilot
- Claude / Claude Code
- ChatGPT Enterprise / Codex
- Gemini / Gemini Code Assist
- Cursor
- Amazon Q Developer
- Windsurf
- JetBrains AI
- or whatever your company has approved
Tools we train on. Not partners or clients.
Private AI training for QA teams
How an engagement runs.
We train the team you already have: QA engineers, SDETs and test leads.
From a 2-week assessment to an 8-week program. Pricing depends on the option and your team size, and comes in a written proposal.
What a typical engagement looks like.
Before we start
A call, then a written proposal.
The proposal sets the option, the schedule, what we’ll measure, and pricing. NDA in place before we see your code. You choose 3–15 engineers and the pace (standard, lighter or extended) around your release schedule.
First week
Baseline.
Each engineer does a practical skills check in your framework, with your approved AI tools. At a kickoff check-in we agree goals and measures with you.
The weeks in between
Live sessions, real work.
Live, instructor-led sessions plus hands-on work on your own code and backlog, with office hours. Remote or on-site. A mid-point check-in with you on attendance, progress and adoption.
Session length and weekly time depend on the pace you pick; your proposal sets them.
Final week
Results.
Each engineer has AI-assisted tests in a pull request in your repo, reviewed under your normal process. The team keeps the workflow files, and you get a results report at a final check-in.
What we need from you
- A contact on your side
- Least-privilege access to the repo your team works in, or screen-share
- Seats on the AI tools you’ve approved
Not a course.
How this compares with the usual options. Each one is useful for what it’s built for.
| Option | Who it’s for | Where the work happens | What you end with |
|---|---|---|---|
| Online courses | Who it’s for: Individuals, at their own pace | Where the work happens: Demo apps and sample projects | What you end with: A certificate of completion |
| Certifications | Who it’s for: Individuals | Where the work happens: A published syllabus and an exam | What you end with: A credential |
| Vendor academies | Who it’s for: Users of one vendor’s tool | Where the work happens: That vendor’s product | What you end with: Know-how in that product |
| QA service firms | Who it’s for: Companies buying testing work | Where the work happens: Their engineers, on your product | What you end with: Tests their team wrote |
| TestHubble | Who it’s for: Your whole QA team, in a private cohort | Where the work happens: Your repo and framework, with your approved AI tools | What you end with: Pull requests reviewed under your process, a shared workflow your team keeps, and a results report |
What changes
Same engineer, same AI tool. The difference is a shared workflow.
The steps your team already follows, with AI at each one: your tools, your repo, one way of working for the whole team.
Step 1: Understand
- Summarize the story and acceptance criteria
- Flag gaps and open questions early
Step 2: Design
- Draft test cases from requirements
- Add edge cases and negative paths
Step 3: Build
- Generate tests in your framework’s patterns
- Reuse your page objects, fixtures and helpers
Step 4: Review
- Check AI code against a shared checklist
- Open a pull request, reviewed under your normal process
Step 5: Run
- Get a readable summary of each failure
- Separate real bugs from flaky tests
Step 6: Maintain
- Fix broken locators with suggested repairs
- Keep the team’s instruction files up to date
AI assists at every step. Your engineer owns the engineering decisions.
Before / after
What changes for the team.
| Area | Without a shared workflow | With a TestHubble workflow |
|---|---|---|
| Team context | Without a shared workflow: The AI guesses your patterns | With a TestHubble workflow: Instruction files in the repo that the AI reads |
| AI-written code | Without a shared workflow: Reviewed like hand-written code, or not at all | With a TestHubble workflow: Reviewed against a shared checklist |
| Rules | Without a shared workflow: Decided case by case | With a TestHubble workflow: A written AI usage policy |
Capabilities
What we train your engineers to do.
Built on the testing skills your team already has.
We train test design, automation, debugging and maintenance, API tests, CI, reviewing AI code, and safe use, fitted to your team in the proposal.
Handover
What your team keeps.
Starting with the Assessment? You leave with a skills baseline, a framework audit and a roadmap.
What’s included depends on the option; your proposal lists it. Everything produced in your repo is yours.
- A shared AI workflow, used on real tickets
- Instruction files tuned to your repo
- An AI code-review checklist
- Automation quality guidelines for AI-written tests
- A CI and debugging workflow
- An AI usage policy: tools, data, review
- A baseline and a results report, with your own data
Workflow demo
One test, start to finish: draft, review, run.
Draft.AI drafts the test fast.
Your engineer asks Copilot or Claude for a checkout test. It looks right. It even passes, some of the time.
Review.Your engineer checks it against the team’s standards.
A hard wait, a brittle selector, a weak assertion. Catching them, and fixing them in your conventions, is part of the workflow.
PromptWrite a Playwright test: a user can check out from the cart.
// AI first draft
1test('user can check out', async ({ page }) => {2 await page.goto('/cart');2 await page.click('#btn-checkout-2');1 await page.waitForTimeout(3000);3 expect(await page.locator('.msg')6 .textContent()).toContain('Thank');7});// After review
1test('user can check out', async ({ page }) => {2 await page.goto('/cart');3 await page4 .getByRole('button', { name: 'Checkout' })5 .click();6 await expect(page.getByRole('heading', {7 name: 'Order confirmed',8 })).toBeVisible();9});PromptWrite a Selenium + Java (JUnit 5) test: a user can check out from the cart.
// AI first draft
1@Test2void userCanCheckOut() throws Exception {3 driver.get(baseUrl + "/cart");2 driver.findElement(By.id("btn-checkout-2"))5 .click();1 Thread.sleep(3000);3 String msg = driver8 .findElement(By.className("msg")).getText();9 assertTrue(msg.contains("Thank"));10}// After review
1@Test2void userCanCheckOut() {3 driver.get(baseUrl + "/cart");4 wait.until(elementToBeClickable(5 By.cssSelector("[data-test=checkout]")))6 .click();7 String heading = wait.until(8 visibilityOfElementLocated(By.tagName("h1")))9 .getText();10 assertEquals("Order confirmed", heading);11}Hard waitopenfixed
waitForTimeout(3000) guesses. Slow CI fails, fast CI wastes time.Thread.sleep(3000) guesses. Slow CI fails, fast CI wastes time.
Brittle selectoropenfixed
#btn-checkout-2 breaks on the next redesign. Find it by role."btn-checkout-2" breaks on the next redesign. Use a stable test id.
Weak assertionopenfixed
"Thank" passes on the wrong page. Assert the outcome, and let it retry."Thank" passes on the wrong page. Wait for the outcome, then assert it exactly.
Run.The reviewed test runs in your CI.
Role-based locators and an assertion that waits for the real outcome. Green in your pipeline, then a pull request in your repo, reviewed under your normal process.
- Install
- Lint
- E2E tests
- Checklist
- Review
$ npx playwright test checkout.spec.tsRunning 3 tests using 3 workers✓ [chromium] › user can check out✓ [firefox] › user can check out✓ [webkit] › user can check out3 passedAgentic QA setup
Then AI agents draft. Your engineer approves.
Once the workflow is in place, AI can take on specialized roles. Each agent drafts one part of the work. Your engineer reviews, corrects and approves every change.
We set it up with you. Then we teach your team to run it.
In plain terms: the AI tools get written instructions, access to a browser and a place in your CI. Your engineers review everything they produce.
- AI that edits code
- Team rules the AI reads (instruction files)
- Reusable task guides (skills)
- Browser and tool access (MCP)
- Specialist agents
- AI in CI
Agents draft. Your engineer reviews and approves every change. Part of the Accelerator, or on its own as Agentic QA setup.
user story
As a shopper, I can apply a coupon at checkout.
- valid code: total drops
- expired code: clear error
- ? stacks with other discounts
- happy: apply SAVE10
- edge: expired code
- edge: empty cart
- test('apply coupon'
- getByLabel('Coupon')
- await expect(total)
- waitForTimeout()
- // hard wait
- .btn:nth-child(3)
- // brittle locator
- UI: Apply is now Redeem
- name: 'Apply'
- name: 'Redeem'
- chromium: passed
- webkit: passed
- flaky test: triaged
sends the crew
drafts come back to you
Agents draft. You review and approve.
Sprint board
To do
In progress
Done
How we measure
Measured with your own data.
We don’t promise a percentage. We promise what we’ll measure, and we report it honestly.
Before
Baseline
A practical skills check in your framework, plus the metrics you already have in your repo, CI and tracker.
During
Hands-on in your environment
Your engineers do real tasks with your approved AI tools. A mid-point check-in with you.
After
Results report
Before and after on skills, AI adoption and team outcomes, including what didn’t move.
Later
Optional follow-up
Through coaching, we keep checking the trend as the habits settle.
Not every metric moves in the first weeks. Skills and day-to-day habits can change during the program; team metrics like flaky test rate take more sprints to read. The report says which is which.
Engineers see their own results first and can correct them. No rankings.
How we measure resultsOptions
Where do you want to start?
One path: assess, enable, implement, sustain. Pick what sounds most like your team. Any option can start as a pilot with 3–5 engineers.
We’d suggest
AI Readiness Assessment
2 weeks
A skills baseline for your team, a scored audit of your framework, and a roadmap.
- Assess
- Enable
- Implement
- Sustain
We’d suggest
Core Enablement
4 weeks
A shared AI workflow in your framework, with a results report.
- Assess
- Enable
- Implement
- Sustain
We’d suggest
Accelerator
8 weeks
Core, plus Agentic QA setup, an AI-ready framework, AI in CI, and a coached real sprint.
- Assess
- Enable
- Implement
- Sustain
We’d suggest
Agentic QA setup
Scoped to your team
We set up agents in your framework with your engineers, then teach them to run it. Included in the Accelerator.
- Assess
- Enable
- Implement
- Sustain
We’d suggest
Coaching retainer
Monthly
Office hours, pull request reviews and metrics check-ins while the tools keep changing.
- Assess
- Enable
- Implement
- Sustain
We’d suggest
Manual-to-Automation with AI
8 weeks
Testers who know your product start contributing Playwright tests, reviewed by your team.
Specialization
For a specific team or job, alone or alongside any step.
We’d suggest
Add-ons
Usually 1–2 weeks each
Selenium to Playwright migration, API testing in depth, a leadership session, or mobile and performance testing on request.
Specialization
For a specific team or job, alone or alongside any step.
All options
- AI Readiness Assessment 2 weeks
- Core Enablement 4 weeks
- Accelerator 8 weeks
- Manual-to-Automation with AI 8 weeks
- Agentic QA setup scoped to your team
- Coaching retainer monthly
- Add-ons usually 1–2 weeks each
Teaching test engineers since 2019.
TestHubble is a Techtorial Academy program. Since 2019, Techtorial has trained more than 2,000 people from zero to software test engineer, and its graduates work as test engineers at IT companies. Techtorial’s founder teaches the first TestHubble cohorts.
- Techtorial Academy founded
- 2019
- students trained from zero to test engineer
- 2,000+
How we teach
- Live and instructor-led, on real code.
- Every piece of work reviewed, like real work.
- Measured before and after, with your data.
Questions
What teams ask before a call.
Safe by default.
Your security team will ask. Here’s the short answer; we’re happy to go through the long one on a call.
security-checklist.txt
- NDA in place before we see your code
- Least-privilege access only
- No production data. No personal data.
- Everything produced in your repo is yours
Can’t our team just learn this with Copilot on their own?
Some engineers can, and the Assessment will tell you honestly if yours can. What’s hard to learn alone is the shared part: one workflow, instruction files your AI tools read, a review checklist, and a policy everyone follows. That’s what we build with your team.
How much does it cost?
It depends on the option and the size of your team, so pricing comes in a written proposal. You can start small: with the Assessment, or with a pilot of 3–5 engineers.
How much time does it take away from delivery?
The hands-on work happens on your own code and backlog, so the time produces real tests for your own suite. We agree the pace with you so it fits your release schedule.
Our engineers are skeptical of AI. Will this work for them?
That’s a good place to start from. We teach where AI goes wrong (invented APIs, brittle locators, weak assertions) and when not to use it. Your engineers review every change it makes.
We’re not on Playwright. Can you still help?
Yes. Cypress and Selenium with Java are supported too. On another stack? Tell us what you run and we’ll say honestly whether it’s a fit.
Who teaches?
Techtorial Academy’s founder teaches the first TestHubble cohorts. Techtorial has trained test engineers since 2019.
TestHubble is new. Where are the case studies?
There aren’t any yet, and we won’t show results we don’t have. Every engagement is measured before and after, so you see your own team’s results. If you’d like to start small, begin with the Assessment or a pilot.
Tell us about your team and your framework.
In a short call we’ll ask how your team tests today, which AI tools you have, and what you want to change. You’ll leave with a suggested starting point, whether or not it’s us.
- We reply.
- A short call.
- A written proposal with the option, schedule, measures and pricing.