May Learning Update - Part 1

My Goal from April 2019 is to learn about BDD.

As I Joined Moolya in the month of September 2018 and working on a Client Project, I have encountered many new things which I never experienced before.

One of the Topic is Feature Files and Step Definitions.

Now, for every new learning. I think and co-relate them to Golden Circles.

Image result for simon sinek why ted talk

WHY - I Wanted to know why Feature Files and Step Definitions are Built, What is the Usage of doing them in the Software Development Process.

HOW - I wanted to know how they are built, and I started looking for books to read, asking the testing community about what to read and learn about them.

WHAT - Started reading the Book: "BDD In Action". Now, Completed Chapter -1 from the Book.

Image result for bdd in action

Highlights from Learning:

  • Creator of BDD - Dan North
  • Why Building Software makes a difference - Building Software right vs Building right Software.
  • BDD tools can help turn these requirements into automated tests that help guide the developer, verify the feature, and document what the application does.
  • BDD isn’t a software development methodology in its own right. It’s not a replacement for Scrum, XP, Kanban, RUP, or whatever methodology you’re currently using.
  • BDD incorporates, builds on, and enhances ideas from many of these methodologies.
  • How BDD In Action improves the software development process, eliminates the uncertainty and locks down the requirements.
  • BDD Principles and Practices
  • Gherkin style of writing Features in a Feature Files (Given, When, Then, And, But)
  • Scenarios and Examples
  • Writing an executable specification for each step in scenarios: Step Definitions (High Level)
  • Writing unit tests for the high-level specifications. (Low-Level Executable Specifications ~ Unit Tests)
  • Tools to use for writing High-Level Executable Specifications in general and in Project
  • Tools to use for writing Low-level Executable Specifications in general and in Project.
  • Benefits and Potential Challenges with BDD.

Posted in , | Leave a comment Location: Bengaluru, Karnataka, India

Lessons Learned Posts: #3 - Heuristics and Oracles

As part of the "Learn Something New Every Day" challenge, I had decided to read an article a day and write short notes on Lessons Learned.

Image result for LESSONS LEARNED

The topic of the week: Heuristics and Oracles

The words "Heuristics and Oracles" are new concepts, for testers who have not heard about it.
I have not used these terminologies in the last 6 years at my job.

I heard about the words "Heuristics, Oracles" in Weekend Testing session.
From a long time, I wanted to learn about Heuristics and Oracles more in detail and to Understand it in a better way.


When we have a Testing Problem in Application, we try with different options or test ideas which we know how to test it and see if it works. The different options which we try are the test heuristics.

Heuristics are simply experience-based techniques for problem-solving, learning, and discovery. 

In Real Time, you might be experienced with testing an application which has scheduling functionality.
Now, the testing problem in an application is "To Test and Validate if scheduled Jobs are running or not"

The Test Heuristics can be:
  • Jobs can be scheduled in different ways: Day, Week, Month, Year and Time.
    • We would be testing if the job is scheduled for 5.00 am UTC is started to execute at a specified time or not, considering the Application server is running on UTC Timezone. --  The test heuristic is running at a specified time.
    • We would also test if the job at the specified day of the week and time is started to execute -- The test heuristic is waiting for the specified day of the week and time.

When we run out of test ideas, we can use heuristics to assist in exploratory testing.
Note: We cannot apply all heuristics, but we must try as much as possible.

Test Heuristics Cheat Sheet

Heuristic Test Strategy Model


While testing an application, we might discover a bug and immediately shouts "Got a Bug".
But there might be some cases, where the developer would not agree and asks for "why it is a bug? Is it part of the requirement document?"

we might think that "It should not work like this right?  Is it really a Bug?" 
There are number of ways, we can determine if its a bug or not. These are called as "Test oracles"

Oracles are simply the principle or mechanism by which we recognize a problem.

Oracles help to discover the real reason, why I think it is a bug.

Testers often say, We recognized the problem as "Product does not meet its expectations/requirements"

Few Hiccups

Posted in , | Leave a comment

Lessons Learned Posts: #2 - Security Testing Terminologies

As part of the "Learn Something New Every Day" challenge, I had decided to read an article a day and write short notes on Lessons Learned.

The topic of the day: Security Testing Terminologies

Last month, I have encountered with new terminology in security testing: False Positive.

I have understood in short, It is not an issue to fix. But wanted to learn more in detail.

Below are the references which I have used to learn about Security Terminologies:

After going through these links, It was easy for me to correlate and understand easily.

What I have learned:

Below is the representation of Security Testing Terminologies.

1. False Positives
2. False Negatives
3. True Positives
4. True Negatives

Posted in , , | Leave a comment