MAHARAS HTRA S TATE BOARD OF TECHN ICAL EDUC ATION

(Autonomous)
(IS O/IEC - 27001 - 2005 Certified)

SUMMER – 12 EXAMINATION
Subject Code : 12258 Model Answer Page No : 1/ 16

Q 1. Attempt any FIVE of the following:

a) Definition of bug 2 marks, reasons for bug 2 marks

Bug: All software problems irrespective of big, small, intended unintended etc are called bugs. A
software bug occurs when one or more of the following rules is true

i. The software doesn’t do something that the product specification says it should do.

ii. The software does something that the product specification says it shouldn’t do.

iii. The software does something that the product specification doesn’t mention.

iv. The software doesn’t do something that the product specification doesn’t mention but
should

v. The software is difficult to understand, hard to use, slow to test from the tester’s view and
from the end user’s point just plain not right.

b) Static testing definition 1 mark, example 1 mark

Dynamic testing definition 1 mark, example 1 mark

Static Testing: Static testing refers to testing something that’s not running, examining and reviewing
it. One of the examples is the static black-box testing. The specification is a document, not an
executing program, so it is considered static. It’s also something that is created using data from many
sources- usability study, focus groups, marketing inputs etc, We need not know the process used to
attain the same. We can just take that document, perform static black-box testing and carefully
examine it for bugs.

Dynamic testing is what we would normally think as testing, running and using the software. The
example is dynamic white-box testing. Since this is dynamic, it must be about looking inside the box,
examining the code and watching it during run. It is also called as structural testing as we can see and
use the underlying structure of the code to the design and run effective test. This includes directly
testing low level functions, procedures subroutines, libraries etc.

c) Each diff 1 Mark (any four)

Difference between peer review and walkthrough

Peer Review Walk Through

i. First formal review, an effort to get i. This is conducted after the peer review
together the team members. by other programmers and testers

ii. It is the best formal method also ii. It is an exhaustive exercise with senior
known as ‘buddy reviews’ programmers involved for review.

iii. Often held with programmers who iii. Here programmers should present line
have written the code with other by line , function by function to
programmers acting as reviewers reviewers who will listen and question
for bugs
 MAHARAS HTRA S TATE BOARD OF TECHN ICAL EDUC ATION
(Autonomous)
(IS O/IEC - 27001 - 2005 Certified)

SUMMER – 12 EXAMINATION
Subject Code : 12258 Model Answer Page No : 2/ 16
iv. The development team reviews for iv. Presenter’s report is reviewed by testers
problems and oversights and plan for addressing bugs discovered

d) Explanation 4 marks

Standard Hardware Configuration: Standard Hardware Configuration is crucial for successful testing
and future functioning of software with reliability. If the bug is specific to hardware, manufactures
website should be referred for reporting problems to them. It is proper to mention hardware
specification on which software successfully functions. Many companies have separate staff to assist
software companies to work with their hardware. Test software may be provided to companies with
supporting details to help them to isolate problems

It is better to choose few configurations for test run of entire course of project. Full test pass, smaller
and small tests to confirm bug fixes. Eventually we get to a point where there are bugs or bugs that
still exist are in uncommon or unlikely test configurations.

For offering hardware configuration and to avoid different hardware setups following ideas, may be
used

i. Buy configurations which can and will use more often

ii. Contact hardware manufacturers if they can lend or give hardware for testing new software
which can be assured that many will use this for them. Good to build such relationships.

iii. Send mails to everyone asking them to allow test run. This can help in cheaper attempt to get
proper hardware configuration.

e) Definition 2 marks, example 2 marks

Gray-Box Testing: Gray –box testing is a mixture of black-box and white-box testing.

It is to straddle the line between the black-box and white –box testing.

Example of gray-box testing can be the HTML web page testing. HTML isn’t a programming language ,
but a markup language.

Gray-box testing can be an effective tester for non programming tools.

f) explanation of localization 2 marks, issues in localization 2 marks

Localization: Localization is the process of adapting software to a specific locale, taking into account
language, dialect, local conventions, culture etc.

