Bug /Defect Life Cycle

Process of Bug Life cycle

• Tester finds the defect
• Status assigned to developer- New
• A defect is forwarded to Project Manager for analyze
• Project Manager decides whether a defect is valid
• Here the defect is not valid- a status is given "Rejected."
• So, project manager assigns a status rejected. If the defect is not rejected
then the next step is to check whether it is in scope. Suppose we have
another function- email functionality for the same application, and you
find a problem with that. But it is not a part of the current release when
such defects are assigned as a postponed or deferred status.
Process of Bug Life cycle
• Next, the manager verifies whether a similar defect was raised earlier.
If yes defect is assigned a status duplicate.
• If no the defect is assigned to the developer who starts fixing the
code. During this stage, the defect is assigned a status in- progress.
• Once the code is fixed. A defect is assigned a status fixed / Resolved
• Next, the tester will re-test the code. In case, the Test Case passes the
defect is closed. If the test cases fail again, the defect is re-opened
and assigned to the developer.
Severity and its Types

• It is defined as the how much impact the issue which was raised by the tester
affects the system.

Severity Types

• Blocker: This defect indicates complete shut-down of the process, nothing can proceed
further
• Critical: It is a highly severe defect and collapses the system. However, certain parts of the
system remain functional
• Major: It causes some undesirable behavior, but the system is still functional
• Minor: It won't cause any major break-down of the system
Priority and Its Types
• Priority is defined as the order in which a defect should be fixed.
Higher the priority the sooner the defect should be resolved.

• Priority Types
• High: The defect must be resolved as soon as possible as it affects the system severely and
cannot be used until it is fixed
• Medium: During the normal course of the development activities defect should be resolved.
It can wait until a new version is created
• Low: The Defect is an irritant but repair can be done once the more serious Defect has been
fixed
Examples of Severity and Priority
High Severity and Low Priority
• Suppose the tester clicks on the “Privacy Notice” hyperlink at the bottom of the amazon.com
homepage and the page is not displayed. This defect will be of high severity because the
functionality is not working. The priority is low because people do not normally spend time
reading the privacy notice.

High Severity and High Priority

• You log in to your amazon.com account, add items to the cart and click the “Proceed to Checkout”
button. You make the payment and the system crashes. This defect makes the whole buying
functionality unusable and so the severity is high. The basic purpose of amazon.com is to buy and
sell products and most of the customers are affected by this. So, this defect is of high priority
which must be fixed immediately for the buying process to work.
Examples of Severity and Priority
Low Severity and High Priority
• Suppose, that in the amazon.com website, the logo is displayed as ”amazn.com” with
the letter “o” missing. This defect does not affect the buying/selling or any other
functionality in any way. So, the severity of this defect is low. But, a mistake in the
company logo affects the brand identity and impacts the user experience. So, the
defect is of high priority.

Low Severity and Low Priority

