Check broken (internal) links with "remark"

ci-install.sh

@@ -4,4 +4,4 @@
 source ./ci-helpers.sh
 
 log_task "Install tool dependencies"
-run_step "npm i -g markdownlint-cli markdown-spellcheck"
+run_step "npm i -g markdownlint-cli markdown-spellcheck remark-cli remark-validate-links"

ci-run.sh

@@ -8,3 +8,6 @@ run_step "markdownlint docs --config docs/.markdownlint.json"
 
 log_task 'Check for spelling mistakes'
 run_step "mdspell 'docs/**/*.md' -r --en-gb --ignore-numbers --ignore-acronyms"
+
+log_task 'Check for broken internal links'
+run_step "remark -u validate-links docs/ --frail"

docs/_coverpage.md

@@ -9,6 +9,6 @@
 - [GitHub](https://github.com/dialex/start-testing) 🤝 **anyone can contribute**
 - [Docsify](https://github.com/QingWei-Li/docsify/) 😎 **looks awesome**
 
-[Let's Start](#syllabus)
+[Let's Start](index.md/#syllabus)
 
 ![color](linear-gradient(to left bottom, #F0FD37 0%, #ACF260 100%))

docs/concepts/requirements.md

@@ -49,8 +49,8 @@ So you might be asking **how can testers add value to this process?**
 - **Align perspectives**. Each side has its own concerns, assumptions and biases. Chat with stakeholders (askers) and developers (givers) to check if they have a common understanding of what needs to be done.
 - **Raise risks**. That's why you are one of the three amigos. Usually the POs are focused on functionality and your developers on implementation details. You can remind them of risks such as non-functional requirements, impacts with previous stories or the cost of automating a specific tests.
 - **Ask questions**. Discuss what-if scenarios. Use personas to discover user-specific issues. Clarify the rules for extreme or unusual values. It's cheaper to improve the design than it is to fix the implementation.
-- **Write scenarios**. When doing [specification by example](/notebook/specification-by-example.md), you should be writing those examples. Most likely you will [automate](/roles/automation-tester.md) them later on, using the Gherkin syntax `Given <condition> When <action> Then <result>`.
-- **Bring your toolbox**. [Mnemonics](/tools/mnemonics.md) such as the five W's are useful to detail stories and create scenarios with less assumptions. Your [list of biases](/tools/biases.md) might also uncover weak requirements.
+- **Write scenarios**. When doing [specification by example](../notebook/specification-by-example.md), you should be writing those examples. Most likely you will [automate](../roles/automation-tester.md) them later on, using the Gherkin syntax `Given <condition> When <action> Then <result>`.
+- **Bring your toolbox**. [Mnemonics](../tools/mnemonics.md) such as the five W's are useful to detail stories and create scenarios with less assumptions. Your [list of biases](../tools/biases.md) might also uncover weak requirements.
 - **Clarify stories**. Your questions lead to explicit requirements and more examples. Doing so you are increasing the probability of meeting the stakeholder's requirement.
 - **Think again**. The more you know, more assumptions you make and more casual you are when testing. Fresh eyes find failure, so stay sharp.
 - **Don't be fooled**. Question requirements and extract their value/usefulness. Be aware of echo chambers.

docs/tools/charters.md

@@ -9,9 +9,9 @@ It works like a map:
 - If you show your map to someone else, they can quickly understand where your destination is.
 - If you wander too much and find yourself lost, your map focuses your mind by showing which paths deviate you from your initial goal and which paths lead you there.
 
-**Exploring software** has much in common with exploring territory. Along the way you will make many discoveries (e.g. information, bugs). To make your journey easier you can use tools. Remember, "the most important tool is the one between your ears". As an [exploratory tester](/roles/exploration-tester.md) you will conduct exploratory testing sessions like these and charters can guide your way.
+**Exploring software** has much in common with exploring territory. Along the way you will make many discoveries (e.g. information, bugs). To make your journey easier you can use tools. Remember, "the most important tool is the one between your ears". As an [exploratory tester](../roles/exploration-tester.md) you will conduct exploratory testing sessions like these and charters can guide your way.
 
-You can write your charters to be precise or broad, as you will see in the practice section below. Nevertheless, for a charter to be useful it should contain enough detail for anyone to understand three things. As a [mnemonic](/tools/mnemonics.md) you can remember the initials `TRI` — because a charter summarises what you are **TR**y**I**ng to accomplish:
+You can write your charters to be precise or broad, as you will see in the practice section below. Nevertheless, for a charter to be useful it should contain enough detail for anyone to understand three things. As a [mnemonic](../tools/mnemonics.md) you can remember the initials `TRI` — because a charter summarises what you are **TR**y**I**ng to accomplish:
 
 - **Target**: What is the name of the area you will explore?
 - **Resource**: What tools will you use on your exploration?

docs/tools/oracles.md

@@ -6,11 +6,11 @@
 
 There are a number of ways in which you can determine that you have discovered a defect in a software application. Those are your test oracles. Oracles are the mechanism by which you **recognise a problem**. They help you discover the real reason why you think there is a problem.
 
-Knowing your oracles means that you can **objectively explain** to developers and business stakeholders why the users of the software may agree that you have found a bug. This makes your [bug advocation](/roles/bug-hunter.md) more effective.
+Knowing your oracles means that you can **objectively explain** to developers and business stakeholders why the users of the software may agree that you have found a bug. This makes your [bug advocation](../roles/bug-hunter.md) more effective.
 
 In **oracle-based testing**, you compare the behaviour of the program under test to the behaviour of a source you consider accurate (an oracle). You constantly look for answers to: Is this behaviour correct? In the user expecting this? A tester who is familiar with the type of product under test will have no problem making these evaluations. However, a newcomer needs a reference for guidance — an oracle.
 
-Some oracles lead you to other oracles, which allow you to extend your initial test strategy into areas you haven't thought about before. Keep in mind that each oracle **focus on a specific perspective**. If you limit yourself to a single oracle, it might bias your testing by giving you a narrow view of your context. That is why oracles are [heuristics](/tools/heuristics.md) — they are useful tools that help us make decisions, but sometimes they point us to the wrong decision.
+Some oracles lead you to other oracles, which allow you to extend your initial test strategy into areas you haven't thought about before. Keep in mind that each oracle **focus on a specific perspective**. If you limit yourself to a single oracle, it might bias your testing by giving you a narrow view of your context. That is why oracles are [heuristics](https://www.npmjs.com/package/PageThatDoesNotExistAndReturns404) — they are useful tools that help us make decisions, but sometimes they point us to the wrong decision.
 
 ## Practice
 
@@ -22,7 +22,7 @@ Oracles come in many shapes, here are a few examples:
 - a human domain expert, who can look at the output and tell whether it is correct;
 - or any other way of telling that a given output is correct.
 
-Use the [mnemonic](/tools/mnemonics.md) `FEW HICCUPS` to remember these oracles:
+Use the [mnemonic](../tools/mnemonics.md) `FEW HICCUPS` to remember these oracles:
 
 - **Familiarity**: Is it free of common/past bugs?
   - _e.g. the product exhibits behaviour X which was marked as a bug on previous releases_

time-counter.txt

@@ -8,3 +8,4 @@
 60
 120
 70
+30