Testing such software is called “localization testing”.

Some of the main issues involved in localization are translation, test expansion (ASCII, DBCS, and
UNICODE etc) which are half of the issues.

Other issues include contents, data formats, configuration, and compatibility issues and data
compatibility.
 MAHARAS HTRA S TATE BOARD OF TECHN ICAL EDUC ATION
(Autonomous)
(IS O/IEC - 27001 - 2005 Certified)

SUMMER – 12 EXAMINATION
Subject Code : 12258 Model Answer Page No : 3/ 16

g) Explanation 4 marks

Goal of Test case planning: In disciplined developed models, testing becomes easier because their
formal documentation such as specification, design, architecture and programming becomes a true
process.

Careful and methodical test cases planning are important for the following reasons.

i. Organization – Organize such that all testers and members can effectively review.

ii. Repeatability – Rerun several times to look for new bugs and fix

iii. Tracking- keeping track of number of test cases run, passed or failed, skipped etc.

iv. Proof of testing- Software team must provide a proof of runs planned for tests. Proper test
case planning and tracking provides a means of proving what was tested.

Above test plan achieves the objectives of efficiency and predictability.

Q. 2 Attempt any four

a) Explanation 4 marks

If you decide not to test every possible test scenario, you have chosen to take on risk ex:- In calculator if
you choose not to test 1024 + 1024 =2048 ? It is possible that programmer accidently left in a bug for
that situation.

If you do not test it, a customer will still use it and discover bugs. And it shall be costly bugs

If you attempt to test everything costs go up dramatically and number of missed bugs decline to
point that it is no longer cost effective to continue.

You can’t test everything and if you do not, you will likely miss bugs.

When product has to be released so you will need to stop testing but if you stop to soon then there
will still areas untested. One key concept that software testers need to learn how to reduce the huge
domain of possible set tests into manageable set and how to make wise risk-based decision on what
is important to test and what is not.

Q.2 (b) each attributes ½ marks (any eight)

List of specific attributes: A good product specification has eight important attributes:

1. Complete
2. Accurate
3. Precise, Unambiguous and clear
4. Consistent
5. Relevant
6. Feasible
7. Code-free
8. Testable
 MAHARAS HTRA S TATE BOARD OF TECHN ICAL EDUC ATION
(Autonomous)
(IS O/IEC - 27001 - 2005 Certified)

SUMMER – 12 EXAMINATION
Subject Code : 12258 Model Answer Page No : 4/ 16

Q.2 (c) each comparison error 1 mark, each control flow error 1 mark (any two for each)

1. Is there any comparison between variables having different data types such as comparing character
string to an address/date or number?

2. Are they mixed mode comparisons or comparisons’ between variables of different length?

3. Are comparison operators correct? Programmers frequently confuse such relation as at most, sat
least, greater than, not less than, less than or equal.

4. Does each Boolean expression state what is supposed to state? Programmer often make mistake
when writing logical expression such as and, or and not.

5. Are comparisons between fractional and floating-point values? Is 1.0000001close enough 1.0000002
to be equal ?

6. Are the operands of Boolean operator Boolean? For ex. Are integer variables containing integer
values being used in Boolean calculations?

[Write any two errors]

Control flow errors: These are result of loops and other control constructs in language not behaving as
expected. They are directly or indirectly due to comparison or computational errors.

1. If language contains statements groups such as begin---end and do--- while, are they ends
explicit and do they match their appropriate groups?

2. Will program, module, subroutine or loop eventually terminate?

3. Is there a possibility of premature loop?

4. Is it possible that loop never executes?

5. If the program contains a multi-way branch such as switch---case statement, can the index
variable ever exceed the number of branch possibilities? If it does, is this case handled
properly?

6. Are there any “off by one” errors that would cause unexpected flow through the loops?

[Write any two errors.]

Q-2(d) each benefit 1 mark

Benefits of automation and tools are:

1. Speed:- Think about how long it would take you to manually try a few thousands tests cases for
windows calculator. You might average a test case every 5 seconds and so automation might be able
to run 10,000 even 1000 times that fast

