ASSIGNMENT 4

SOFTWARE TESTING
AND
QUALITY ASSURANCE

Submitted to – Submitted by-

Lect. Jiteshwar Anand Surendra Singh

MCA 4th SEM

D3804A15

10806601
DECLARATION

It is declared by me that this assignment is purely my effort and I had done my assignment of
my own. I accept that I had taken the help of internet and books of modern programming
tools and technique but I had used my own language while answering the questions of
homework 1. I had tried my best to make my assignment unique from other student.

DECLARED BY

SURENDRA SINGH
 Part – A

Q1: Life cycle of all bugs shows up the same phases, justify it by taking few examples?

A computer bug is an error, flaw, mistake, failure, or fault in a computer program that
prevents it from working correctly or produces an incorrect result.
Life cycle of Bug:
1) Log new defect
When tester logs any new bug the mandatory fields are:
Build version, Submit On, Product, Module, Severity, Synopsis and Description to
Reproduce
In above list you can add some optional fields if you are using manual Bug submission
template:
These Optional Fields are: Customer name, Browser, Operating system, File Attachments or
screenshots.
The following fields remain either specified or blank:
If you have authority to add bug Status, Priority and ‘Assigned to’ fields them you can
specify these fields. Otherwise Test manager will set status, Bug priority and assign the bug
to respective module owner.
Look at the following Bug life cycle:
The figure is quite complicated but when you consider the significant steps in bug life cycle
you will get quick idea of bug life.

On successful logging the bug is reviewed by Development or Test manager. Test manager
can set the bug status as Open, can Assign the bug to developer or bug may be deferred until
next release.

When bug gets assigned to developer and can start working on it. Developer can set bug
status as won’t fix, Couldn’t reproduce, Need more information or ‘Fixed’.

If the bug status set by developer is either ‘Need more info’ or Fixed then QA responds with
specific action. If bug is fixed then QA verifies the bug and can set the bug status as verified
closed or Reopen.

Bug status description:

These are various stages of bug life cycle. The status caption may vary depending on the bug
tracking system you are using.
1) New: When QA files new bug.
2) Deferred: If the bug is not related to current build or can not be fixed in this release or bug
is not important to fix immediately then the project manager can set the bug status as
deferred.
3) Assigned: ‘Assigned to’ field is set by project lead or manager and assigns bug to
developer.
4) Resolved/Fixed: When developer makes necessary code changes and verifies the changes
then he/she can make bug status as ‘Fixed’ and the bug is passed to testing team.
5) Could not reproduce: If developer is not able to reproduce the bug by the steps given in
bug report by QA then developer can mark the bug as ‘CNR’. QA needs action to check if
bug is reproduced and can assign to developer with detailed reproducing steps.
6) Need more information: If developer is not clear about the bug reproduce steps provided
by QA to reproduce the bug, then he/she can mark it as “Need more information’. In this case
QA needs to add detailed reproducing steps and assign bug back to dev for fix.
7) Reopen: If QA is not satisfy with the fix and if bug is still reproducible even after fix then
QA can mark it as ‘Reopen’ so that developer can take appropriate action.
8 ) Closed: If bug is verified by the QA team and if the fix is ok and problem is solved then
QA can mark bug as ‘Closed’.
9) Rejected/Invalid: Some times developer or team lead can mark the bug as Rejected or
invalid if the system is working according to specifications and bug is just due to some
misinterpretation.
Q2: Suppose that you are running tests in windows calculator and find that 1+1=2,
2+2=5, 3+3=6, 4+4=9 ...... and 6+6=13…? Write a bug title and bug description that
effectively describes the problem?
Ans :

Bug Title:- Incorrect Sum when an even number is added to

itself.

Bug Description :- Actual sum = Expected sum + 1 whenever

and even number is added to itself. This does not happen

with odd numbers.

Q3: Write the test cases and write them in proper test case format for a web page
having following fields:
I) Roll number
II) Class
III) Registration number
IV) Section
V) Session
VI) Course
VII) Email id

ANS.:
Roll number:-
Test case id: Verification of roll number
Unit to test: valid roll number.

Steps to be executed:
• User can enter invalid roll number which is not specified like KLP/98U.
• User can enter infinite length.
• User can enter special character.

Expected result:
• Output will not be obtained .in all the above cases it will discarded the value.
Actual result:
• After entering the verified roll number home page of that perticuler roll number will be
opened.
Pass/Fail:
• Fail

II)Class:-
Test case id: Verification of Class
Unit to test: valid class.
Steps to be executed:
• User can enter invalid class like Tba, M-ab
• User can enter integer value.
• User can enter special character with class.
• User can enter character with integer value.

Expected result:
• Output will not be obtained .in all the above cases it will discarded the value and show the
massage “please fill the valid class.”

Actual result:
• After entering the verified class like MCA, MBA, M.Tech etc. home page of that perticuler
class will be opened.
Pass/Fail:
• Fail

III)Registration number:-
Test case id: Verification of Registration number
Unit to test: valid registration number.
Steps to be executed:
• User can enter character instead of integer value like CGDRT67.
• User can enter special value with integer value like 567%^&*.
• User may create space between the values like 786 876.

