What's in my Bag? EDC of a Tester

 

Responsibilities of a Tester working for a Startup

 

An Introduction to mind maps for testers

Why?

• Similar to identifying test conditions and done as part of the test analysis activity.
• Better medium to convey the test scope to other stakeholders than written test conditions.
• As relationships between branches and a complete picture can be seen, it can be a better guide than test conditions when test design is done.

How?

• Think in terms of categories, where supersets should be closely related than subsets.
• Think in terms of use case actors.
• Think in terms of quality characteristics
• Think in terms of architecture
• In terms of success and failure interactions.
• In terms of design techniques
• Classification tree
• Write in short form
• Level of detail should be decided on project requirements and constraints. If you have broken it down to the level of high-level test cases you have gone too far.

Multi Tab Support in Selenium Web Driver

Selenium Web Driver is capable of handling multiple browser tabs. Though the requirement to automate workflows that span multiple tabs is one that automation engineers don’t come across all the time, it’s always good to know how it can be done. 

Selenium Custom Locators

Selenium Web Driver supports both Xpath and CSS Locators as element locator strategies. As these strategies are comprehensive ideally there is no need to provide other abstract strategies such as ID and Class, but providing such strategies OOTB the designers of Selenium have lowered the entry barrier to automation using their library. So as framework developers you can take this further and provide other custom locator strategies to the users. The snippet below shows how a custom by class can be made to wrap around the XPath contains function.

A Comparison of Network Interception capabilities between Cypress and Selenium

Both Selenium and Cypress provide network interception capabilities. As the name implies, the capability allows the user to intercept HTTP requests and manipulate the response received for the given response. This is useful when you want to automate UI scenarios where the preconditions and steps required for the expected output can’t be easily produced.

To evaluate this capability I went about automating the 3 scenarios found below,

• Intercepting and waiting for a network resource attached to a web page to be received to the client side.
• Intercepting and simulating 400 and 500 errors.
• Intercepting and changing response payloads.

I found that Cypress provides HTTP level interception while Selenium simulates interception through the Web Driver client. And that interception in general is easier in Cypress. Selenium provides better control over response status code manipulation, but surprisingly selenium doesn’t provide a way to access the HTTP response codes through its client so asserting status code related scenarios may be more troublesome.

Cypress Examples

Selenium Examples

Abstracting the Test Layer using TestNG

The library architecture is popular among test automation framework designers. To follow this pattern, engineers decompose and abstract the automation logic at various conceptual levels, such as at the page, the component or at the element level. But usually, the test layer is left out of these decomposition efforts.

Leaving abstraction out of the test layer can in time lead to duplication of the logic as well as having to spend more time than what is required to script new scenarios. This post will discuss how the test layer can be abstracted and decomposed using TestNG.

High-level Steps

1. Start with designing and implementing test cases so that they are atomic
2. Encapsulate the test layer by scripting the test steps and adding assertions required to validate the component. Then put a mechanism in place to read the test data from an object that can be passed from one test class to another as required.
3. Finally, use the Factory feature in TestNG to compose the larger scripts using the test classes.

Let’s take a crude example of validating a web page with a dropdown[1]. For this example, I have identified the two test cases seen below,

1. Validate that the dropdown page loads the dropdown and that the values are as expected.
2. Validate that the dropdown allows the user to select the option he wants to select.

The test layers for the two test cases were scripted as seen below and were joined together using the factory annotation in the DropDrownTest class. Notice how the same test data object is passed between the two test cases.

Test Class 1

Test Class 2

Factory Class

[1] - https://the-internet.herokuapp.com/dropdown

[repo] - https://github.com/handakumbura/SeleniumAutomationEmployerProfile/tree/feature/atomic_test_cases