Explore topic-wise InterviewSolutions in Current Affairs.

Martin Fowler first proposed the concept of the test automation pyramid[1] in 2012. It’s a technique to think about how you should use different types of test automation to get the maximum value out of them. 
The main idea behind the test pyramid is to have many unit tests and a few broad tests for the GUI.

GUI testing is very BRITTLE. User interfaces are constantly changing. An enhancement to the software easily breaks up many tests, which need to be updated, causing ADDITIONAL work for the team. Testing the UI is slow and results in increased build times. You can perform it on a few machines on which you have the license for the GUI testing tool.

Hence, the test pyramid ARGUES that you should have more AUTOMATED unit tests than through the traditional UI-automation tests. It also has an intermediate layer of service tests that can provide many benefits of end-to-end UI tests without the complexities of dealing with the UI FRAMEWORKS.

Here are some of the best practices a software development and the testing team should use to ensure quality software.

• Decide what to automate
  • It’s not possible or practical to automate certain tests, such as usability, accessibility, exploratory testing, or non-repetitive test cases that frequently change. 
• Assign test cases based on skill and experience
  • When dividing test cases, TAKE into account the skills and experience of the tester and the complexity and severity of the feature under test. 
• Removing Uncertainty
  • The whole goal of test automation is to have reliable, accurate, consistent tests that PROVIDE helpful feedback to the tester. If the tests fail due to bugs in the test itself, or it’s giving false positives, then the ROI on test automation starts decreasing. 
• Choosing the right FRAMEWORKS and tools
  • There are a lot of tools to perform automation testing. Picking the wrong tool for the test at hand will waste TIME and provide false confidence to release software that may fail in production. 
• Keeping test records in a bug database
  • Using a bug database is a best PRACTICE whether a team uses test automation or not. 
  • Whenever new bugs are found by the automation tool or by the testers, they should be recorded in a bug tracking tool with the exact steps to reproduce the bugs and other details.

Software is never done. The developers are constantly adding new features, functions, fixing bugs, and so on. There is a chance that all this new code might break the existing functionality that was working.

Users DISLIKE using a product that is broken after they DOWNLOAD and INSTALL a new release. They expect a CONSISTENT and reliable experience from the software, no matter which version they are using. They also expect that previously working features will keep on working and won't break in the future.

Regression testing is a testing technique where a tester makes sure that the new features didn't break any existing functionality. Its goal is to ensure that previously developed and tested functionality still works after adding new code. When a tester performs the regression testing automatically using testing frameworks and TOOLS, it's known as automated regression testing.

In automated regression testing, a tester runs the suite of regression tests after each new release of the software. If the tests pass, then the tester continues with other types of testing. However, if it fails, then there is no point in further proceeding with tests until the developers fix the broken regression tests. Hence, they also act as a time-saver for the tester and ensure quality in software before shipping it.

With web applications, you can’t GUARANTEE the browsers/platforms/devices your users might use to access your software. Some users could be using Google Chrome on their ANDROID phones, some might use Firefox on a Windows desktop machine, or others could use Safari on their Macbooks.

Cross-browser testing ensures that your web application works as expected on different versions of popular browsers on multiple platforms and devices. It ensures that the users get the same experience and features irrespective of which browser they use. It helps to reach a wide range of users, allows the users to switch browsers and devices, and STILL get the same user experience, increasing customer SATISFACTION and building a loyal user BASE.

With web applications, you don’t know in advance which browsers your users will use. Hence, it’s crucial to test the web application or the website on multiple MAJOR browsers running on different operating systems.

Cross-browser testing is a type of browser automation testing where the tester verifies if the web application will work smoothly on different browsers. Some of the popular browsers include Google Chrome, Mozilla FIREFOX, Internet Explorer, Safari, etc. 

The goal of the cross-browser testing is to launch the application on VARIOUS browsers running on different operating systems, e.g. WINDOWS, Mac OS, Linux, etc., and verify that the application works as expected. The tester looks for the design/rendering issues, the functionality of the application, and device-specific functionality.

Though it can be typically, sophisticated tools exist that allow the testers to automate cross-browser testing. Some examples include Selenium BOX, BrowserStack, Browsershots, LambdaTest, etc.

Browser automation is the technique of programmatically launching a web APPLICATION in a browser and automatically executing various actions, just as a regular USER would. Browser testing gives you the speed and efficiency that would be impossible for a human tester. Protractor, Cypress, and Selenium are some of the popular tools used in-browser testing.

Some of the activities performed in browser automation are as FOLLOWS:

• Navigate to the application URL and make SURE it launches
• Test the various links on the web PAGE and ensure they are not broken. 
• Keep a record of the broken links on the page.
• Perform load and performance testing on your web application.
• Launch multiple instances of the browsers with different test users and ensure that concurrent actions work as expected.

A test environment is a computer or a server on which a tester tests the software. After the team builds the software, the tester installs it on this computer with all its DEPENDENCIES, just like the production environment. This allows the tester to test the software in a real-world scenario. 

