Agile is a software development approach where a self-sufficient and cross-

functional team works on making continuous deliveries through iterations and

evolves /throughout the process by gathering feedback from the end users.

AGILE TESTING is a testing practice that follows the rules and principles of agile
software development. Unlike the Waterfall method, Agile Testing can begin at the
start of the project with continuous integration between development and testing.

In software testing, a requirement traceability matrix is a table that relates the

high-level requirements with detailed requirements, test plans, or test cases. RTM
helps in ensuring 100% test coverage.

Test coverage for any software can be calculated as the percentage of the number of
test areas or coverage items covered with respect to the total number of test
areas.

Scrum
Scrum is an Agile development method that emphasizes on team-centric approach. It
advocates participation of the entire team in all the project development
activities.

Roles in Scrum:
The Product Owner – This role represents the client and the business in general for
the product on which they’re working.
The Scrum Master – This person is responsible for ensuring the team has everything
they need to deliver value.
The Development Team – This is a group of cross-functional team members all focused
on the delivery of working software. It is the singular noun for any developers,
designers, QA and other technical roles that must collaborate on the actual
development of a product. Ideally, this group of 5-9 people is fully dedicated to
one scrum team.

Sprints:
A sprint is a short, time-boxed period when a scrum team works to complete a set
amount of work. Sprints are at the very heart of scrum and agile methodologies, and
getting sprints right will help your agile team ship better software with fewer
headaches.

Sprint Planning:
Sprint Planning is the scrum ceremony designed to make sure the team is prepared to
get the right things done every sprint.

Daily Scrum (Daily Standup):

The Daily Scrum is the team’s chance to get together, define a plan for the day’s
work, and identify any blockers.

Sprint Review:
The Sprint Review is the scrum ceremony where all work completed during the sprint
can be showcased the stakeholders.

Sprint Retrospective:
The Sprint Retrospective is the final scrum ceremony in the sequence that allows
the team to look back on the work that was just completed and identify items that
could be improved.

Ans. Quality assurance is a process-driven approach that checks if the process of

developing the product is correct and conforming to all the standards. It is
considered a preventive measure.
Ans. Quality control is a product-driven approach that checks that the developed
product conforms to all the specified requirements.

The software testing life cycle refers to all the activities performed during the
testing of a software product. The phases include-
Requirement analysis and validation – In this phase, the requirements documents are
analyzed and validated and the scope of testing is defined.
Test planning – In this phase, the test plan strategy is defined, the estimation of
test effort is defined along with the automation strategy, and tool selection is
done.
Test Design and Analysis – Here, test cases are designed, test data is prepared and
automation scripts are implemented.
Test environment setup – A test environment closely simulating the real-world
environment is prepared.
Test execution – The test cases are prepared, bugs are reported and retested once
resolved.
Test closure and reporting – A test closure report is prepared to have the final
test results summary, learning, and test metrics.

Functional testing is a type of testing which involves testing the functional

requirements of the system under test
Types of Functional testing
Unit testing – Unit testing is a type of testing performed by developers on the
individual module or piece of code. This ensures that the individual modules work
correctly and can be integrated with other modules.

Integration testing – Integration testing is performed after unit testing. In

integration testing, the interfacing between the inter-connected modules is tested.

Big-bang Integration Testing – In big bang integration testing, testing starts only
after all the modules are integrated.

Top-down Integration Testing – In top-down integration, testing/integration starts

from top modules to lower-level modules.

Bottom-up Integration Testing – In bottom-up integration, testing starts from

lower-level modules to higher-level modules up in the hierarchy.

Ques.63. How is monkey testing different from Adhoc testing?

Ans. In the case of Adhoc testing although there are no predefined or documented
test cases still testers have an understanding of the application. While in the
case of monkey testing testers don’t have any understanding of the application.

System testing – System testing is the third level of testing performed after
integration testing. In system testing, the application as a whole is tested
against its requirement specifications.

Acceptance testing – Acceptance testing is performed after system testing and it

involves validation of all the business requirements to make sure that the
application can be accepted for delivery.

SIT is mainly done to check how individual modules interact with each other when
integrated into a system as a whole.
SIT is conducted after unit testing and will be done each time when a new module is
added to the system.

System Testing is conducted at the final level i.e. after the completion of
integration testing and just before delivering the system for UAT.
System testing is mainly done to check if the whole system is working as expected
with reference to the specified requirements.

Smoke testing – Smoke testing is a type of testing that involves the execution of a
limited number of test cases to ensure that a new build can be considered for
thorough testing. If the smoke test cases fail, then the build is rejected for
further testing.

Regression testing – Regression testing is the type of testing that is performed to

ensure that a code fix or a new functionality implementation hasn’t affected
previously working functionality.

