MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION

(Autonomous) (Autonomous)
(ISO/IEC - 27001 - 2013 Certified) (ISO/IEC - 27001 - 2013 Certified)

Winter – 19 EXAMINATION c Enlist any two activities involved in test planning. 2M

Subject Name: Software Testing Model Answer Subject Code: 22518 Ans 1. Scope Management: Deciding what features to be tested and not to be Any two
tested. activities 2M
Important Instructions to examiners:
1) The answers should be examined by key words and not as word-to-word as given in the 2. Deciding Test approach /strategy: Which type of testing shall be done
model answer scheme. like configuration, integration, localization etc.
2) The model answer and the answer written by candidate may vary but the examiner may try
to assess the understanding level of the candidate. 3. Setting up criteria for testing: There must be clear entry and exit
3) The language errors such as grammatical, spelling errors should not be given more criteria for different phases of testing. The test strategies for the various
Importance (Not applicable for subject English and Communication Skills. features and combinations determined how these features and
4) While assessing figures, examiner may give credit for principal components indicated in the combinations would be tested.
figure. The figures drawn by candidate and model answer may vary. The examiner may give
credit for any equivalent figure drawn. 4. Identifying responsibilities, staffing and training needs.
5) Credits may be given step wise for numerical problems. In some cases, the assumed constant d Enlist objectives of software testing. 2M
values may vary and there may be some difference in the candidate’s answers and model
Ans Objectives of software testing are as follows: Any two
answer.
6) In case of some questions credit may be given by judgement on part of examiner of relevant 1. Finding defects which may get created by the programmer
while developing the software. Objectives 2M
answer based on candidate’s understanding.
7) For programming language papers, credit may be given to any other program based on 2. Gaining confidence in and providing information about the
equivalent concept. level of quality.
3. To prevent defects.
Q. Sub Answer Marking 4. To make sure that the end result meets the business and user
No Q. Scheme
requirements.
. N.
5. To ensure that it satisfies the BRS that is Business
1. Attempt any Five of the following: 10 M
Requirement Specification and SRS that is System
a Define static and dynamic testing. 2M
Requirement Specifications.
Ans Static testing: 1 M for each
6. To gain the confidence of the customers by providing them
In static testing code is not executed. Rather it manually checks the definition
a quality product.
code, requirement documents, and design documents to find errors. e Define Defect. 2M
Main objective of this testing is to improve the quality of software Ans It refers to the several troubles with the software product, with its Correct
products by finding errors in early stages of the development cycle. external behavior or its internal features. Definition 2M
Dynamic testing: OR
The dynamic testing is done by executing program. Main objective A defect is an error in coding that causes a program to fail or to
of this testing is to confirm that the software product works in produce incorrect /unexpected results.
conformance with the business requirements. f State any four advantages of using tools. 2M
b Ans Save Time /Speed: Due to advanced computing facilities, Any 4 advantages
State any two examples of integration testing. 2M
Ans 1. Verifying the interface link between the login page and the Any two similar automation test tools prevail in speed of processing the tests. : ½ M for each
home page i.e. when a user enters the credentials and logs it example:2M Automation saves time as software can execute test cases faster than
should be directed to the homepage human.
2. Check the interface link between the Login and Mailbox Reduces the tester’s involvement in executing tests: It relieves
module the testers to do some other work.
3. Check the interface link between the Mailbox and Delete
Mails Module. Repeatability/Consistency: The same tests can be re-run in exactly
4. Verifying the interface link between the home page and the the same manner eliminating the risk of human errors such as testers
profile page i.e. profile page should open up. forgetting their exact actions, intentionally omitting steps from the
test scripts, missing out steps from the test script, all of which can

1|3 3 2|3 3
 MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous) (Autonomous)
(ISO/IEC - 27001 - 2013 Certified) (ISO/IEC - 27001 - 2013 Certified)

d State any eight limitations of manual testing. 4M

