What should be done aftre bug found?

The main principal of Software testing of an application is to find important bugs in the software application & try to make software application bug free. But many of testers are thinking of “What should we do after a bug is found?”

 

Once a bug is found this should be communicated to developer. Before reporting the bug make sure that the bug is well documented with steps to repro, conditions under which this bug is occurring, how many time it occurs &  the excepted result of the bug. The bug report should accurate & complete, so that developer can get the exact failure reason. Based on this developer can get exact idea of problem faced by user & it helps to resolve the problem accurately. To facilitate this task tester should repro the bug & verify that this is a bug & add same repro steps with example & attach screenshots which helps to prove that a bug has been encountered. Also attach the related logs that provide the activities about the time of bug occurrence.

While reporting the bug, it should be divided into various categories like GUI, Functional or Business, Navigational, Validation error etc. which will again help to categorize the bugs in the bug management.

The approach of tester would help a lot to get bug fixed bug quickly & correctly. The main thumb rule is that you (tester) should be confident enough while reporting the bug. Before adding a bug makes sure that you are not adding duplicate bug (which is already logged). Many of the bugs tracking systems are help to identify or prevent to add duplicate bug, which is restricting to adding unnecessary bugs which will help to reduce rework in case of bug management.

Along with bug report adding few extra information would definitely help developer to get exact scenario or steps to understand the problem like types of hardware & software, environment configuration, setup, versions (like Browser version & name) etc.

This page describes the various fields that you see on a bug.

• Bug Title: This is title of bug help to identify bug in one liner description.
• Bug identifier: It is auto generated unique ID helps to identify the bug.
  In the Bug Tracking Tool this field is auto populated.
• Description: This should cover bug description along with the exact Steps To Reproduce, Expected Result, Actual Result and example.
• Status: This field indicates the actual status of the bug in the Bug life cycle.
  Here are the list of Bug Statuses in standard Bug life cycle:
  New, Assigned, Resolved, Reopened, Verified (Vary based on Bug Tracking Tool)
• Bug Assignee: This is the name of the developer who is responsible to resolve the bug.
• Bug Cc: Add the manager and lead email address in CC list.
  In the Bug Tracking Tool this field is auto populated based on configuration.
• Reported On: The date on which the bug is occurred & reported the bug.
• Browser: This field indicates on which browser & version this issue is occurred.
• Bug Type: The bug is categories into different category like Functional, Navigational, GUI etc.
• Environment: On which OS, platform this bug is occurred.
• Component: This field indicates the sub modules of the product.
• Priority: Urgency to fix the bug?
  Priority can be set as P1 to P5.
  The P1 means “first fix this bug i.e. priority is highest” and P5 means “No urgent, when get time then fix it”.
• Severity:This tells you about the impact of the bug.
  Types of Severity:
  
  
  • Blocker: Unless and until this fix no further testing can be done
  • Critical: Application is crashing or Losing the data.
  • Major: Major function under test is not working.
  • Minor: Minor function under test is not working.
  • Trivial: UI issues
  • Enhancement: Asking for new changes as enhancement.
   
• Product
• Reporter: Your name.
  In the Bug Tracking Tool this field is auto populated.
• Reproduces: In this section you can have options like Always and Sometimes etc.
• URL: The page URL on which bug occurred.
• Build number: The Build number field describes the number of Build on which the bug is found in.

Some Bonus tips to write a good bug report:

1) Report the problem as early as possible: While testing if you observed any bug, add this bug in the bug tracking tool immediately, don’t wait to write bug in details afterwards. If you thinking of reporting bug later then it might be possible that miss few important reproduce steps. Reporting bug immediately will help to write good bug report, which help developer to get exact idea of problem faced by user.

2) Double cross check bug before reporting the bug: Thumb rule is the bug should be reproducible using added “Steps to reproduce” in bug report. If you are thinking that the bug is not reproducing all the time then it should be reported in the bug by using the field “Reproduces: Sometimes” field in bug report.

3) Check if the same bug is occurring in some other related module: Many of the time the same issue might be occurring in the other module of project as well. So might be possible that occurrence of same issue in other module. Check this before filing a bug & if it is happening then this should be added in bug report.

4) Write a good bug summary:Based on the summary of the bug the developers are getting nature of the bug. If bug summary is not that good enough then because of such poor quality bugs will unnecessary increasing the bug cycle. The bug summary should be well communicated & good enough to understand developer about exact problem. Also keep in mind that this bug summary will be used to search the bug afterwards from the all reported bug.

6) Don’t make use of offensive language in bug:
It is very nice that you found bug but it not mean that you use offensive language in bug against developer or any individual or should not all blame to developer.

