A little delayed, Selenium 4.0 Alpha version is released which can be downloaded from Selenium official website for javascript. Let’s revisit the features which were announced in the Selenium conference and some of the improvements and additional features that are present in this version.

Why Selenium 4.0 is important

If you think that testing automation engineers are the only people in the world who should care about the major update of Selenium, you’re wrong.

Of course, Selenium has become the industry standard for implementing custom automated tests and is considered to be the first go-to solution for every web application that has grown out of an approach where manual testing could have solved the majority of the problems.

But what is often left out of the picture is that businesses that heavily rely on Selenium are not only the ones who have automation QA engineers on their team but also the ones who have integrated codeless automation testing tools based on Selenium.

Selenium-based codeless testing has become a real lifesaver for every business that realizes the importance of automation but doesn’t have in-house QA experts who would be able to implement it. Such tools not only make the deployment possible for anyone with the basic understanding of web browsers but also make it possible to run regression tests, do synthetic monitoring and load testing without any knowledge of the Selenium framework at all.

A perfect example of such codeless automation software is CloudQA. On top of Selenium, we’ve developed a tool that requires zero effort from the team, integrates with the third-party applications, makes building test cases easier than ever before, monitors your web page performance 24/7, and costs less than hiring a junior manual tester.

If you want to learn more about the benefits of Selenium-based codeless automation tools, get a free demo.

Selenium 4 major changes

Let's go through the major changes of Selenium 4.0 Alpha version-

W3C WebDriver Standardization

First of all, Selenium 4 WebDriver is completely W3C Standardized. The WebDriver API has grown to be relevant outside of Selenium and has been used in multiple tools for automation. For example, such mobile testing tools as Appium and iOS Driver heavily rely on it. The W3C standard will also encourage the compatibility across different software implementations of the WebDriver API.

Here’s how Selenium Grid communicates with the Driver executables in previous versions:

A test in Selenium 3.x communicates with the browser at the End node through the JSON wire protocol at the local end. This approach requires encoding and decoding of API.

With the updates we’re expecting to see in Selenium 4, the test will directly communicate without any encoding and decoding of API requests through the W3C Protocol. Although JAVA bindings will be backward compatible, the focus will remain more on the W3C Protocol. The JSON wire protocol will no longer be used.

There are multiple contributors to the W3C WebDriver specs, and the whole process can be seen on GitHub.

Selenium 4 IDE TNG

The Selenium IDE support for Chrome is available now. You can download it from- https://selenium.dev/selenium-ide/

As we all know that Selenium IDE is a record and playback tool. It will now be available with the following, much richer and advanced features:

• New plug-in system. Any browser vendor will now be able to easily plug into the new Selenium IDE. You’ll be able to have your own locator strategy and Selenium IDE plug-in.
• New CLI runner. It will be completely based on NodeJS, not the old HTML-based runner, and will have the following capabilities:
• WebDriver Playback. The new Selenium IDE runner will be based entirely on the WebDriver.
• Parallel execution. The new CLI runner will also support parallel test case execution and will provide useful information like time taken, and a number of test cases passed and failed.

Looking for the best Selenium IDE Alternative? Checkout CloudQA!

Improved Selenium Grid

Anyone who has ever worked with Selenium Grid knows how difficult it is to set up and configure. Selenium Grid supports test case execution on different browsers, operating systems, and machines providing parallel execution capability.

There are two main elements of the Selenium Grid: Hub and Node.

Hub acts as a server, a central point to control all the test machines in the network. In Selenium Grid there is only one hub that allocates the test execution to a particular node based on capability matches.

Node, in simple words, is a test machine where test cases actually run.

For more details on Selenium Grid, we suggest reading the complete official tutorial on Selenium Grid.

Until now, the setup process of the Selenium Grid has often caused testers difficulties with the connecting node to the hub.

In Selenium 4, the grid experience has become smooth and easy since there will no longer be any need to set up and start hubs and nodes separately. Once you start a Selenium server, the grid will act as both a hub and node.

Selenium provides three types of the grid-

1. Standalone Mode
2. Hub and Node
3. Fully Distributed

The new selenium server jar contains everything which is required to run a grid. It has all the dependencies. The new grid also comes with Docker Support. For now, the docker integration doesn’t make use of UNIX domain sockets, so ensure your docker daemon is listening on port 2375.

For more details, refer to- https://github.com/SeleniumHQ/selenium/wiki/Selenium-Grid-4

Better Observability

“Passive observability is the ability to do descriptive tracing.”  
– Simon Stewart

Observability, logging, and debugging is no more confined to DevOps now. As part of the upcoming release, the request tracing and logging with hooks will be improved to provide automation engineers a hold on debugging.

Refreshed Documentation

Documentation plays a key role in the success of any project. Selenium docs have not been updated since the release of Selenium 2.0. Meaning, that anyone trying to learn Selenium in the past several years, had to use the old tutorials.

So, naturally, the renewed and up-to-date documentation, which SeleniumHQ promises to deliver us along with the 4.0 version, has become one of the most anticipated Selenium updates within the testing automation community.

Improvements in Selenium 4.0 Alpha version-

ChromiumDriver and DevTools:

In Selenium 3, EdgeDriver and ChromeDriver have their own implementation inherited from RemoteWebDriver class. In Selenium 4 Chromedriver and EdgeDriver are inherited from ChromiumDriver. ChromiumDriver class has predefined methods to access the dev tools. Consider the below code snippet-