Sanity testing – Sanity testing is a type of testing that involves running of a

subset of regression tests to ensure that a new fix hasn’t affected an already
working functionality but in lesser time as compared to regression testing.

Defect Severity means how badly the defect has affected the application’s
functionality.

Defect Priority defines the order in which developers will fix defects (because
priority describes business importance). Note that the higher the impact of a bug
on a business’s bottom line, the higher the priority assigned to it.

1. High Severity and High Priority

The banking application has a login page where the user is authenticated. The steps
involved are-

The user enters the username and password and clicks on the ‘Login’ button.
The user is navigated to the home page of the user profile.

For Example,

The system crashes after you made the payment or when you are not able to add the
items to the Cart, this defect is marked as High Severity and High Priority defect.

Another example would be ATM vending currency feature wherein after entering the
correct username and the password, the machine does not dispense money but deducts
the transferred from your account.

#2) High Priority and Low Severity

For Example, the feature is expected to display a particular error to the user with
respect to its return code. In this case, functionally the code will throw an
error, but the message will need to be more relevant to the return code generated.
The blue lines in the figure indicate these kinds of defects.

For Example,

The logo of the company in the front-page is wrong, it is considered to be High

Priority and Low Severity defect.
#3) High Severity and Low Priority

For Example, a particular functionality can be used only on a later version of the
firmware, so in order to verify this – the tester actually downgrades his system
and performs the test and observes a serious functionality issue that is valid. In
such a case the defects will be classified in this category denoted by pink lines,
as normally end users will be expected to have a higher version of the firmware.

#4) Low Severity and Low Priority

Any spelling mistakes /font casing/ misalignment in the paragraph of the 3rd or 4th
page of the application and not in the main or front page/ title.

These defects are classified in the green lines as shown in the figure and occur
when there is no functionality impact, but still not meeting the standards to a
small degree. Generally cosmetic errors or say dimensions of a cell in a table on
UI are classified here.

For Example,

If the privacy policy of the website has a spelling mistake, this defect is set as
Low Severity and Low Priority.

Defect priority is an urgency of fixing the defect. Normally the defect priority is
set on a scale of P0 to P3 with the P0 defect having the most urgency to fix.
Defect severity is the severity of the defect impacting the functionality. Based on
the organization, we can have different levels of defect severity ranging from
minor to critical or show stopper.

Deferred: If the present bug is not of a prime priority and if it is expected to

get fixed in the next release, then status “Deferred” is assigned to such bugs
Defect not in scope is called Deferred Bug

Bug severity is concerned with the product and how far this damage extends. In
contrast,
Bug priority refers to the order in which bugs should be fixed depending on their
impact on the system and other variables.

High Priority, Low Severity bug :- If the company name is misspelled in the home
page of the website,then the priority is high and severity is low to fix it.