Expected result:
• Output will not be obtained .in all the above cases it will discarded the value and show the
massage “please fill the valid number.”
Actual result:
• After entering the verified registration number like 08704798 etc. home page of that
perticuler registration number will be opened.
Pass/Fail:
• Fail

IV)section:-
Test case id: Verification of section
Unit to test: valid section.
Steps to be executed:
• User can enter special value with integer value like 567%^&*.
• User may create space between the values like 786 876.

Expected result:
• Output will not be obtained .in all the above cases it will discarded the value and show the
massage “please fill the section.”
Actual result:
• After entering the verified section. home page of that particular section will be opened.
Pass/Fail:
• Fail
V)session:-
Test case id: Verification of session
Unit to test: valid year.
Steps to be executed:
• User can enter special value with integer value like 567%^&*.
• User may create space between the values like 786 876.
• User can enter character like thdufo

Expected result:
• Output will not be obtained .in all the above cases it will discarded the value and show the
massage “please fill the valid year.”
Actual result:
• After entering the valid year home page of that particular year will be opened.
Pass/Fail:
• Fail

VI)email id:-
Test case id: Verification of email id
Unit to test: valid address.
Steps to be executed:
• If user forget to press the shift button with the sign of @ it will make wrong address.
• User may create space between the email address like lets.priya 08 @gmail.com
• User can enter special character with address.

Expected result:
• In all the above cases it will discarded the value and show the massage “please fill the valid
email address..”
Actual result:
• After entering the valid email id home page of that particular email id will be opened.
Pass/Fail:
• Fail

..................................................
The test case for the web page having the given fields are given below:

1. Test the Font should be readable or portability.

2. Test the color combination is appropriate.
3. Test the spelling is all correct.
4. Test the grammar used is correct.
5. Test alphabet of the word use should be case sensitive.
6. Testing that the Help menu should be work properly
7. Test whether the description should be displayed when pointer moves to certain icon,
menu, tool, link etc.
8. Test the Lay out of the page must be correct.

Part – B

Q4: Smart monkeys, macros and dumb Monkeys are different give one example?
ANS.

Smart monkeys have some knowledge about how to access the user interface in the product
they’re testing. They know at a simple functional level what can be done, and—more
important—they understand what should happen when they do it. For example, they may
know that choosing the New item on the File menu creates a new document, and they know
that the new document will be displayed as a window with a particular class and text. If no
new document window appears, or the window has the wrong caption or class, the monkey
can identify the problem and report a bug.

Smart monkeys usually get their product knowledge from a state table or model of the
software they test. Randomly traversing the state model, they choose from among all the legal
options in the current state for moving to another state, and then verify that they have reached
the next expected state. You can add illegal inputs to the monkey’s repertoire if the model
includes error-handling states.
Dumb monkeys act differently. (“Ignorant monkey” is technically more accurate, but the term
“dumb” is far more common.) They don’t use a state table; they have no idea what state the
test application is in, or what inputs are legal or illegal. Most important, they can’t recognize
a bug when they see one. The pure dumb monkey exemplifies Beizer’s “keyboard
scrabbling” test tool, and it isn’t very useful for most projects. What can be useful is a “not-
quite-dumb” monkey that’s ignorant about your project, but understands its environment
enough to find very obvious bugs like crashes and hangs

Q5: For a Project list the major Risks and risk Mitigation Strategies for them?
Ans :
A risk is something that may happen and if it does, will have a positive or negative impact on
the project. A few points here. "That may happen" implies a probability of less then 100%. If
it has a probability of 100% - in other words it will happen - it is an issue. An issue is
managed differently to a risk and we will handle issue management in a later white paper. A
risk must also have a probability something above 0%. It must be a chance to happen or it is
not a risk

• Personnel Shortfalls
• Unrealistic schedules/budgets
• Developing the wrong software functions
• Developing the wrong user interface
• Gold plating
• Continuing stream of requirements changes
• Shortfalls in externally furnished components
• Shortfalls in externally performed tasks
• Real-time performance shortfalls
• Straining computer science capabilities
Purpose

The risk mitigation plan (also sometimes referred to as a risk response plan) communicates
how specific risks will be dealt with and the action steps that are required to carry them out. It
gives team members a clear sense of the actions that they are expected to take and provides
management with an understanding of what actions are being taken on their behalf to
ameliorate project risk.

Application
The plan is frequently applied in the project management software as a series of tasks in
addition to those that were on the original activity list. The risk mitigation plan may also
identify specific triggers, which are events that spur action based on the escalating proximity
of a given risk. As risks become imminent, the risk mitigation plan identifies what actions
should occur and who is responsible for implementing those actions.

Q6: Process of creating the plan that matters, not the plan itself, give a case study?

Ans:

The process of the creating plan can matters or not. The creating plan is the most important
plan of the case. At the time of the planning we have to understand the situations of the
project. For planning every member of the team should be agreed. Everyone should be agreed
for the plan. All the issues of the project should be done and understand.