Better Testing – Full Stack QE https://fullstackqe.org Just another WordPress site Tue, 06 Jul 2021 10:03:02 +0000 en-US hourly 1 https://wordpress.org/?v=6.1.6 155680629 Why You Should Consider the Testing Pyramid Structure? https://fullstackqe.org/why-should-sdets-care-about-the-test-pyramid/ Fri, 02 Jul 2021 20:22:05 +0000 https://fullstackqe.org/?p=743 Continue reading "Why You Should Consider the Testing Pyramid Structure?"

]]>
The purpose of the test pyramid is to provide a structure for designing and executing tests. It is also the cornerstone of testing at Google.

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.

]]>
743
Automation testing tools at Google https://fullstackqe.org/automation-testing-tools-at-google/ Fri, 25 Dec 2020 20:22:52 +0000 https://fullstackqe.org/?p=592 Continue reading "Automation testing tools at Google"

]]>
Knowing that Google’s testers are really software engineers building test frameworks and tools, what are these frameworks and tools? Here’s a short list of the well-known testing solutions built or influenced by Google:

  • 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

]]>
592
Why are full stack QEs needed? https://fullstackqe.org/why-are-full-stack-qes-needed/ Sat, 29 Dec 2018 20:15:22 +0000 https://fullstackqe.org/?p=110 Continue reading "Why are full stack QEs needed?"

]]>
With the adoption of Agile development and DevOps culture, a story/feature is not complete without testing, and rather than being reactive by looking for bugs after development, full-stack QEs will focus on proactively looking for defects throughout the planning, design and development stages. When full-stack QEs work within a developer’s technical stack (as in the example, working within the JS stack as the developer), they can be Agile, prevent bugs, and increase engineering productivity. Full-stack QEs treat testing as defect prevention than defect detection.

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

]]>
110
Who is a Full Stack Quality Engineer (a.k.a Test Engineer)? https://fullstackqe.org/who-is-a-full-stack-quality-engineer-a-k-a-test-engineer/ Thu, 27 Dec 2018 18:37:15 +0000 https://fullstackqe.org/?p=95 Continue reading "Who is a Full Stack Quality Engineer (a.k.a Test Engineer)?"

]]>
A Full Stack Quality Engineers (a.k.a. Testers) is the opposite of a traditional black box tester. In contrary, a Full Stack Tester, creates business value by giving fast feedback loops on all layers of a technical process. Full Stack Testers can provide the information about the software quality faster by automating the testing activities of each layer. They are adaptive, collaborative, responsive and culturally fit in as an agile team member.

Full Stack QEs are professionals, or “nerds”, with knowledge of operating systems, databases, web servers, server side codes, browsers and client side code. These skills and flexibility allow the tester to deliver quickly and efficient.

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/


]]>
95
Redefined: Agile Testing Mindset & Role of an Agile Tester. https://fullstackqe.org/redefined-agile-testing-mindset-role-of-an-agile-tester/ Sun, 23 Dec 2018 17:50:49 +0000 https://fullstackqe.org/?p=53 Agile in Software Development is all about Value-Driven Development. Most of the Software Development companies are now following agile practices. Working in agile environment involves Continuous Learning, Discipline & Collaboration. A mind-shift is needed for testers to sustain Agile Teams.

]]>
53
[Video] Simplified – Shift Left in Software Testing https://fullstackqe.org/simplified-shift-left-in-software-testing-2/ Mon, 17 Dec 2018 08:55:46 +0000 https://fullstackqe.org/?p=14
]]>
14
[Tip] Practical Examples of Shift Left in Software Testing https://fullstackqe.org/simplified-shift-left-in-software-testing/ Fri, 14 Dec 2018 17:20:17 +0000 https://fullstackqe.org/?p=7 Continue reading "[Tip] Practical Examples of Shift Left in Software Testing"

]]>
Shift Left is a buzzword in Software Testing. It is not new, in fact it has always been around. Shift left is all about creating a culture where testers can be involved early in the software development life cycle to start testing activities early. Idea is to reduce the risks.

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.
]]>
7