Posted on

Software Testing at – Google, Apple, Facebook, Amazon & Spotify

Google takes testing seriously:

To that end, Google employs a four-stage testing process for changes to the search engine, consisting of:

Testing by dedicated, internal testers (Google employees)

Further testing on a crowdtesting platform

“Dogfooding,” which involves having Google employees use the product in their daily work

Beta testing, which involves releasing the product to a small group of Google product end users

Facebook: Developer-driven testing

Facebook employs a wide variety of automated testing solutions. The tools that are used range from PHPUnit for back-end unit testing to Jest (a JavaScript test tool developed internally at Facebook) to Watir for end-to-end testing efforts.

Amazon: Deployment comes first

The feeling at Amazon is that its development and deployment processes are so mature (the company famously deploys software every 11.6 seconds!) that there is no need for elaborate and extensive testing efforts. It is all about making software easy to deploy, and, equally if not more important, easy to roll back in case of a failure.

Spotify: Squads, tribes and chapters

Testing at Spotify is taken very seriously. Just like programming, testing is considered a creative process, and something that cannot be (fully) automated. Contrary to most other companies mentioned in this article, Spotify heavily relies on dedicated testers that explore and evaluate the product, instead of trying to automate as much as possible.

Microsoft: Engineers and testers are one

Microsoft’s ratio of testers to developers is currently around 2:3 (SDETs)

Source: 5 effective and powerful ways to test like tech giants: https://bit.ly/2nkjIvy

Posted on

Simplest Guide to XPath Axes in Selenium Webdriver by Codoid

Simplest guide to XPath Axes by Codoid. Must Read:

To use XPath effectively in Selenium WebDriver, you should be familiar with XPath Axes and HTML. There are thirteen axes available for XPath. As per the definition in Mozilla Web Docs – “An axis represents a relationship to the context node, and is used to locate nodes relative to that node on the tree.”

As an automation tester, if you are familiar with XPath Axes, you can write robust locators for dynamic WebElements.

Let’s look into all the XPath Axes which are useful for test automation scripting.

Let’s say you want to select a parent node using its child node. You first write XPath to pick the child node and the parent node using XPath parent axis.

Read More at: https://codoid.com/how-to-use-xpath-axes-in-selenium-webdriver/

Read More at: https://codoid.com/how-to-use-xpath-axes-in-selenium-webdriver/

Posted on

Career Roadmap for SDET – Automation

SDET-Career-Roadmap
(image embedded in video to enable HD format readability)

Stage 1 – Starting Point:

Learn a programming language in-depth preferably one of these – Java, JavaScript, Python

Stage 2 – Front End Automation:

Key Tools:
Web — Selenium, Protractor, Webdriver.io, Puppeteer, Cypress.
Mobile — Appium, Espresso, XCUITest.
Desktop — UFT, UiPath

Stage 3 – Backend Automation:

Key Tools: SOAP — SoapUI.
RESTful, GraphQL — PostMan, RestAssured, RestSharp,Karate.
gRPC — BloomRPC

Stage 4 – DevOps Automation:

Key Tools:
Code & Build — Git, Bitbucket, Maven, Gradle, WebPack, Docker
Packaging— Docker, Ansible, Puppet, Chef
Release & Configure — Jenkins, Docker Swarm, Kubernetes, GitLab, GitHub Actions

Stage 5 – Cloud Automation:

Key Tools:
AWS Services — EC2, S3, Lambda, SNS, Glacier, RDS, VPC

Read complete details at: https://babu-manickam.medium.com/career-roadmap-for-functional-test-automation-developers-611b77f126ac

Posted on

[Tips] What must be checked when performing API testing?

Seems easy but yet a tricky interview question. Here is the answer by Katalon experts:

During the API testing process, a request is raised to the API with the known data. This way you can analyze the validation response. While testing an API, you should consider:

  1. Accuracy of data
  2. Schema validation
  3. HTTP status codes
  4. Data type, validations, order and completeness
  5. Authorization checks
  6. Implementation of response timeout
  7. Error codes in case API returns, and
  8. Non-functional testing like performance and security testing
