Continuing on our Software Testing Interview Questions series, let’s look at some more interesting interview questions.
Software Testing Interview Questions
Smoke Testing (General Health check-up) – What if developers are too reckless? There is a defect at the very first step – User is unable to login itself. Yeah! You will say what about Unit testing, but usually developers don’t follow the rules every time. Smoke testing is the preliminary testing to reveal simple failures severe enough to reject a prospective software release. In other terms you can call it as ‘Confidence testing’ or the ‘Build verification testing’. Smoke tests cover the MOST CRITICAL functionalities. The purpose is to reject a ‘critical defect’ build before the Test team starts detailed functional tests. Before starting the day, a daily build and smoke test is among industry best practices.
Note: The term “smoke test” refers to powering on a device simply to make sure it does not start smoking (indicating a major problem). It originated in the testing of electronic hardware.
Sanity Testing (Specialized Health check-up) – First of all irrespective of Testing, Sanity check is a basic concept – a simple check to see if the produced output is rational (that the product’s creator was thinking rationally, applying sanity). Extending the concept to software, after every change in a build Sanity testing is performed to ascertain that the particular changes are working as expected post which detailed tests are performed. If sanity test fails, the build is rejected to save the time and costs involved in a more rigorous testing.
Note: Sanity in general refers to the soundness, rationality and healthiness of the human mind. A person is not considered sane anymore just if he/she is irrational.
This is where “Object Spy” comes to rescue. Object Spy is a utility within UFT to,
- Highlight the object.
- Adding objects to object repository.
- Check the properties of object (also to copy that to clipboard). For e.g. values for object attributes like name, class, outertext, etc.
- Check what all the operations can be performed on the object, say click, select, etc.
Before moving to Automation framework, first let’s understand the different components involved in test automation.
- AUT: The application under test
- Test Automation tool such as HPE UFT or Selenium
- Test Management Tool where the test cases & screenshots are stored. In its absence a common shared drive can also be used.
- Test environment: A stable environment on which application is deployed for test purpose
- Application Objects: Different elements within application like textbox, checkbox, radio button, dropdown, etc.
- Application modules: Specific functional flows that needs to be executed within different test cases. E.g. User login.
- Test Data: Input values (valid or invalid) for the application fields such as Login credentials
- Functions: A set of reusable statements (for a particular functional flow) that needs to be executed within different scripts. E.g. User login.
- Test script: A standalone test case coded in a particular programming language using the test automation tool
- Results: This includes the error logs, execution status, screenshots, formal reports, etc.
Now how do you think these different components interact to successfully test the application, automatically? How do you modularize application flows into different functions? How do you identify & organize application objects? Where is the Test data stored? How is it accessed? From where do you run the test scripts? Automation tool or Test Management tool? Which all screenshots & logs are captured? & in which format? How do you report the test execution results? Yeah! There has to be a set of guidelines driving these rules, right? That’s what we call it a “Test Automation Framework”!
Retesting (Recovery Health check-up, post medicine) – This is the simplest to understand. What do you do in testing? Obviously find & log defects. After that? Yeah! Developer will fix the defect. As a Test team you need to verify that the defect fix is working fine, in other words you need to ‘retest’ the defect based on its steps to reproduce. Simple, right?
Regression Testing (No side-effects) – The job is not yet over the code is developed >> Build is deployed >> Sanity is performed >> Full testing is done >> Defects are logged, fixed & retested. What else? Yeah! Truth is stranger than fiction, and so is the Software. You never know a change in one function (defect fix or enhancement or change request) can impact multiple areas of the software. It’s our duty as a Test team to ensure everything (apart from the change) impacted is working as expected. In other words, to ensure there are no new defects introduced. As you might have guessed, knowing the impact (Impact analysis) is a must-have to perform effective regression tests!
In Selenium, ‘Locators’ are used to uniquely identify the objects used in the Application under Test while automating the test cases. Once identified, we will be able to confirm the expected results on the web page.
Locators: Selenium offers a wide choice of Locators, namely – ID, Name, Identifier, Link, XPath, CSS, Class, tag, DOM and Filters. Here XPath and CSS are the most widely used locators.
Widgets and applications do not mean the same thing, but they are similar terms. In mobile computing, for example, we tend to think of widgets and apps as “objects” that enhance the user experience. But widgets and apps are separate types of programs that run on a Mobile phone and they serve different purposes.
Widgets are basically self-contained mini programs that live & run on the phone’s home screen and stays open all the time so that you can just glance at it and get the information that you need without opening an app. They tend to perform simple functions — like the Clock widget showing the time and temperature — but do so dynamically so you do not have to fiddle around to update them. Apps, on the other hand, are typically programs you tap open and run. Apps can be very multi-functional, like a program that lets you create and edit spreadsheets right on your phone.
Easy way to think of it is: Apps are programs that you need to open. Widgets are apps that are basically always running on your home screen. So if you had a battery App, you would have an icon that you would click and it would show you all the battery info on a new screen. If you had a battery widget, when you are on your home screen the app is already running on a part of the screen showing you all the info without having to click anything or open a new window.
‘Repository’ is a generic term meaning a central location in which data is stored and managed. And why would someone need a central location? To access data from a single source of truth, which can be accessed across-locations by multiple users. Now apply the same concept to Automation.
Say you want to test multiple application flows wherein some objects are referenced in each flow. What does your logic say? Yeah! To have a repository of these objects & access it for different flows. Now what should this repository contain w.r.t. Automation Testing? Yeah, as you would have guessed – Objects & their properties so that UFT can refer repository to identify these objects during run-time.
Object Repository is a collection of objects and its properties with which QTP will be able to recognize the objects and act on it. These objects and properties play a vital role in UFT, without these two things UFT could not play back the scripts. When a user records a test, the objects and its properties are captured by default.
Question-18. Based on your prior experience, what are some ‘things’ that developer do or don’t do that bothers corresponding testing activities?
Agree or not, once in a while every one of us enjoy criticizing something – a person or a situation. A conflict between a developer & a tester is not new – it has been there since the inception of Software Testing. After all, nobody likes it when their mistakes are pinpointed & written on the wall. What they don’t understand is – it’s not about ‘You’, it’s about the ‘Software’!
- Unit Testing: Yeah! In theory! But practically, most of the times we find during our ‘Smoke Test’ that the main functional flow itself isn’t working. It’s like developing a Gmail login page where error is displayed as soon as the user clicks ‘Sign In’ after entering username and password. Yeah! WTF! Is this a kind of development we expect? Nah! But what’s the way out? First – curse the developer, drop a mail marked as Critical keeping seniors in loop. The issue gets fixed & comes back for retest.
- Software Design: The product/software architecture is as important for Test teams as it is for Development team. It is always a good practice to include test team representatives in architecture sessions. But as usual, the general perception is ‘Testing team has nothing to do with the architecture’ – just develop & deploy the build for testing.
- Defect Life cycle: ‘Fixed, retest all the defects’ the developer said >> Tester looks into Defect Management tool (e.g. HP Quality Center) and see that none of the defect’s status is changed to either ‘Fixed’ or ‘Ready for Test’ >> But still he/she verifies all defects & reopens half of them. Looks like a common scenario, right? Yeah! Developers seldom follow the defect life cycle in the management tool.
- Defect is not Reproducible: The famous one-liner among the tester-developer communication “The defect is not reproducible” – on my machine, in this environment, on this browser, etc. Identifying the defects isn’t enough for a tester, he/she needs to keep a track of steps followed, screenshots of the errors, check the logs, etc.
To begin automation, the first step every tester learns is ‘Record-and-Play‘. Why? It’s the easiest Also, during automation there will be cases when we need to record object using its properties, or continuous mouse movements, or object’s co-ordinates, or to record images of the object. The purpose defines the type of UFT Recording mode you select.
Recording a test corresponds to recording the user actions of the application under test so that UFT automatically generates the scripts that can be played back. It is used as the preliminary investigation method to verify if UFT can support the technology/application and to create a test script to check the basic functionality of an application that does not require long-term maintenance. It is one of the start point for any Automation, post which the scripts are enhanced with Object repositories, Checkpoints, Parameterization, etc.
UFT offers below recording modes:
- Normal or Default mode
- Analog recording
- Low-level recording
- Insight recording
Will you start testing in parallel with development or only after the development is completed? What about testing at the code-level? I.e. code reviews to ensure best practices are followed. Will it only be reviews or will you actually run the application to identify defects? How about utilizing some automation tool to ease the process? Or will it be hybrid? As you might have guessed there are various approaches or methods to test a application.
- Preventive and Reactive approach
- White-box, Black-box and Gray-box Testing
- Static and Dynamic Testing
- Manual and Automated Testing
Fast Forward to next set of Software Testing Interview questions and answers –