A video player connects to a source card, a timeline of notes, and a checked note. A card with a question mark sits above.

Start with the video, your software, and the official documentation. You can check a short tutorial by hand. Timed captions can help you find instructions in a longer video. They cannot confirm the code shown on screen or prove that it works.

The result is a table that tells you what you checked, what changed, and what still needs evidence. It supports a decision about one tutorial task in one stated setup.

1. Define the task and record both versions

Choose one result you want from the tutorial. For example, you might want to remove an exact prefix from text. A prefix is text at the start of a longer piece of text.

Keep the task small enough to check. “Does this text operation work?” gives you a clear test. “Is this programming course still good?” does not.

One public programming question asks, “Can i learn programming by purely youtube videos and tons of practise?” The supplied evidence says replies raise outdated software versions. That is a useful reason to check the setup before practice. This single question does not measure how many learners have the problem.

Record these facts before you copy an instruction:

  1. The tutorial title and video URL.
  2. The publication date, if known.
  3. The software name and version stated in the tutorial.
  4. Where the tutorial states that version.
  5. The software version you will actually use.
  6. The date you make the check.
  7. The one result you want to reproduce.

An environment is the software setup in which you do the work. Include other setup facts when they affect the selected step. For example, record a required tool version when the tutorial names one.

Keep publication date and software version separate. A recent upload does not prove that its instructions match your version. An old upload does not prove that every instruction has stopped working.

If the tutorial gives no version, write “unknown.” Do not guess from its age or appearance. If you cannot confirm your own version, resolve that gap before you claim a version match.

2. Find each instruction and watch the screen

Watch the part that performs your chosen task. Pause at each required action. Copy the visible instruction exactly before you propose a change.

A caption is a piece of text stored with a video. A transcript collects the caption text. A timed segment is one caption piece with a start and end time.

Use captions to find likely passages. Then watch those passages. The speaker may say “run this” while the screen shows the only complete command. Captions may also contain a wrong software name or omit a silent action.

For a long video, use the narrow navigation approach in finding one concept in a long lecture. Here, the purpose is to find the instruction you must verify. You do not need to build an index of the whole lesson.

For each required step:

  1. Save the video time where the instruction appears.
  2. Read the code, menu option, or setting on screen.
  3. Record any setup shown just before it.
  4. Preserve the original instruction.
  5. Mark unclear text as unresolved.

Do not treat spoken words as extracted code. The caption tool described below does not perform optical character recognition. That term means reading text from an image. You must inspect the screen yourself.

A comment saying “it worked” can suggest something to check. It does not establish compatibility. Compatibility means that an instruction works with the relevant software version. The comment may not state that version or the exact steps used.

If a comment reports a missing button or an error, compare it with the actual passage before you use it as evidence. The method in checking a comment against a tutorial passage explains that separate check. Keep the comment as a clue until you confirm its setup and relevance.

3. Use timed captions when they help

The YouTube Transcript Scraper is an Actor: a hosted program that collects data. Its documented role here is to read existing public captions. You still identify the instructions, inspect the screen, read the official documentation, and judge the test.

The public contract checked on 25 October 2026 describes build 0.1.43. It accepts direct public YouTube video URLs or video IDs. An ID is the short code that identifies a video. It does not accept a channel, playlist, or search page as the source list. It reads existing caption tracks; it does not create new text from speech or download audio or video.

The public timestamped transcript Task is a starting preset. A Task is a saved set of input values. Its public page and Task ID were found on 25 October 2026. That check did not inspect authenticated saved input or test execution.

This small input passed the supplied schema check. A schema defines the allowed input fields and values. A schema check is not a successful collection run.

json
{"includeFailedInputDetails":true,"outputFormats":["json"],"preferredLanguages":[],"startUrls":["https://www.youtube.com/watch?v=dQw4w9WgXcQ"]}
3. Use timed captions when they help

