DigitableCourses
Portal settings
Русский
Show me around

Local and account-free. No account, no sign-up: whatever you type into the tools stays in this browser's localStorage and never reaches a server.

Our own counter records page opens and finishes: the address leaves, plus one tenth-of-the-text figure. No cookies, no outside trackers, your IP is not stored, Do Not Track is honoured. How to check that

The portal's own repository is not published, so we do not call it open source. What is open:

Digit flang Agent gate tools-core IT Tools Chat digitwm blender-mcp Hugging Face Licences

The portal lives on donations, paid consultations and requested write-ups, and on Workbench sales.

Support Order a write-up Workbench

There are no plans to make the courses paid.

Career

QA engineer

Quality as a job of its own: test design, automation, feedback into the process.

Roles and moves Self-assessment

Step 2 of 2 · QA engineer

Which level inside the role?

Where people go from here: Backend developer, SRE and platform engineering, Systems and business analyst, Team lead, tech lead, engineering manager

Not sure — open the whole role card Pick another role

  1. Junior
  2. Middle
  3. Senior
  4. Further on: a branching, not a rung

Junior

Straight to the self-check

Compared with simply trying the thing out, what is asked of the result changes: an observation now has to reproduce for somebody else.

Do now

  • I lay the checks out by equivalence classes and boundaries instead of going through options blindlyI can explain why these checks are enough.
  • I write a bug report that reproduces the defect on the first tryThe developer does not come back asking how to repeat it.
  • I send a request to the API by hand and read the responseI can say whose side the problem is on before I file the bug.
  • I use the terms of the team the same way the team doesAt a defect review we do not argue about words.

Where next

Middle

Sideways out of the role

What this step asks of you

  • I use the terminology of testing the same way the team doesI do not confuse a defect, a failure and an error, and I do not argue about words at a bug review.
  • I design the checks instead of going through options blindlyI use equivalence classes and boundaries, and I can explain why these checks are enough.
  • I write a bug report that reproduces the defect on the first tryThe developer does not come back asking how to repeat it.
  • I check the API directly, not only through the interfaceI can send a request by hand and work out whose side the problem is on.

Common mistakes

  • Filing a bug that says it looks odd: it comes back with questions and dies in the queue.
  • Checking only the happy path: the rest is found by users and already in production.
  • Learning to click instead of learning test design: there are plenty of checks, and what was missed is still missed.

What to learn

  1. Junior
  2. Middle
  3. Senior
  4. Further on: a branching, not a rung

Middle

Straight to the self-check

Code of your own appears: automation starts to need maintenance and easily eats more time than it saves.

Do now

  • I fix a flaky test instead of rerunning the suiteThe suite has no tests that everyone is used to running twice.
  • I wire the tests into the pipeline so that a red build stops the deploymentNobody treats a red build as an obstacle.
  • I refactor test code the way I would product codeThe test project is readable and is not afraid of change.
  • I set up a load run and the basic checks on securityI know where the system starts to degrade.

Where next

Senior

Sideways out of the role

What this step asks of you

  • I write automated tests that do not flakeThe suite has no sometimes-red tests that everyone is used to rerunning.
  • I wire tests into the pipeline so that their result is trustedA red build stops the deployment, and nobody treats that as an obstacle.
  • I program well enough to maintain the test codeMy test project is no worse than the product one: it is readable and refactorable too.
  • I check more than the functionalityI can set up a load run and check the basic things about security.

Common mistakes

  • Automating everything in sight: the suite grows, trust falls, and the manual checks do not go anywhere.
  • Keeping fragile scenarios alive by rerunning them: the team stops believing the colour red.
  • Treating coverage as the goal: coverage goes up and the defects that were missed stay missed.

What to learn

  1. Junior
  2. Middle
  3. Senior
  4. Further on: a branching, not a rung

Senior

Straight to the self-check

The question you get asked changes: not whether everything has been checked but whether we can ship, and it is you who answers it.

Do now

  • I rebuild the testing strategy around the risks of the product rather than around the shape of the pyramidI can explain why there are few unit tests here, and it is a decision rather than an accident.
  • I bring my questions to the statement of work before development startsMy questions change the requirements instead of turning up at acceptance.
  • I look at the time to restore and the share of failed releasesWe discuss the quality of the process rather than the number of tests written.
  • I name the forks inside quality work for myself and for the teamI understand the difference between engineering in tests, the quality of the process and the analysis of risk.

Where next

Further on: a branching, not a rung

Sideways out of the role

What this step asks of you

  • I build a testing strategy around the risks of the product, not around the template of the pyramidI can explain why there are few unit tests here, and it is a deliberate decision.
  • I catch a defect at the requirements stage, not in productionMy questions about the statement of work change that statement before development starts.
  • I measure the quality of the process, not the number of tests writtenI look at the time to restore and the share of failed releases, not at coverage for the sake of coverage.
  • I understand the forks inside quality work and choose mine deliberatelyI can explain the difference between an SDET, a process quality engineer and a risk analyst.

Common mistakes

  • Becoming the only person who knows how to check the system: the release starts waiting for you.
  • Competing on the number of tests: the suite grows and the risks stay unnamed.
  • Arguing with development about fault instead of risk: quality turns into a conflict between two departments.

What to learn

  1. Junior
  2. Middle
  3. Senior
  4. Further on: a branching, not a rung

Further on: a branching, not a rung

Straight to the self-check

There is no rung upwards: from here the subject changes — code, process or people — and none of these roads is higher than the others.

Do now

  • I take one review of a failure in production and carry it through to a checkThe pipeline has a check in it that was not there before.
  • I hand my tool to a neighbouring team and watch whether they use itThey use it with no involvement from me.
  • I try the neighbouring job on my own task: development, analysis or an on-call shiftI know what that work actually consists of rather than what it is called.

Where next

Not another step — a fork

Sideways out of the role

What this step asks of you

  • I build the tools for checking, not only the checksThe team uses my test bench or my data generator with no involvement from me.
  • I make quality a property of the process rather than a stage before the releaseThe checks live in the pipeline, and their result is trusted at deployment.
  • I turn failures in production into checks rather than into correspondenceA review leaves behind a test or a safeguard, not an entry in a wiki.
  • I change the practice of quality in teams that do not report to meMy check has been adopted where I decide nothing.

Common mistakes

  • Treating heading a quality department as the only continuation: that is management, not the next rung of testing.
  • Building your own tool instead of taking somebody else's: the maintenance lands on you and stays for good.
  • Handing out advice instead of doing the work: a practice you have not tried yourself does not take root.

What to learn

IT Tools source · GPL-3.0 Digitable Chat source · GPL-2.0-or-later Legal documents