Posted on

Understanding Parallel Testing in Test Automation (Part 1)

Parallel testing is an automated testing process that developers and testers can launch multiple tests against different real device combinations and browser configurations simultaneously. The goal of parallel testing is to resolve the constraints of time by distributing tests across available resources.

For example, if 20 test cases take a total of 100 minutes to complete, then 10 parallel execution could run 2 test cases each and bring the total testing time down to 10 minutes. Ideally, if you have sufficient resources, say 20 real mobile devices and real browsers for simultaneous execution of 20 test cases, then you’ll be able to significantly shrink the runtime to 5 minutes.


Benefits of Parallel Testing:

Speed: Sequential testing is time-consuming, while parallel testing will allow you to divide invested time by the number of environments. In order to test your application against ten devices, all you need to do is write only ONE script and run it against all your target devices, cutting your testing time by ten times.

Cost-Efficiency: The building, maintaining and keeping your own test environment up-to-date can burn a hole in your pocket. When it comes to parallel testing, maintenance isn’t a headache anymore — in fact, you lease the needed testing environment, always updated. Plus, cloud-based testing grids allow you to run tests at high concurrency, making the cost per test significantly lower.

Better Coverage: It’s always a good idea to run your application through as many platform-device-browser combinations as possible so that no bug sneaks in. Parallel testing will take your test coverage to the next level, giving you a significant ROI boost.

Optimization of Your CI/CD Processes: Parallel testing is the best friend of continuous integration and delivery. By testing in parallel, you can run tests as soon as developers submit new code updates throughout the entire SDLC. Timely reporting and quick feedback in parallel testing will also facilitate better communication between various departments.

Improvement of Testing Practices: Parallel testing improves the QA routine in your company. The reason is crystal clear: by testing at high speed, you can test more. This gives your QA team a chance to improve their testing practices and pinpoint bugs faster.

Read Part 2: Tips for Successful Parallel Testing

Source

Posted on

Tips for Successful Parallel Testing (Part 2)

Read Part 1: What is Parallel Testing in Automation?

Here are some of the tips for Successfull Parallel Testing:

Tip 1: Test in the Cloud-Based Environment

Implementing a parallel testing strategy using in-house resources is one of the most typical mistakes. Building and maintaining your own infrastructure is not efficient. It is not just time- and cost-consuming – you won’t be able to make the most of parallel testing where the ability to test at high concurrency is a major advantage. Also, keeping your testing environment up-to-date requires a lot of resources. To this end, it’s a good idea to turn to cloud-based services that allow you to access the necessary devices at any time.

Tip 2: Avoid Dependencies Between Tests

Dependencies between different test cases are a primary reason why transitioning to parallel testing is so challenging for many teams. Simply put, when test cases are dependent on each other, you should run them in a particular order, which can destroy any parallel testing strategy. So, it is critical to creating your test cases to be atomic, independent from each other. Only then, you will be able to run them at any time and in any order, making your testing processes free of constraints.

Tip 3: Avoid Hard-Coding

Hard-coding is embedding data directly into the source code instead of generating it at runtime. This notion is an enemy of efficient parallelization since it creates dependencies between test cases, mentioned above. It is strongly recommended to avoid hard-coding values when scripting your test cases to ensure that each of your tests is self-sufficient and can be run whenever necessary. Use the data-driven approach to configure your test cases when they are running in parallel.

Tip 4: Manage Test Data Efficiently

Efficient test data management is the key to successful parallel test execution. But first, you need a strategy. There are two components you might want to add to it: a creational strategy (which creates test data needs) and a cleanup strategy (which cleans it up). Still, the only thing that matters is that your strategy is adapted to your particular case. The following ones are quite basic, and perhaps that’s what makes these data management strategies so effective:

  • elementary approach, which has no creational and cleanup strategies
  • refresh-your-data approach, which resets your source code in between test executions but has no creational strategy
  • selfish data generation approach, which has a creational strategy but no clean up one.

These are the most basic strategies. You can mix and match them to serve your own case or explore alternatives, such as generating other data or refreshing specific data.