Stubs Drivers Ans 1. Manual testing is slow and costly. Any 8 points 1/2
2. It is very labor intensive; it takes a long time to complete M for each point
Stubs are dummy modules Drivers are dummy tests.
that always used to simulate modules that always 3. Manual tests don’t scale well. As the complexity of the
the low level modules. used to simulate the software increases the complexity of the testing problem
high level modules. grows exponentially. This leads to an increase in total time
devoted to testing as well as total cost of testing.
Stubs are the called Drivers are the calling 4. Manual testing is not consistent or repeatable. Variations in
how the tests are performed as inevitable, for various
programs. programs.
reasons. One tester may approach and perform a certain test
differently from another, resulting in different results on the
Stubs are used when sub Drivers are only used
same test, because the tests are not being performed
programs are under when main programs are identically.
construction. under construction. 5. Lack of training is the common problem.
6. GUI objects size difference and color combinations are not
Stubs are used in top down Drivers are used in easy to find in manual testing.
approach. bottom up integration. 7. Not suitable for large scale projects and time bound projects.
8. Batch testing is not possible, for each and every test
c State the contents of ‘Test Summary Reports’ used in test 4M execution Human user interaction is mandatory.
reporting. 9. Comparing large amount of data is impractical.
10. Processing change requests during software maintenance
Ans Test reporting is a means of achieving communication through the Explanation4 M takes more time.
testing cycle. There are 3 types of test reporting.
1. Test incident report: 3. Attempt any Three of the following: 12M
2. Test cycle report: a Describe the use of decision table in black box testing with the 4M
3. Test summary report: help of suitable example.
Test summary Report: The final step in a test cycle is to Ans I.Decision table testing is black box test design technique to Use of decision
recommend the suitability of a product for release. A report that determine the test scenarios for complex business logic. table in black box
summarizes the result of a test cycle is the test summary report. ii. Decision tables provide a systematic way of stating complex testing with
There are two types of test summary report: business rules, which is useful for developers as well as for testers. example 4M
1. Phase wise test summary, which is produced at the end of every iii. Decision tables can be used in test design whether or not they are
phase. used in specifications, as they help testers explore the effects of
2. Final test summary report, which has all the details of testing done combinations of different inputs and other software states that must
by all phases. A Summary report should present correctly implement business rules.
1. Test Summary Report Identifier iv. It helps the developers to do a better job can also lead to better
2 Description: Identify the test items being reported in this report relationships with them.
with test id v. Testing combinations can be a challenge, as the number of
3 Variances: Mention any deviation from test plans, test procedures, combinations can often be huge.
if any. vi. Testing all combinations may be impractical if not impossible.
4 Summary of results: All the results are mentioned here with the vii. We have to be satisfied with testing just a small subset of
resolved incidents and their solutions. combinations but making the choice of which combinations to test
5 Comprehensive assessment and recommendation for release and which to leave out is also important.
should include: Fit for release assessment and recommendation of
release.

5|3 3 6|3 3
 MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous) (Autonomous)
(ISO/IEC - 27001 - 2013 Certified) (ISO/IEC - 27001 - 2013 Certified)

 The skill is relatively easy to learn, and once you've attained riskier the project will be—and, at the same time, the less
some mastery your quick-attack session will probably valuable this technique will be.
produce a few bugs. d) State-Transition Diagrams
 Finally, quick attacks are quick. In this technique the state transition diagram is prepared with respect
 They can help you to make a rapid assessment. You may not to the applied inputs and produced output. It clearly shows how the
know the requirements, but if your attacks yielded a lot of state transition of software takes place from one to another and
bugs, the programmers probably aren't thinking about hence can be useful to find the defects.
exceptional conditions, and it's also likely that they made One of the example is as shown in the diagram below:
mistakes in the main functionality.
 If your attacks don't yield any defects, you may have some
confidence in the general, happy-path functionality.
ii. Weaknesses
 Quick attacks are often criticized for finding "bugs that don't
matter"— especially for internal applications.
 While easy mastery of this skill is strength, it creates the risk
that quick attacks are "all there is" to testing; thus, anyone Figure 4: State Transition Map
who takes a two day course can do the work. i. Strengths
b) Equivalence and Boundary Conditions  Mapping out the application provides a list of immediate,
i. Strengths powerful test ideas.
 Boundaries and equivalence classes give us a technique to  Model can be improved by collaborating with the whole
