Assignment – 1

1. What are Software practices? Explain the phases in SDLC?

2. List different Software Engineering Tools and explain each of them?
3. Explain different Software Engineering Methods?
4. What is SRS? Explain the requirements classification?
5. What are functional and Nonfunctional requirements explain in detail?
6. Briefly explain the benefits of Requirement Management tool?
7. Write the selection criteria for choosing Requirement Management tool?
8. What is traceability? How do you generate traceability report using ReqView tool?
9. How does enterprise architecture support business goals and strategy?
10. Why is the enterprise architecture so important? What stakeholder groups would be
involved in the Enterprise Architecture lifecycle?
11. What are the architectural domains of TOGAF?
12. How the TOGAF creates importance as a skeleton for enterprise architecture?
13. What are the steps involved in Architecture Development Method (ADM)?
14. What is Version Control System? Explain types of Version control system in detail?
15. What is GIT? Explain the advantages of using GIT?
16. What is “Staging Area” or “Index” in GIT? Explain them in detail
17. What is the difference between ‘git remote’ and ‘git clone’?
18. What is the difference between the ‘git diff ’and ‘git status’?
19. Why is it advisable to create an additional commit rather than amending an existing
commit?
20. What is repository? Name a few Git repository hosting services?
21. What is build tool? Explain the need for build tools? Give some examples

Assignment -2
1. What is Automation Testing?
Automation Testing Beats Manual Testing.