2. Efficiency: While you are busy running test cases; you can’t doing anything else if you have a test
tools that reduces time it takes for you to run your tests and you have more time for test planning
and thinking for new test cases.
 MAHARAS HTRA S TATE BOARD OF TECHN ICAL EDUC ATION
(Autonomous)
(IS O/IEC - 27001 - 2005 Certified)

SUMMER – 12 EXAMINATION
Subject Code : 12258 Model Answer Page No : 5/ 16
3. Accuracy and precision: After trying a few hundred cases, your attention span d will decrease and you
shall start to make mistake. But a test tool will perform the same test and check result perfectly each
and every time.

4. Relentlessness: Test tools and automation never tire or give up. They are like that battery-operated
bunny of T.V. commercials they can keep going and going.

Q-2(e) explanation 4 marks

User Interface: The windows calculator has two views: standard and scientific

User can decide which one thy need for their tasks or the one they are most comfortable.

With flexibility comes complexity

Flexibility software provides more options

It contains

1. State jumping: Flexible software provides more options and more ways to accomplish the same task.
the result is additional paths among the different states of software then your state transition
diagram can became much more complex and you will need to spend more time deciding which
interconnecting paths should be tested.

2. State termination and skipping: this is most evident when software has power user model where who
is familiar with software can skip numerous prompts as windows and go directly to where they want
to go.

In this way we say that user interface is flexible due to more options in front of user.

Q-2(f) test-to-pass-2 marks,test-to-fail-2 marks

Test – to – pass/ Test to fail: In software testing two fundamentals approaches are there:

1) Test –to-pass 2) test-to- fail

When test-to-pass, you really assures only that software minimally works. You don’t push capabilities and
you do not break it.

Ex. Analogy of newly designed car. You are assigned to test the very first prototype that has just rolled off
assembly line and has never been driven and if you drive car at full speed then you should crash and die
that is test-to- fail.

For test-to –pass, with new car there should be all ki9nds of bugs and that should be properly tested at the
time of testing ex: low sped, or may be tier are at right size or breaks are adequate, tester test all this by
considering various test cases if they got correct result then that will be test –to –pass otherwise test-to- fail

(Or any other suitable example)

 MAHARAS HTRA S TATE BOARD OF TECHN ICAL EDUC ATION
(Autonomous)
(IS O/IEC - 27001 - 2005 Certified)

SUMMER – 12 EXAMINATION
Subject Code : 12258 Model Answer Page No : 6/ 16

Q-3 Attempt any four

a) Backward compatibility 2 marks, forward compatibility 2 marks

Backward and Forward compatibility:

If something is backward compatible then it will work with previous version of the software

If something is forward compatible then it will work with future versions of software

The simple example is with .txt and text file

As shown in the diagram a text file created using notepad 98 running under windows 98 is
backward compatible and it is also forward compatible to windows 2000.

Notepad
98
Edit text running
running on
on windows
WordPad
MSDOS 98
1.0 running
on
Notepad
windows
running
2000
on
windows
3.1
??
Running
on OS ??
Notepad
running
on
MYDATA.TXT
Windows
T
95
Backward Compatibility Forward Compatibility

Q-3 (b) explanation Repetition, Stress and Load Testing: 4 marks

Repetition testing involves doing same operation over and over. This could be as simple as starting
up and shutting down the program over and over. It could also mean repeatedly saving and loading
data or repeatedly selecting same operation might find bugs after couple of repetitions.

The main reason for doing repetition testing is to look for memory leaks
 MAHARAS HTRA S TATE BOARD OF TECHN ICAL EDUC ATION
(Autonomous)
(IS O/IEC - 27001 - 2005 Certified)

SUMMER – 12 EXAMINATION
Subject Code : 12258 Model Answer Page No : 7/ 16
Stress testing is running software under less than ideal conditions like as slow memory, low disk
space, slow CPU, slow modem and so on.

The goal is to starve the software

Load Testing is opposite to stress testing that means operates software with largest possible data
files.

If your software operates on peripherals such as printers or communication part connect as many as
you can that means max out the software capabilities.