The above code creates a session to the given URL and executes javascript to print a message. DevTools is a class which has methods to get a handle on developer options.

DevTools can also be used for performance measurement and get page load time.

Better Window and Tab Management

Selenium 4 now has given the capability to work on two different windows at the same time. This is particularly useful when we want to navigate to a new window(or tab) and open a different URL there and perform some action.

newWindow() method opens a new window or tab based on the WindowType given in its parameter.

Relative Locators

In Selenium 4 alpha version we can also get locators relative to any other locator.

• toLeftOf(): Element located to the left of specified element.
• toRightOf(): Element located to the right of the specified element.
• above(): Element located above with respect to the specified element.
• below(): Element located below with respect to the specified element.
• near(): Element is at most 50 pixels far away from the specified element. The pixel value can be modified.

Full-Screen Snapshot

Now we can take the full page screenshots with getFullPageScreenshotAs() method in the Firefox. But instead of typecasting it to ‘TakesScreenshot’ interface, we need to typecast it to FirefoxDriver instance.

File src = ((FirefoxDriver) driver).getFullPageScreenshotAs(OutputType.FILE);

There might be some more interesting features and improvements, so go ahead and explore!

If there’s a failure in any of the subsystems, it can cause the entire application to crash.

So to make sure everything is working fine, we need to test the entire flow of an application from start to finish (or end-to-end).

E2E testing mainly serves two purposes:

1.        To test the entire application for major business components such as communicating with the other systems, interfaces, databases, networks, and other applications.

2.        To create a complete production-like scenario and test happy flow, so that we can simulate real-time settings and environment and avoid any application crash.

Why do we need End-to-End testing in Agile?

In each sprint, both the dev and test teams focus on a single service out of all the integrated services used in an application. But there are chances that they missed out on the sub-systems or services that could potentially break.

Therefore, the QA team must make sure that specific changes in a single service don’t affect the entire workflow.

How is E2E testing different from traditional testing?

Traditional testing comprises Unit, Integration, System, and UAT. But End-to-end testing is started after System testing.

Sometimes we get confused between System/Unit/Integration testing and end-to-end testing. But these are quite different.

Here’s a short example for some clarity — let’s assume we have an application with three subsystems:

• Search
• Order
• Payment

In the current sprint, requirement specification changes in the payment subsystem are: Adding new payment options should be visible to the customers.

So as per the requirement, System testing will take care of the functionality related only to the newly added payments option.

But end-to-end testing will have the scenarios starting from Search to Payment (with newly added payment option) with the Order confirmation.

The scope, complexity, and maintenance of E2E testing are higher than that of the Unit and Integration testings.

So while preparing test cases and automation scripts, it’s always better to first understand the application architecture with the complete happy flow so that it will be easy to define the coverage.

Who can perform E2E Testing?

E2E testing should be performed by someone who has in-depth knowledge of application and aware of the product architecture. So apart from QA, a business analyst, client, product owner or even technical manager are good candidates to perform E2E testing.

End-to-end Testing Methods:

Horizontal E2E testing

It works through every phase of business workflow and ensures that the functional requirement document maps with the developed application.

A horizontal end-to-end test verifies each and every workflow through individual applications from start to finish ensuring that each interrelated process works correctly. In general, this type of testing takes place at the end of the release cycle and in a stable environment setup. So with this approach, we can get more coverage on the functional part but it cannot be performed until all release changes are fully implemented.

Vertical E2E testing

This method refers to testing in layers, tests happen in sequential, hierarchical order. Vertical testing used to test each component separately and thoroughly, and it is more part of SDLC. The most common approach to performing this is BDD, TDD, and CI-CD.

The best way to achieve it by performing unit tests for each component and then perform testing on network infrastructure, API integration, and UI layers. So by using this we can get high coverage of testing for the core code. As it can be implemented in stages so easy to find defects respective to each stage.

Steps for End to End Testing Process

These are the steps essential to E2E testing:

Requirements Analysis: Analyze the requirement thoroughly and cover major business components in the E2E workflow.

Environment Set-Up: Set up a test environment keeping the production environment details in mind. Try to make it as similar to the production in terms of software and hardware requirements.

Sub-Systems: Make sure that all the sub-systems are part of E2E flow.

TestCase Design: Design test cases with maximum coverage and add test data to test common user scenarios. Focus on functionality of high priority, and design more elaborate test cases to verify it.

Execution: Execute the entire E2E test suite and then analyze the results. Never forget to run a suite in the proper sequence. If required, execute the E2E scenario in multiple browsers.

Maintain Order: Since E2E testing comprises the entire application, test cases are more complex than functional test cases. Each component of the system has to be tested, which increases failure percentage. Structure and sequence of execution are very crucial in E2E testing. Conduct unit tests and integration tests first to resolve the initial level of errors. Once end to end testing begins, simultaneously run the smoke and sanity tests with high-risk user scenarios.

How to make E2E testing in Agile more efficient:

• Try to automate the E2E test cases with maximum coverage.
• Keep the E2E automation suite separate from Smoke, Sanity, and BVT.
• Execute E2E suite before any sprint release to make sure that the happy flow of the application is working as expected and new changes don’t have any impact on the subsystems of the product.
• Integrate the E2E suite with CI/CD pipeline using any tool like Jenkins.
• As E2E suites take time to execute so create Jenkins job and schedule it at night so that all the failed test cases can be analyzed in the working hours.
• Every so often, E2E does contain some cross-browser and parallel testing too, so in that case, try to take advantage of Selenium Grid with Docker. Use Docker containers for different browsers and execute the test cases in parallel using TestNG.
• While running the E2E automation suite, it is required to create an environment similar to production and need to avoid any environment level issue, so to achieve this, you can use Docker containers.

