Between the words Smoke and Sanity, and Test

 

Why Testing and Tests?

In simple and short, we test to have confidence in what we expect to believe or claim.  For example, I believe this code does what it is supposed to do in a context.  The tests in the testing may help to learn that and thereby help in having confidence.  Likewise, if the tests in testing are intended to prove with rational evidence that this does not work as expected -  this is also a confidence in how we see the claim.

Testing and Tests:

• are highly contextual
• it depends on the person who is testing
• her/his understanding of testing and tests
• how she/he applies the testing and tests
• her/his thought process and ideologies on testing and tests
• it depends on the person who is referring to the outcome of testing
• it is highly oriented toward the expectation of the stakeholders
• on what it has to be
• on how it has to be
• on what it has to serve

If there is anything in Software Development that can be tailored to the need, I see it is Software Testing.  It happens that everyone has her/his own understanding and definitions for Software Testing and how it has to be implemented and executed.  And, it is done that way!

But the same is not observed with programming, DevOps, finance, sales & marketing; or, not to the extent seen in Software Testing.  This is my observation and understanding.  Is that wrong?  That's altogether a different topic of discussion.

In the organizations, I have worked and in the projects that I have worked on within an organization, the software testing was defined and executed how they wanted it.   Though they were a few common things, how these common things were implemented and understood is not the same.

Smoke and Sanity, and Test

Before I begin, here are the questions that I would want you to answer for yourself:

1. Would you start with Smoke Test and then start the Sanity Test?
2. Would you continue with Sanity Test after the Smoke Test?  Why?
3. What do you consider in Smoke Test and Sanity Test?  Anything in common?
4. What did you learn from the outcome of the Smoke Test and Sanity Test?
5. What did you decide and what was the next action to the outcome of the Smoke Test and Sanity Test?
6. What was the need if you carried out Smoke Test and Sanity Test as a different testing activities?
• How this is helping you and your stakeholders?
7. What will you lose if you do not perform either the Smoke Test or the Sanity Test?
• What is the cost of doing so?
8. What is your understanding of the Smoke Test?
• How did you establish this understanding?
• Any update to this understanding of yours?
• What is the coverage expected out of the Smoke Test?
9. What is your understanding of the Sanity Test?
• How did you establish this understanding?
• Any update to this understanding of yours?
• What is the coverage expected out of the Sanity Test?
10. Do software engineers, software companies and practitioners, and engineering teams use these terms as you use?

I learn the word "Smoke Test" comes from the hardware testing context.  Then from where did the word "Sanity Test" come from?  I don't know!  

Further, I understand that the intent of these two words is the same.  That is, to have confidence in either continuing to use the build for further tests or not to use that particular build to test.

Scope and Coverage of Smoke and Sanity Tests

What comes in the scope of the "Smoke Test" or "Sanity Test" is again the question and confusion that is being carried and passed on to the generation of Software Test Engineers.  Could be this is creating a gap in understanding what it is.

Often, I have seen the scope and coverage expected out of the Smoke Test and Sanity Test are the same.  Just these two words, the Smoke Test and Sanity Test are being used interchangeably in the Software Engineering community and practice.

I could not differentiate and identify the uniqueness among them to date in my experience.  All I see is the words "test" and "testing" associate very well with any word you bring into a context. Later, everyone will define their own idea and words to it.  

If observed, the same does not happen in the other areas of software engineering.  Why?  I learn that we have kept Software Testing to be far from being technical.  This is one of the major setback reasons.

Software Testing is Technical

When I say technical, the programming is treated and accepted as technical; the DevOps is considered technical; the database administration is taken as technical.  But the software testing which overlaps with all of these engineering areas is not considered technical.

I started my software testing career in the waterfall practice days.  At times, the testing and programming teams were independent and did not interact at all. The business and project management team which got the requirement did not have interaction with testing unless for asking "can you sign off saying this be shipped.".

Today, I see the mindset of accepting software testing is technical.  In my career, over the last 7 years, I see the industry is slowly including software testing to tech excellence.  But it is yet to get its one common standards and glossary which will be used by all practitioners.

However, I see the software industry and communities yet to accept and acknowledge that people and context dynamics are also the propellers of Software Testing while it is technical.

A Solution to the Problem

When a subject and practice are considered technical, the ideas and how it is defined will also be taken seriously.  There will be no casual language when communicating the subject, work and practice.  

