Skip to main content

Posts

What topics should we cover if we are planning to appear for an SDET Selenium/Java position (Exp 4-9 years)?

Here are the topics that we should prepare if we are planning to appear for an SDET Selenium/Java position (Exp 4-9 years): Iteration in Java Abstract Class Vs Interface Strings in Java Static Usage in Java Exceptions in Java HashMap in Java Java Annotations Master to Build your own XPATH and CSS Implicit, Explicit and Fluent Waits Handling Frames Data-driven testing using Excel JavaScript Executor Logs Generation (Logging infrastructure with Log4j) Advanced Reporting (Extent, Allure, Klov Report Generation) TestNG Framework Design Pattern (Page Object Model, Fluent, Singleton- Any 1 should be fine) Selenium Grid And finally: BDD Using Cucumber  Build Management with Maven and/or Gradle Git, GitHub, etc. Continuous Integration with Jenkins, Azure DevOps, Team City, etc. (Any 1 should be fine)

package.json in any node JS project

What is package.json in any node JS project? package.json is the heart of any Node.js project. Every Node JS project should have this file at the root directory. This file lists: • All the packages/modules needed for a Node JS project and their requested versions. • Several different directives or elements that tell NPM “How to handle the project” like scripts that can be run to automate tasks within the project. • All the metadata for a project, such as a name, the author, the license, etc. It makes your build reproducible, and therefore easier to share with other developers. In Simple words , if you have worked on any Java/Maven project- what pom.xml is for maven project; is the same as what package.json is for any Node JS Project. How we can generate it (package.json)? 1. Using “npm init” : Running this command (‘npm init’) will set up a new NPM package. On initializing, you will be prompted to enter a few answers. Once you answer those and if it worked successf

Lesson learned from API Testing

Of course, we should ensure that even our basic API tests are built to cover "Triple S" checks i.e. Status code, Schema, and Scenario checks but when we test our APIs, we should NOT just focus on the request and response part of our APIs but most importantly we should understand that how application(s) are going to consume our APIs. This will definitely give you a solid set of additional use cases from an end-user point of view to cover all your bases.

Test Data Strategies in test automation

Your test results are mostly as good as the test data it consumes. What should be our Test data cleanup strategy in automation? -> Should we clean up the data immediately after each and every run? OR, Should we perform the clean slate periodically? It's hard to find one strategy that can solve all our test data issues in our automation suite. So, instead of focusing on finding that silver bullet, think thoroughly about your own test requirements and see which strategy can bring in max stability in your automation suite instead of following blindly what others are doing. I know you are still not sure that which particular strategy is right for your automation suite or not? Don't rush, after a few tests run your test suite itself will let you learn by generating issues like flaky tests/intermittent failures, false positives, slowness/performance issues, etc. etc. Please go through this well-crafted article on "Test Data Strategies" by @Joe Colantonio/@P

Mutation Testing

What is Mutation Testing? Mutation Testing is an approach that evaluates the quality of existing software tests. The whole idea is to modify a small part in your code (mutated version code- faulty seed) covered by tests and check whether the existing test suite will find the errors and reject this mutated code. If it doesn’t, it means the tests are less strong and does not match your code’s complexity and thus leave many aspects untested. The changes introduced or injected in the program code are generally referred to as ‘ mutants ’. Let's take an example now- say we have a function where we take the monthly Total income of a family as an input and then decide whether they are eligible for a subsidy of Gas or not. If it is equal or less than ₹10,000, give them a subsidy.  It will be something like: -  Input the monthly Total income -  If monthly Total income=<₹10,000 -  Gas Subsidy= Yes -  End if (Gas Subsidy= No) For testing, our test data inputs will be like 9999

Should not call "automate testing"

You can’t automate testing; you automate only the checks (tests)... Still baffled? Checks can be automated for sure but testing can NOT. When we interact with any application, we use our human brilliance to know the functionality of that application and then based on our intelligence we judge whether the behavior (use case) of that application is right or wrong — Can that judgment be automated? So far- Nope. Can we automate whether the behavior of that application is right or wrong on performing certain action/test? Yes.