Automation testing or Test Automation is a process of automating the manual process to test the
application/system under test. Automation testing involves the use of a separate testing tool
which lets you create test scripts which can be executed repeatedly and doesn’t require any
manual intervention
2. Why should Selenium be selected as a test tool?
1. Is a free and open source
2. Have a large user base and helping communities
3. Have cross Browser compatibility (Firefox, Chrome, Internet Explorer, Safari etc.)
4. have great platform compatibility (Windows, Mac OS, and Linux etc.)
5. Supports multiple programming languages (Java, C#, Ruby, Python, and Purl etc.)
6. Has fresh and regular repository developments
7. Supports distributed testing

3. What is Selenium? What are the different Selenium components?

Selenium is not just a single tool but a set of software, each catering to different testing needs of
an organization.

• It has four components:

Selenium Integrated Development Environment (IDE)

This is the simplest suite present in the Selenium suite. Selenium IDE allows to record and
playback of the scripts. It is implemented using the Firefox extension. By using Selenium, we
can record, edit and debug different tests. The tests created can be easily organized by having
different tests in different suites. The record and playback functionality helps in prototyping the
tool and provides the ease of learning. It acts as an overall solution for developing and
maintaining different suites. Having basic knowledge about HTML, JavaScript and DOM can
help the tester in utilizing the best of Selenium IDE. When the tester creates test cases it provides
a feature of auto-completing these. This helps in entering commands quickly and saves time. It
also reduces the chances of entering invalid commands.

How to record/replay with selenium IDE, see the following steps:

1. Start recording in Selenium IDE

2. Execute scenario on running web application

3. Stop recording in Selenium IDE

4. Verify / Add assertions

5. Replay the test.

Selenium IDE test cases:

 • Selenium saves all information in an HTML table format

• Each record consists of:

• Command – tells Selenium what to do (e.g. “open”, “type”, “click”,
“verifyText”)
• Target – tells Selenium which HTML element a command refers to (e.g. textbox,
header, table)
• Value – used for any command that might need a value of some kind (e.g. type
something into a textbox)

Selenium Remote Control (RC)

 Selenium Remote Control is a testing tool which helps in writing test scripts for web-
based applications in any programming language. It has two parts to it. First is the one
which launches and kills browsers. This server acts as an HTTP proxy server for different
web requests. It also supports different client libraries. Selenium RC is the first tool that
provided support for different programming languages like Java, Ruby, Perl, PHP, etc. In
 Selenium it is required to start the Selenium server before the tester starts the execution.
The Selenium server kills the browsers and runs Selenese commands which act as an
HTTP proxy and intercepts messages.
 This server acts as a mediator between the code and the browser. The commands are sent
to the server and they interpret the commands which in turn are converted to JavaScript
and this JavaScript is then injected to the browser. Once this is done then the browser can
execute the JavaScript and send the response to the server. The browser now interprets
the command and will return the code in the respective language from which it was
converted. Selenium RC also supports parallel execution of different test cases as it
supports Selenium Grid.

Selenium WebDriver

 Web Driver is the extension of Selenium RC. It supports all the latest browsers and
different platforms. There is no need of the Selenium server being started before starting
the execution of different test scripts. Selenium Web driver does not require JavaScripts.
It was developed in order to support dynamic web pages where any elements which will
be present on the page can change without having the page to be reloaded. It provides a
 proper designed API that provides improved support for modern web testing applications.
Web driver is created in a way which directly calls the browser by using the native
support for automation.
 Selenium server depends on the intention of using the Web driver. If the browser and test
cases are to run on the same machine, then there is no need to run the Selenium server.
Web driver will run directly. You can use Selenium Grid to segregate the tests over
multiple machines and virtual machines. Selenium server would be required when the
tester is connecting remotely or through a particular browser. The web driver interface
declares different methods that can be used for end to end testing. The test class which is
created should be used in the browser-specific implementation. This test class can control
web browser and also select different elements which can be loaded from HTML pages.
The web browser provides APIs which help in remotely controlling the user interface test
web applications

‘From sanjaw slide’

• Each browser has its own driver on which the application runs.
• Selenium WebDriver makes direct calls to the browser.
• For testing on a local machine, you need to use WebDriver.
• But for testing on a remote machine, you need selenium RC server to be running before
testing.
• While testing on a remote machine commands form WebDriver go to selenium RC server
which is then interpreted on remote machine to automate the browser.
Selenium WebDriver architecture – has 4 parts:
• There are four components of Selenium Architecture:
• Selenium Client Library
• JSON Wire Protocol over HTTP
• Browser Drivers
• Browsers
Selenium Grid

 Selenium GRID is a suite that has specialization in running multiple test cases parallel.
These can be different browsers, operating systems, and machines in parallel. It uses the
concept of hub-node. This means that only running the test on a single machine but
executing it on different nodes. This helps in parallel execution and makes GRID
platform-independent. Also, it is not browser-specific and supports all browsers.
 There are two versions of Grid. They are Grid 1 and Grid 2. Hub is the central point
where all test cases are to be loaded. There should be only one hub in the grid. There are
be any number of nodes in the grid. Also, nodes can be launched on different platforms
and browsers.
Example of grid:
4. What are the testing types that can be supported by Selenium?
 Functional Testing.
 Regression Testing.
 Sanity Testing.
 Smoke Testing.
 Responsive Testing.
 Cross Browser Testing.
 UI testing (black box)
 Integration Testing.

5. What are the limitations of Selenium?

Following are the limitations of Selenium:
 Selenium supports testing of only web-based applications
 Mobile applications cannot be tested using Selenium
 Captcha and Barcode readers cannot be tested using Selenium
 Reports can only be generated using third-party tools like TestNG or JUnit.
 As Selenium is a free tool, thus there is no ready vendor support through the user can find
numerous helping communities.
 The user is expected to possess prior programming language knowledge.

6. What is the difference between Selenium IDE, Selenium RC, and WebDriver? (Refer to Q3)
or below table

Feature Selenium IDE Selenium RC WebDriver

WebDriver supports a varied range

Selenium RC supports a
Selenium IDE of versions of Mozilla Firefox,
varied range of versions
comes as a Firefox Google Chrome, Internet Explorer
Browser of Mozilla Firefox,
plugin, thus it and Opera.
Compatibility Google
supports only Also supports HtmlUnitDriver
Chrome, Internet
Firefox which is a GUI less or headless
Explorer and Opera.
browser.
Selenium IDE Selenium RC doesn't
Record and WebDriver doesn't support record
supports record supports record and
Playback and playback feature
and playback feature playback feature.
Selenium IDE
doesn't require Selenium RC requires
WebDriver doesn't require any
Server any server to be server to be started
server to be started before
Requirement started before before executing the test
executing the test scripts
executing the test scripts.
scripts
Selenium IDE is a Selenium RC is a
WebDriver uses the browser's
Architecture JavaScript based JavaScript based
native compatibility to automation
framework Framework.
Selenium IDE is not
Selenium RC is semi WebDriver is a purely object
Object Oriented an object oriented
object oriented tool. oriented tool
tool
Dynamic Finders
Selenium IDE
(for locating web Selenium RC doesn't WebDriver supports dynamic
doesn't support
elements on a support dynamic finders. finders
dynamic finders
webpage)

Selenium IDE doesn't Selenium RC doesn't WebDriver offers a wide range of

Handling Alerts, explicitly provides explicitly provides utilities and classes that helps in
Navigations, aids to handle alerts, aids to handle alerts, handling alerts, navigations, and
Dropdowns navigations, navigations, and dropdowns efficiently and
dropdowns dropdowns. effectively.
WAP Selenium IDE doesn't Selenium RC doesn't WebDriver is designed in a way to
 efficiently support testing of
iPhone/Android applications. The
(iPhone/Android support testing of support testing of
tool comes with a large range of
) iPhone/Android iPhone/Android
drivers for WAP based testing.
Testing applications applications.
For example, AndroidDriver,
iPhoneDriver
Selenium IDE doesn't
Selenium RC doesn't WebDriver supports the
Listener Support support
support listeners. implementation of Listeners
listeners

Selenium RC is
slower than
WebDriver
Selenium IDE is fast
as it doesn't
as it is plugged in with
communicates directly
the web browser that WebDriver communicates directly
with
Speed launches the test. with the web browsers. Thus
the browser; rather it
Thus, the IDE and making it much faster
sends selenese
browser
commands over to
communicates directly
Selenium Core which
in turn communicates
with the browser.

7. What are the different types of locators in Selenium?

• By id
• HTML: <div id="coolestWidgetEvah">...</div>
• WebDriver:
driver.findElement( By.id("coolestWidgetEvah") );
• By name
• HTML: <input name="cheese" type="text"/>
• WebDriver: driver.findElement( By.name("cheese") );
• By Xpath
• HTML
<html>
<input type="text" name="example" />
<input type="text" name="other" />
 </html>
• WebDriver: driver.findElements( By.xpath("//input") );
• There are plug-ins for firefox/chrome to automatically display the Xpath

• By ClassName
• By TagName
• By LinkText
• By PartialLinkText
• By CSS Selector
• By DOM

8. What the difference is between assert and verify commands?

Assert: Assert command checks whether the given condition is true or false. Let’s say we
assert whether the given element is present on the web page or not. If the condition is true then
the program control will execute the next test step but if the condition is false, the execution
would stop and no further test would be executed.

Verify: Verify command also checks whether the given condition is true or false. Irrespective
of the condition being true or false, the program execution doesn’t halt i.e. any failure during
verification would not stop the execution and all the test steps would be executed.

9. How do I launch the browser using WebDriver?

The following syntax can be used to launch Browser:
WebDriver driver = new FirefoxDriver();
WebDriver driver = new ChromeDriver();
WebDriver driver = new InternetExplorerDriver();

10. What are the different types of Drivers available in WebDriver?

The different drivers available in WebDriver are:
 FirefoxDriver
 InternetExplorerDriver
 ChromeDriver
 SafariDriver
 OperaDriver
 AndroidDriver
 IPhoneDriver
 HtmlUnitDriver
11. What are the different types of navigation commands?
Following are the navigation commands:
navigate().back() – The above command requires no parameters and takes back the user to the
previous webpage in the web
browser’s history.
Sample code:
driver.navigate().back();
navigate().forward() – This command lets the user to navigate to the next web page with
reference to the browser’s history.
Sample code:
driver.navigate().forward();
navigate().refresh() – This command lets the user to refresh the current web page there by
reloading all the web elements.
Sample code:
driver.navigate().refresh();
navigate().to() – This command lets the user to launch a new web browser window and navigate
to the specified URL.
Sample code:
driver.navigate().to(“https://google.com”);

12. What is TestNG and how is it better than Junit?

TestNG is an advanced framework designed in a way to leverage the benefits by both the
developers and testers. With the commencement of the frameworks, JUnit gained enormous
popularity across the Java applications, Java developers and Java testers with remarkably
increasing the code quality. Despite being easy to use and straightforward, JUnit has its own
limitations which give rise to the need of bringing TestNG into the picture. TestNG is an open
source framework which is distributed under the Apache Software License and is readily
available for download.
 TestNG with WebDriver provides an efficient and effective test result format that can, in turn,
be shared with the stakeholders to have a glimpse on the product’s/application’s health thereby
eliminating the drawback of WebDriver’s incapability to generate test reports. TestNG has an
inbuilt exception handling mechanism which lets the program to run without terminating
unexpectedly.
There are various advantages that make TestNG superior to JUnit. Some of them are:
 Added advance and easy annotations
 Execution patterns can set
 Concurrent execution of test scripts
 Test case dependencies can be set
13. What is white box testing and list the types of white box testing?
The term ‘White Box’ is used to refer to a transparent or glass box, through which the internal
structure of a product is visible, and which allows the team to analyze, evaluate as well as
explore the workings of an application’s internal structure. White Box Testing, which is also
known as glass box testing, tests the internal structure of an application product through the
derivation of test data from the program logic.
Types of white testing:
 Unit Testing: ...
 Static and dynamic Analysis: ...
 Statement Coverage: ...
 Branch Coverage: ...
 Security Testing:
 Mutation Testing:
 Decision Coverage

Unit Testing:
The developer carries out unit testing in order to check if the particular module or unit of code is
working fine. The Unit Testing comes at the very basic level as it is carried out as and when the
unit of the code is developed or a particular functionality is built.

Static and dynamic Analysis:

Static analysis involves going through the code in order to find out any possible defect in the
code. Dynamic analysis involves executing the code and analyzing the output.

Statement Coverage:
In this type of testing the code is executed in such a manner that every statement of the
application is executed at least once. It helps in assuring that all the statements execute without
any side effect.
Branch Coverage:
No software application can be written in a continuous mode of coding, at some point we need to
branch out the code in order to perform a particular functionality. Branch coverage testing helps
in validating of all the branches in the code and making sure that no branching leads to abnormal
behavior of the application.

Security Testing:
Security Testing is carried out in order to find out how well the system can protect itself from
unauthorized access, hacking – cracking, any code damage etc. which deals with the code of
application. This type of testing needs sophisticated testing techniques.

Mutation Testing:
A kind of testing in which, the application is tested for the code that was modified after fixing a
particular bug/defect. It also helps in finding out which code and which strategy of coding can
help in developing the functionality effectively.

Besides all the testing types given above, there are some more types which fall under both Black
box and White box testing strategies such as: Functional testing (which deals with the code in
order to check its functional performance), Incremental integration testing (which deals with the
testing of newly added code in the application), Performance and Load testing (which helps in
finding out how the particular code manages resources and give performance etc.) etc.

14. What is black box testing? What are the different black box testing techniques?
BLACK BOX TESTING is defined as a testing technique in which functionality of the
Application Under Test (AUT) is tested without looking at the internal code structure,
implementation details and knowledge of internal paths of the software. This type of testing is
based entirely on software requirements and specifications. In BlackBox Testing we just focus
on inputs and output of the software system without bothering about internal knowledge of the
software.
Types of blackbox testing:

There are many types of Black Box Testing but the following are the prominent ones -

 Functional testing - This black box testing type is related to the functional requirements
of a system; it is done by software testers.
 Non-functional testing - This type of black box testing is not related to testing of
specific functionality, but non-functional requirements such as performance, scalability,
usability.
 Regression testing - Regression Testing is done after code fixes, upgrades or any other
system maintenance to check the new code has not affected the existing code
Black Box Testing Techniques:

Following are the prominent Test Strategy amongst the many used in Black box Testing

 Equivalence Class Testing: It is used to minimize the number of possible test cases to
an optimum level while maintains reasonable test coverage.
 Boundary Value Testing: Boundary value testing is focused on the values at boundaries.
This technique determines whether a certain range of values are acceptable by the system
or not. It is very useful in reducing the number of test cases. It is most suitable for the
systems where an input is within certain ranges.
 Decision Table Testing: A decision table puts causes and their effects in a matrix. There
is a unique combination in each column.

Tools used for black box testing:

 For Functional/ Regression Tests you can use - QTP, Selenium

 For Non-Functional Tests, you can use - LoadRunner, Jmeter

15. What are the different test levels?

1. Unit/component/program/module testing
2. Integration testing
3. System testing
4. Acceptance testing

Details of different Levels of Testing:

1. Unit/component testing
The most basic type of testing is unit, or component, testing.
Unit testing aims to verify each part of the software by isolating it and then perform tests to
demonstrate that each individual component is correct in terms of fulfilling requirements and the
desired functionality.
This type of testing is performed at the earliest stages of the development process, and in many
cases it is executed by the developers themselves before handing the software over to the testing
team.
The advantage of detecting any errors in the software early in the day is that by doing so the
team minimizes software development risks, as well as time and money wasted in having to go
back and undo fundamental problems in the program once it is nearly completed.
(Must read: 5 best unit testing frameworks to automate unit tests)
2. Integration testing
Integration testing aims to test different parts of the system in combination in order to assess if
they work correctly together. By testing the units in groups, any faults in the way they interact
together can be identified.
There are many ways to test how different components of the system function at their interface;
testers can adopt either a bottom-up or a top-down integration method.
In bottom-up integration testing, testing builds on the results of unit testing by testing higher-
level combination of units (called modules) in successively more complex scenarios.
It is recommended that testers start with this approach first, before applying the top-down
approach which tests higher-level modules first and studies simpler ones later.
 

3. System testing
The next level of testing is system testing. As the name implies, all the components of the
software are tested as a whole in order to ensure that the overall product meets the requirements
specified.
System testing is a very important step as the software is almost ready to ship and it can be tested
in an environment which is very close to that which the user will experience once it is deployed.
System testing enables testers to ensure that the product meets business requirements, as well as
determine that it runs smoothly within its operating environment. This type of testing is typically
performed by a specialized testing team.
 

4. Acceptance testing
Finally, acceptance testing is the level in the software testing process where a product is given
the green light or not. The aim of this type of testing is to evaluate whether the system complies
with the end-user requirements and if it is ready for deployment.
The testing team will utilize a variety of methods, such as pre-written scenarios and test cases to
test the software and use the results obtained from these tools to find ways in which the system
can be improved.
The scope of acceptance testing ranges from simply finding spelling mistakes and cosmetic
errors, to uncovering bugs that could cause a major error in the application.
By performing acceptance tests, the testing team can find out how the product will perform when
it is installed on the user’s system. There are also various legal and contractual reasons why
acceptance testing has to be carried out.

16. What Test Plans consists of?

Test plan consists the following contents:
Test Plan Identifier
Create a unique number with which to identify the plan. This number may include version
information and the level of software it’s related to.
References
A list of documents that support the test plan. These might include a project plan, functional
specifications, or corporate guidelines.
Introduction
A summary of the test plan, including the purpose of the testing project and scope.
Test Items
The systems and subsystems which will be tested.
Features To Be Tested
The individual features that will be tested within the systems/subsystems during the testing
project.
Features Not To Be Tested
A list of features that will not be tested.
Approach
The overall strategy of how the tests will be performed.
Pass/Fail Criteria
Completion criteria for the test (minimum number of defects, percentage of passed tests).
Suspension Criteria
Specify what constitutes pausing the test. This might be when a certain number of defects are
found.
Test Deliverables
The artifacts created by the testing team that are to be delivered upon completion of the test.
These could be test cases, output from testing tools, and reports.
Testing Tasks
Any dependencies or remaining activities that must be done.
Environmental Needs
Any specific tools or hardware that are needed for the tests.
Responsibilities
Who’s in charge of the test team and project? This may include training, guiding the strategy,
and identifying risks.
Staffing And Training Needs
What resources are needed? Does anyone need additional or special training in order to conduct
the test?
Schedule
Details on when the testing will take place.
Risks And Contingencies
The overall risk of the project as it pertains to testing. This might be a lack of resources or a
delayed delivering of the software from the development team.
Approvals
Who signs off on the testing project and approves it to proceed to the next step?

17. What is the difference between UAT (User Acceptance Testing) and System testing?
System Testing:
System Testing is done to check whether the software or product meets the specified
 requirements or not. It is done by both testers and developers. It contains the Tastings: System
testing, Integration Testing. It is done through more positive and negative teat cases.
Acceptance Testing:
Acceptance Testing is done after the system testing. It is used to check whether the software
meets the customer requirements or not. Acceptance testing is used by testers, stakeholders as
well as clients. It includes only Functional Testing and it contain two testing Alpha
Testing and Beta Testing.

S.NO SYSTEM TESTING ACCEPTANCE TESTING

System testing is done to check Acceptance testing is the type of testing

whether the software or product meets which is used to check whether the software
1. the specified requirements or not. meets the customer requirements or not.

System testing is used by developers Acceptance testing is used by testers,

2. as well as testers. stakeholders as well as clients.

System Testing is both functional and

3. non-functional testing. Acceptance testing is only functional testing.

System Testing is the constitute of Acceptance testing is the constitute of alpha

4. System and integration testing. and beta testing.

System testing is done before the Acceptance testing is done after the System
5. Acceptance testing. testing.

System testing is the constitute of Acceptance Testing is the constitute of

6. positive as well as negative test cases. positive test cases.

In system testing, system is checked In acceptance testing, system is checked for

7. for dummy inputs. random inputs.

18. What is the difference between test scenarios, test cases, and test script?
Test Scenarios:  A Test Scenario is any functionality that can be tested. It is also called Test
Condition or Test Possibility.
Test Cases:  It is a document that contains the steps that has to be executed, it has been planned
earlier.
Test Script:  It is written in a programming language and it's a short program used to test part of
functionality of the software system. In other words a written set of steps that should be performed
manually.

19. Explain what Test Deliverables is?

What is a deliverable ?
A deliverable is a product or outcome that is given to the client. A deliverable can be a
software product, a design document, or any other asset that is required.
Test Deliverables:
Test Deliverables are the artifacts which means “things” that are produced by people
involved in the process and are given to the stakeholders. Some deliverables are provided
before testing phase, some during the testing phase and rest after the testing cycle. The
below are the list of test deliverables.
 Test Specifications document
 Test Plan document
 Test Strategy
 Test Scenarios document
 Test Design standards
 Test Case document
 Traceability matrix
 Test execute
 ion reports
 Test logs
 Bug reports
 Test summary reports
 Test Data
 Flow document
 Test Metrics
 Test Status reports

20. What all things you should consider before selecting automation tools for the AUT?
Here are some things to consider when selecting an automated testing tool:
1.) Platforms, Technology and Types. Whether you're testing. ...
2.) Tester Skills. ...
3.) Feature-Rich. ...
4.) Manual and Automatic. ...
5.) Change Management. ...
6.) Results Management. ...
7.) Collaboration. ...
8.) Data In, Data Out

