Docker containers include the application and all of its dependencies but share the kernel with other containers, running as isolated processes in user space on the host operating system. Docker containers are not tied to any specific infrastructure: they run on any
computer, on any infrastructure, and in any cloud.
Docker containers can be created by either creating a Docker image and then running it or you can use Docker images that are present on the Dockerhub.
Docker containers are basically runtime instances of Docker images.
Q4. What is Docker image?
Docker image is the source of Docker container. In other words, Docker images are used
to create containers. Images are created with the build command, and they’ll produce a
container when started with run. Images are stored in a Docker registry such as
registry.hub.docker.com because they can become quite large, images are designed to
be composed of layers of other images, allowing a minimal amount of data to be sent
when transferring images over the network.
Q3. How exactly are containers (Docker) different from hypervisor virtualization (vSphere)? What are the benefits?
Q2. What are the advantages that Containerization provides over virtualization?
Below are the advantages of containerization over virtualization:
- Containers provide real-time provisioning and scalability but VMs provide slow provisioning
- Containers are lightweight when compared to VMs
- VMs have limited performance when compared to containers
- Containers have better resource utilization compared to VMs
Q1. What are containers?
Containers are used to provide consistent computing environment from a developer’s laptop to a test environment, from a staging environment into production.
Now give a definition of containers, a container consists of an entire runtime environment: an application, plus all its dependencies, libraries and other binaries, and configuration files needed to run it, bundled into one package. Containerizing the application platform and its dependencies removes the differences in OS distributions and underlying infrastructure.
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
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
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/
Career Roadmap for SDET – Automation
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