reduce an infinite test set into something manageable. team to find "hidden" states—transitions that might be
 They also provide a mechanism for us to show that the known only by the original programmer or specification
requirements are "covered". author.
ii. Weaknesses  Once you have the map, you can have other people draw
 The "classes" in the table in Figure 1 are correct only in the their own diagrams, and then compare theirs to yours.
mind of the person who chose them.  The differences in those maps can indicate gaps in the
 We have no idea whether other, "hidden" classes exist—for requirements, defects in the software, or at least different
example, if a numeric number that represents time is expectations among team members.
compared to another time as a set of characters, or a "string," ii. Weaknesses
it will work just fine for most numbers.  The map you draw doesn't actually reflect how the software
c) Common Failure Modes will operate; in other words, "the map is not the territory."
i. Strengths  Drawing a diagram won't find these differences, and it might
 The heart of this method is to figure out what failures are even give the team the illusion of certainty.
common for the platform, the project, or the team; then try  Like just about every other technique on this list, a state-
that test again on this build. transition diagram can be helpful, but it's not sufficient by
 If your team is new, or you haven't previously tracked bugs, itself to test an entire application.
you can still write down defects that "feel" recurring as they e) Use Cases and Soap Opera Tests
occur—and start checking for them. Use cases and scenarios focus on software in its role to enable a
ii. Weaknesses human being to do something.
 In addition to losing its potency over time, this technique i. Strengths
also entirely fails to find "black swans"—defects that exist  Use cases and scenarios tend to resonate with business
outside the team's recent experience. customers, and if done as part of the requirement process,
 The more your team stretches itself (using a new database, they sort of magically generate test cases from the
new programming language, new team members, etc.), the requirements.

9|3 3 10 | 3 3
 MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous) (Autonomous)
(ISO/IEC - 27001 - 2013 Certified) (ISO/IEC - 27001 - 2013 Certified)

evaluate it with expected behavior. It includes black box testing d) A number of test tools cannot distinguish between a product
methodology such as system testing and unit testing. failure and a test failure. This increases analysis time and manual
The testing methods evaluate the product with respect to testing. The test tools may not provide the required amount of
requirements defined; designs created and mark it as pass or fail. trouble-shooting/debug/error messages to help in analysis.
3.Operational techniques: Operational techniques typically For example, in case of GUI testing, the test tools may determine
include auditing work products and projects to understand the results based on messages and screen coordinates at run-time.
whether the processes defined for development /testing are Hence, if the screen elements of the product are changed, it requires
being followed correctly or not, and also whether they are the test suite to be changed. The test tool must have some
effective or not. It also includes revisiting the defects before and intelligence to proactively find out the changes that happened in the
after fixing and analysis. Operational technique may include product and accordingly analyze the results.
smoke testing and sanity testing of a work product. 2) Technology Expectations:
d Enlist factors considered for selecting a testing tool for test 4M a) In general, test tools may not allow test developers to extend /
automation. modify the functionality of the framework. So, it involves going
Ans The following factors are important during tool selection: Any relevant back to the tool vendor with additional cost and effort. Very few
i. Assessment of the organization’s maturity (e.g. readiness for factors minimum tools available in market provide source code for extending
change); 4M functionality or fixing some problems. Extensibility and
ii. Identification of the areas within the organization where tool customization are important expectations of a test tool.
support will help to improve testing processes; b) A good number of test tools require their libraries to be linked
iii. Evaluation of tools against clear requirements and objective with product binaries. When these libraries are linked with the
criteria; source code of the product, it is called as the “instrumented code”.
iv. Proof-of-concept to see whether the product works as desired This causes portion of testing be repeated after those libraries are
and meets the requirements and objectives defined for it; removed, as the results of certain types of testing will be different
v. Evaluation of the vendor (training, support and other and better when those libraries are removed. For example, the
commercial aspects) or open-source network of support; instrumented code has a major impact on the performance testing
vi. Identifying and planning internal implementation (including since the test tools introduce an additional code and there could be
coaching and mentoring for those new to the use of the tool). a delay in executing the additional code.
c) Finally, test tools are not 100% cross-platform. They are
OR supported only on some O.S. platforms and the scripts generated
from these tools may not be compatible on other platforms.
The industry experts have suggested following four major Moreover, many of the test tools are capable of testing only the
criteria for selection of testing tools. product, not the impact of the product/test tool to the system or
1) Meeting requirements. network. When there is an impact analysis of the product on the
2) Technology expectations. network or system, the first suspect is the test tool and it is
3) Training / skills. uninstalled when such analysis starts.
4) Management aspects. 3) Training Skills:
1) Meeting Requirements: Test tools require plenty of training, but very few vendors provide
a) There are many tools available in the market today but rarely do the training to the required level. Organization-level training is
they meet all the requirements of given product or a given needed to deploy the test tools, as the users of the test suite are not
organization. Evaluating different tools for different requirements only the test team but also the development team and other areas like
involves lot of effort, money and time. Huge delay is involved in SCM (Software Configuration Management). Test tools expect the
selecting and implanting test tools. users to learn new language/scripts and may not use standard
b) Test tools may not provide backward or forward compatibility languages/scripts. This increases skill requirements for automation
with the product-under-test (PUT). and increases the need for a learning curve inside the organization.
c) Test tools may not go through the same amount of evaluation for 4) Management Aspects:
new requirements. For example: some tools had Y2K-problem.