With stress testing you starves software and with load testing you feed it all that it can handle.

Q- 3 (C) each diff 1 mark (any four)

Difference between Dynamic white Box testing and Debugging

Dynamic white Box testing Debugging

1. The goal of dynamic white box testing is 1. The goal of debugging is to fix bugs
to find bugs.

2. It include information about what line of 2. The programmer who does

code look suspicious debugging picks process up from
there and determines exactly what is
causing the bug and attempts to fix it.

3. Dynamic white –box testing is a general 3. Debugging is done once a problem

investigation process of checking. has been identified and is re-
producible

4. Dynamic white-box testing is testing 4. Debugging is defect addressing effort

effort

5. This testing is done on architectural basis 5. Debugging is done on thread basis.

Q-3 (d) disabled testing 2 marks, accessibility testing 4 marks.

Accessibility: Area of usability testing is that of accessibility testing

There are many types of disabilities.

1) Visual impairment: Color blindness , extreme near far sightedness, tunnel vision, dim vision, blurry
vision are examples of visual limitation people with one or more of these would have their own
unique difficulty in using software

2) Hearing impairment: Someone may be partially of completely deaf such a person may not be able to
hear the sound or voices that accompany onscreen video.

3) Motion impairment: Disease or injury can cause a person to lose fine, gross or total motor control of
his hands or arms ex. They may not be able press more than one key at a time.
 MAHARAS HTRA S TATE BOARD OF TECHN ICAL EDUC ATION
(Autonomous)
(IS O/IEC - 27001 - 2005 Certified)

SUMMER – 12 EXAMINATION
Subject Code : 12258 Model Answer Page No : 8/ 16
4) Cognitive and language: Dyslexia and memory problem may make it difficult for someone to use
complex user interface.

Legal Requirements:

Some laws are applied for such areas are :

1) The Americans with Disability Act State

2) Section 508

3) Section 255 of telecommunication Act

Accessibility features in Software:

Software can be made accessible in one of two ways . The easiest way to take advantages of support built
into its platform or O.S. Your system only needs to adhere to platforms standard. For communicating
with keyboard, mouse, sound card and monitor to be accessibility enabled if the software you are testing
doesn’t run on this platform or its own platform it will need to have its own accessibility features
windows provides following capabilities.

1) Strict keys

2) Filter keys

3) Toggle keys

4) Sound sentry

5) Show sounds

6) High contrasts

7) Mouse keys

8) Serial keys

Q-3(e) explanation equivalence partitioning 2 marks, example 2 marks

Equivalences partitioning : Equivalences partitioning is process of methodically reducing the huge set of
possible test cases into much smaller but still equally effective. It is also called as equivalence classing for
ex. A program which edits credit limits within a given range ($10,000- $15,000) would have three
equivalence classes.

.Less than $10,000 (invalid)

Between $10,000 & $ 15,000 (valid)

Greater than $15,000 (invalid)

Equivalence classes may be defined according to following guidelines:

1. If an input condition specifies range then one valid and two invalid equivalence classes are defined
 MAHARAS HTRA S TATE BOARD OF TECHN ICAL EDUC ATION
(Autonomous)
(IS O/IEC - 27001 - 2005 Certified)

SUMMER – 12 EXAMINATION
Subject Code : 12258 Model Answer Page No : 9/ 16
2. If an input condition requires specific value the one valid and two invalid equivalence classes are
defined.

3. If an input condition is Boolean then one valid and two invalid equivalence classes are defined. The
aim of equivalence partitioning is to minimize number of test cases required to cover input condition.

Input condition for above example is 5 digit integer between 10,000 & 99,999 equivalence partitions are
<10,000, 10,000-99,999 and >99,999

Q-3 (f) explanation 4 marks

Purpose of Test Procedures: Test procedure defines step-by-step details of exactly how to perform those
test cases. Here is information that needs to be defined.

