Bug Life Cycle

Introduction:
Bug can be defined as the abnormal behavior of the software. No software exists without a bug.

A mistake in coding is called error ,error found by a tester is called defect,  defect accepted by development team then it is called bug ,build does not meet the requirements then it is failure.

Bug Life Cycle:
In software development process, the bug has a life cycle. The bug should go through the life cycle to be closed. A specific life cycle ensures that the process is standardized. The bug attains different states in the life cycle. The life cycle of the bug can be shown diagrammatically as follows:


The different states of a bug can be summarized as follows:

1. New
2. Open
3. Assign
4. Test
5. Verified
6. Deferred
7. Reopened
8. Duplicate
9. Rejected and
10. Closed

Description of Various Stages:
1. New: When the bug is posted for the first time, its state will be “NEW”. This means that the bug is not yet approved.

2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as “OPEN”.

3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to “ASSIGN”.

4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to “TEST”. It specifies that the bug has been fixed and is released to testing team.

5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.

6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “REJECTED”.

7. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “DUPLICATE”.

8. Verified: Once the bug is fixed and the status is changed to “TEST”, the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “VERIFIED”.

9. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “REOPENED”. The bug traverses the life cycle once again.

10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “CLOSED”. This state means that the bug is fixed, tested and approved.

While defect prevention is much more effective and efficient in reducing the number of defects, most organization conducts defect discovery and removal. Discovering and removing defects is an expensive and inefficient process. It is much more efficient for an organization to conduct activities that prevent defects.

Guidelines on deciding the Severity of Bug:
Indicate the impact each defect has on testing efforts or users and administrators of the application under test. This information is used by developers and management as thebasis for assigning priority of work on defects.

A sample guideline for assignment of Priority Levels during the product test phase includes:

1. Critical / Show Stopper — An item that prevents further testing of the product or function under test can be classified as Critical Bug. No workaround is possible for such bugs. Examples of this include a missing menu option or security permission required to access a function under test.
   .
2. Major / High — A defect that does not function as expected/designed or cause other functionality to fail to meet requirements can be classified as Major Bug. The workaround can be provided for such bugs. Examples of this include inaccurate calculations; the wrong field being updated, etc.
   .
3. Average / Medium — The defects which do not conform to standards and conventions can be classified as Medium Bugs. Easy workarounds exists to achieve functionality objectives. Examples include matching visual and text links which lead to different end points.
   .
4. Minor / Low — Cosmetic defects which does not affect the functionality of the system can be classified as Minor Bugs.

Roles and Responsibilities for Sr Quality Analyst (Automation)

Roles and Responsibilities for Sr Quality Analyst (Automation)

·  Prepare Reusable functions, which improve the robustness, re-usability, and maintainability of their test scripts.
·  The framework should be designed in such a way that it increases and speeds up their productivity.
·  The engineer also must support the framework/s, for example, supporting dev/qa with issues using the tool. The engineer will implement automation test scripts. Integration with the test management tool is also, planned.
·  The Senior Test Automation Engineer must be able to take on leadership responsibilities and influence the direction of the automation effort, and its schedule and prioritization.
·  The engineer will work with management, developers, and quality assurance personnel, to meet these goals.
·  Additionally the Test Automation Engineer will also be involved in supporting the build master implement/improve build test processes, environments, and scripts. These build tests ensure that the code drops to quality assurance are of the highest quality.

·  He will provide a practical approach to complex product testing,  in the areas of the automation of test cases for the purposes of regression testing.

· He will be a creative and proactive thinker and you will make use of current technologies to provide extensible automation infrastructures.

·  He will review product requirements, functional and design specifications to determine and prepare automated test cases.
·  He will work closely with other QC team members to automate the execution and verification of reports created by the various company products.
·  He will be part of a team focusing on automation of an identified set of migration tests, checking they run correctly and working within the infrastructure. The team would focus on develop and test these automation buckets which would be executed by other teams

Test Automation Life Cycle

Following are the phases of Test Automation Life Cycle. It can be varied from project to project.

1.      Automation Feasibility Analysis

1.1.   Decision to Automate Test

1.2.   Overcoming False Expectations for Automated Testing

