From 4a91a137f0c568fa134fc69333ed830011cf1362 Mon Sep 17 00:00:00 2001 From: Grant Kiely Date: Thu, 17 Nov 2022 06:37:48 -0600 Subject: [PATCH] Fix typo --- benefit-handle-anomalies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/benefit-handle-anomalies.md b/benefit-handle-anomalies.md index 32bc88b..a2b367c 100644 --- a/benefit-handle-anomalies.md +++ b/benefit-handle-anomalies.md @@ -10,4 +10,4 @@ In a lot of bottom-up approaches, it is common to forego the error states: When In a statechart approach, failures are generally failures of background [activities](glossary/activity.html){:.glossary}. When a background activity fails, a simple thing to do is to inform the statechart about the failure (by sending an [event](glossary/event.html){:.glossary} that describes the error), and describe _in the statechart_ how the failure should be handled, typically by introducing a new [transition](glossary/transition.html){:.glossary} to deal with the error. -This simple act causes the error to be explicitly visible in the statechart, _and_ therfore to the development team and other stakeholders. It allows [QA teams to discover](benefit-qa-exploration-tool.html) that the error state exists, possibly prompting them to actually test this path. It allows designers to design the error states [that have been uncovered](benefit-all-states-explored.html). +This simple act causes the error to be explicitly visible in the statechart, _and_ therefore to the development team and other stakeholders. It allows [QA teams to discover](benefit-qa-exploration-tool.html) that the error state exists, possibly prompting them to actually test this path. It allows designers to design the error states [that have been uncovered](benefit-all-states-explored.html).