1. Identifier: A unique identifier that ties the test procedure to the associated test cases and test
design
2. Purpose: The purpose of procedure and reference to the test cases it will execute
3. Special Requirements: Other procedures, special testing skills or special equipments needed to
run procedure
4. Procedure steps: Detailed description of how tests are to be run.
5. Log: Tells how and by what methods the results and observation will be recorded.
6. Setup: Explain how to prepare for the test
7. Start: Explains the steps used to start the test
8. Procedure: Describes the steps used to run tests
9. Measure: Describes how results are to be determined ex. With stopwatch
10. Shut down: Explains the steps for suspending the test for unexpected reasons.
11. Restart: Tells the tester how to pick up the test at a certain point if there is failure.
12. Stop: Describes the steps for an orderly to halt to the test.
13. Wrap Up: Explains how to restore the environment to its pre-test condition.
14. Contingencies: Explains what to do if things don’t go as planned.

Q. 4. Attempt any TWO

a) Definition of SDLC-2 marks, Each model 3 marks (Any two models)

SDLC: The process to create a software product from its initial conception to its public release is known as
the ‘Software Development Life Cycle (SDLC) Model

The four frequently used models are

i. Big-Bang

ii. Code and fix

iii. Waterfall

iv. Spiral
 MAHARAS HTRA S TATE BOARD OF TECHN ICAL EDUC ATION
(Autonomous)
(IS O/IEC - 27001 - 2005 Certified)

SUMMER – 12 EXAMINATION
Subject Code : 12258 Model Answer Page No : 10/ 16

Such model has its own advantages and limitations.

i. Big –Bang Model: This is the simplest model of Final

software development. Product
This involves large number of people and monger BOOM or
efforts to come out with perfect software product
or it doesn’t. There is little amount of planning, ?
scheduling or formal development process. All the
effort is spent developing the software and writing BIG -BANG
the code. It is an ideal process if the product requirements aren’t well understood with flexible
release date. Customers should be flexible as they will relive the product results only at the end.

The most cases there are little efforts done for formal testing. The testing is squeezed between
development and delivery.

In Big-Bang model the users have easy as well as difficult task. Software is complete, ready with
specifications. It is difficult if there are bugs and fix things that are broken

The downside, if developer is holding up delivery to the customer, more bugs are found with longer
development and testing process, more contentious the situation will become. Development should
be good with minimum efforts for testing

ii. Code and fix model: Code and Fix model

is usually the one that project teams fall Final
into the by default if they don’t Specification Product
consciously attempt to use something
else. It is a step up , procedurally from
the Big- Bang Model , in that at least
requires some idea of what the product
Code-fix repeats until
requirements are. A team using this
approach usually starts with a rough
Fig: Code and Fix model
idea of what they want, does some
simple design and then proceeds into a
long repeating cycle of coding, testing
and fixing bugs. At some point, they decide to release the product

The overheads for the planning and documenting are limited, a project team can show quick results. This
models works well with small projects intended to be created quickly and then thrown out shortly after
there are done, such as prototypes and demos. Sometimes code and fix are used for large products too
such as word processor software, when little bugs do not impact the performance.

Code and fix projects constantly needs cycling. There are constant test runs and bug fixes to get new
software release. Even before completion of testing of previous release, the new one may arrive with
changed features. The programmers most likely encounter code and fix model during working as software
tester.
 MAHARAS HTRA S TATE BOARD OF TECHN ICAL EDUC ATION
(Autonomous)
(IS O/IEC - 27001 - 2005 Certified)

SUMMER – 12 EXAMINATION
Subject Code : 12258 Model Answer Page No : 11/ 16

Q. 4 (b)Relevant explanation 8 marks.

High Level Review of the specification: Defining a software product is a difficult process. The specification
must deal with many unknowns, take a multitude of changing inputs, and attempt to pull them all
together into a document that describes a new product. The process is an inexact science and is prone to
having problems. High level review includes examining the specification in detail.

Some of the approaches include

(i) Pretend to be the customer and understand expectations. Consider ‘quality’ as ‘meeting customer
needs’ and do not assume anything. Use the specifications to design software tests to eventually
understand the software. If you find the bugs , all the better

(ii) Research existing standards and guidelines some of the guidelines to consider are