2.      Test Strategy

3.      Environment Set up

4.      Test Script Development

5.      Test Script Execution

6.      Test Result Generation and Analysis

1.      Automation Feasibility Analysis

Before kicking off implementing test automation, it is mandatory to analyze the feasibility of the application under test (AUT). Whether AUT is a right candidate or not for the test automation?

1.1 Decision to Automate Test

In this phase it is important for the test team to manage automated testing expectations and to outline the potential benefits of automated testing when implemented correctly. A test tool proposal needs to be outlined, which will be helpful in acquiring management support.

1.2 Overcoming False Expectations for Automated Testing

Automated testing is valuable and can produce a return on investment, there isn't always an immediate payback on investment.

Some myths regarding automation testing should be cleared. People often see test automation as a silver bullet, but they have to understand that test automation requires a significant investment of time and energy to achieve a long-term return on investment (ROI) of faster and cheaper regression testing.  Automation testing should be introduced correctly into a project to manage the valid expectations.

Also, feasibility analysis should be done on the manual test case pack which enables automation engineers to design the test scripts.

Following are the feasibility check to be done to begin test automation:

• AUT automation feasibility
• Test Case automation feasibility
• Tool feasibility

1.3 Proof of Concept phase (POC)

Objective of this phase is to do POC for customer after customer is identified as a lead.

Activities –

•         Identification and evaluation of test automation tool.

•         Identification of FW and changes as needed.

•         POC / Test cases development and scripting to be done as needed by the customer.

•         Typically this takes 1 weeks’ time.

•         Arrange a demo for the customer.

•         There is no guarantee that the project will come to.

Deliverables

•         POC done.

•         Demo to customer.

2. Test Strategy

This phase defines how to approach and accomplish the mission. First in test strategy is selection of test automation framework.

Following are the types of test automation framework:

1. Record and Playback Framework
2. Functional Decomposition Framework
3. Keyword/Table Driven Framework
4. Data Driven Framework
5. Hybrid Framework

Other factors which involves in test strategy as follows

1. Schedule
2. Number of resources
3. Mode of communication process
4. Defining in-scope and out-of-scope
5. Return on Investment analysis

3. Environment Set up

It is ideal to execute test automation scripts in regression environment. Test environment set up phase has following tasks:

1. Sufficient tool licenses
2. Sufficient add-ins licenses
3. Sufficient utilities like comparison tools, advance text editors etc.
4. Implementation of automation framework
5. AUT access and valid credentials

4. Test Script Development

Activities of Automation test engineers are as follow:

1. Object Identification
2. Creating Function Libraries
3. Building the scripts
4. Unit testing the scripts
5. Test execution

 5.  Test Script Execution

Following are the tasks involved with test script execution team.

1. Test script execution
2. Defect Logging
3. Modifying scripts as developer changes occur

 6. Test Result Generation and Analysis

Result generation and analysis is the last phase and important deliverables in test automation. Results must be base lined and signed-off. Following are the important activities in this phase:

1. Result analysis
2. Report generation
3. Documenting the issues and knowledge gained
4. Preparation of client presentation

Test Cases for a Text Box

Validation Criteria for Test /String Fields

While checking a text field following points should be taken in to consideration

1. Aesthetic (Visual) Conditions

2. Validation Conditions

3. Navigation Conditions

4. Usability Conditions

5. Data Integrity Conditions

6. Modes (Editable Read-only) Conditions

7. General Conditions

8. Specific Field Tests

       8.1. Date Field Checks

       8.2. Numeric Fields

       8.3. Alpha Field Checks

1. Aesthetic Conditions

•Check that the text field has a caption.

•The label is not editable.

•Check the spelling of the label.

•Move the Mouse Cursor over all Enter able Text Boxes. Cursor should change from arrow to Insert Bar

•If it doesn't then the text in the box should be grey or non-update able.

•Are the field prompts the correct color?

•Are the field backgrounds the correct color?

•In read-only mode, are the field prompts the correct color?

•In read-only mode, are the field backgrounds the correct color?

•Are all the field prompts aligned perfectly on the screen?

•Are all the field edits boxes aligned perfectly on the screen?

•Are all the field prompts spelt correctly?

