Intro [5 mins]

Writing faster cases [15 mins]

Ideal test case characteristics and examples of implementing them (sample content shared in the end):

1. Repeatability

2. Reusability

3. Accuracy

4. Traceability

5. Atomicity

How to determine cases which need refactoring:
Here I will talk about Open Source tools which you can use to identify cases which take longer than normal to run.

How to use locators smartly

I will present a statistical comparison of using locators by ID, name, and CSS. We’ll compare the speed of each one of them and see which is the best option.

Faster test execution [15 mins]

Using product APIs’ smartly

The right set of exposed APIs and can make functional test cases lighter. Here, I will talk about how product APIs can help with the right user states and allowing to run UI tests much faster.

For example, if I have tested the UI for a particular flow till the checkout page for a specific payment method, I do not need to test it again. I can use the right APIs to replicate the checkout state with the product and sign-in state. The only part that the test will run for is the new payment method that I want to test.

Using the right Selenium waits

I’ll talk about the different types of waits and how to use them in the right places. I’ll also show some open source tools you can use to configure these properly.

Parallel test execution

Here I’ll talk about how one can increase parallelization in their test cases. Furthermore, I’ll discuss how one can control Jenkins jobs better by configuring the master and slaves.

Queueing

Finally, I’ll also talk a little bit about how you can utilize queuing smartly by separating queues for your flaky tests vs normal test cases.

Conclusion [5 mins]

---------------------------------------------------------------------------------------------------

{Sample content for atomicity - this will give you an idea of the sort of examples I will present in the talk}

Atomicity in test cases: Test cases should ideally test a single functionality. This helps to pinpoint the exact failures, keeps the test cases fast and small. It also reduces flakiness and maintenance.

Example

Consider a flow when user purchases a product from any shopping website. If such a test were to be done manually, the steps involved would be as follows:    


    Sign-in/Sign-up

    Search the Product

    Add to Cart

    Enter card details and purchase



The above scenario can be split into smaller (atomic) tests as below:

1. Test "SignUp" / Test "SignIn"

2. Test "Search"

3. Test "Add to Cart"

4. Test "Purchase"



To test purchase scenarios only, one can simulate users' state. Thus, if there is an issue with signup functionality, it won’t affect the execution of other functionalities.