The test pyramid has four layers – unit tests, service tests, integration tests, end-to-end or acceptance tests. By dividing up the different types of tests into these levels, it becomes easier to decide what type of testing needs to be done when building and maintaining software.

At the bottom are unit tests. Unit tests are “white box” tests because they interact directly with product code. They typically perform operations on functions, methods, and classes. Unit tests should be concise, to the point, and focused on a single object/variation. They should be devoid of external dependencies and should instead rely on mocks/monkey-patching. These tests took less time to execute.

Integration tests are located in the center. Integration tests examine the point at which two distinct entities come together. They should be “black box” in nature, interacting with actual instances of the product being tested, rather than with code. Integration tests include service call tests (REST, SOAP, and others).

End-to-end tests are at top level. End-to-end tests trace a system’s path. They could be argued to be a multi-step integration test, and they should also be “black box.” Typically, they interact with the product in the same way that a real user would. Web UI tests are an example of integration tests, as they require the entire stack to run.

And manual testing is the cherry on top. Certain types of tests, such as exploratory or usability testing, cannot be automated, but we should always strive to minimize the number of manual tests.

You should be aware that as we progress up the pyramid, three factors begin to increase:

• Costs associated with the development and maintenance of tests
• Time frame for execution
• Possibility of erroneous negatives

Key aspects relating to the software testing pyramid include the following:

Avoid conducting duplicate tests at multiple levels. There is no reason to conduct the same tests at various levels. For instance, if boundary values were validated in unit tests, they should not be repeated in the GUI – you will not obtain any new data.

One should strive to reduce the difficulty of tests whenever possible. For example, you can verify interest calculation on a negative sum at a “medium level” or even at the unit test level. Therefore, why should you do it at the UI level? Lower-level test automation is more efficient; it enables you to identify defects earlier and saves you time and money.

• Selenium. No, Google didn’t build Selenium, but Jason Huggins (the creator of Selenium) worked at Google in 2007 on Selenium RC. Besides, it was the Google Test Automation Conference 2009 where Google and ThoughtWorks agreed to merge Selenium and WebDriver into Selenium 2.0. What followed is now history.
• Protractor. Originally developed for end-to-end testing of Angular apps, Protractor is one of the most popular automation frameworks. Needless to say, engineers from Google use Protractor for many products and play an important part in the development of this framework.
• Karma. The spectacular test runner for JavaScript is the brainchild of the AngularJS team at Google. Also, the original name of this test runner was Testacular.
• Espresso UI is a test framework and a record-playback tool for Android.
• EarlGrey. In addition to UI testing for web application and Android, Google taps into functional UI testing for iOS with EarlGrey. At Google, this framework is integral to the UI testing of Google apps for iOS, including YouTube, Play Music, Google Calendar, Google Translate, etc.
• GoogleTest. The products that use this C++ test framework are the Chrome browser, Chrome OC, and the computer vision library OpenCV.
• Google Test Case Manager is a test management software that Search giant uses internally.
• OSS-Fuzz is Google’s solution for the fuzz testing of open-source software.
• Martian proxy is a library for building programmable HTTP proxies for testing purposes. As pointed out on this project’s GitHub page, Martian proxy isn’t not really a Google product. Rather, it’s just code that Google happens to own.
  

Here is the complete list of testing tools used by Google and are Open source: https://opensource.google/projects/list/testing

Reference: http://syscolabs.lk/blog/

Full Stack Testers also go deeper and specialize in automated testing with usage of different tools e.g. Tosca, Selenium, more examples. Therefore, a base knowledge in programming languages like Java is very normal within this chapter.

Their focus is on building quality in the software rather. They gave priority to Defect Prevention over Defect detection.

How to become a Full Stack Tester:

• Continuous Learning – Reading, Conferences, Sharing
• Continuous Practicing – Practice new techniques
• Continuous improvement – retrospect your practices, process being followed at set intervals and Seek for better solutions.

REMEMBER: Being technical is not enough. Understanding the need for Continuous Delivery, Continuous Integration, Continuous Testing, Its about using the right skills at right time. Technical skills can be gained easily, but change in mindset and ownership are the difficult things to adopt.

In upcoming posts, we will learn in detail about – Skills required for Full Stack Quality Engineer and How to become a Full Stack Quality Engineer.

References:
https://www.valori.nl
https://www.slideshare.net/kmstechnology/
https://www.slideshare.net/NalinGoonawardana/

Perhaps inspired by the maxim, “a stitch in time saves nine”, Shift Left is a practical attempt to actually ensure a timely stitch; to check for errors in the software testing process earlier than the conventional time to do so.  Shift Left testing means testing earlier in the software development cycle, so that risks and unknowns can be reduced which enables smooth deliveries to the clients.

Few Examples of Shift Left:

• Pair with the developers – More Collaboration and brainstorming on the requirements / test scenarios with the Team (including Devs and PO) so that unknowns and risks can be discovered earlier in the phase. Both Devs and QEs will have the same understanding on the requirements.
  • Rework (Issue fixing & retesting) will be less.
  • Scope creep will be less.
• Test different layers – In SOA applications, APIs are developed first. Team should plan the API testing so that issues can be identified early in the cycle (rather than just testing from the UI).
• Plan Non-functional Testing early in the cycle (Performance Testing, Security Testing etc) – Identifies issues early and reduces the risks.
• Automate the “Automation Test Case Execution” – Integrate the automation scripts with Jenkins/any Build automation tools that automation scripts should run in CI region before the new code deployment. It will help in ensuring that new code change is safe or not.
• Automate Unit Tests, Integration tests, API Tests – These tests runs faster and help in identifying the defects early in the cycle.