Corporate Terminology and conventions

Industry requirements

GNI standards

Graphical User Interface (GUI)

Hardware and Networking standards

As a tester, you can verify above information which is provided by the developer

(iii) Review and test similar software: This is one of the methods to compare the similar available
software. The software likely may not be a exact match, but should help to think about test
situations. It should also flag potential problems that may not have been considered which
reviewing the testers should look for scale, complexity, testability, and quality / reliability.

Q. 4(c ) explanation of each one 2 marks, one example 2 marks

Program statement and line coverage, branch coverage, condition coverage : All the three are part of
code testing are code-coverage analysis. This is a dynamic white-box testing techniques which requires
full access to the code to view parts of the software which run the test cases.

i. Program statement and line coverage is also called statement coverage. The goal is to make sure that
we execute every statement in the program at least once. However through this we can tell that
every statement is executed but difficult to state that all paths of software are passed through.

ii. Condition coverage testing takes the extra conditions on the extra conditions on the branch
statements into account. the conditions coverage will check for each condition all the possible cases
are tested

iii. The branch coverage covers all paths in the software and also called as path testing. This is done after
the statement and line coverage for possible branching, most code coverage analyzers will account
for code branches and report both statement coverage and branch coverage results separately

If we test for all possible test conditions we can achieve branch coverage and statement coverage as well.
 MAHARAS HTRA S TATE BOARD OF TECHN ICAL EDUC ATION
(Autonomous)
(IS O/IEC - 27001 - 2005 Certified)

SUMMER – 12 EXAMINATION
Subject Code : 12258 Model Answer Page No : 12/ 16

Q. 5 Attempt any two of the following:

a) Dumb monkey: 4 marks Semi-smart Monkey: 4 marks

Dumb and Semi-smart monkeys: Dumb and Semi-smart monkeys are the type of automation tool used to
simulate what users might do.

Dumb Monkey: A dumb monkey doesn’t know anything about the software being tested. It just clicks or
types randomly. Ex.

1. For I = 1 to 1000

2. Play “{click” + STR$( INT(RND*640))+ “,”+STR $(INT(RND*480))+”}”

3. Play CHR$(RND*256)

4. NEXT

In the above, example Line 1 starts looping from 1 to 10,000 times . Line 2 selects a random point
onscreen between 0,0 and 640,480 and click it .Line 3 picks a random character between 0 to 255 and
types it in.

This money is doing absolutely no verification. It just clicks and types until one of two things happens
either it finishes its loop or the software or operating system crashes.

With this monkey, sometimes a magic sequence that a programmer and tester may not think of may be
an input from the monkey. He may enter some data and immediately deletes it or types in a huge string
where a short one was expected. This can be a bug which is not found by programmer and tester. A
dumb monkey with its continuous repetition and use can expose bugs such as memory leaks that might
not occur until many hours or days of normal use. Dumb monkeys are day to write and can find serious
crashing bugs.

Semi Smart Monkeys: In this monkey whatever monkey is doing it is recorded to a file. When the monkey
finds the bug, log file records the actions that monkey have done before the failure.

A monkey can be program to operate only on the software you are testing. If its randomly clicking all over
the screen, it could click the exit command and stop the program.

A monkey can be made semi-smart by adding feature crash recognition. Example a monkey can start
running for the night, Once it finds a bug it should recognize that a crash has occurred. We can ad d
programming to the monkey to recognize that a crash has occurred, restart the computer and start
running again if no one is there to see the bug in the night. This will allow to find several bugs in absence
of supervisor.

Q-5 (b) Each element 2 marks

Basic Element of Web Page:

1.) Text 2) Hyperlinks 3) Graphics 4) Forms 5) Objects and other (any four)

1. Text: Web text should be treated just like documentation. Check the audience level, the terminology,
the content and subject matter, the accuracy- especially of information that can become outdated-
and always, always check spelling.
 MAHARAS HTRA S TATE BOARD OF TECHN ICAL EDUC ATION
(Autonomous)
(IS O/IEC - 27001 - 2005 Certified)