E2E Test Deliverables

The E2E test team will create the following work products:

• Test cases with detailed steps for the E2E test suite.
• Enterprise test automation framework configured for the application.
• Automated test execution reports and defects encountered during the End-to-End test suite.
• The requirement traceability matrix will ensure that the entire requirement on the E2E workflow.
• Transactional test data generated during test execution.
• Documentation and manuals.
• Script coding and management standards.
• Script Development/Execution tracker.
• Functional Issue log tracker.
• Workflow diagram of the application.
• Ensure maximum coverage with data, process, and the logic behind the functional workflow.

Benefits of end-to-end testing:

Ensures stability and quality of product

Since the application is tested at different layers like data, business, integration, and presentation, it ensures the stability and quality of the application.

Increases Confidence on E2E Business workflow

End-to-end testing increases the confidence in the functional flow and performance before its release as the application is validated across all endpoints for different devices, browsers, platforms.

Frequent Testing Reduces Risks

As the application is tested in every iteration and sprints, it reduces the chances of any major bugs.

Reduces Repetitive Testing Efforts

End-to-end testing reduces the occurrences of frequent breakdowns and thus reduces repetitive testing efforts.

Costs Effective & Less Time

Implementing E2E testing reduces error recurrence in the later stage of product development, so fixing those issues during the early phase of the SDLC saves lots of budgets. As in E2E we make sure of the major business flows so by performing it we can avoid all major issues which can be a blockage for sprint release. Automation of the end-to-end test allows quickly adapt changing business requirements and enhance agility to the testing project.

Conclusion

The objective of end-to-end is to verify system integration with the functional flow. Thus, while testing any application, it is important to note that the user interface or presentation layer is not the only area to be focused but the underlying data, processes, and logic behind the application’s behavior need to be verified too. The connected systems and integrations are equally relevant to assure the quality of the application in terms of frontend, backend, functional flow, and integration. To know more, visit https://cloudqa.io/ or email us at info@cloudqa.io.

Bright-Interactive is award-winning, feature-rich, intelligent digital asset management software that makes managing brand media seamless, whatever the size of the organization.

Customer’s digital files are centrally stored and are secure, searchable, and easily accessible by anyone you choose – fast.

Challenges faced:

As any company Bright-Interactive ensuring the quality of the production the application remained high, i.e. as free from defects as possible. They primarily wanted to eliminate laborious manual testing of the application in staging before pushing code changes to production as manual testing was time-consuming Customers were noticing defects on production. While the team supported a variety of different test automation functions, they never had enough time to invest in automating the User Interface level testing. The team considered Selenium and experimented with it.

The Solution:

Bright-Interactive believes that everyone on the team should be able to write tests and own code quality. Bright-Interactive’s R&D team members analyzed different tools in the market and picked up CloudQA quickly, using it for frontend test automation coverage.

Bright-Interactive was able to create a UI regression suite that gave the team confidence knowing when developers have ‘broken’ existing functionality so they could fix it as soon as possible while allowing them to add, expand, and grow without investing a ton of resources into their UI test automation. The regression test suite is extremely valuable for the app development team as it serves as a safety net they can rely on when they make changes that break things.

Bright-Interactive is now working to leverage CloudQA to not only help with code-coverage but run various test cases in production, thus giving us an app-level production monitoring to mitigate production malfunctions, above & beyond code regressions.

The Results:

Bright-interactive’s team ran for quite some time by doing UI level testing manually. To keep up with customer demands meanwhile, without slowing down their daily releases.

Earlier Bright Interactive would occasionally have a regression at the UI level that forced the team to stop working and go back and fix the issues. Now the team can find the problems quickly and react to them faster, giving them more coverage without slowing down the development pace.

Now with CloudQA they can create tests at a faster pace and can be created by developers and non-developers. Now the quality of the product is maintained, increased in deployment velocity, and greater customer satisfaction. To know more, visit https://cloudqa.io/ or email us at info@cloudqa.io.

Before CloudQA

Teletrac Navman has distributed teams, working from countries in different time zones. So the coordination of teams is a must.

But using Coded UI for web test automation came with a lot of hassles:

• Coded UI, a deprecated UI-driven functional testing tool was deprecated in 2019.
• It was becoming outdated for the rapidly upgrading of web technologies.
• Moreover, Teletrac Navman couldn’t manage global operations using Coded UI due to a lack of collaboration features.
• Testing more than one region at the same time was an unsolved issue.
• Test automation with Coded UI was time-consuming and required a lot of scripting.
• Coded UI has good support for IE but performed inadequately for all other browsers.

Journey with CloudQA

Teletrac Navman was looking to move from Coded UI to Selenium for testing. But shifting to Selenium would have taken a lot of time and resources.

CloudQA came with everything they required. Teletrac Navman could work with:

• Selenium cloud, cross-browser testing, minimal test code dependencies, and an intuitive UI making automated tests maintenance simpler.
• Real-time coordination between global team members was established.
• Multiple users were able to generate test cases and test the application at the same time.
• The critical integrations with the TFS Application pipeline (Azure DevOps)  and Jenkins for auto-triggering of tests and deployment upon success.
• And integration with Apache Subversion (SVN).

Conclusion

