Requirement analysis, Test Execution, Implement testing procedures:
As this project contains more than one requirement ticket, I will be documenting the Requirement analysis, test executions and test procedures under this heading for each requirement, to enable flow readability.
Cypress Automation Jira Ticket
ECOM-1705_ Gift Shop search scenario1 - Search and publications checkout1
On the right-hand side of the screenshot above, you can see under Development that 1 branch was created and 1 pull request was merged. This was because as part of the instructions, we created branches referencing it to the Jira ticket to provide traceability. This proves my willingness to following instructions.
So, from the Acceptance criteria above on the screenshot, I needed to search for a product with a product code, then validate the product name on the product page, and finally, add the product to the product cart/basket.
Test Cases for - ECOM-1705Gift Shop search scenario1 Search and publications checkout1 Jira ticket above
Since this is a migration of on already designed test framework, my test cases are provided within the cucumber files of the java automation framework. I followed the steps for each scenario to write the cypress automation test scripts. This is a functional test case.
Our test cases were derived from the Java automation cucumber feature files. We followed the steps for each scenario to write the test scripts. Below are screenshots of the 2 test cases for the above Jira ticket requirement-
Background / before each test execution-
Given I am on giftshop
Test case-
'Should display product in the search results'
When I enter product code into the search text field,
And click Enter on the keyboard,
Then I should see the product name from the search results.
Test Case for the Test Basis above:
The above Test case should be divided into two one for the user and the other for the admin actions.
Background / before each test execution-
Given I am on publications.
When I click on ‘Early Diagnosis’ on the Main Navigation menu.
And click on ‘Spotting cancer early saves lives’ link.
And I select ‘Quantity’ 25.
And I click on ‘View Basket’ button.
And I click on the ‘Place order’ button.
Test case for User-
'User should be able to select option(s) for receiving the latest CRUK Ecommerce Shop Updates'.
And I am at the checkout.
And I complete the Shipping Details as detailed on the JSON file.
And I select my contact preference as listed on the JSON file.
And I click on ‘Confirm your order’ button.
Then I should confirm the ‘order number’ at the ‘Thank you’ page.
Test case for the Admin user-
'User should be able to select option(s) for receiving the latest CRUK Ecommerce Shop Updates'.
And I am at the checkout
And I complete the Shipping Details as detailed on the JSON file.
And I select my contact preference as listed on the JSON file.
And I click on ‘Confirm your order’ button.
And I store the ‘order number’ at the ‘Thank you’ page in a string variable.
Static Test on the above Test basis’:
I decided to change some of the scenario’s descriptions to reflect user-friendly automation. Publications scenario Verify Opt-in changes was modified to 'User should be able to select option(s) for receiving the latest CRUK Ecommerce Shop Updates', to enable code readability.
During code review, this was accepted by the Automation Lead. Here I am using my attributes of attention to detail effectively, by making sure the scenario description was more understandable or clearer to users who would be reading the code.
Test Condition for -
ECOM-1705Gift Shop search scenario1 - Search and publications checkout1 Jira ticket
Product Name
Test Conditions | Comments |
Product search text field | Product code is entered in the search text field to be found. |
Product Name | The product name needs to be validated after it has been searched and found. |
Exit Criteria for -
ECOM-1705Gift Shop search scenario1 Search and publications checkout1 Jira ticket above
After coding for the above Acceptance Criteria is completed, the code needs to go through a pull request review. After the code is accepted, the code can be merged into the main develop branch, the tester can exit and move on to the next requirement.
Test Data Preparation
Test Quality Time constraints
Recreating my test data would cost and take too much time. So I used the stage test environment which has anonymised data from production, that saves time and money. This project would have been delayed by months if I was to create the relevant product test data from scratch, so we accessed that using existing data, would provide us with enough coverage and quality data– Test quality time constraints.
Most of the following referenced data already prepared within the Java automation framework. However, data does sometimes need updating when there is a data refresh during UAT deployment.
Test Data
Giftshop:
Test –
The following test data is for the tests below:
Should display product in the search results:
Should validate the product name:
Field | Data | Data Type | Data Length |
SkuCode | KT23122 | Alphanumeric | Up to 7 |
Field | Data | Data Type |
ProductName | A to Z of the United Kingdom Kids Book | String |
Test -
Should find and select another product colour
Field | Data | Colour | Data Type |
SKU Code | WC28304 | Blue | Up to 7 |
Product Name | Unity Band® |
Field | Data | Colour | Data Type |
SKU Code | WC28302 | Magenta | String |
Using these test design techniques saves time and finds more defects than just entering random value numbers. Some of the data had to be tested using the above test techniques. For example, UK telephone numbers need to be 11 digits and numbers only.
Cypress Test Spec file –
Test -
Verify Opt-in changes (Verify Get The latest updates)
TC Scenario | Email | Mobile Number | Title | First Name | Last Name | Country | Post Code |
Verify Thank you page displays correct information | stjohn.kawazaki@mailinator.com | 07808149811 | Mr | St John | Kawazaki | United Kingdom | PA42 7EP |
Some other test case | bella.baxter@mailinator.com | 07808149811 | Mrs | BELLA | BAXTER | United Kingdom | B95 5RP |
Verify Opt in changes | helen.robinson@mailinator.com | 07808149811 | Ms | Helen | Robinson | United Kingdom | E20 1JQ |
Field | Data | Data Type | Data Length |
Email | stjohn.kawazaki@mailinator.com | Alphanumeric | |
Mobile Number | 07808149811 | numeric | |
Title | Mr | String | |
First Name | St John | String | |
Last Name | Kawazaki | String | |
Country | United Kingdom | String | |
Post Code | PA42 7EP | Alphanumeric | Up to 7 (UK) |
The Rule:
A UK telephone number should be 11 digits, no less or more.
Field | Data Type | Test Technique |
Mobile number | number | And boundary value analysis |
Invalid(10 digits) | Valid(11 digits) | Invalid(12 digits) |
0780814981 | 07808149811 | 078081498112 |
A UK telephone should begin with 07, 01, 02 or 03.
Invalid(lower boundary value) | Valid | Invalid(upper boundary value) |
00 | 01 | |
02 | ||
03 | 04 | |
06 | 07 | 08 |
A UK postcode Rule:
- · It should only begin and end with a letter.
- · It is 6 or 7 characters, no more no less.
- · The first having between 2 to 4 characters and the second set has 3 characters.
- · The second set should only begin with a number and end with a letter.
Field | Data Type | Test Technique |
Postcode | Alphanumeric | Equivalence Partitioning |
Invalid | Valid | Invalid |
PA42 7EP | PA42 7EPE | |
B95YU 5RP | B95 5RP | B95YU 5R |
B 5RP | B9 5RP | B9 PR5 |
Address Line 1 | Address Line 2 | Address Line 3 | City | Email Option | Post Option | Phone Option | Text Option |
8 Livingstone Way | Port Ellen | Isle of Islay | yes | No | |||
Elmhurst House | Rams Hill Lane | Henley-in-Arden | No | Yes | |||
cancer research UK | 2 Redman Place | London | Yes | No |
The above was just one example of the test data. As this project is very big, it would take too many pages to cover all the data for all the shops.
Setting up the environment
The test environment setup is based on Cypress. Cypress is installed using the following command in the windows command prompt:
1. Install node and check the version
Node –version
V12.13.0
2. Install visual studio code IDE
Npm package is installed in the same folder as the project itself.
mkdir ecomCypressAutomation
Open folder in visual studio code by typing the command:
cd ecomCypressAutomation
Code.
Press enter
In visual studio-code open the terminal command line
Create the package.json
Npm init -y
This initialises the folder to be ready for the npm commands. Type the following command to install cypress.
Npm install cypress –3.4.1
As mentioned in my introduction, one of the reasons why we decided to migrate into JavaScript using Cypress, here you can understand why we made the right choice. Cypress is so easy to set-up and gets started.
Test Script
After the successful installation:
Project script folder details
Fixtures
Fixtures folder is used to manage the test data. I will be placing my JSON files for all the project in this folder.
fixtures for setting the environment for test
Fixtures are also a great way of setting the test environments for automation to be executed. I have three environments for the tests –
Dev, int and stg.
3 folders to be created under Fixtures in cypress.
dev
Int
stg
Inside these folders, I created files as:
Env_settings.json
Inside each file above should have details for the URL–
"url":"https://.developer"
This would be used to execute the script in any of the environments.
Integration
The integration folder will host the test files for the project. Each test file is distinguished by the extension:
filename.spec.js
Plugin
This folder will host the events Listeners.
Screenshot and video
This folder will host all the screenshots and videos captures by cypress during the execution.
Support
This folder will host any scripts used to support or commonly used for more than one part of the system, or across all the shops.
Node_modules
Contains cypress libraries to make the program work. Also contains the Mocha framework dependencies.
Cypress.json file
When a project is added to cypress, cypress.json is created to store the project. Contains all global configuration for the application. If there’s a need to override the global configuration, then it must be specified here.
Package.json file
Required to install cypress and other testing tools for this project.
Package.lock.json file –
‘package-lock.JSON is automatically generated for any operations where npm modifies either the node_modules tree or package.JSON. It describes the exact tree that was generated, such that subsequent installs can generate identical trees, regardless of intermediate dependency updates.’ -
Commands for writing the scripts
Cy. -Is the parent function that contains all the commands we need to write our tests.
Npx cypress open – runs on the cypress runner
Npx cypress run -executes all test cases in Terminal
Npx cypress run –headed: executes all test cases in Terminal- see UI
Npx cypress run –spec – specify which spec file to execute
npx cypress run --browser chrome
Integration framework
As part of this project, the integration framework I would be using is Mocha. Example of mocha is as follows:
Describe(‘Test Suite’, function(){
It (‘Test Case1’, function(){
Steps;
});
It (‘Test Case2’, function(){
Steps;
})
});
How Test Suites and Test Cases in cypress are presented
The above example is how a test Suite and test Cases are coded and presented. The describe block would be used as the parent block which has the tests written within the ‘it’ function. It may contain more than one ‘it’ test. The describe block can be pictured as a test suite containing test cases.
Automation implementation
The test scripts are created on cypress using JavaScript following the steps in the acceptance criteria of the Test Basis/Jira ticket. After executing the test script, I would then add validations of the ‘Then’ part of the acceptance criteria.
Script to Convert data in Excel into JSON format.
Early during the test automation coding, I realised we had a lot of data in an excel spreadsheet which needed to be converted into JSON. I decided to research for a solution to convert the data.
To run the script the following command needs to be executed-
Npm run <nameOfTheJsonScriptFile>
Npm run convertXLSDataToJSon.js.
This can be useful if you have a lot of data in an excel spreadsheet and need to be converted into JSON format.
With GitHub actions in place as our continues integration, codes are checked for failure so it can be fixed before it can be merged into the master branch. As part of the Test Strategy, we need to enable GitHub actions. I created a Jira ticket so this could address. I requested an example of how the YML file looks like, from our Automation Lead. Then I started creating one for the e-commerce website. I created a pull request of which the Automation Lead responded. Together we worked through to get it working.
All branches needed to start with test/ or feature/, followed by the branch reference or name. The GitHub Actions YML files check for any branches into GitHub, beginning with test/ or feature/. Then it creates a virtual test on ubuntu Operating system. It follows steps using GitHub-action@v1 and uses the working-directory of tests. It investigates the integration folder of cypress, then uses the stg environment. After cypress run, it generates a report and merges the report in the tests/cypress/assets directory. This is very useful as all code are tested, any team member can view the code to check what’s failing and passing.
Fixing conflicts on GitHub to merge the branch into the master origin
I had a pull request which had conflicts with the master origin branch, so I needed to fix this to merge into the master branch.
I pulled the master branch locally. Then I executed the pull action in visual code. I then git bash on the project directory folder and issued ‘git status’ command to check the status of master origin. Then I issued:
$ git checkout test/ECOM-1868_Wedding_Favour_Feature2
To switch to my branch. Then I issued:
git merge develop
Find details below:
to merge the master branch into my branch. It could not be merged automatically so I switched from the command line to Visual code to fix the problem.
I hovered over the changed code and clicked on ‘Accept incoming change’.
After fixing the code, I went to the command line again to merge the master branch into my current working branch. I issued the following commands-
Git add *
git commit -m "Merge branch 'develop' into test/ECOM-1868_Wedding_Favour_Feature2" --no-verify
After the above command, I issued the following to merge branches:
Git merge ‘develop’
Code was merged locally into the develop branch.
Use text field labels to access the text field element
This also contributes to Accessibility Testing as it’s asserting on the label’s element to validate its existence before execution. Firstly, I added the following statement to the support/commands.js file –
Here the getInputByLabel function takes in a text input variable. Then it checks any label element that contains any text contained in the text variable, then it stores it in the variable- $label. And check for the label attribute ‘for’ which may have a link to the text field or text area. Then it passes its contents to the const variable name. Then use an if statement to return the content of const variable name. If that does not work, then uses the cy.wrap to look and find any other elements such as ‘input’, ‘select’ or ‘text area’.
Structuring/Refactoring the code
- I applied structure into the script as follows-
- moving functions into new classes – applying reusability -code simplicity
- Make changes to environment login.
- change element reference using best practice – try and use ‘cy.contains’, where possible to encourage readability.
- use case switch for long if statements.
- Turn long if statements into switch statements -what condition to pass to switch and case. Turn long if condition statement which was causing errors into conditions such as – yes, no, null conditions in a switch statement.
- I was required to apply these structures into my coding for it to be accepted and merged into our master develop branch.
Encouraging others to Participate
When the Test Lead for Ecommerce joined the team, I encouraged her to begin learning cypress and join in the migration. Eventually, she began taking courses and when I returned from furlough, she was well into the migration. She mentioned at a meeting she appreciated me and others who encouraged her. I mentioned my appreciation for her contribution to e-commerce. Here I interacted positively with her. I was also setting reasonable expectations with her as it was expected for Quality Assurance testers to join in the Cypress migration project.
Details of Coding
Code
Below are some screenshots of some of the codes implemented –
Cypress Limitation.
Even though cypress is said to be an end-to-end automation testing tool, it does not allow integration testing where the test requires navigating through multiple domains. It allows subdomains but not super domains. According to cypress documentation, when we specify a URL for the Application under test (AUT), cypress specifies its host URL to match the application. It requires a single test to only navigate to on single super domain. Super domains can be visited in different tests. This means we cannot test the User Interface(UI) from the start of a user journey of finding, adding product to cart to checkout and payment page. The workaround is to use cy.request. To do this, I analysed data on the network tab of the Devtool and collected data from manual inputs.
Taking a closer look and analysing the data, I discovered that the data from the network tab was very complicated. I also know that directing to the payment page will not work so by researching I am adapting ideas and approaches as circumstances changes.
Here I have analysed the situation a realised the limitation of cypress. I have defined my goals to implement it by using cypress requests as a solution. Exploring it further on the Developer tool I realised how complicated it would be, so I prioritised my workload by leaving any payment integration feature to the end of my workload. Initially, I thought I would be ok to go ahead on implementing it, but it required some research and further analyse, the reason why I would implement this in the end, when I may have more time to dedicate. You can see I am dealing with the unexpected. I was expecting cypress to be an End-to-End testing framework and did not expect this limitation. I am also adapting ideas and approaches as condition changes.
Find part 2 here.
Comments
Post a Comment