From ae7dc2315c2683d8c87ba36e393c0f4f73b4934e Mon Sep 17 00:00:00 2001 From: Diogo Nunes Date: Thu, 15 Feb 2018 11:18:54 +0000 Subject: [PATCH 1/3] install/run tool --- ci-install.sh | 2 +- ci-run.sh | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/ci-install.sh b/ci-install.sh index 887461b8..4657a502 100755 --- a/ci-install.sh +++ b/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 markdown-link-check" diff --git a/ci-run.sh b/ci-run.sh index 6deae431..4691eb97 100755 --- a/ci-run.sh +++ b/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 links' +run_step "find docs -name \*.md -exec markdown-link-check {} \;" From df938f2c9db3d9fd4fa6097d3f88f31868d83bb3 Mon Sep 17 00:00:00 2001 From: Diogo Nunes Date: Thu, 15 Feb 2018 11:19:16 +0000 Subject: [PATCH 2/3] fix "issues" (make all links relative) --- docs/_sidebar.md | 12 ++++++------ docs/concepts/requirements.md | 4 ++-- docs/notebook/specification-by-example.md | 2 +- docs/notebook/user-story-mapping.md | 4 ++-- docs/tools/charters.md | 4 ++-- docs/tools/oracles.md | 6 +++--- 6 files changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/_sidebar.md b/docs/_sidebar.md index acf0c381..305390af 100644 --- a/docs/_sidebar.md +++ b/docs/_sidebar.md @@ -2,18 +2,18 @@ -- [**Home**](/) +- [**Home**](./) - **Concepts** - ~~Testing's purpose~~ - ~~Tester's responsibility~~ - ~~Software Testing Life Cycle (STLC)~~ - - [Requirements](/concepts/requirements.md) + - [Requirements](./concepts/requirements.md) - **Tools** - ~~Test strategy~~ - ~~Test methodologies~~ - ~~Test pyramid~~ - - [Charters](/tools/charters.md) - - [Oracles](/tools/oracles.md) + - [Charters](./tools/charters.md) + - [Oracles](./tools/oracles.md) - ~~Heuristics~~ - ~~Mnemonics~~ - **Test types** @@ -53,5 +53,5 @@ - **Next steps** - ~~Staying updated~~ - **EXTRA: Notebook** - - [User Story Mapping](/notebook/user-story-mapping.md) - - [Specification by Example](/notebook/specification-by-example.md) + - [User Story Mapping](./notebook/user-story-mapping.md) + - [Specification by Example](./notebook/specification-by-example.md) diff --git a/docs/concepts/requirements.md b/docs/concepts/requirements.md index 99404544..eac0a221 100644 --- a/docs/concepts/requirements.md +++ b/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 When Then `. -- **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 When Then `. +- **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. diff --git a/docs/notebook/specification-by-example.md b/docs/notebook/specification-by-example.md index f92ff3d1..1398c1eb 100644 --- a/docs/notebook/specification-by-example.md +++ b/docs/notebook/specification-by-example.md @@ -18,7 +18,7 @@ 1. Continue until the scope of the story is clear (or time runs out). 1. Find out who would be suitable to answer the questions 🔴 raised. -![example](/_media/notebook/specification-by-example-1.png) +![example](../_media/notebook/specification-by-example-1.png) **Exercises**: [Story](https://medium.com/@mattwynne/introducing-example-mapping-42ccd15f8adf) / [Rules vs Examples](https://speakerdeck.com/mattwynne/rules-vs-examples-bddx-london-2014) diff --git a/docs/notebook/user-story-mapping.md b/docs/notebook/user-story-mapping.md index 02be4cbf..daa5a9f0 100644 --- a/docs/notebook/user-story-mapping.md +++ b/docs/notebook/user-story-mapping.md @@ -14,7 +14,7 @@ Story mapping is an engaging activity where all stakeholders participate on buil [Example](https://www.thoughtworks.com/insights/blog/story-mapping-visual-way-building-product-backlog) _goal (red), activity (blue), task (green), user story (yellow)_ -![diagram](/_media/notebook/user-story-mapping-1.png) +![diagram](../_media/notebook/user-story-mapping-1.png) **How to prepare a session**: @@ -24,7 +24,7 @@ Story mapping is an engaging activity where all stakeholders participate on buil - A good camera to take photos of the wall (detail and panorama) - Optional: stickers, like dots or stars (to flag special cases) -![structure](/_media/notebook/user-story-mapping-2.jpg) +![structure](../_media/notebook/user-story-mapping-2.jpg) **Tips**: diff --git a/docs/tools/charters.md b/docs/tools/charters.md index 8260574d..3497fdc6 100644 --- a/docs/tools/charters.md +++ b/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? diff --git a/docs/tools/oracles.md b/docs/tools/oracles.md index 4bdc070d..c7cdf25f 100644 --- a/docs/tools/oracles.md +++ b/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](../tools/heuristics.md) — 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_ From 501a0306c3161eb45c57f534f8a3fadfbda9d5c3 Mon Sep 17 00:00:00 2001 From: Diogo Nunes Date: Thu, 15 Feb 2018 11:19:24 +0000 Subject: [PATCH 3/3] log time --- time-counter.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/time-counter.txt b/time-counter.txt index 28119317..9ec43012 100644 --- a/time-counter.txt +++ b/time-counter.txt @@ -8,3 +8,4 @@ 60 120 70 +30