Teletrac Navman teams could collaborate globally. Regression testing automation is much faster with great reliability.

With CloudQA, the team could set up a CI/CD pipeline in no time. Multiple environments setup made the life easy to maintain different variables for each environment. Hence re-use the same tests against the different environments as possible. The regression testing and release process was completely automated.

Teletrac Navman found CloudQA to be the best Coded UI alternative. To know more, visit https://cloudqa.io/ or email us at info@cloudqa.io.

With the advent of agile and continuous integration and deployment, continuous testing has become a requirement. There is no alternative to that. The emphasis on shorter release cycles to give the product an edge in the competitive market is crucial.
In the faster release cycles, maintaining the quality of delivery is a real challenge.

Case in point:

Let’s assume you build an accounts screen for a highly secured banking app. Now some of the users might be using Chrome to access the application, some might use Internet Explorer, some might use mobile apps, etc. Now in the mobile app also, some users may have an Android phone and some may have iOS. So while deploying the code on production, developers and testers have to make sure that the feature is compatible with all different OS, browsers, platforms.

In the traditional approach, the developer has to handle the environment-specific compatibility before each deployment. Containers save us from such dependencies. Containers provide a logical packaging in which applications can be abstracted from the environment. It doesn’t matter where it is going to run in a private data center, a public cloud, or a personal laptop. A container is a collection of code, environment configurations, dependencies all bundled together with an execution engine on a virtual machine.

A containerized test environment is often configured as close to production as possible. It gives a safe way to test a scenario in real-world like conditions before it actually goes to the real world. With the containers, you can get a well-maintained test environment without the implications of the development process. Test engineers can spin up the services and dependencies on their own test machines which would be available on production and run their automation suit.
So containers are here to make our lives easy.

An example of a container-based setup with Docker

Docker provides an API to operate containers in the state of resource isolation called Namespace. It does not launch the OS and thus makes it quite lightweight. For common test scenarios, 10 or more instances can run on a single server simultaneously. Clearly it is more efficient and gives enormous coverage for automation testing.

• Containers provide consistency in the environment. The tests are highly repeatable without the worry about environmental factors and dependencies.
• Another advantage of containers is that the dependencies and configurations are established once and can be used throughout the SDLC for continuous testing.
• Supports versioning. Rollback to the previous version is easy.
• Well managed test suits that are handy to set up and execute.

Let’s take an example of Selenium Grid. A Selenium Grid is used to configure the distributed execution of automation tests. It consists of a hub and many nodes. Each node can have a different execution environment and can be considered as a virtual machine. To set up a grid, we need to download the selenium server jar file and run it on each and every machine where we want to set up the grid. Docker solves this time-consuming task. To setup docker based Selenium Grid, we should follow these steps-

• Download the Docker toolbox for Windows/ Linux machine and install it.
• Install Docker image for Selenium Hub and for each of the nodes which we want to configure. The Docker images are available on Docker’s official website- https://hub.docker.com/
• Start selenium hub from the docker container.
• Start selenium nodes. Note that for cross-browser testing different nodes will have different browsers.
• Start test case execution.

The advantage of this approach is that once set up, it proves to be very efficient in case test cases need to be run on different operating systems and on multiple browsers. In those cases, we can set up Selenium Grid with Docker.

Orchestration: One step ahead of containerization

Automating the containers, how about this idea? So here comes Kubernetes which automates containers. This process is called Orchestration.
Let’s understand first, what Kubernetes is, and how it works.

Kubernetes

Kubernetes oversees the containers and balances the load among all the containers. In essence, Kubernetes automates the containers, managing the load among them by strategically distributing it. While running, if a container is down due to heavy load, Kubernetes manages by distributing the load to other containers.

Each instance in Kubernetes is known as Kuberlet. As we all know that without containers, we would need physical devices. Containers eliminate physical devices by eliminating device drivers and making it a candidate for cloud-based deployment. In this way, the entire application can be tested in cloud-based virtualized containers eliminating the physical devices which would be needed otherwise. This reduces the cost and also makes the process seamless.

Let’s have a look at Kubernetes architecture for a typical application-

The containers are called as ‘Pod’ in Kubernetes terms. So a single Kubernetes node can have multiple containers. As we know that development, testing, and deployment are integrated, it is essential to be ready to adopt that in testing as well. Lets us examine the advantages of using containers and Kubernetes clusters in automation testing-

1. Fast- We can deploy selenium containers as and when required.
2. Short-Lived- Selenium containers are destroyed once the test ends.

Conclusion

Moving from traditional automation solutions to a fully automated and lightweight solution using containers and kubernetes can be really efficient if there are a large number of test cases. Also, it makes room for integrating it with the DevOps pipeline and moving testing to shift left.
So this can be proved to be a well thought off approach for enabling continuous testing in an agile environment. To know more, visit https://cloudqa.io/ or email us at info@cloudqa.io.

If your test library is large, it is important that you find out if the individual test scenarios are properly organized, critical to the core application, and relevant to the latest application version or to the usage pattern.

1. Test Organization: Your application tests may involve testing various functional capabilities of an application. How do you determine which tests to run after you have made updates to just one section of your application (for example, your “billing” functionality has been updated)? You may not want to run all your test scenarios (unless doing regression tests) in order to test a small update. Your test framework should allow you to categorize your tests by functional areas so that you can quickly filter out everything else and run only those tests that belong to a specific function.