1.) Platforms, Technology and Types            

Whether you’re testing .Net, C#, or WPF applications, Windows-based or relying on the LINUX
kernel, your automated testing tool must support these systems and technologies.
Comprehensive automated testing tools that support unit, functional (or UI), regression, data-
driven, manual and distributed testing of Windows applications exist, so why not use an
integrated solution? Look for flexibility and support for unit tests created in NUnit, JUnit, DUnit,
and MSTest.
 
2.) Tester Skills           
The bench strength within any given QA department can vary considerably, and you need to take
into account the skill levels your team has. Can your tests write automated test scripts or will
they need help? Is keyword testing part of the process? If so, how well can the automated testing
applications you’re looking at handle those tasks? Your testers may have a wide range of skills, a
narrow set of skills, or something in-between with gaps here and there. Choose an automated
testing application compatible with the skill-set your QA team needs.
 
3.) Feature-Rich       
No matter where you are in the application lifecycle, one thing is clear, the app will only get
more sophisticated; it will only have more features, not less, as the application lives on.
Choose an automated testing tool that is feature-rich to keep up with the development lifecycle
and the challenges that each new waterfall release or iteration is certain to bring. Look for the
ability to implement checkpoints to verify values, databases, or key functionality in your
applications.
 
4.) Manual and Automatic                     
Look for automated testing tools that support record-and-playback test creation and manual
creation options.
 