Before you run it:

  1. Replace the whole sample list in `startUrls` with your intended public tutorial URL.
  2. Keep `outputFormats` set to `["json"]` to request timed segments.
  3. Choose your caption language policy.
  4. Keep `includeFailedInputDetails` true so failed inputs remain visible in the run report.

The sample URL is a schema example. It is not evidence of a useful tutorial result. No Actor run was performed for this guide.

An empty `preferredLanguages` list requests the best available caption track. It does not promise English. If you set language preferences, the Actor tries them in order. If none is available, the documented result is a typed language-unavailable failure. That means a failure with a stated category, rather than an unannounced switch to another language.

The documented input limit is 1–1,000 entries. Repeated video IDs are processed once. For this check, use one tutorial.

After a proposed run, inspect the result before you use the text. A dataset row is one saved video result. Successful unique videos produce rows. Failed inputs appear in the run report called OUTPUT.

Keep the video identity, `status`, `statusReason`, `transcriptLanguageCode`, `isAutoGenerated`, and `scrapedAt`. The last field records the collection time. Keep the original `segments`, including `text`, `startSeconds`, `endSeconds`, and `durationSeconds`.

Use the returned times to find the passage. Plain text alone does not establish caption end times. A missing duration remains unknown, even if an end time is available. Do not replace a missing value with zero.

Language labels, caption source labels, and coverage values do not prove that the words are correct. Watch the relevant passage in all cases.

The captions are public source data. Your saved input, private run records, local version record, and test results are separate records. A public preset page does not prove what an account owner saved or ran.

4. Build a version-and-step table

A version-and-step table connects each instruction to its source, official reference, and test result. Use one row per required step. Split a row when two actions need different checks.

Save these fields:

4. Build a version-and-step table
FieldWhat to save
TaskThe small result you want
Video sourceTitle and public URL
Source cueVideo time and relevant caption segment, if available
Original instructionExact visible code, option, or action
Tutorial versionStated version and where you found it, or unknown
Local environmentYour actual software version and relevant setup
Official referencePage URL, version scope, and relevant passage
Reference check dateWhen you read that page
Proposed changeYour replacement instruction, kept apart from the original
Test inputExact harmless input, if tested
Expected resultWhat should happen and why
Actual resultExact observed output or error, or not tested
Test dateWhen the test occurred, or not tested
StateChecked, documented change, untested, or blocked
Open issueMissing evidence and the next needed check

Preserve errors as carefully as successful output. Do not replace an error with the result you expected.

Use “unknown” when a fact is missing. Use zero only when zero is the actual known value. “No test recorded” does not mean “zero failures.” It means you have no test evidence for that row.

Keep the original and proposed instructions in separate fields. Otherwise, a later reader cannot see what changed or why.

5. Read the official reference for the feature and version

Open the official documentation for the exact feature. A feature is one software function or behavior. Check which software version the page covers.

Read the behavior description as well as notes about when the feature was introduced, changed, or removed. Save the relevant passage and the date you checked it.

Use this sequence:

  1. Match the exact feature name to the visible instruction.
  2. Confirm the version covered by the reference.
  3. Read the expected behavior.
  4. Check version notes.
  5. Compare that scope with your local version.
  6. Record any remaining gap.

A current documentation page can state when a feature was added. That does not make it evidence for every behavior in every earlier version. If the page does not cover the version you need, leave that part unresolved until you have a relevant official reference.

Do not infer that a feature is unavailable because you could not find its documentation. Record the failed search as a source gap.

The official Python string reference gives a clear example. `str.removeprefix` removes an exact supplied prefix when it occurs at the start. Otherwise, it returns the unchanged string. The reference says it was added in Python 3.9.

The same supplied reference evidence distinguishes `lstrip`: it removes leading characters from a supplied set. It is not an equivalent replacement for exact prefix removal. Similar names or similar results on one input do not establish the same behavior.

6. Choose a harmless test with a clear result

A reproducibility test checks whether you can get a stated result from stated inputs in a stated environment.