•Are all character or alpha-numeric fields left justified? This is the default unless otherwise specified.

•Are all numeric fields right justified? This is the default unless otherwise specified.

•Is all the micro help text spelt correctly on this screen?

•Is all the error message text spelt correctly on this screen?

•Is all users input captured in UPPER case or lower case consistently?

•Assure that the password entered is visible in encrypted format.

2. Validation Conditions

•Does a failure of validation on every field cause a sensible user error message?

•Is the user required to fix entries which have failed validation tests?

•Have any fields got multiple validation rules and if so are all rules being applied?

•If the user enters an invalid value and clicks on the OK button (i.e. does not TAB off the field) is the invalid entry identified and highlighted correctly with an error message?

•Validation consistently applied at screen level unless specifically required at field level?

•For all numeric fields check whether negative numbers can and should be able to be entered.

•For all numeric fields check the minimum and maximum values and also some mid-range values 

allowable?

•For all character/alphanumeric fields check the field to ensure that there is a character limit specified and that this limit is exactly correct for the specified database size?

•Do all mandatory fields require user input?

3. Navigation Conditions

•Does the Tab Order specified on the screen go in sequence from Top Left to bottom right? This is the default unless otherwise specified.

4. Usability Condition

•Is all date entry required in the correct format?

•Are all read-only fields avoided in the TAB sequence?

•Are all disabled fields avoided in the TAB sequence?

•Can the cursor be placed in the micro help text box by clicking on the text box with the mouse?

•Can the cursor be placed in read-only fields by clicking in the field with the mouse?

•Is the cursor positioned in the first input field or control when the screen is opened?

•SHIFT and Arrow should Select Characters. Selection should also be possible with mouse. Double Click should select all text in box.

5. Data Integrity Conditions

•Check the maximum field lengths to ensure that there are no truncated characters?

•Where the database requires a value (other than null) then this should be defaulted into fields. The user must either enter an alternative valid value or leave the default value intact.

•Check maximum and minimum field values for numeric fields?

•If numeric fields accept negative values can these be stored correctly on the database and does it make sense for the field to accept negative numbers?

•If a particular set of data is saved to the database check that each value gets saved fully to the database. i.e. Beware of truncation (of strings) and rounding of numeric values.

6. Modes (Editable Read-only) Conditions

•Are the screen and field colors adjusted correctly for read-only mode?

•Are all fields and controls disabled in read-only mode?

•Check that no validation is performed in read-only mode. 

7. General Conditions

•Assure that the Tab key sequence which traverses the screens does so in a logical way.

•Errors on continue will cause user to be returned to the tab and the focus should be on the field causing the error. (i.e. the tab is opened, highlighting the field with the error on it)

•All fonts to be the same

8. Specific Field Tests

8.1. Date Field Checks

•Assure that leap years are validated correctly & do not cause errors/miscalculations

•Assure that month code 00 and 13 are validated correctly & do not cause errors/miscalculations

•Assure that 00 and 13 are reported as errors

•Assure that day values 00 and 32 are validated correctly & do not cause errors/miscalculations

•Assure that Feb. 28, 29, 30 are validated correctly & do not cause errors/ miscalculations

•Assure that Feb. 30 is reported as an error

•Assure that century change is validated correctly & does not cause errors/ miscalculations

•Assure that out of cycle dates are validated correctly & do not cause errors/miscalculations 

8.2. Numeric Fields

•Assure that lowest and highest values are handled correctly

•Assure that invalid values are logged and reported

•Assure that valid values are handles by the correct procedure

•Assure that numeric fields with a blank in position 1 are processed or reported as an error

•Assure that fields with a blank in the last position are processed or reported as an error an error

•Assure that both + and - values are correctly processed

•Assure that division by zero does not occur

•Include value zero in all calculations

•Include at least one in-range value

•Include maximum and minimum range values

•Include out of range values above the maximum and below the minimum

•Assure that upper and lower values in ranges are handled correctly 

8.3. Alpha Field Checks

•Use blank and non-blank data

•Include lowest and highest values

•Include invalid characters & symbols

•Include valid characters

•Include data items with first position blank

•Include data items with last position blank 

•Use html tags.