Tip 5: Build Tests to be Run in Parallel

You don’t want to end up with a bunch of tests that can’t be run in parallel right before the release date. Planning correctly from the get-go will save you from nasty surprises when time’s up or when a deadline is due. Create your test cases with parallelization in mind should be your way to go. And believe us, it sounds harder than it actually is: test cases created for running in parallel are simpler, shorter and faster to build.

Source

Posted on

[ebook] Mobile App Testing Strategy Combining Virtual and Real Devices

Mobile Apps Require Rigorous Testing & Smart Strategies

But with such a fragmented landscape and so many device/OS combinations to test, as well as specific device capabilities, how can a team make sure they test effectively?

The way to ensure this is through a well-defined testing strategy in each step of the app development lifecycle. By combining real devices with virtual ones, teams can create a risk-based testing strategy to mitigate the risk of escaped defects.

Download this eBook to learn:

  • The main differences between virtual iOS/Android simulators and emulators and real devices.
    • OS version differences.
    • Platform capabilities and feature support.
    • Varying environment conditions.
    • Using each platform within the right SDLC phase.
  • The differences between iOS and Android virtual platforms.
  • How to build a testing strategy with both real and virtual platforms.
  • How to get started with Appium on real and virtual devices.

Click Here to Download this eBook.

Posted on

Job – Test Automation (~10years exp) (Delhi / NCR)

Job Opening: Immediate Joiner required:
Looking for a test automation expert/architect having ~10 years of experience on multiple automation frameworks.

Location: Delhi/NCR.
Candidate should be from Delhi/NCR only.

Remote working available.
Insterested candidates can drop email (with contact details/ resume) at leadershipintech@gmail.com

Posted on

Challenges with Traditional Testing and the adoption of Continuous Testing

Organizations now expect software development teams to deliver more, and more innovative, software within shorter delivery cycles. To meet these demands, teams have turned to lean approaches, such as Agile, DevOps, and Continuous Delivery, to try to speed up the systems development life cycle (SDLC). After accelerating other aspects of the delivery pipeline, teams typically find that their testing process is preventing them from achieving the expected benefits of their SDLC acceleration initiative. Testing and the overall quality process remain problematic for several key reasons:

[[Also Read: Understanding the Continuous Testing in DevOps]]

  • Traditional testing processes are too slow. Iteration length has changed from months to weeks or days with the rising popularity of Agile, DevOps, and Continuous Delivery. Traditional methods of testing, which rely heavily on manual testing and automated GUI tests that require frequent updating, cannot keep pace. At this point, organizations tend to recognize the need to extend their test automation efforts.
  • Even after more automation is added to the existing test process, managers still lack adequate insight into the level of risk associated with an application at any given point in time. Understanding these risks is critical for making the rapid go/no go decisions involved in Continuous Delivery processes. If tests are developed without an understanding of what the business considers to be an acceptable level of risk, it is possible to have a release candidate that passes all the available tests, but which the business leaders would not consider to be ready for release. For the test results to accurately indicate whether each release candidate meets business expectations, the approach to designing tests must be based on the business’s tolerance for risks related to security, performance, reliability, and compliance. In addition to having unit tests that check code at a very granular bottom-up level, there is a need for a broader suite of tests to provide a top-down assessment of the release candidate’s business risk.
  • Even if testing is automated and tests effectively measure the level of business risk, teams without a coordinated end-to-end quality process tend to have trouble satisfying the business expectations within today’s compressed delivery cycles. Trying to remove risks at the end of each iteration has been shown to be significantly slower and more resource-intensive than building quality into the product through defect prevention strategies such as development testing.
  • Organizations adopt Continuous Testing because they recognize that these problems are preventing them from delivering quality software at the desired speed. They recognize the growing importance of software as well as the rising cost of software failure, and they are no longer willing to make a tradeoff between time, scope, and quality.

Continuous testing has evolved to become an important phase in modern application development and delivery. Its very important for today’s testers to understand the Shift Left and Continuous Testing practices. It is not possible achieve Shift Left / Continuous Testing without enhancing the skill set to SDET/Full Stack QE