Stqa Viva Que
Stqa Viva Que
You can test the software in many different ways. Some types of testing are
conducted by software developers and some by specialized quality assurance staff.
Here are a few different kinds of software testing, along with a brief description of
each.
Type Description
A programmatic test that tests the internal working of a unit of
Unit Testing
code, such as a method or a function.
Integration Ensures that multiple components of systems work as expected
Testing when they are combined to produce a result.
Regression Ensures that existing features/functionality that used to work are not
Testing broken due to new code changes.
Complete end-to-end testing is done on the complete software to
System Testing
make sure the whole system works as expected.
Type Description
A quick test performed to ensure that the software works at the
most basic level and doesn’t crash when it’s started. Its name
Smoke Testing
originates from the hardware testing where you just plug the device
and see if smoke comes out.
Ensures that the software performs according to the user’s
Performance
expectations by checking the response time and throughput under
Testing
specific load and environment.
User- Ensures the software meets the requirements of the clients or users.
Acceptance This is typically the last step before the software is live, i.e. it goes to
Testing production.
Ensures that the performance of the software doesn’t degrade when
the load increases. In stress testing, the tester subjects the software
Stress Testing
under heavy loads, such as a high number of requests or stringent
memory conditions to verify if it works well.
Measures how usable the software is. This is typically performed
Usability
with a sample set of end-users, who use the software and provide
Testing
feedback on how easy or complicated it is to use the software.
Now more important than ever. Security testing tries to break a
Security software’s security checks, to gain access to confidential data.
Testing Security testing is crucial for web-based applications or any
applications that involve money.
The dictionary definition of regression is the act of going back to a previous place
or state. In software, regression implies that a feature that used to work suddenly
stopped working after a developer added a new code or functionality to the
software.
Regression problems are pervasive in the software industry, as new features are
getting added all the time. Developers don't build these features in isolation,
separate from the existing code. Instead, the new code interacts with the legacy
code and modifies it in various ways, introducing side effects, whether intended or
not.
As a result, there is always a chance that introducing new changes may negatively
impact a working feature. It's important to keep in mind that even a small change
has the potential to cause regression.
Regression testing helps ensure that the new code or modifications to the existing
code don't break the present behaviour. It allows the tester to verify that the new
code plays well with the legacy code.
With the first approach, the tourist follows a predetermined plan and executes it.
Though they may visit famous spots, they might miss out on hidden, more exciting
places in the city. With the second approach, the tourist wanders around the city
and might encounter strange and exotic places that the itinerary would have
missed.
A tester is similar to a tourist when they are testing software. They can follow a
strict set of test cases and test the software according to them, with the provided
inputs and outputs, or they can explore the software.
When a tester doesn't use the test scripts or a predefined test plan and randomly
tests the software, it is called exploratory testing. As the name suggests, the tester
is exploring the software as an end-user would. It's a form of black-box testing.
In exploratory testing, the tester interacts with the software in whatever manner
they want and follows the software's instructions to navigate various paths and
functionality. They don't have a strict plan at hand.
End to End testing is the process of testing a software system from start to finish.
The tester tests the software just like an end-user would. For example, to test a
desktop software, the tester would install the software as the user would, open it,
use the application as intended, and verify the behavior. Same for a web
application.
There is an important difference between end-to-end testing vs. other forms of
testing that are more isolated, such as unit testing. In end-to-end testing, the
software is tested along with all its dependencies and integrations, such as
databases, networks, file systems, and other external services.
Unit testing is the process of testing a single unit of code in an isolated manner.
The unit of code can be a method, a class, or a module. Unit testing aims to focus
on the smallest building blocks of code to get confidence to combine them later to
produce fully functioning software.
A unit test invokes the code and verifies the result with the expected result. If the
expected and actual outcomes match, then the unit test passes. Otherwise, it fails.
8. What is an API?
Another use of an API is to provide data required by an application. Let's say you
are building a weather application that displays the temperature. Instead of
building the technology to collect the temperature yourself, you'd access the API
provided by the meteorological institute.
Whenever a new build of the software is released, the tester updates the test
environment with the latest build and runs the regression tests suite. Once it
passes, the tester moves on to testing new functionality.
When software is being tested, the code coverage measures how much of the
program's source code is covered by the test plan. Code coverage testing runs in
parallel with actual product testing. Using the code coverage tool, you can monitor
the execution of statements in your source code. A complete report of the pending
statements, along with the coverage percentage, is provided at the end of the final
testing.
11. Can you describe the different types of test coverage techniques?
It is extremely beneficial to use automation testing when using the agile model in
software testing. It helps in achieving maximum test coverage in a lesser time of the
sprint.
14. Explain test scenarios, test scripts, and test cases in software
testing.
Test Case: Test Cases are a series of actions executed during software
development to verify a particular feature or function. A test case consists of
test steps, test data, preconditions, and postconditions designed to verify a
specific requirement.
Test Scenario: Usually, a test scenario consists of a set of test cases covering
the end-to-end functionality of a software application. A test scenario
provides a high-level overview of what needs to be tested.
Test Scripts: When it comes to software testing, a test script refers to the set
of instructions that will be followed in order to verify that the system under
test performs as expected. The document outlines each step to be taken and
the expected results.
A software bug is an error in the software that produces wrong results. A software
tester tests the software to find bugs in it.
There are many causes for the bugs—for example, poor design, sloppy
programming, lack of version control, or miscommunication. Throughout
development, developers introduce hundreds or thousands of bugs in the system.
The goal of the tester is to uncover those bugs.
You can find a bug in many different ways, regardless of your role. When building
the software, the software developer might notice the bug in another module,
written by another developer or by themselves. The tester actively tries to find the
bugs as part of a routine testing process. Finally, the users could see the bugs when
the software is in production.
All bugs, no matter how they are found, are recorded into a bug-tracking system. A
triage team triages the bugs and assigns a priority to the bug, and assigns the bug
to a software developer to fix it. Once the developer resolves the problem, they
check in the code and mark that bug as ready for testing. Once a bug is ready for
testing, it goes to the tester, who tests the software to verify if it’s indeed fixed. If it
is, then it’s closed. If not, they assign it to the same developer with a description of
the exact steps to reproduce the bug. Some examples of popular bug-tracking
systems include BugZilla, FogBugz, etc.
Trivia:
The first software bug was discovered by Admiral Grace Hopper, on September 9,
1947. After they opened a malfunctioning piece of hardware, they found an insect
stuck in the relay. Image Source: Link
First Software Bug
Bugs Errors
Software bugs are defects, which occur
Errors in code are caused by problems with
when the software or an application
the code, which means that the developer
does not work as intended. A bug
could have misunderstood the requirement
occurs when there is a coding error,
or the requirement was not defined
which causes the program to
correctly, leading to a mistake.
malfunction.
Errors are raised by test engineers and
The bug is submitted by the testers.
developers.
Syntactic error, error handling error, error
Logic bugs, resource bugs, and handling error, user interface error, flow
algorithmic bugs are types of bugs. control error, calculation error, and testing
error are types of errors.
Bugs Errors
The software is detected before it is The error occurs when the code is unable
deployed in production. to be compiled.
Test Strategy
Test Objective
Test Scope
Reason for Testing
Exit/Suspension Criteria
Resource Planning
Test Deliverables.
Test Objective
Project Information
Defect
Test Summary
Test deliverables, also known as test artifacts, are basically a list of all of the
documents, tools, and other components that are given to the stakeholders of a
software project during the SDLC. Test deliverables are maintained and developed
in support of the test. At every phase of SDLC, there are different deliverables as
given below:
Test Scripts
Simulators.
Test Data
Test Traceability Matrix
Error logs and execution logs
Test Results/reports
Defect Report
Installation/ Test procedures guidelines
Release notes
Poor Scheduling
Underestimating
Ignoring small issues
Not following the exact process
Improper resource allocation
All software has a target user. A user story describes the user's motivations and
what they are trying to accomplish by using the software. Finally, it shows how the
user uses the application. It ignores the design and implementation details.
A user story aims to focus on the value provided to the end-user instead of the
exact inputs they might enter and the expected output.
In a user story, the tester creates user personas with real names and characteristics
and tries to simulate a real-life interaction with the software. A user story often
helps fish out hidden problems that are often not revealed by more formal testing
processes.
1. Selenium: a web browser automation tool that automates the test suites you
need to run on a web browser.
2. Protractor: An end-to-end test framework for Angular and AngularJS
applications. Protractor runs tests against your application running in a real
browser, interacting with it as a user would.
3. Cypress: A modern front-end testing tool built for the modern web. Though
it’s similar to Selenium and Protractor, it’s architecturally different from them.
4. Jasmine: This is an open-source JavaScript testing framework that allows you
to write behaviour-driven tests.
5. JUnit and NUnit: These are unit testing frameworks for Java and C#
programming languages, respectively.
A/B testing is the process of testing two or more different versions of your software
with users to assess which performs better. It is a low-risk way of testing variations
of a new or existing functionality.
You can choose a part of your users to use feature A. The other group uses feature
B. Then user feedback and response are evaluated using statistical testing to decide
the final version of the feature.
Typically, A/B testing is used to test the user experience of different interfaces. This
allows the team to quickly gather feedback and test their initial hypothesis.
Latent Defect: Latent defects are defects that exist but have not yet been
invoked because the conditions required to invoke them have not been met.
As a systematic flaw, it encompasses the entire production process of the
software, including all pre-production testing and extended testing. When
users perform a particular task in an unusual or rare situation or without the
presence of usual scenarios, latent defects are revealed.
Masked Defect: These are the defects that have not yet resulted in a failure
since another defect hides that portion of the code from being executed. It
can only be discovered when the defect hiding it is exposed by the user
through a specific operation. There are defects that are hidden or marked by
another defect and remain hidden until the other defect is detected.
The term 'sanity testing' refers to a subset of regression testing. The sanity testing
ensures that the changes made to the code do not adversely affect the system's
performance. After the software build is received, a sanity test is conducted to
ensure that the changes made to the code are working correctly. As a checkpoint,
this testing is used to determine whether the build can proceed with further testing.
Sanity testing focuses on validating the functionality of the application rather than
detailed testing.
Features
Yes, you can skip a particular test method or code by setting the 'enabled'
parameter to ‘false’ in test annotations.
@Test(enabled = false).
31. What is the best way to set priority for test cases in TestNG?
Syntax: @Test(priority=2)
Example: The following code demonstrates how to set the priority of a test case in
TestNG.
package TestNG;
import org.testng.annotations.*;
public class SettingPriority {
@Test(priority=0)
public void scalermethod1() {
}
@Test(priority=1)
public void scalermethod2() {
}
@Test(priority=2)
public void scalermethod3() {
}
}
ScalerMethod1
ScalerMethod2
ScalerMethod3
Object Repository is a collection of web elements and their locators that belong to
the Application Under Test (AUT). The QAs maintain all element locators in a
separate file known as the property file (. properties) in Selenium. During execution,
it serves as a means of identifying objects between the test script and the
application.
33. What are the valuable steps to resolve issues while testing?
Record: Keep track of any problems that arise and resolve them.
Report: Inform higher-level managers of the issues.
Control: Establish a process for managing issues.
Any software tester's goal is to find out as many bugs and problems in the system
so that the customers don't have to. Hence, a good software tester should have a
keen eye for detail. They should know the ins and outs of the software they are
testing and push every aspect of the software to its limits, to identify bugs that are
hard to find with the software's regular use.
A good tester should keep the end-user in mind when they are testing. Having
empathy with the end-user helps the tester ensure that the software is accessible
and usable. Simultaneously, the tester should possess basic programming skills to
think from a developer's perspective, which allows them to notice common
programming errors such as null-references, out-of-memory errors, etc.
Communication, both written and verbal, is an essential skill for a tester. A tester
will frequently have to interact with both the developers and the management.
They should be able to explain the bugs and problems found during testing to the
developers. For each bug found, a good tester should provide a detailed bug report
consisting of all the information a developer would need to fix that problem. They
should be able to make a good case to the management if they are uncomfortable
releasing the software if it contains unresolved issues.
BVA (Boundary Value Analysis) is a black box software testing technique that uses
boundary values to create test cases. Input values near the boundary have a higher
probability of error, so BVA is used to test boundary values. BVA includes values at
the boundaries in the test cases. If the input falls within the boundary range, then
the test is positive; if it falls outside, then it is negative. There are several types of
values, including maximum or minimum, inside or outside edge, and typical or error
values.
An agile software development model works in small iterations. You test the
software in parallel as it is getting built. The developers build a small functionality
according to the requirements. The testers test it and get customer feedback, which
drives future development.
37. How much testing is sufficient? Or, is it possible to do exhaustive
testing of the software?
An extensive test that finds hundreds of errors doesn’t imply that it has discovered
them all. There could be many more errors that the test might have missed. The
absence of errors doesn’t mean there are no errors, and the software is perfect. It
could easily mean ineffective or incomplete tests. To prove that a program works,
you’d have to test all possible inputs and their combinations.
Consider a simple program that takes a string as an input that is ten characters
long. To test it with each possible input, you’d have to enter 2610 names, which is
impossible. Since exhaustive testing is not practical, your best strategy as a tester is
to pick the test cases that are most likely to find errors. Testing is sufficient when
you have enough confidence to release the software and assume it will work as
expected.
They try to test the code to make sure that it works, rather than testing all
the ways in which it doesn't work.
Since they wrote it themselves, developers tend to be very optimistic about
the software and don't have the correct attitude needed for testing: to break
software.
Developers skip the more sophisticated tests that an experienced tester
would perform to break the software. They follow the happy path to execute
the code from start to finish with proper inputs, often not enough to get the
confidence to ship software in production.
However, it doesn't mean that developers shouldn't test the software before
sending it to the tester. Developer testing helps find many bugs that are caused by
programming errors. These are hard to find for a tester because they don't always
have access to the source code.
In short, SDLC (Software Development Life Cycle) enables the development of high-
quality, low-cost software with the shortest possible development time. A major
objective of the SDLC is to produce high-quality software that meets and exceeds
the expectations of customers. SDLC provides a detailed plan with a series of
stages, or phases, that encompass their own processes and deliverables. By
adhering to the SDLC, developers can enhance the speed of their projects and
minimize risks and costs.
Similar to software development, testing has its life cycle. During the testing, a
tester goes through the following activities.
1. Understand the requirements: Before testing software or a feature, the
tester must first understand what it is supposed to do. If they don’t know
how the software is supposed to work, they can’t test it effectively.
2. Test Planning and Case Development: Once the tester has a clear
understanding of the requirements, they can create a test plan. It includes
the scope of testing, i.e., part of software under test and objectives for
testing. Various activities are involved in planning the test, such as creating
documentation, estimating the time and efforts involved, deciding the tools
and platforms, and the individuals who will be conducting the tests.
3. Prepare a test environment: The development happens in a development
environment, i.e., on a developer’s computer that might not represent the
actual environment that the software will run in production. A tester
prepares an environment with the test data that mimics the end user’s
environment. It assists with realistic testing of the software.
4. Generate the test data: Though it is impossible to do exhaustive testing of
the software, the tester tries to use realistic test data to give them the
confidence that the software will survive the real world if it passes the tests.
5. Test Execution: Once the tester has a complete understanding of the
software and has a test environment set up with the test data, they execute
the test. Here, execution means that the tester runs the software or the
feature under test and verifies the output with the expected outcome.
6. Test Closure: At the end of the test execution, there can be two possible
outcomes. First, the tester finds a bug in the part of the software under test.
In this case, they create a test record/bug report. Second, the software works
as expected. Both these events indicate the end of the test cycle.
41. What is functional testing?
During testing, a tester records their observations, findings, and other information
useful to the developers or the management. All this data belongs to a test record,
also called a bug report.
A detailed bug report is an important artifact produced during testing. It helps the
team members with:
Here are a few bits of information that a good bug report should contain. Image
Source: Bugzilla
Field Description
Title A short headline that summarizes the problem. It shouldn’t be too
long but just to give just the right information to the reader. It should
be specific and accurate.
Description The description should answer all the questions that are not
explained by the title. It contains a detailed summary of the bug, its
severity, and impact, steps to reproduce, expected results vs. the
actual output.
Version A lot of time can be wasted in trying to reproduce a bug in the
wrong version of the product. Knowing the exact product version or
the build number on which this bug was found is very useful to the
developer in reproducing the bug.
Status At any point, a bug can be either ‘Active’, ‘Ready for Testing’, or
‘Closed’. A bug becomes active when it is found, is ready for testing
once the developer fixes it. A tester can mark it closed if the
developer fixed it, or active if not.
Steps to Though the steps to reproduce the problem can be provided in the
Reproduce description, sometimes having a distinct field force the tester to think
about them. They include each step one must take to successfully
reproduce the problem.
Assigned To Name of the developer or the tester to whom this bug is assigned.
Resolution When a developer fixes the bug, they should include the cause for
the bug and its resolution. It helps the team in the future when a
similar bug resurfaces.