13 | 3 3 14 | 3 3
 MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous) (Autonomous)
(ISO/IEC - 27001 - 2013 Certified) (ISO/IEC - 27001 - 2013 Certified)

It captures all the relevant information of defect repository for a c Describe the process of preparing summary report in test 4M
product. The information that a defect repository includes planning.
 Defect details Ans Preparing test summary report Process of
 Defect test detail At the completion of a test cycle, a test summary report is produced. preparing
 Fix details This report gives insights to the senior management about the fitness summary report
 Communication of the product for release. There are two types of reports that are in test planning
2. Defect repository required: 4M , any other
It captures all the relevant information of defect repository for a 1. The Incident Report relevant answer
product. The 2. Test Cycle Report shall be given
information that a defect repository includes 3. Test Summary Report Marks.
 Defect details A summary report should present the following things:
 Defect test detail 1. A summary of the activities carried out during the test cycle;
 Fix details 2. Variance of the activities carried out from the activities planned;
3. Summary of results should include tests that failed and severity
 Communication
of impact of defect;
3. Configuration Management (CM) repository and tool
4.Comprehensive assessment and recommendation for release
Software Configuration Management is defined as a process to
should include “Fit for release” assessment and Recommendation of
systematically manage, organize, and control the changes in the
release
documents, codes, and other entities during the Software
Development Life Cycle.
It keeps track of change control and version control of all the
files/entities that make up a software product. Change control
ensures that
 Changes to test files are made in a controlled fashion and
only with proper approvals
 Change are made by one test engineer are not accidently
lost or overwritten by other changes
 Each change produces distinct version of the file that is
re-creatable at any point of time
 Everyone gets access to only the most recent version of
the test files.

d Describe object oriented metrics in testing. 4M

Ans Object oriented metrics in testing: Any 4 object
oriented metrics
OBJECT-ORIENTED METRICS AND MEASURES in testing 4M;
Relevant answer
As object-oriented approach emerged to support major applications, shall be given
the effectiveness of applying traditional software metrics to Marks.

17 | 3 3 18 | 3 3
 MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous) (Autonomous)
(ISO/IEC - 27001 - 2013 Certified) (ISO/IEC - 27001 - 2013 Certified)

testing is required to understand the behavior of a system in login

this situation. message
 Disaster Recovery /Business continuity testing: When the
client server are communicating with each other , there exit
a possibility of breaking of the communication due to
various reasons or failure of either client or server or link Message
It should
connecting them. The requirement specifications must displayed
describe the possible expectations in case of any failure. not
Password Invalid as invalid
TC3 accept Pass
field password login or
 Testing for extended periods: In case of client server the valid