2. Test Criticality: Ideally you would create tests that cover both the critical and non-critical areas of your application. Your testing framework should provide an efficient way to manage bugs and failures. You should be able to categorize your test upfront by criticality (Critical, High, Medium, or Low) so as to prioritize the testing as well as the resolution based on the criticality of the test.

3. Test Relevance: In most environments, software development and testing is a continuous process and over time you can have a large number of tests. Unfortunately, as software evolves (with new or updated features, changed processes, etc.) some of the tests become redundant or duplicate. It can be challenging managing test library to ensure that only quality test cases exist, especially if your testing framework does not allow for easy review of the individual test cases/scenarios. You should be able to log and keep a track of the entire test creation life cycle (including updates). For instance, you should be able to track the test creation date, the module/release version for which the test was created, the test case revision history along with the name of individuals who authored the tests. This would make a periodic review of test cases to identify redundant scenarios much easier and keep your test library lean and clean. It will ensure a test environment that provides high-quality test results that you can rely on to make decisions. You do not want to rely on the results from redundant tests by ignoring “passed” results or waste your time by acting on “failed” results that they produce.

4. Test Usage: If there are test scenarios exceeding 2 months sitting in your library, there is a possibility that they are just taking up space and may not be required anymore. It is vital that your testing framework should be able to identify such test scenarios so that you can make apt decisions, either to re-prioritize or re-categorize them for efficient usage or get rid of them.

By maintaining your test libraries through regular checks, you will certainly have a manageable test environment that produces reliable results on which you can make assertions and also ensure a faster and better software development process.

CloudQA and Effective Test Management

CloudQA is much more than just a Test Automation tool. It has some helpful features that make test management much simpler.

Test Organization: You have the ability to tag your test cases and test scenarios by functional groups or any other preferred method.

Test Criticality: Tag your test cases/test scenarios as Critical, High, Medium or Low.

Test Usage & their Relevance: CloudQA keeps a record of the run history of all your test cases. You can view the history in many ways – for example – show the behavior of “Critical” Test Scenarios in “Billing” function over the last 4 weeks OR show the “Critical” test scenarios that have not been run in the last 2 months OR look at the revision history or a particular test.

To know more, visit https://cloudqa.io/ or email us at info@cloudqa.io.

E-commerce, in its initial days, was just a complementary medium. But due to its broad reach and open marketplace, it boomed in no time. In the last decade, e-commerce has evolved as a medium not only for e-trade but also for e-banking, e-wallets, and diverse form of e-marketing. Now to attract customers and retain their loyalty, companies need to focus on each of their customers and provide them with a smooth user experience.

UX (User Experience) is the process of creating a meaningful and relevant experience to the users for selling products and services.

Companies nowadays do a lot of analysis and experiments to ensure that the user gets what they want in minimum time spent on the website/App. As e-commerce is growing, the competition in e-marketplace is also increasing. Nowadays, UX has become the crux of successful e-commerce websites/apps.

The early birdies like me, who have started using online ticket booking, net banking, shopping, and other things in its initial days, would certainly know the difference between then and now. So much has been done to improve the user experience. If we study the e-commerce websites, we will get to know the keys where the focus has been shifted to improve UX. Some of which are mentioned below-

Keys to improving UX

1. Efficient Search- The essential requirement for e-commerce to be successful is how efficiently it can search for the given product. Search should be fast, relevant, and should show other related products if there is no result for the searched item. It should be optimized in such a way that the user drop rate is minimum to zero.
2. Social Feedbacks and customer Reviews- Consider a situation where you have to buy a good cell phone. Most of us would ask reviews of different cell phones from our friends and other sources. This is the most significant factor in decision making. E-commerce companies have studied this factor and are provide social proofs to support the user in decision making. Amazon, Flipkart, and many other websites provide customer reviews for each of their products
3. Personalization- Websites now use a lot of historical data to analyze what the customer is looking for. Many websites provide “recommended products” to help customers choose wisely. In the backend there is a lot of data analysis done to give the user the choices, they are looking for.
   Many of you would have noticed that when we search something on a particular e-commerce website/app and then close it without buying anything, the next time you browse that website, it shows products related to the previous search. This is personalization. To remember its customer’s choices and use that for optimizing user experience is personalization.
4. Guidance- This is a recent development in UX. Most of the e-commerce websites/apps are now guiding the customers based on their requirements. Customers have to give answers to some simple questions and companies provide results based on that. Consider an example of Myntra.com, which is an online apparel selling website. It gives style suggestions to the customers for the product they are looking in.
5. Trending- In almost all the e-commerce websites/apps, we can see the trending section where the most popular products are listed. Customers can easily go through the recent trends and make a decision.
6. Upsell and cross-sell- Upsell is the practice of encouraging customers to buy a high-end product than the one which they are looking for. Cross-sell is a practice to invite customers to related or complementary products.
   For e.g.,- If you are buying a mobile phone, the websites show you the phone covers and other related accessories before checkout. This is cross-selling. While upsell is when you are purchasing an old school phone and websites show you the latest smartphones.
7. Categorization- One of the crucial aspects of selling products online is to categorize them right so that it will be easy for customers to find the products. It saves time and also provides a listing of products of the same categories to compare.
8. Customer feedback- Customer feedback gives insight for the improvement of product and overall business. Almost every website gives its customers a feedback form after their purchase. This would give them insights about customer experience.
   Customers who have a positive experience are more likely to become repeat customers and it also builds trust between the customer and the company.