A test environment enables the tester to create RELIABLE test SETUPS which are identical whenever a new version of the software is released. The test environment includes the test bed, which is the test data using which the tester will test the software. This data helps the tester to verify test cases that need a particular setup.

Typically, the test environment is an identical copy of the production environment. Having a duplicate copy allows the tester to reliably reproduce the bugs reported by the CUSTOMERS and provide the exact steps to the developers to fix them.

Here are some prerequisites for a good test environment:

1. A server with a similar configuration, including the software and the hardware to match a production environment.
2. Sample test data with which to test the software.
3. Test DATABASE with reasonably realistic data, it can be a copy of an actual production database.
4. Installed software under the test.

Although test automation has its advantages, it is not practical to automate all kinds of testing. Some testing can be DONE only by a human tester, such as user interface testing, usability, and accessibility testing.

Exploratory testing is another type of testing where a human tester provides more value than an automated test. In exploratory testing, a tester EXPLORES the software randomly, just as an end-user would do, and tries to find the bugs or UI inconsistencies or any hidden problems that developers MIGHT have overlooked.

Automated testing is helpful for LARGE projects involving complicated calculations and for repeatable test cases. For features that change often and rarely executed test cases, a human tester provides a BIGGER ROI than automation would.

A test automation framework makes it easy to perform automation testing for your software. Here are some components of a test automation framework.

• Test Data Management
  • A big problem in automation testing is generating the test data. A good test automation framework makes it easy to build test data for the application under test.
• Testing LIBRARIES
  • Managing and running the automated tests is a crucial component of any automated testing strategy. A test automation framework provides libraries that make test management easy.
  • A good test automation framework provides support for UNIT tests, integration tests, and end-to-end tests.
• Testing Tools
  • Includes any GUI or command-line tools that make it CONVENIENT for testers to run the SET of tests repeatedly.
  • It also consists of tools that ENABLE testing the software under high load to conduct performance testing.

To perform any automation testing, you NEED to rely on software tools or frameworks. There are plenty of options to CHOOSE from many alternatives.

Here are some CRITERIA based on which one can EVALUATE these tools.

• Programmable (code-based) or code-less tools. Some tools require programming skills, while some don’t, allowing a non-coder tester to create test cases with visual assistance. Depending on your team’s experience and skill-set, you should choose accordingly.
• Commercial vs. Open Source. There’s a vast variety in the pricing of the tools based on the feature they have. Commercial tools can be expensive, but you get tech support when needed. Open-source software is free, but you have to do your RESEARCH when troubleshooting the problems.
• Ease of use. Some automated testing tools are notoriously hard to use and require extensive training before providing any value. Some are easy to use, and you can start using them out-of-box.

Some of the most popular automation tools include Selenium, Katalon Studio, UFT, TestComplete, Testim, etc., and many more. When choosing one, you should consider the testing requirements for your project, consult your team, and assess their skills, experience, and comfort with the tool.

You should also periodically assess the return on investment from the tool you choose and be prepared to switch if needed.

Though automation has its advantages, it’s not a GOOD idea to automate all of your testings. Here are some scenarios when a human tester can do a much better job of testing the software than an automated test suite.

1. The software or the feature under the test CHANGES frequently. It MEANS you have to update your automated tests often to keep them up to date. Tests can quickly become obsolete and stop providing any value. 
2. Automated testing is also not suitable for exploratory testing. A human tester can explore the software in a much better way than a computer. 
3. Unless the automated tests are programmed or CONFIGURED to look for UI issues, they can’t find any problems with the UI. It’s much efficient for a human tester to SPOT any UI inconsistencies or design issues.

A test is a good candidate for automation under the FOLLOWING conditions.

• The test is repeatable.
• The feature under the test doesn’t CHANGE its BEHAVIOR frequently.
• It’s time-consuming for a human tester.
• The test INVOLVES complicated calculations.
• The test ensures the previous functionality didn’t break after a NEW change.

There are different testing TECHNIQUES, but you can not automate them all. For example, exploratory testing. Here are some testing techniques that you can automate.

1. Unit tests: These are written by software DEVELOPERS and test a unit of code in isolation.
2. Integration tests: These test how well different software components work with each other.
3. Regression tests: Verify that the new code didn't break any existing functionality.
4. Performance tests: Ensure that the software won't crash and perform reasonably under heavy load or stringent conditions.
5. UI tests: Ensure that the software USES a CONSISTENT USER experience and no visual or graphical elements on the screen are broken.

Automation testing is a software testing strategy in which a TESTER programmatically runs the tests USING a tool or a framework instead of MANUALLY going through the test cases and executing them one by one.

The primary goal of automated testing is to save time, effort, and money on repetitive tests that don’t change frequently.

Automation testing helps teams and organizations automate the testing efforts, in turn reducing the need for human intervention and thus achieving greater speed, reliability, and efficiency. It ALSO helps speed up the development cycle, as the DEVELOPERS get quick feedback and can iterate quickly.