wrong
applications generally server is never shutdown unless there password
is some agreed Service Level Agreement (SLA) where password.
server may be shut down for maintenance. It may be
expected that server is running 24X7 for extended period. Date
One needs to conduct testing over an extended period to format
understand if service level of network and server deteriorates not It should
Date of Accepted
over time due to some reasons like memory leakage. TC4 before accept Pass
Compatibility Testing: Client server may be put in different journey the date
the date
environments when the users are using them in production. Servers current
may be in different hardware, software, or operating system
date
environment than the recommended. Other testing such as security
testing and compliance testing may be involved if needed, as per
Date
testing and type of system.
format,
5. Attempt any Three of the following: 12M Date of date It should
Accepted
a Design test cases for railway reservation system. 4M TC5 return greater accept Pass
the date
Ans Test cases for railway reservation system: Any 6 valid test journey than the the date
cases :6 M, 1 M date of
Test each Any other
Test case Input Expected Actual Stat journey
case relevant test
objective data result result us
ID Cases shall be Accepted
considered Valid
Boarding It should the
Any TC6 boarding Pass
It should It station accept boarding
valid station
Login accept accepted station
TC1 login Pass
field the login the login
name It should
name name
(abcxyz) Valid accept Train
Train
TC7 train the valid number Pass
It should It number
number train accepted
Password Valid accept accepted
TC2 Pass number
field password the valid the valid
password password; b With respect to GUI testing write the test cases for Amazon 4M
successful login form.

21 | 3 3 22 | 3 3
 MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous) (Autonomous)
(ISO/IEC - 27001 - 2013 Certified) (ISO/IEC - 27001 - 2013 Certified)

It
Proper
Radio should
radio
button select
button
should be the Pass
is
selected. proper
selecte
Gender F or M radio
d
TC3 field button
Date
format
It
not Accept
should
before ed the Pass
accept
the date
date
Date of current
TC4 admission date
It
should
Any accept
numerica the Accept
l data number ed the Pass
greater greater age
than or than or
6. Attempt any Three of the following: 12M
equal to equal to
a Design test cases for hostel admission form of your institute. 4M
TC5 Age field 16 16
Ans 6 test cases of
Valid It
Test test cases for
Test case Input Expecte Actual Statu alpha should Accept
case hostel admission
objective data d result result s numeric accept ed the Pass
ID form of institute :
Address character the address
Any 6 M; 1M each;
It Student TC6 field s address
valid any other valid
should s name It
alphabeti test cases shall be Pin
accept is Pass Valid 6 should
cal considered code
the accepte digits accept Pass
Student character accepte
name d numeric the valid
TC1 name field s (John) d
TC7 Pin code format pin code
It
should b 4M
It Design a test plan along with the test cases for edit function in
Date accept
accepte notepad.
format the date
d the Pass Ans Any 3 valid test
before less than
valid cases 3 M ; 1M
the the
date each for edit
Date of current current
function in
TC2 birth field date date
notepad test plan
3M

25 | 3 3 26 | 3 3
 MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous) (Autonomous)
(ISO/IEC - 27001 - 2013 Certified) (ISO/IEC - 27001 - 2013 Certified)

3 copy the text Test engineer 1

5 find the text Test engineer 2
6 replacing text Test engineer 2
7 delete the selected Test engineer 2
text
Staffing and Training Needs
To perform the tasks, you need to have the following knowledge and
skills:

 knowledge and practical application of the notepad;

 knowledge and ability to apply in practice the basic
techniques of test design
 Knowledge of various types of testing including functional
and non-functional.
Schedule
The deadline for completion of all works and delivery of the project
is 06/12/2019 by 5.00pm
Risks and Contingencies
Possible risks during testing:
 Insufficient human resources for testing the application in
deadlines.
 Changing the requirements for the product
Approvals
Team Lead
Test engineer 1
Test engineer 2 OR
Test engineer 3
Test engineer 4

c Draw a diagram for defect life cycle and write example for
defect template.
Ans Defect life cycle Defect life cycle
diagram : 3 M;
defect template :
3M

29 | 3 3 30 | 3 3
 MAHARASHTRA STATE BOARD OF TECHNICAL EDUCATION
(Autonomous)
(ISO/IEC - 27001 - 2013 Certified)

Attachm
ents

Remarks Causes inconvenience to the user in terms of limited cash

withdrawal options.

Defect High
Severity

Defect High
Priority

Reported Test Engineer1

By

Assigned XYZ
To

Status Assigned

33 | 3 3