This repository was created for QA exercises.
This exercise consists of two parts. In the first part, I investigated the first SUT and documented all my findings under the ./manual.tests folder. In the second part, test automation involves both UI and API automated tests. I used Playwright Test Framework with Ts Language.
I haven't created any defect or bug reports for a while. Because many agile teams are now using some productivity tools such as Jira, Test Rail, Xray, etc. to record and track their findings. But for the sake of exercises, I created a bug report under the ./manual.tests folder.
🐛 Please click here to open the bug report. 🐛
I tried to add must-have fields to my bug report. All screenshots related to manual tests are stored under the ./manual.tests/screenshots folder and they are named with its bugId + underscore + pictureNumber. For example, if the screenshots belong to bugId: 101, screenshots could be 101_01, 101_02, etc.
I didn't create all the screenshots. I gave some examples of how it could be done for the bug report.
I documented some test cases as examples under the ./manual.tests/test.cases folder.
🔎 Please click here to open sample test cases. 🔎
I automated some test cases under the ./tests folder. Each test cases are very self-explanatory with comments. They are kind of test steps.
The factorial calculator exposes an API URL so I also created API test cases as well as UI test cases. These tests use Mocha or Jest style BDD test cases. It could be Cucumber (Gherkin) based test cases but I preferred them this way. If semi-technical people join the test process or if we are creating acceptance criteria then Cucumber might be a good choice since people find all When-Then steps easy. But personally, I find mocha-style test cases very flexible and it is just fun.
For integer numbers in range (10, 100) test cases placed here
I already run automation and the nice execution HTML report is under the ./playwright-report folder. Served HTML Report is here. You may click all test cases and see the steps. When you click the failed test cases you may also see screenshots.
Acceptance criteria can be written in different formats based on context and requirements. I saw two different types of them widely used in my experience:
- The first one is scenario-based (Given-When-Then pattern)
- The second one is task-based (or rule-based) mainly consists of a checklist of tasks.
I tried to write two Acceptance Criteria used two different ways. Please find under the ./acceptance.criteria folder.
This project requires node v16.# and at least one browser (chrome or firefox) to be installed.
-
Clone the project
git clone https://github.com/ikoral/swiss-borg-challenge.git` -
Install Packages & Dependencies
npm installthen
npx playwright install
This command runs all tests under the ./tests folder with the provided config file. Playwright runs all tests in headless mode by default. If you add headed flag, you can see the browser for UI tests.
npx playwright test tests --config=playwright.config.ts --headed`
You can add a decorator/tag to your test cases with @ symbol. Please look at the examples under the tests folder. Then you may want to execute the specific tests which have a specific decorator. Below, the command runs all test cases with the @navigation tag under the tests folder no matter which sub-folder they are in.
npx playwright test --grep @navigation --config=playwright.config.ts --headed
For detailed command and command flags please refer to Playwright documentation.
if any tests fail, Playwright will open HTML test report by default. You can also open the latest execution report by running the below command:
npx playwright show-report playwright-report/html.report