Choose the smallest test that answers the feature question. Prefer an operation that only works on local values and has no outside effect. Write the expected result before you run it.

For this first check, avoid unreviewed installations, account creation, credentials, production systems, and commands copied without review. Credentials are secrets used to gain access. A production system is a system used for real work.

Record the exact input, expected output, actual output, local version, and test date. If the test fails, keep the exact error and stop that step. Do not make several unexplained changes and then record only the final success.

A harmless feature test has a narrow purpose. It can confirm one operation in your environment. It cannot prove that a whole project installs, that every tutorial step works, or that other software versions behave the same way.

7. Worked example: exact prefix removal

This example uses the supplied recorded local test. It is not original fiction. It also is not a test of a real YouTube tutorial.

The recorded environment was Python 3.12.12. The check date was 25 October 2026. The test used only local standard-library string expressions. The standard library is the set of tools supplied with Python. No installation, network access, or tutorial execution formed part of this test.

The task is to remove the exact prefix from a string. A string is a text value.

First expression:

python
"Arthur: three!".removeprefix("Arthur: ")
7. Worked example: exact prefix removal

The expected result was `three!`. The recorded actual result was `three!`.

The prefix contains eight characters: six letters, one colon, and one space. The original text contains 14 characters. Removing that prefix leaves 14 − 8 = 6 characters: the five letters in `three` and the exclamation mark. These units are characters, not bytes.

Second expression:

python
"Arthur: three!".lstrip("Arthur: ")
7. Worked example: exact prefix removal

The expected result was `ee!`. The recorded actual result was `ee!`.

Here, `lstrip` treats the supplied text as a set of characters to remove from the start. After it removes `Arthur: `, it continues through the leading `t`, `h`, and `r` in `three!`. Those characters are also in the supplied set. It stops at `e`.

That removes eight prefix characters plus three more characters. The count is 14 − 8 − 3 = 3 characters. The remaining text is `ee!`.

7. Worked example: exact prefix removal
CheckRecorded evidenceLimit
Local versionPython 3.12.12Does not describe another environment
Official version note`str.removeprefix` added in Python 3.9Does not establish every later-version behavior
Exact prefix testExpected `three!`; actual `three!`Checks this expression and input only
Leading-character testExpected `ee!`; actual `ee!`Shows why this expression is not an equivalent substitute
Tutorial version and cueUnknown; no tutorial was testedNo tutorial step can be marked checked
Full workflowNot testedNo full-tutorial success claim

The supported decision is narrow. Use exact prefix removal when that is the intended text operation and the version supports it. Do not replace it with `lstrip` as if they meant the same thing.

For your tutorial, add its actual visible instruction and source time. Then perform your own harmless test on your stated version. The supplied result is evidence about Python 3.12.12, not a result from your computer.

8. Assign a state and decide what can proceed

Use the same four states throughout the table:

8. Assign a state and decide what can proceed
StateMeaningNext decision
CheckedYou inspected the instruction and confirmed the selected test in the stated environmentProceed within that tested scope
Documented changeThe official reference supports a relevant version differencePreserve the original, propose a change, and record whether the change was tested
UntestedYou have not performed the needed testTest before you claim it works locally
BlockedMissing evidence or an unsafe required action prevents the checkResolve the gap before you follow that step

A documented change is not automatically a tested repair. Keep its test outcome in the separate result fields. If you need a new instruction, give it its own row so its evidence stays clear.

If captions are unavailable, you can still inspect the video manually. If the screen is unreadable, keep the exact instruction unresolved. If your version is unknown, resolve it before making a compatibility claim. If the official reference has the wrong scope, retain the source gap.

Before you follow the full tutorial, check every required row. Each row needs evidence for the action you plan to take. A passed expression does not clear an untested installation or account step.

Do not convert the table into a general video-quality score. Its purpose is to support one practical decision: which instructions you can follow in your stated environment, and which still need work.

Sources & further reading

By Chronometrica · Updated

Back to top ↑