5.) Change Management   
Over time, it's certain that some changes will need to be made in the application’s user interface
(UI). Choose automated testing tools that won’t break down and fail when the UI changes. You
want an automated testing tool that is easily maintained and whose tests can be reused as long as
possible.
 
6.) Results Management     
You want to be able to see the results of your testing clearly. Logs, dashboards, and other
instrumentation that automatically records and logs report results make managing the testing
process smoother and more effective from start to finish.
 
7.) Collaboration   
The ability for testers to share their work and have developers and other colleagues share theirs
too is invaluable. Look for automated testing applications that can support concurrent work with
project files, sharing script code among several projects and integration with source code control
and issue-tracking systems.
 
8.) Data In, Data Out               
Data sources and the venues to which you need to provide data are in constant flux. Look for an
automated testing tool that can provide reports in XML+HTML, Excel, and MHT. The ability to
intake data from multiple sources, such as text and XML files, Excel worksheets , and databases,
like SQL Server, Oracle, and MySQL, also make the tool more valuable.
Prepare a list of the capabilities and features you’d like to have in your automated testing tool.
Identify which are “must-haves” and which are “nice-to-haves.” Leave a little space on the list
for the stuff you’ll soon discover along the way but you don’t know you want yet.

21. How will you conduct Risk Analysis?