9. Trust and transparency- Trust is the most critical factor to build a loyal customer base for any business. Trust can be achieved through transparency. A business should be transparent in their offerings. This holds good for the entire supply chain. E-commerce success highly depends on the trust between partners and keeps the whole network to be responsible, which eventually reduces business risk. Transparency leads to integrity, loyalty, and sustainability.
10. Engage re-engage and awards- Engagement of customers is as important as building the customer base. E-commerce websites offer many reward points for purchases as well as many loyalty programs. For e.g.,- Uber, which is an online cab booking company, offers credits to its customers for referring their app to other customers. Re-engage in the re-targeting of customers by showing them products of their interest. Customer engagement, re-engagement can be achieved in various ways-

• Offer loyalty programs to customers through rewards.      
• Immediately Engage unhappy customers by resolving their issues. Sometimes business follows the strategy of instant gratification to avoid any possible customer drop.        
• Use all the social mediums to interact directly with the customers. For e.g.,-Nowadays the majority of e-commerce businesses have their twitter handles open to accept customer’s feedback and resolving their conflicts.
• Keeping track of important days of each of their customers like anniversaries, birthdays, and other special days. This kind of personalization is fantastic for customer engagement as it gives them a vibe of being treated individually.

Apart from the strategies mentioned above, e-commerce companies are now focusing more on easy to use interface and information processing. A very fundamental thing is to take customers through the entire flow in minimum clicks. They should get what they want in the minimum amount of time. Few notable points are-

1. Usability - defines how easy the customer’s journey is without any unnecessary clicks and flows, time lost in page load, etc
2. Intuitive Navigation - The success of an e-commerce website depends upon how well the company can provide the relevant information, brand image to the users at each step. They should know at each page how to go back, forward, the home page, main menu, etc.
3. Presentation - Presentation of items should be effective. It should have clear images, product descriptions, customer reviews, etc. Check out the presentation of the famous jewelry selling app. It has clear information with an attractive presentation.
4. Accessibility - This is to take care of different categories of customers like customers with disabilities or with low literacy.

In a nutshell, e-commerce is a lot more than only selling and buying products and services. It is the overall customer’s experience and journey with the business. To know more or for further inquiries, email us at info@cloudqa.io or visit us at https://cloudqa.io/.

Whatsoever, there is no doubt that unit testing is a crucial part of SDLC and the first step towards testing.

Here I am going to discuss more the unit testing standards which we can leverage in our testing and automation to make it more effective and efficient.

What is unit testing?

Unit testing is a type of testing which is performed to ensure that individual units or components of the application are working as expected. The units or components, in this case, are independently tested using stubs and drivers. Unit testing is crucial as it finds out defects at an early stage and thus reducing the overall project cost and ensuring the code stability.

As a tester, It is also our responsibility to make sure that unit tests are part of our deployment pipeline. As the role of QA has evolved in the last few years, they not only perform functional and integration testing but also actively participating in unit testing. In continuous integration and delivery, the role of QA has become multidimensional and more agile. It’s important to know what unit tests are executed as a part of the release and what is the coverage. I am not going to discuss the importance of unit testing here, I believe that’s pretty clear to everyone.

This article is about how unit test cases are designed and how we can leverage that in our automation test design.

Understanding the concept of unit testing

It’s important to understand the core concept of unit testing. A unit is any entity that can be executed independently. It can be a few lines of code or an entire feature for that matter. The bottom line is it should be an independent executable piece of code. Here is the first take away.

While designing out automation framework, we should also treat our tests as a single independent unit so that they can be tested and executed independently.

Unit testing involves unit test frameworks, drivers, stubs, and mocks /fake objects. It works on the basis of a white box technique where conditions, loops, and code coverage are tested.

Below are some unit testing principles which equally hold good for automation testing, let’s revisit them-

• Tests should be independent – This is the basic principle, there should not be any dependency among the test cases. This is important because one test case result should not impact subsequent cases.
  In automation, we should make sure that there is no dependency such as environment setting, creating instances of shared resources, and cleaning up the same.
• Tests should be deterministic – A test should either pass or fail all the time. The worst test is the one that passes some of the time. We should always have a definite reason if the test fails and when correcting that, the test should always pass.
• Tests should hold good for pass/fail cases – By this, I mean that a test should fail when it meant to fail. Put assertions carefully and run the test for a fail condition also.
• Tests should be self-validating – This means that the test should itself determine that the output is expected or not. There should not be any manual interpretation.
• Repeatable – Test should produce the same output every time it runs. This can be accomplished by making them isolated and independent.

How unit testing is performed

Unit testing requires Mocking. It works on mock objects that fill the missing part of functions to be tested. As the other components are still in development or yet to develop, we would need some piece of code to ‘act’ like those components.

Another crucial component of unit testing is APIs. APIs provide an interface for communication between two components. APIs contain business logic and the way APIs work makes it very handy to use them in unit testing.

Both mocking and API go hand in hand to perform unit testing.

How test automation leverages from unit testing

With more and more organizations going into the agile model, testing (both manual and automation) starts in the initial phase of SDLC. To expedite the process automation has a key role to play. Now we know that in agile requirements keep on changing, development is still in progress, and in that situation, API and mocking can be very helpful for automation.

Use of Mock objects – Data mocking can be used to speed up the process rather than depending on the real test data. When the automation test interacts with an object’s properties rather than its functions and behaviors, mocking can be used. Mocking is mostly required when an application interacts with any external service but it can be used in other scenarios also.

A mock object can be used when the real object is:

1. Slow in operation, for eg- Database access
2. Hard to trigger for eg- A server crash scenario or a network error.
3. Still in development.
4. Not compatible or needs high-cost setup for testing environment.

There are various libraries available for Mocking. Some mocking frameworks are – Mockito, powermock, and easymock for mocking.

Use of APIs – let’s come straight to the point, APIs are faster. Also, API tests are reliable. UI tests can be flaky and slow to execute but API tests will either pass or fail. Of course, we need UI tests but its always a good idea, to begin with, API testing. APIs are developed before UI in most cases so we can always kick start with API testing.

APIs are also useful while writing integration tests and an end to end testing. We can always integrate APIs in the UI test framework to perform pre-requisite. APIs make them faster and thus reduce overall test suit execution time making it more efficient for releases.

To know more about API testing, you can refer to-

https://cloudqa.io/api-testing-and-automation-101-the-essential-guide

Conclusion – Almost all unit testing principles and techniques are relevant to the automation and automation engineers should leverage them as and when needed rather than only relying on the traditional automation methods. To know more, visit https://cloudqa.io/ or email us at info@cloudqa.io.

So here’s the million-dollar question: Whether Cypress is better than or a substitute for the most preferred web automation tool – Selenium?

This article will do an in-depth comparison to show how both tools serve the purpose of automation testing and which tool has the upper hand in different circumstances.

Let’s look at a few points that will help you make the call:

In a Nutshell

Cypress (latest release 4.11.0) is a next-generation front-end testing tool built for the web. It is a JavaScript-based end-to-end testing framework built on top of Mocha and Chai.

Selenium (latest release 4.0.0 Alpha 5) is an open-source tool used for automating the tests on web browsers. The Selenium WebDriver drives a browser natively; either locally or on remote machines and it is used for UI automation testing. Similarly, all the other components have a specific role to perform in terms of making the product more reliable and robust.

How it Works

Cypress executes in the same run loop as application. Behind Cypress is a Node.js server process. Cypress and the Node.js process constantly communicate, synchronize, and perform tasks for each other. Cypress also operates at the network layer by reading and altering web traffic during processing. This enables Cypress to not only modify everything that emerges from the browser but also to change code that may interfere with its ability to automate the browser.

In Selenium, once we run the automation script in Selenium then the Selenium client library will communicate with Selenium API that will send the command taken from language level binding to browser driver with the help of JSON wire protocol. The browser driver will use the HTTP server for getting the HTTP request and the HTTP Server filter out all the commands that require execution. After that, the commands in your Selenium script executes on the browser and HTTP server sends the response back to the automation test script.

Based on their internal working architecture, we can say that Selenium executes remote commands through the network whereas Cypress runs in the same run-loop as your application.

Installation

In Cypress there’s no configuration, just need to install the .exe and all the drivers and dependencies get automatically installed and configured. This allows automation to be set up to get running in minutes. One of the design principles of Cypress was to be able to package and bundle everything together to make the entire end-to-end testing experience pleasant and simple for developers.

To use Selenium in your automation project you need to install the language binding’s libraries for your language of choice. Besides, you will need WebDriver binaries for the browsers you want to automate and run tests on.

So if we take installation time and complexity into consideration then Cypress has the upper hand as compared to Selenium.

Languages Supported

Cypress only supports JavaScript. No other languages support provided, which sometimes forces the user to learn a particular scripting language.

On the other hand, Selenium supports wide range language: Java, C#, Python, Ruby, R, Dart, Objective-C, Haskell, PHP, and JavaScript.

Due to the support of many languages, Selenium comes handy and gives users the privilege to decide the language they want to use to develop an automation framework.

Cross-browser Support

Cypress supports Canary, Chrome, Chromium, Edge, Edge Beta, Edge Canary, Edge Dev, Electron, Firefox (Beta support), Firefox Developer Edition (Beta support), Firefox Nightly (Beta support).

Selenium supports almost all major browsers in the market, which is an added advantage for Selenium. Below is the list of supported browsers:
Chrome(All versions), Firefox(54 and newer), Internet Explorer(6 and newer), Opera(10.5 and newer), Safari(10 and newer)

Selenium has better cross-browser support as compared to Cypress because Selenium gives support to almost all available browsers available in the market whereas Cypress you can’t test on Safari.

Parallel Execution of Test Automation Suite

Cypress falls behind when compared to Selenium in parallel testing.

Selenium has many options to perform parallel execution which is quite important for automation testing. Selenium component Grid is used widely for parallel execution in the QA community with TestNG. And it can be easily integrated with Docker containerization.

Performance

Cypress doesn’t have as many layers of architecture as Selenium. It operates on the same process in the browser. That is why we see a remarkable improvement in the pace of test execution compared to Selenium.

Selenium is relatively slow compared to Cypress as it has several layers of code running between the test and the browser.

Integration of Automation with CI/CD

Cypress: Possible but with restrictions. Only one option is available and that is by using the command line and the npm library – Mocha. The CI service has to support npm and test recording on the CI server is a paid option for most of the recordings.

Selenium: Possible to perform integration of CI/CD. We can use any testing library, test reports, and execution patterns and can easily adjust it to the needs.

Licensing