When I say technical, I mean it in the context of Software Engineering.  How we perceive what is technical in Software Engineering, I mean that.

I wish, this comes to Software Testing and possibly put an end to the casually used language and words.

WebDriver: Clarifying the Confusion on Why and What is the WebDriver - Part 1

 

I had a question "What is WebDriver and why should I use it to automate on a browser?"  I tried to understand it and relate its presence in code written using Selenium.  I see this question in the test engineers who are starting the practice of automation on browsers. 

And, most of us get confused with WebDriver, WebDriverManager, and WebdriverIO.  All of these are not the same but all these work around the same space that is automation on the web and mobile.

Between, I learn understanding of WebDriver is fundamental to the practice of automation on web browsers. The same idea is taken to the automation of mobile apps using Appium. 

I'm sharing this learning of me as a part of 21Days21Tips the initiative from The Test Chat community.  The tip here is to assist by providing clarity around the WebDriver and why we use it in automation on a browser.

What is WebDriver?

The WebDriver is part of the Selenium library and we use it every time when we are trying to do any interaction with and upon a browser.  It is also a language binding and helps to write the browser controlling code.  For example, if I pick Selenium's Java WebDriver,

• it provides the APIs that I consume to control the actions on the web page displayed on a browser
• likewise, if I pick Selenium's Python WebDriver it provides me the APIs that I consume to automate my actions on a browser
• I code here using Python

That said, the WebDriver is a set of APIs and to be precise it is an object-oriented API adhering to the W3C standards.  As a result, the WebDriver drives the browsers effectively today as all popular browsers to the W3C standards.  The HTTP is used as the transport protocol.

Understanding the WebDriver

On a higher level, this is what WebDrier does:

1. The tests we write make use of WebDriver API 
2. This WebDriver API carries the commands (written in the test) to interact with the browser's driver
3. On receiving the commands, the browser's driver and the browser will have native communication, where the driver will translate the commands to the browser to emulate the action on a browser.
4. The browser returns the response to its driver
5. The browser's driver will transfer information to the WebDriver
6. Then, WebDriver shows the information to a user who is running the test

Examples of browser's driver are:

• chromedriver of Chrome
• geckodriver of Firefox

Representation of Selenium WebDriver's Communication

The instructions (commands) that I pass via WebDriver's object are translated to stateless information.  That is, there is no state maintained between the client and the browser's driver.

Representation of Selenium's WebDriver SPI & Browser Interaction

When the code enters into Stateless Programming Interface (SPI), it is called into a process that breaks down what the element is, by using the unique identification and then calling the command.  For example, let us look into the below statements to understand what the code looks like at SPI:

Code written using WebDriver API:

WebElement greetBox = driver.findElement(By.id("greeting_textbox"));

greetBox.sendKeys("Welcome to Testing Garage's Blog");

 SPI:

findElement(using="id", value="greeting_textbox")

sendKeys(element="greetBox", value="Welcome to Testing Garage's Blog");

Note: The findElement and sendKeys are the commands provided by Selenium's WebDriver API to find the web element on the web page and enter the text into the web element. The browser's driver receives these commands and data, then emulates the command (a user action) on the browser, and carries back the response to WebDriver.

21 Days 21 Tips -- #day13

Here are my pointers to fellow test engineers who are confused about WebDriver

1. WebDriverManager and WebdriverIO are not WebDriver
• But all of these are around automation of the web and mobile
2. WebDriver interface helps in
   
1. Control of the browser
2. Identification and selection of web elements on the web page
3. Provides assistance to debug
3. Browser Level API
1. driver.manage().window().maximize();
2. driver.get("https://testingGarage.blogspot.com");
3. driver.navigate().back();
4. driver.navigate().forward();
5. driver.getWindowHandle();
6. driver.getWindowHandles();
4. Few Page Level API
1. driver.findElement(By by)
2. driver.findElements(By by)
3. driver.getCurrentURL();
4. driver.getTitle();
5. driver.getPageSource();
5. If you notice, we use these APIs to automate the browser
• The tests we write use these APIs of Selenium WebDriver along with the assertion
6. Why are we using "driver" in the above commands?
• This is another question and confusion among fellow test engineers starting to practice automation
• I will share this in the next tip :)

This understanding of WebDriver, and the why and how it is instantiated (in the next post) will help you to be comfortable in starting to read the test code written using Selenium.