You do a Risk Analysis by identify threats, and estimating the likelihood of those threats being
realized. Once you've worked out the value of the risks you face, you can start looking at ways
to manage them effectively. This may include choosing to avoid the risk, sharing it, or accepting
it while reducing its impact.
While a test plan is being created, risks involved in testing the product are to be taken into
consideration along with possibility of their occurrence and the damage they may cause along
with solutions; if any. Detailed study of this is called as Risk Analysis.

Some of the risks could be:

- New Hardware
- New Technology
- New Automation Tool
- Sequence of code delivery
- Availability of application test resources
- Identify and describe the risk magnitude indicators: High, Medium and Low
High magnitude means the effect of the risk would be very high and non-tolerable. Company
may face severe loss and its reputation is at risk. Must be tested.

Medium: tolerable but not desirable. Company may suffer financially but there is limited
liability or loss of reputation. Should be tested.
Low: tolerable. Little or no external exposure. Little or no financial loss. Company’s reputation
unaffected. Might be tested.

Three perspectives of Risk Assessment: Effect, Cause and Likelihood.

- To assess risk by Effect, identify a condition, event or action and try to determine its impact.
- To asses risk by Cause is opposite of by Effect. Begin by stating an undesirable event or
condition and identify the set of events that could have permitted the condition to exist.
- To asses risk by Likelihood is to determine the probability that a requirement will not be
satisfied.
22. Explain what Test Plan is? What is the information that should be covered in Test Plan?
A TEST PLAN is a detailed document that describes the test strategy, objectives, schedule,
estimation and deliverables and resources required for testing. Test Plan helps us determine the
effort needed to validate the quality of the application under test. The test plan serves as a
blueprint to conduct software testing activities as a defined process which is minutely monitored
and controlled by the test manager.
23. What are the important steps that are covered in Functional testing?