• Suppose the tester clicks on the “Conditions of Use” hyperlink at the bottom of the
amazon.com homepage. If there is an alignment issue in the text displayed or if there
is a spelling mistake in the content displayed, the defect is said to be of low priority
because people rarely read this page and it does not impact the user experience. The
severity is also low because the functionality of the application is not affected.
Bug or Defect Report
• Bug ID: (It will be automatically created by the BUG Tracking tool once you save this bug)
• Bug Title: Title should be short and crisp, with examples
1. Application crash on clicking the SAVE button while creating a new user.
2. Upon uploading JPEG file format in the registration form, crashes the system.
• Reported By: Your Name
• Reported On: Date
• Severity: Blocker/critical/major/minor
• Priority: High/low/medium
• Assigned to: Developer-Name
• Description:
• Application crash on clicking the SAVE button while creating a new
• the user, hence unable to create a new user in the application.
Bug Report or defect report
• Steps To Reproduce:
• 1) Login into the Application
• 2) Navigate to the Users Menu > New User
• 3) Filled all the user information fields
• 4) Clicked on the ‘Save' button
• 6) And also see the attached screenshot of the error page.
• Expected Result: On clicking SAVE button, should be prompted to a success message
“New User has been created successfully”.
• Actual Results : (Attach ‘application crash' screenshot. IF any)
• Status of the bug: New / open / closed
• Bug Closure date :
Software Testing Techniques
• Software Testing Techniques help you design better test cases.
• Since exhaustive testing is not possible.
• Manual Testing Techniques help reduce the number of test cases to
be executed while increasing test coverage.
• 5 important software testing techniques:
• Boundary Value Analysis (BVA)
• Equivalence Class Partitioning
• Decision Table based testing.
• State Transition
• Error Guessing
Boundary value analysis
• Boundary Value Analysis is also called as (BVA)
• Boundary value analysis is based on testing at the boundaries
between partitions.
• It includes 6 parameters maximum, minimum, inside or outside
boundaries.
• Input condition is valid between 1 to 10 and Input values are 0,1,2
and 9,10,11

• Valid input - 1,2,9,10

• Invalid Input - 0, 11
Equivalence class Partitioning
• It is also called as ECP.
• It is used to check the values of the test data.
• For Example : Input condition is valid between a to z

• Valid input - a to z(lower cases)

• Invalid Input - A-Z(upper cases), special character, numbers and
spaces.
Decision Table
• Decision table is an excellent tool to use in both testing and requirements management.
• Essentially it is a structured exercise to formulate requirements
• They can make it easy to see that all possible combinations of conditions and actions
• It is also called Cause-Effect Table. Example for bank application
• Conditions to transfer money are
• Account Already Apporved
• OTP
• Sufficient Money in the account
• Actions performed are
• Transer the Money
• Show a message as insufficient Amount
• Block the transaction.
State Transition Testing Techniques

• State transition should be used when a testing team is testing the application for a
limited set of input values.
• The technique should be used when the testing team wants to test sequence of events
which happen in the application.

• Example:
• In the following example, if the user enters a valid password in any of the first three
attempts the user will be able to log in successfully. If the user enters the invalid
password in the first or second try, the user will be prompted to re-enter the password.
When the user enters password incorrectly 3rd time, the action has taken, and the
account will be blocked.
State Transition Example
Error Guessing
• Error guessing is a software testing technique which is based on
guessing the error .

• Error guessing mainly focus on Exploratory testing in which

application is already developed and testing the application by the
exploring it without any formal requirement documents and test
cases.

• Error guessing is done by the experience test engineers.

Use Case
• Use cases are prepared from requirements.
• Use case is a representation of actions which describes the behaviour
of system to do a particular task.
• Use Case document is prepared by the BA(Business Analyst).
• Use Cases performs an important role in the requirement analysis
phase of Software Development Life Cycle, where the interaction of
the user and the system is demonstrated
Test case and Test scenario
• Test Scenario is ‘What to be tested’

• Test Scenario is defined from the Use case document

• Test scenario is one liner statement which tell us about what to test.
• Test scenarios are the high level classification of test requirement grouped depending
on the functionality of a module and it can be derived from use cases.
• Test Case is ‘How to be tested’

• Test case is derived from the test scenario

• Test case means detailed documenting the cases which help executing while testing
and to compare expected result with the actual results.
• Test cases are low level actions and it can be derived from test scenarios.
Example of test case and test scenarios
• For a Test Scenario: Check Login Functionality
• Test Case 1: Check results on entering valid User Id & Password
• Test Case 2: Check results on entering Invalid User ID & invalid
Password
• Test Case 3: Check response when a User ID and password is Empty &
Login Button is pressed.
• Test Case 4: Check results on entering Invalid User ID & valid Password
• Test Case 5: Check results on entering valid User ID & Invalid Password
Sample Radio button.
Sample Testcases for radio button
• Check if the radio control button gets selected using mouse cursor
action or TAB keyboard key selection.
• Check the alignment of the radio button control on the form.
• Check if the multiple radio button on the form get selected or not.
• Check the CSS style of the radio button is as per the specification.
• Check the CSS size of the radio button is as per the specification.
• Check the CSS color of the radio button is as per the specification.
Sample Test cases for radio button
• Click the radio control button and see if the page gets redirected to the
next page.
• Dont click on the radio buttons and see if clicking on the submit button
generates warning “to make a choice” is shown or not.
• Click on ‘Yes’ radio button control and hit submit to see if it redirects to
the specific page.
• Click on ‘No’ radio button control and hit submit to see if it redirects to
the specific page.
• Check if the user response of Yes is saved in the right database column.
• Check if the user responsse of No is saved in the right datbase column.
Software Test Life Cycle
• Phases of STLC
• Test Planning
• Writing Test cases
• Executin Test cases
• Reporting a defect
• Testing
• Complete round of testing
Test case sample format
STLC Input/ Entry Criteria Activities Responsibilities Outcome/

Test Planning Requirement Identifying the resouces Project manager 75% Test
Docucment, Team Formation and Team led 25% plan/strategy
FRS document Team Estimation document.
Preparation of test plan
Review of test plan

Writing test cases FRS document Preparation of test scenarios Team lead 50% and test Test case
Test Plan doc,design Preparation of test cases engineers 50% document
doc , Use case doc Review of test scenario
Review of test cases

Executing the test Test plan Executing the test cases. Team lead 10% and test Test report
cases Test case doc engineers 90% document
Design doc
Build from development
team

Identify the defect Test report, Identifying the bug. Team lead 10% and test Defect report
test cases document Raising a bug engineers 90% doc
Test plan Communicate with the
developer

Test Closure Test report Analysing the test report Project manager 80% Test summary
Defect report Analysing the bug report and Team lead 20% report