diff --git a/docs/03_Get-Started/step-27-unit-test-with-qunit-e1ce1de.md b/docs/03_Get-Started/step-27-unit-test-with-qunit-e1ce1de.md
index a547022..06347f4 100644
--- a/docs/03_Get-Started/step-27-unit-test-with-qunit-e1ce1de.md
+++ b/docs/03_Get-Started/step-27-unit-test-with-qunit-e1ce1de.md
@@ -78,7 +78,7 @@ sap.ui.define([
 
 We create a new `formatter.js` file under `webapp/test/unit/model` where the unit test for the custom formatter is implemented. The `formatter` file that we want to test is loaded as a dependency.
 
-The formatter file just contains one QUnit module for our formatter function and one unit test for the formatter function. In the implementation of the `statusText` function that we created in Step 23, we use the translated texts when calling the formatter. As we do not want to test the UI5 binding functionality, we just use text in the test instead of a `ResourceBundle`.
+The formatter file just contains one QUnit module for our formatter function and one unit test for the formatter function. In the implementation of the `statusText` function that we created in Step 22, we use the translated texts when calling the formatter. As we do not want to test the UI5 binding functionality, we just use text in the test instead of a `ResourceBundle`.
 
 Finally, we perform our assertions. We check each branch of the formatter logic by invoking the isolated formatter function with the values that we expect in the data model \(`A`, `B`, `C`, and everything else\). We strictly compare the result of the formatter function with the hard-coded strings that we expect from the resource bundle and give a meaningful error message if the test should fail.