What is Functional Testing?

FUNCTIONAL TESTING is a type of software testing that validates the software system
against the functional requirements/specifications. The purpose of Functional tests is to test each
function of the software application, by providing appropriate input, verifying the output against
the Functional requirements.

Functional testing mainly involves black box testing and it is not concerned about the source
code of the application. This testing checks User Interface, APIs, Database, Security,
Client/Server communication and other functionality of the Application Under Test. The testing
can be done either manually or using automation.

What do you test in Functional Testing?

The prime objective of Functional testing is checking the functionalities of the software system.
It mainly concentrates on -
  Mainline functions:  Testing the main functions of an application
 Basic Usability: It involves basic usability testing of the system. It checks whether a user
can freely navigate through the screens without any difficulties.
 Accessibility:  Checks the accessibility of the system for the user
 Error Conditions: Usage of testing techniques to check for error conditions.  It checks
whether suitable error messages are displayed.

How to perform Functional Testing: Complete Process

In order to functionally test an application, the following steps must be observed.

 Understand the Software Engineering Requirements

 Identify test input (test data)
 Compute the expected outcomes with the selected test input values
 Execute test cases
 Comparison of actual and computed expected result

24. Explain the difference between Functional testing and Non-Functional testing.

Functional Vs Non-Functional Testing:

Functional Testing Non-Functional Testing

Functional testing is performed using the Non-Functional testing checks the  Performance,
functional specification provided by the client reliability, scalability and other non-functional aspects
and verifies the system against the functional of the software system.
requirements.

Functional testing is executed first Non-functional testing should be performed after

functional testing

Manual Testing or automation tools can be Using tools will be effective for this testing
used for functional testing

Business requirements are the inputs to Performance parameters like speed, scalability are
functional testing inputs to non-functional testing.

Functional testing describes what the product Nonfunctional testing describes how good the product
does works

Easy to do Manual Testing Tough to do Manual Testing

Examples of Functional testing are Examples of Non-functional testing are

 Unit Testing  Performance Testing

 Smoke Testing  Load Testing
 Sanity Testing  Volume Testing
 Integration Testing  Stress Testing
 White box testing  Security Testing
 Black Box testing  Installation Testing
 User Acceptance testing  Penetration Testing
 Regression Testing  Compatibility Testing
 Migration Testing
 
 25. How is ‘Build’ different from ‘Release’?
A “build” is given by dev team to the test team. A “release” is formal release of the product to
its customers.

A build when tested and certified by the test team is given to the customers as “release”. A
“build” can be rejected by test team if any of the tests fail or it does not meet certain
requirements. One release can have several builds associated with it.
26. What are the important points that should be considered while writing Test Cases?
When writing test cases for your project, it’s often easy to forget what is important. This article
is aimed at reminding experienced testers or informing new ones of what the key items are, to
ensure we are being efficient in writing our tests.
The End User is key
Who will be executing the test scripts? Will the scripts form part of a Regression Pack? Will the
scripts be used for anything else (e.g. training manuals)?
These questions are meant to kick start your thought process. Essentially, the person who writes
the test is not always the person who executes it. As such, Test Cases need to be written so that
anyone of any level can read, understand and be able to execute the test case. The aim of this is
that no matter the level of the tester, the outcome will always be the same. When writing your
test, if you approach this with ‘baby-steps’ in mind and make no assumptions that the person
who executes it is has any prior knowledge of the project, and you shouldn’t go far wrong. 
Unique, Measurable, Specific (UMS)
Every single test case should be Unique, Measurable and Specific. If you aren’t quite clear what
this means, I’ve defined this below for you.

 Unique – There should only be one test with a particular objective in the scenario you are