High Severity, Low Priority :- Web page not found when user clicks on a link
(user's does not visit that page generally)

Low Priority, Low Severity :- Any cosmetic or spelling issues which is within a
paragraph or in the report

High Priority, High Severity :- An error which occurs on the basic functionality of
the application and will not allow the user to use the system (E.g. user is not
able to login to the application)

High Priority and High Severity Examples

The products added to the cart of an e-commerce website are not visible on the
payment page.
The login button of the application is not working.

High Priority and Low Severity Examples

The logo of the company’s welcome page is distorted.
The action buttons are not visually appealing or the information on the page
appears hazy.

Low Priority and High Severity Examples

If the application is crashing on passing very large input for processing (which is
very rarely done).
There are some buttons on the website which are overlapping. Although clickable,
are creating a fuss.

Low Priority and Low Severity Examples

A spelling mistake on the page of the site which is not frequently visited.
The color of any text does not match the theme of the website.

Specification-based test design techniques are also referred to as black-box

testing.
It involves testing based on the specification of the system under test without
knowing its internal architecture. The different types of specification-based test
design or black box testing techniques are-

Ques.38. Explain equivalence class partitioning.

Ans. Equivalence class partitioning is a specification-based black-box testing
technique. In equivalence class partitioning, a set of input data that defines
different test conditions are partitioned into logically similar groups such that
using even a single test data from the group for testing can be considered similar
to using all the other data in that group.

For example, for testing a Square program (a program that prints the square of a
number), the equivalence classes can be-
Set of Negative numbers, whole numbers, decimal numbers, sets of large numbers,
etc.

Equivalence partitioning is a black-box testing technique that allows testers to

group input data into sets or classes, making it possible to reduce the number of
test cases while still achieving comprehensive coverage. This technique is
particularly useful when dealing with a large range of input values.

Ques.39. What is boundary value analysis?

Ans. Boundary value analysis is a software testing technique for designing test
cases wherein the boundary values of the classes of the equivalence class
partitioning are taken as input to the test cases e.g. if the test data lies in the
range of 0-100, the boundary value analysis will include test data – 0,1, 99, 100.

Ques.40. What is decision table testing?

Ans. Decision table testing is a type of specification-based test design technique
or black-box testing technique in which testing is carried out using decision
tables showing the application’s behavior based on different combinations of input
values.

Decision tables are particularly helpful in designing test cases for complex
business scenarios involving the verification of applications with multiple
combinations of input.

Ques.41. What is a cause-effect graph?

Ans. A cause-effect graph testing is a black-box test design technique in which a
graphical representation of input i.e. cause and output i.e. effect is used for
test designing. This technique uses different notations representing AND, OR, NOT,
etc relations between the input conditions leading to output.

Ques.42. What is state transition testing?

Ans. State transition testing is a black box test design technique based on a state
machine model. State transition testing is based on the concept that a system can
be defined as a collection of multiple states and the transition from one state to
another happens because of some event.

Ques.43. What is use case testing?

Ans. Use case testing is a black-box testing approach in which testing is carried
out using use cases. A use-case scenario is seen as an interaction between the
application and actors(users). These use cases are used for depicting requirements
and hence can also serve as a basis for acceptance testing.

Structure-based test design techniques are also referred to as white box testing.
In these techniques, the knowledge of the code or internal architecture of the
system is required to carry out the testing. The various kinds of testing
structure-based or white testing techniques are-

Statement testing – A white box testing technique in which the test scripts are
designed to execute the application’s code statements. Its coverage is measured as
the line of code or statements executed by test scripts.

Decision testing/branch testing – A testing technique in the test scripts is

designed to execute the different decision branches (e.g. if-else conditions) in
the application. Its coverage is measured as the percentage of decision points out
of the total decision points in the application.

Condition testing – Condition testing is a testing approach in which we test the

application with both True and False outcomes for each condition. Hence for n
conditions, we will have 2n test scripts.

Multiple condition testing – In multiple condition testing, the different

combinations of condition outcomes are tested at least once. Hence for 100%
coverage, we will have 2^n test scripts. This is very exhaustive and very difficult
to achieve 100% coverage.

Condition determination testing – It is an optimized way of multiple condition

testing in which the combinations which don’t affect the outcomes are discarded.

Path testing – Testing the independent paths in the system(paths are executable
statements from entry to exit points).

Smoke testing is a type of testing in which all major functionalities of the

application are tested before carrying out exhaustive testing.
Sanity testing is a subset of regression testing which is carried out when there is
some minor fix in the application in a new build.

Black box Testing: The strategy of black box testing is based on requirements and
specification. It requires no need of knowledge of internal path, structure or
implementation of the software being tested.

White box Testing: White box testing is based on internal paths, code structure,
and implementation of the software being tested. It requires a full and detail
programming skill.

Gray box Testing: This is another type of testing in which we look into the box
which is being tested, It is done only to understand how it has been implemented.
After that, we close the box and use the black box testing.

A build is an executable file provided by the developers to the testing team for
testing the application. It undergoes various iterations of fixing and testing
until the application works as expected. Once the application becomes stable and
ready for the end-users, it’s released in the market.
Whereas, a release is an installable software provided to the end-users after it
gets certified by the testing team. During the release of any software to the
client, release notes are attached to it that includes a number of defects still
open, covered user stories, change requirements, and version of the release.

Native mobile apps work only on one specific mobile platform or operating system
(OS).
Native applications for Google’s Android OS can only work on Android mobile
devices. Similarly, a native app on Apple iOS can only work on iPhones and iPads.

Hybrid mobile apps combine the capabilities of a native app and a web app.
Unlike native apps, hybrid apps have cross-platform compatibility. They are not
bound by a specific operating system.

Web applications use a web browser as their UI. Thus, they need an Internet
connection.
They can run on desktop computers, smartphones, and tablets with web browsers.

iOS package App Store (IPA) is a file containing a specific application's

compressed data in a ZIP file. The IPA file functions as a container to hold pieces
of data that make up an iPod, iPad, or iPhone touch app. The IPA file holds a
specific code proprietary to Apple and can't be run apart from iOS devices

APK stands for Android Application Package.

An APK file is the file format used to install the applications on the android
operating system. A program in android is first compiled, and then all of its parts
are packaged into one single file to make it an APK file.

Present
- Avoid Telling the name.
- High level view of the current role
- Key Accomplishments

Past
- Don't reiteriate your resume
-

Future

Enphase:

The Enphase IQ Gateway Metered is an integral component of the Enphase Energy

System that bridges communication between Enphase IQ Microinverters located on the
rooftop and the Enphase App for remote control and monitoring.

Commissioning refers to the process of ensuring that a solar energy system, whether
it's a residential, commercial, or utility-scale installation, is correctly
installed, configured, and functioning according to design specifications and
industry standards.
The commissioning process is crucial to ensuring that the solar system operates
efficiently, safely, and reliably over its operational lifetime.

Microinverters are devices used in solar power systems to convert the direct
current (DC) electricity generated by solar panels into alternating current (AC)
electricity that can be used to power homes and businesses.

Enphase Installer Toolkit is a mobile application designed to assist solar

professionals and installers who work with Enphase Energy's solar energy systems.
Enphase Energy is a company that specializes in solar microinverters and related
technologies. The Installer Toolkit app serves as a valuable tool for installers to
streamline the installation, commissioning, and maintenance processes of Enphase
solar systems.

Commissioning Assistance: The app likely provides step-by-step guidance through the
commissioning process, helping installers ensure that the solar system is properly
configured and ready for operation.

System Diagnostics: The app might offer diagnostic tools to troubleshoot issues
with individual solar panels, microinverters, or the overall system. This can help
identify and resolve problems quickly, minimizing downtime.

Real-time Monitoring: It could provide real-time monitoring of the solar system's

performance, allowing installers to remotely track energy production and system
health.

Firmware Updates: The app may facilitate the process of updating firmware for
microinverters and other system components, ensuring that the system is running the
latest software for optimal performance.

Documentation and Reporting: Installers might be able to generate reports and

documentation for each installation, which can be useful for record-keeping and
customer communication.

Compatibility and Configuration: The app could include tools to verify the
compatibility of components and help with the configuration of the system based on
specific requirements.

Customer Management: Some versions of the app might offer features to manage
customer information and installations, making it easier for installers to keep
track of their projects.

Support Resources: The app could provide access to Enphase's support resources,
such as manuals, guides, and troubleshooting tips.

User-Friendly Interface: The app likely features an intuitive and user-friendly

interface, making it accessible to both experienced solar professionals and those
new to the Enphase system.

------------------------------------

Explain the general structure of mobile application testing frameworks?

Mobile application testing framework includes three segments:

Application Package: It is the target application that requires to be tested.

Instrumentation TestRunner: It is a test case runner that runs test cases on the
target application. It includes an SDK tool for building test and a tool that
provides APIs for writing a program that controls an Android device, for example,
MonkeyRunner.

Test Package: It includes two classes, Test case classes, and Mock objects. Test
case classes include test methods to perform on the target application, while the
mock object includes mock data that will be used as sample input for test cases.

iPA: iOS APP Store Package

APK: Android Application Package file
exe: Executable File
jad: Java Application Descriptor
prc: Palm Resource Compiler

Appium with all sorts of testing frameworks. NUnit and .NET Unit Test Framework are
just a few examples. You will write your tests using one of the drivers for Appium,
thus your tests will interface with Appium just in terms of an external dependency.

------------------------------------------------------------------------
Mention The Basic Requirement For Writing Appium Tests.
For writing Appium tests you require:

Driver Client: Appium drives mobile applications as though it were a user. Using a
client library you write your Appium tests which wrap your test steps and sends
them to the Appium server over HTTP.
Appium Session: You have to first initialize a session, as such Appium test takes
place in that session. Once the Automation is done for one session, it can be
ended.
Desired Capabilities: To initialize an Appium session you need to define certain
parameters known as “desired capabilities” like PlatformName, PlatformVersion,
Device Name and so on. It specifies the kind of automation one requires from the
Appium server.
Driver Commands: You can write your test steps using a large and expressive
vocabulary of commands.

--------------------------------------------------------

Explain the general responsibilities of a mobile application testing framework.

Also explain the general structure of a mobile application testing framework.
Following are the general responsibilities of a mobile application testing
framework:

Choosing a format for expressing expectations

Developing a means to connect to or control the test application
Performing the tests and reporting the results
The general structure of a mobile application testing framework consists of the
following segments :

Application Package: This refers to the target application which needs to be run
and tested.
Instrumentation TestRunner: A test case runner that executes test cases against the
target application. It includes an SDK tool for creating tests as well as an API
tool, such as MonkeyRunner, that gives APIs for designing a program that controls
an Android device.
Test Package: Two classes, Test case classes, and Mock objects are included in the
Test Package. The mock object contains mock data that will be used as sample input
for test cases, while the test case classes contain test methods to run on the
target application.

----------------------------------------------------

DSEE, which stands for Digital Sound Enhancement Engine, is a technology developed
by Sony, to enhance the sound quality of compressed audio files by restoring high-
range sound removed by the compression process.

The Intelligent wind filter, available on some Xperia smartphones, allows you to
reduce wind noise while recording, without losing the original audio quality. It is
available in Cinema Pro, Camera app, third-party video recording apps and audio
recording apps.