SUMMER – 12 EXAMINATION
Subject Code : 12258 Model Answer Page No : 13/ 16

If there is contact information such as email addresses, phone numbers, or postal addresses,
check them to make sure that they are correct.

Test that each page has a correct title. This text appears in the browser’s title bar.

Check for text layout issues by resizing your browser window to be very small or very large

2. Hyperlinks: Links can be tied to text or graphics. Each link should be checke d to make sure that it
jumps to the correct destination and opens in the correct window. Text links are usually underlined,
and the mouse pointer should change to a hand pointer when it’s over any kind of hyperlink-text or
graphic. If the link opens up an email message, fill out the message, send it, and make sure you get a
response.

3. Graphics: Do all graphics load and display properly? If a graphic is missing or is incorrectly named, it
won’t load and the Web page will display an error where the graphic was to be placed. If text and
graphics are intermixed on the page, make sure that the text wraps properly around the graphics. Try
resizing the browser’s window to see if strange wrapping occurs around the graphic.

4. Forms: Forms are the text boxes, list boxes, and other fields for entering or selecting information on a
Web Page.

Test forms just as you would if they were fields in a regular software program . Are the fields the
correct size? Do they accept the correct data and reject the wrong data? Is there proper confirmation
when you finally press Enter? Are optional fields truly optional and the required ones truly requ ired?
What happens if you enter 99999999999999999999999?

5. Objects and Other Simple Miscellaneous Functionality: Your Web site may contain features such as a
hit counter, scrolling marquee text, changing advertisements, or, internal site searches.

Q-5(c) Diagram 4 marks Explanation 4 marks

Bug’s life Cycle: When a bug is first found by a software tester, it’s logged and assigned to a programmer
to be fixed. This state is called the open state. Once the programmer fixes the code, he assigns it back to
the tester and the bug enters the resolved state. The tester then performs a regression test to confirm
that the bug is indeed fixed and, if it is, closes it out. The bug then enters its final state, the closed state.
 MAHARAS HTRA S TATE BOARD OF TECHN ICAL EDUC ATION
(Autonomous)
(IS O/IEC - 27001 - 2005 Certified)

SUMMER – 12 EXAMINATION
Subject Code : 12258 Model Answer Page No : 14/ 16
Review State: It is a state where the project manager or the committee decides whether the bug should
be fixed. In some projects all bugs go through the review state before they are assigned to the
programmer for fixing. Review state can also go to directly closed state. This happens if the review
decides that the bug should not be fixed.

Deferred State: It is the state when the review may determine that the bug should be considered for
fixing at some time in the future but not for this release of the software.

The additional line from the resolved state back to the open state covers the situation where the tester
finds that the bug has not been fixed. It gets reopened and the bug’s life cycle repeats. An error which is
closed or deferred may be afterwards a serious bug then it is reopened and starts through the process
again.

Q-6) Attempt any Four:

a) Each specification 1 mark (Any four)

System Specification: (Any other valid specification should be considered)

1. Form displays title as ‘User form’

2. Username text box (text1) accept alphanumeric data
3. Text1 box accept characters up to 20 char.
4. Forward textbox (text2) accepts password and displays it in encrypted form.
5. Length of password is between 6 to 12
6. After entering user name and password submit command button is enabled
7. Click on submit button submits the login form and displays welcome page
8. Click on clear button resets the form.
Q-6) (b)Each staff 1 mark

Software Project Staff:

Projects manage, program managers, or producers drive the project form beginning to end.
They are usually responsible for writing the product speck managing the schedule and
making the critical decisions and trade-offs.

Architects or system engineers are the technical experts on the product team. They are
usually very experienced and therefore are qualified to design the overall systems
architecture or design for the software. They work very closely with the programmers

Programmers, developers, or coders design, write, and fix bugs in the software. They work
closely with the architects and projects managers to create the software. Then, they work
closely with the project managers and testers to get the bugs fixed.

Testers or QA(Quality Assurance) are responsible for findings and reporting problems in the
software product. They work very closely with all members of the team as they develop and
run their tests, and report the problems they find.