writing it for.
 Measurable – You should be able to say at the end of the test whether it has passed or not.
The objective should be very clear and each Input and Expected Output should marry up
concisely.
 Specific – Each test case must be written to test a particular function or action. A good
test case is usually brief and to the point.
Where possible, keep test cases reasonably short. A long number of test steps can add
complexity to the scenario, it can make the tester feel like they’ve been executing the same test
forever and it can affect the accuracy of progress and defect reporting. Break your test scripts
down into smaller scenarios if possible and although this will mean more test cases, they will be
quicker to execute and will produce more accurate statistics of test results.
Data
The inclusion of data in your test steps can be very useful. It saves time and energy sourcing the
test data. It makes test execution more efficient.
Before you do this though, you need to understand a few things. Can the data go out of date? Is a
database refresh likely to occur? If the data is likely to change however it may be easier to create
a database or reference sheet to store your test data in one place. This means that if you need to
change the data, you can do it in one place rather than have to trawl through your test cases to
make the change individually. 
Test Case Layout
Test Management tools often cater for the information which should go into a test case by
providing fields for testers to enter the details which need.
Those who have completed their ISTQB Foundation course will know that IEEE829 states that
the following should be included in a Test Case:

 Test Case Specification Identifier

 Test Items
o Describe features and conditions tested
 Input Specifications
o Data Names
o Ordering
o Values (with tolerances or generations procedures)
o States
o Timing
 Output Specifications
o Data Names
o Ordering
o Values
o States (with tolerances or generations procedures)
o Timing
 Environmental Needs
o Hardware
o Software
o Other
 Special Procedural Requirements
 Inter-case Dependencies
Consider the approach
You may also need to consider using different approaches, dependant on the delivery
methodology being used and to ensure your test scripts are maintainable. Using a Behaviour
Driven Development (BDD) approach for your test scripting makes it easier to automate your
test scripts at a later date, enabling the automation team to pick up your manual BDD scripts and
convert them in to code. BDD scripts are also usually written from an end users perspective,
which helps if the scripts are to be reused for UAT - saving valuable time and effort.