Cypress is also released as open-source under the MIT license. But if we compare it to Selenium then all the features provided by Cypress are not free, e.g. the dashboard in Cypress is free for Seed but paid for Sprout, Tree, and Forest. ( https://www.cypress.io/pricing)

Selenium is licensed under the Apache 2.0 license, with the Software Freedom Conservancy as the copyright holder

OS Support

Cypress: Windows, Mac, Linux

Selenium: Windows, Linux, Mac, Android, iOS

BDD and DataDrivenTesting Support

Selenium supports BDD and data-driven by using external libraries, but as of now which is quite not possible to do in Cypress.

Locators for Object Identification

Cypress supports only CSS and Xpath.

Support all types of locators for a normal web application like ID, Name, XPath, CSS selectors, link text, partial link text, etc.

Execution Report

Selenium: Allure, Extent, and all other dashboards can be integrated into automation suites.

Cypress: Only Cypress Native Dashboard.

The Verdict

Selenium targets more towards the test automation engineer while Cypress is more developer-centric and aims to improve TDD development.

Selenium was developed in 2004 so it has better community support then Cypress which was developed in 2015 and still in the growing phase. In-fact when we work with the browser using Selenium it is possible to manipulate many options like Cookie, Local Storage, Screen, Sizes, Extensions, Command-line options but Cypress can only help to manipulate Network options.

However, some of the selling points, which Cypress claims, are:

• It can take snapshots of the application when the tests are running. Then as a test developer, we can hover over each command in the Test Runner panel to see what happened at each step.
• With Cypress, there is no need to put explicit waits or sleeps to your tests. It automatically waits for commands and assertions before proceeding.
• Similar to unit test cases, you can verify and control the behavior of functions, server responses, or timers at run time using the spies and stubs provided by Cypress. Using Cypress, you can stub network traffic as you like and customize the response of your API calls as per your need.

Hope the above points will help to decide which tool to use for automation testing and on that note keep exploring. If you have any questions or suggestions email us at info@cloudqa.io or visit the Cloud QA website.

We often come across such a statement.

I was working with a startup offering travel services. They never had a QA process before I joined, and they wanted me to set up one soon.

While talking to the CTO, I learned that the application was growing as fast as the massive user base. So app crashes were becoming costlier by the day.

We focused on setting up a QA process and started improving the product quality within weeks. Having said that, the QA didn’t receive a fair budget. As a result, testing always struggled to keep pace with accelerating app developments.

Does this sound familiar?

The demand for shopping is 24*7. But how would you know if something went wrong while users are shopping? For example – during late hours, there is an increase in the traffic, at such point if users experience a delay in loading or encounter a 404 error, it will impact your sales and customers’ trust. Ecommerce monitoring can assist in such a situation by continuously monitoring the performance and alerts the team for technical glitches. It constantly helps in preventing a bad shopping experience.

According to the World Quality report 2019-20, only 23% of IT budget is allocated to QA. It was a decreasing trend since 2015 when it used to be 35%. The report also highlights the major contributing factors responsible for the trend. It includes Cloud computing, the increasing adoption of agile and DevOps approaches, integration of development and testing, and resolution of defects much sooner in the SDLC.

Often, it’s true that with a growing business, managers tend to invest in product and development while QA is left behind. Few organizations realize the need for QA and are ready to invest.

But how do you set up a QA process when your organization doesn’t have enough experience or budget?

Let’s discuss how to establish a QA process along with agile and DevOps approaches and the recent changes in the overall development process.

1.        Setting up Ownership- To start with, you must identify someone who can own the QA process. The size of the team does not matter. It can be a single person team or more than that. Even if you outsource QA, there must be someone to strategize and prioritize the overall software testing.

2.        “Prioritization of QA in SDLC- QA must be prioritized. It would help if you ensured that tasks that can be tested depending on the bandwidth of the QA team should only be included in the release cycle.

3.        Integration and alignment of QA- Integration of the whole QA cycle, its estimates, and deliverables should be accounted for. In agile, the QA cycle starts with development itself, so it must provide QA all the product documentation and involve in the ticket grooming activities.

4.        Automate what can be automated- Automation cannot be an afterthought. Test automation reduces effort and time, eventually increasing productivity. It doesn’t necessarily mean creating a complicated framework, but also small scripts which can reduce the efforts. There are many tools available to help you with test automation without having to hire a test automation expert or spending a lot of time in scripting tests.

5.        Reporting and bug researching- Every bug should be reported and documented. There are many tools available to record a bug and provide many analytical features to provide valuable insights. Bug researching offers a quick reference to the nature of the application and where it frequently breaks.

6.        Tools, documentation, and more- Use the tools wherever possible. It saves time significantly and also provides handy documentation. QA should be inquisitive enough to search for new tools and technology. Documentation is crucial as it is almost impossible to remember n no. of scenarios, x no. of bugs and their resolutions.

Best Practices for setting up QA processes

Though this might differ in organizations, there are few practices to consider:

1.        Drive testing through the user interface- By this, I mean looking at the application through the end-users eyes. You might use various tools, automate regression tests, perform API testing, DB testing, code reviews, etc., but do not overlook UI.

2.        Keep the test environment separate- It is always good to keep an independent test environment similar to production. Do not ever test on the development environment as it is highly compromised.

3.        Integrate automation tests into the pipeline- Integrate the unit and integration tests in the delivery pipeline to save time. If you are still far away from creating a pipeline, try to make it as a goal.

4.        Continuous Testing- Continuous testing ensures agility and reduces the cost to fix bugs. According to the World Quality report 2019-20, a bug caught in production costs 70% more than the one found in the early stage.

In conclusion, investing in QA and setting up a QA team would always provide a good ROI and also helps in building the right image of the product by enhancing quality.

To discuss further or to know more, visit us at Cloud QA or email at info@cloudqa.io