Technical writers, user assistance, user education, manual writers, or ill ustrators create the
paper and online documentation that comes with a software product.

Configuration management or builder handless the process of pulling together all the
software written by the programmers and all the documentation created by the writers and
putting it together into a single package.
 MAHARAS HTRA S TATE BOARD OF TECHN ICAL EDUC ATION
(Autonomous)
(IS O/IEC - 27001 - 2005 Certified)

SUMMER – 12 EXAMINATION
Subject Code : 12258 Model Answer Page No : 15/ 16

Q-6) (c) Definition 2 marks, Test Driver 1 mark, Stub 1 mark

Integration Testing approach: In a project there are multiple modules i.e. units. Each unit is tested and if
any bug is found, it is fixed at that level. After performing unit testing, all the units are integrated and
integration testing is performed against groups of modules. This process of incremental testing continues
putting together more and more pieces of the software until the entire product or at least a major
portion of it is tested at once.

Integration testing includes test drivers and stubs.

Test driver send test case data to the modules under test, read back the results and verify that they
are correct. A bottom up testing where test driver is your own module to pass data to the module
under test

A top down testing approach include stub which is a small piece of code that acts as a interface
module for feeding the input to the module under test.

Q-6) (d) Definition data sharing compatibility 2 marks, example 2 marks

Data Sharing Compatibility: Data Sharing compatibility testing is essential for sharing the data among
different applications. In the regular working we transfer data from one program to another. This is done
by saving and loading disk files. i.e. We share data among multiple machines. The data that we store
should be compatible on all the machines on which we are sharing file . File save and file load are the
data sharing methods that are commonly used in daily working. You save your data into any storage
device such as pen drive and then load it on another computer running different software. The data
formats of the files need to meet standards for it to be compatible on both computers. For example, you
save a file abc.doc on Windows Microsoft Word. When you try to open the same file on another
computer with open office word processor it should support all functionalities such as save, insert,
import etc.

Data sharing compatibility testing means testing one file created on one machine is compatible with
another machine running different software.

Q-6) (e) Each standard 1 mark (Any four)

ISO 9000 Standard: Any four from the following.

Develop detailed quality plans and procedures to control configuration management,

product verification and validation (testing), nonconformance(bugs), and corrective actions
(fixes)

Prepare and receive approval for a software development plan that includes a definition of
the project, a list of the project’s objectives, a project schedule, a product specification, a
description of how the project is organized, a discussion of risks and assumptions, and
strategies for controlling it.
 MAHARAS HTRA S TATE BOARD OF TECHN ICAL EDUC ATION
(Autonomous)
(IS O/IEC - 27001 - 2005 Certified)

SUMMER – 12 EXAMINATION
Subject Code : 12258 Model Answer Page No : 16/ 16

Communicate the specification in terms that make it easy for the customer to understand
and to validate during testing.

Plan, develop, document, and perform software design review procedures.

Develop procedures that control software design changes made over the product’s life cycle.

Develop and document software test plans.

Develop methods to test whether the software meets the customer’s requirements.

Perform software validation and acceptance tests

Maintain records of the test results.

Control how software bugs are investigated and resolved

Prove that the product is ready before it’s released

Develop procedures to control the software’s release process.

Identify and define what quality information should be collected

Use statistical techniques to analyze the software development process.

Use statistical techniques to evaluate product quality.

Q-6) (f) Definition 2 marks, example 2 marks

Boundary Condition: Boundary condition testing test the application for valid data in the boundary and
invalid data outside the boundary. Ex. If you are testing for an input box accepting numbers from 1 to
1000 then there is no need to write thousand test cases for all 1000 data input numbers.

Boundary conditions in this example checks whether the input box accepts the number in the range
of 1 to 1000 and rejects the number less than 1 and greater than 1000.

In the example, test cases can be written for:

1. Test data exactly as the input boundaries of input domain i.e., values 1 & 1000 in this case.

2. Test data with values below the extreme edges of input domain i.e. values 0 and 999.

3. Test data with values above the extreme edges of input domain i.e. values 2 and 1001.