5) Before clicking Submit button please review the bug report:
This is good practice to read bug before reporting it. You should check for Title, Summary, and Steps to repro in bug report. As mention in above point check for if any offensive language used in bug report which might creating misunderstanding or false impression. Such sentences or words should be keeping away from the bug report. Also add Screenshots which helps prove that a bug has been encountered.

Conclusion:
The Bug Report is the document use to communicator between developer, manager, lead & tester about the bugs in the system. So it the quality of the bug report document should be high. Good bug report help to save time of developer & tester. Take time before reporting the bug but make sure that you should stick to bonus tips added above. Taking such effort of reporting good quality bug report strengthen then relationship between tester & developer.

Learn Concept In Software Testing (Manual Testing).: Review Process(Peer/Walk Through/Technical Review/...

Learn Concept In Software Testing (Manual Testing).: Review Process(Peer/Walk Through/Technical Review/...: 'In simple word  is meeting where people  analyze a software work product and recommend changes with objectives of improving quality ....

Review Process(Peer/Walk Through/Technical Review/Inspection)

'In simple word  is meeting where people  analyze a software work product and recommend changes with objectives of improving quality .

 

Software product could be design document, System Requirement Document ,Tets plan etc. It helps in detecting ,defect early in development life cycle and reduces costs.

 

Almost always testing team is part of review meetings.

 

To understand better review process lets consider  example

•  To add a e-mail functionality in  flight reservation system ,  for which  function design document  is prepared by technical lead.
• Technical lead approaches to his  manager to initiate review process .
• Manger quickly review the document to ensure whether the document is acceptable quality  for review by other people or not ,For example, Suppose Manager find spelling mistake ,then manager ask technical lead to correct them.
• Once Corrected.
• Manager send a  meeting request to Stack holders(It's stakeholders and includes anyone related to project. Users, admins, project managers, business owners, product owners, devs etc.)with Meeting Location, Date ,Time ,Agenda & also attache document. This is called
  
  
  'Planning Stage'
  
• Next Stage is Preparation Where individual go through document find defect ,comment, question to  be ask during review  meeting.
• The Next Stage is actual review meeting ,where all participate get roll as:

                   1. Moderator: Moderator is Manager who set meeting ,agenda for meeting.

                   2. Author : Creator of document ,Under review process paly a role of author.

                   3. Scribe/recorder: Will note down all defect,suggestion,Comment.

                     

                   4. Reviewer: The task of reviewer is to communicate defect in work product, give  

                       comment, suggestion.

Finally , all comments are discussed and the scribe gives a list of Defects / Comments / Suggestions that the author needs to incorporate into his work product.

              

SR. #	Review Comment
1	Reset Button
2	Add Detail about menu
3	Ask client facility to share by social networking site

The next phase of the review, is the  re-work phase, where the author will make changes in the document ,as per the action items of  the meeting .

 

SR. #	Review Comment	Status
1	Reset Button	Done
2	Add Detail about menu	Done
3	Ask client facility to share by social networking site	Not Valid,Client does not need it.

Next is Follow -up phase , the moderator will circulate the  reworked document all review participants and ensure that all changes have been included satisfactorily. This was a generic review.

 
What are the types of review?

 

The main review types that come under the static testing are mentioned below:
1. Peer Review(Informal review) :

• Check the functionality at same level

 2.    Walkthrough: (Semi Formal Review)

• Checking Document ne level up like manager check the baseline
• It is not a formal process
• It is led by the authors
• Author guide the participants through the document according to his or her thought process to achieve a common understanding and to gather feedback.
• Useful for the people if they are not from the software discipline, who are not used to or cannot easily understand software development process.
• Is especially useful for higher level documents like requirement specification, etc.

The goals of a walkthrough:

• To present the documents both within and outside the software discipline in order to gather the information regarding the topic under documentation.
• To explain or do the knowledge transfer and evaluate the contents of the document
• To achieve a common understanding and to gather feedback.
• To examine and discuss the validity of the proposed solutions

2.    Technical review:

• It is less formal review
• It is led by the trained moderator but can also be led by a technical expert
• It is often performed as a peer review without management  participation
• Defects are found by the experts (such as architects, designers, key users) who focus on the content of the document.
• In practice, technical reviews vary from quite informal to very formal

The goals of the technical review are:

• To ensure that an early stage the technical concepts are used correctly
• To access the value of technical concepts and alternatives in the product
• To have consistency in the use and representation of technical concepts
• To inform participants about the technical content of the document

3.    Inspection (Formal Review):

• It is the most formal review type
• It is led by the trained moderators
• During inspection the documents are prepared and checked thoroughly by the reviewers before the meeting
• It involves peers to examine the product
• A separate preparation is carried out during which the product is examined and the defects are found
• The defects found are documented in a logging list or issue log
• A formal follow-up is carried out by the moderator applying exit criteria

The goals of inspection are:

• It helps the author to improve the quality of the document under inspection
• It removes defects efficiently and as early as possible
• It improve product quality
• It create common understanding by exchanging information
• It learn from defects found and prevent the occurrence of similar defects

 

Traceability Matrix?

This post  is prepared with the intention of providing an insight into the important concept in the life cycle of Software called Traceability Matrix:

 

Automation requirement in an organization initiates it to go for custom built Software. The client who had ordered for the product specifies his requirements to the development Team and the process of Software Development gets started.

 

In addition to the requirements specified by the client, the development team may also propose various value added suggestions that could be added on to the software. But maintaining a track of all the requirements specified in the requirement document and checking whether all the requirements have been met by the end product is a cumbersome and a laborious process. But if high priority is not provided to this aspect of Software development cycle, it may result in a lot of confusion and arguments between the development team and the client once the product is built.

 

              The remedy for this problem is the Traceability Matrix

 

What is Traceability Matrix?

 Requirements tracing is the process of documenting the links between the user requirements for the system you’re building and the work products developed to implement and verify those requirements. These work products include Software requirements, design specifications, Software code, test plans and other artifacts of the systems development process. Requirements tracing helps the project team to understand which parts of the design and code implement the user’s requirements, and which tests are necessary to verify that the user’s requirements have been implemented correctly.

 

  



 

In the diagram, based on the requirements the design is carried out and based on the design, the codes are developed. Finally, based on these the tests are created. At any point of time , there is always the provision for checking which test case was developed for which design and for which requirement that design was carried out. Such a kind of Traceability in the form of a matrix is the Traceability Matrix.

Benefits of Using Traceability Matrix

• Make obvious to the client that the software is being developed as per the requirements.


• To make sure that all requirements included in the test cases


• To make sure that developers are not creating features that no one has requested


• Easy to identify the missing functionalities.


• If there is a change request for a requirement, then we can easily find out which test cases need to update.


• The completed system may have “Extra” functionality that may have not been specified in the design specification, resulting in wastage of manpower, time and effort.
 
Disadvantages of Not Using Traceability Matrix [Some Possible (Seen) Impact
 
• Poor or unknown test coverage, more defects found in production 
• It will lead to miss some bugs in earlier test cycles which may arise in later test cycles. Then a lot of discussions arguments with other teams and managers before release.
• Difficult project planning and tracking, misunderstandings between different teams over project dependencies, delays, etc

Steps to Create Traceability Matrix

1. Make use of excel to create Traceability Matrix:

2. Define following columns:
Base Specification/Requirement ID (If any)
Requirement ID
Requirement description

TC 001 TC 002 TC 003... So on.

3. Identify all the testable requirements in granular level from requirement document. Typical requirements you need to capture are as follows:

Used cases (all the flows are captured)

Error Messages

Business rules

Functional rules

SRS

FRS

So on…

4. Identity all the test scenarios and test flows.
5. Map Requirement IDs to the test cases. Assume (as per below table), Test case “TC 001” is your one flow/scenario. Now in this scenario, Requirements SR-1.1 and SR-1.2 are covered. So mark “x” for these requirements.

Now from below table you can conclude –

Requirement SR-1.1 is covered in TC 001 Requirement SR-1.2 is covered in TC 001

Requirement SR-1.5 is covered in TC 001, TC 003 [Now it is easy to identify, which test cases need to be updated if there is any change request].
TC 001 Covers SR-1.1, SR, 1.2 [we can easily identify that test cases covers which requirements].
TC 002 covers SR-1.3.. So on..

This is a very basic traceability matrix format. You can add more following columns and make it more effective:

ID, Assoc ID, Technical Assumption(s) and/or Customer Need(s), Functional Requirement, Status, Architectural/Design Document, Technical Specification, System Component(s), Software Module(s), Test Case Number, Tested In, Implemented In, Verification, Additional Comments,

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Testing Tips _Day 3

Methods for Test Estimation

1. Best Guess: This technique is purely guesswork and based on the some sort of experience. The method is very common, but since it is based on your gut feeling, its uncertainty contingency is probably around 200% or even higher.

2. Ad-hoc Method: The test efforts are based on tentative timeframe. The timeline set by managerial or marketing personnel or by client without any guess/experience. Alternatively, it is done until the budgeted finances run out.
This is very common practice in extremely immature organizations and has error margins of over 100% at times.

3. Experience Based: Analogies and experts:

• Metrics collected from previous tests.
• You already tested similar application in previous project.
• Inputs are taken from Subject Matter experts who know the application (as well as testing) very well.

4. Work Breakdown Structure: It is created by breaking down the test project into small pieces. Modules are divided into sub-modules. Sub modules are further divided into functionalities and functionalities are divided in sub-functionalities.
Review all the requirements from Requirement Document to make sure they are added in WBS. Now you figure out the number of tasks your team needs to complete. Estimate the duration of each task.

5. Delphi Technique – Same as above WBS. Here functionalities and each task are allocated to each team member. Then team member gives estimate that they will take this many hours to complete the task.

Averagely, this technique gives good confidence in the estimation. This technique can be combined with other techniques.

6. Three-point Estimation – This technique is based on statistical methods In this technique, task is broken down into subtasks (similar to WBS) and then three types on estimation are done on each chunk –

• Optimistic Estimate (Best case scenario in which nothing goes wrong and all conditions are optimal.) = a
• Most Likely Estimate (most likely duration and there may be some problem but most of the things will go right.) = m
• Pessimistic Estimate (worst case scenario which everything goes wrong.) = b
 

Formula to find Value for Estimate (E) = a + (4*m) + b / 6

Standard Deviation (SD) = = (b - a)/6

TESTING TIPS_The Day -2

TESTING TIPS

1        Make sure test cases should be available to developers prior to coding, let the developers analyze your test cases thoroughly to develop quality application and it will also save re-work.   2        If possible identify major scenarios and group them and create a regression test suite for an effective regression testing cycle.   3        While doing regression testing always use previous reports of infected areas this will let you know that on which part of the application possibility of reoccurrence of issues is higher.   4        Always try to keep developers away from the test environment, so that they cannot do any such changes accidentally or intestinally so that missing things can be captured at the right place and at right time.   5        Testing team should share best testing practices, experience with other teams in organization.   6        Communication between developers & testing engineers must be strong to know more about the internal logics and try to resolve disputes face to face quickly to avoid misunderstanding (Make sure all such kind of communication should be documented or should be on proper emails. always avoid verbal communication).

TESTING TIPS_The Day -1

TESTING TIPS

Its Always good approach to keep the Tester from software Requirement and design phase , so that Tester can have full knowledge of application and if you are not being  part of it , then always Request to your superior and asked to be a part , to have full knowledge of product.   Use traceability matrix to maximize Test Coverage whenever you test the application, because might be 100% coverage is not possible, but still try to reach near it.   Try to Break the Modules into smaller sub modules  for i.e. if you are testing web based application and there is one functionality of checking User Information , so one should break into different parts like – UI,  Functional,  Security, Browser testing including Positive , Negative , Field type , validation test to ensure maximum coverage.   Think positively as well as negatively while doing testing, as it’s very important while testing an application with intend of finding issues, by doing this you will definitely get subtle bugs.

 

“COMMAN SQL STATEMENTS”

In this post we will discuss Comman SQL Statement, which one  of the most important part for testing .Must read this ......

P_Id	LastName	FirstName	Address	City
1	Hansen	Ola	Timoteivn 10	Sandnes
2	Svendson	Tove	Borgvn 23	Sandnes
3	Pettersen	Kari	Storgt 20	Stavanger
4	Nilsen	Johan	Bakken 2	Stavanger
5	Tjessem	Jakob	Nissestien 67	Sandnes

 

1.DELETE FROM Persons WHERE LastName='Tjessem' AND FirstName='Jakob'

 

2. SELECT DISTINCT City FROM Persons

 

Operators Allowed in the WHERE Clause

 

3. With the WHERE clause, the following operators can be used:

 

Operator	Description
=	Equal
<>	Not equal
>	Greater than
<	Less than
>=	Greater than or equal
<=	Less than or equal
BETWEEN	Between an inclusive range
LIKE	Search for a pattern
IN	If you know the exact value you want to return for at least one of the columns

Note: In some versions of SQL the <> operator may be written as ! =

4. SELECT * FROM Persons WHERE LastName='Svendson' AND (FirstName='Tove' OR FirstName='Ola')

5. SELECT column_name(s) FROM table_name ORDER BY column_name(s) ASC|DESC

 

 

6. INSERT INTO table_name (column1, column2, column3,...) VALUES (value1, value2, value3,...)

 

7. UPDATE Persons SET Address='Nissestien 67', City='Sandnes' WHERE LastName='Tjessem' AND FirstName='Jakob'