Testing Process/Flow

 

How to write a good bug report?

 

                  ***For better productivity write a better bug report. ***                        
                Why good Bug report?

If your bug report is effective, chances are higher that it will get fixed. So fixing a bug depends on how effectively you report it. Reporting a bug is nothing but a skill and I will tell you how to achieve this skill.

The point of writing bug report is to get bugs fixed. If tester is not reporting bug correctly, programmer will most likely reject this bug stating as irreproducible. This can hurt testers moral and some time ego also. (It is suggested not to keep any type of ego. Ego's like “I have reported bug correctly”, “I can reproduce it”, “Why he/she has rejected the bug?”, “It's not my fault” etc etc..)

What are the qualities of a good software bug report? Anyone can write a bug report. But not everyone can write a effective bug report. You should be able to distinguish between average bug report and a good bug report. How to distinguish a good or bad bug report? It's simple, apply following characteristics and techniques to report a bug.

1) Having clearly specified bug number: Always assign a unique number to each bug report. This will help to identify the bug record. If you are using any automated bug-reporting tool then this unique number will be generated automatically each time you report the bug. Note the number and brief description of each bug you reported.

2) Reproducible: If your bug is not reproducible it will never get fixed. You should clearly mention the steps to reproduce the bug. Do not assume or skip any reproducing step. Step by step described bug problem is easy to reproduce and fix.

3) Be Specific: Do not write an essay about the problem. Be Specific and to the point. Try to summarize the problem in minimum words yet in effective way. Do not combine multiple problems even they seem to be similar. Write different reports for each problem.
                                        How to Report a Bug?

Use following simple Bug report template: This is a simple bug report format. It may vary on the bug report tool you are using. If you are writing bug report manually then some fields need to specifically mention like Bug number which should be assigned manually.

Reporter: Your name and email address.

Product: In which product you found this bug.

Version: The product version if any.

Component: These are the major sub modules of the product. Platform: Mention the hardware platform where you found this bug. The various platforms like „PC‟, „MAC‟, „HP‟, „Sun‟ etc.
Operating system: Mention all operating systems where you found the bug. Operating systems like Windows, Linux, Unix, SunOS, Mac OS. Mention the different OS versions also if applicable like Windows NT, Windows 2000, Windows XP etc.

Priority: When bug should be fixed? Priority is generally set from P1 to P5. P1 as “fix the bug with highest priority” and P5 as ” Fix when time permits”.

Severity: This describes the impact of the bug. Types of Severity: 

•  Blocker: No further testing work can be done.  
•  Critical: Application crash, Loss of data. 
•   Major: Major loss of function.  
•  Minor: minor loss of function.  
• Trivial: Some UI enhancements.  
• Enhancement: Request for new feature or some enhancement in existing one. 

Status: When you are logging the bug in any bug tracking system then by default the bug status is „New‟. Later on bug goes through various stages like Fixed, Verified, Reopen, Won‟t Fix etc.

Assign To:  If you know which developer is responsible for that particular module in which bug occurred, then you can specify email address of that developer. Else keep it blank this will assign bug to module owner or Manger will assign bug to developer. Possibly add the manager email address in CC list.

URL: The page url on which bug occurred.

Summary: A brief summary of the bug mostly in 60 or below words. Make sure your summary is reflecting what the problem is and where it is.

Description: A detailed description of bug. Use following fields for description field:

Reproduce steps: Clearly mention the steps to reproduce the bug.  
Expected result: How application should behave on above mentioned steps. 
Actual result: What is the actual result on running above steps i.e. the bug behavior. 

These are the important steps in bug report. You can also add the “Report type” as one more field which will describe the bug type.

The report types are typically:
1) Coding error
2) Design error
3) New suggestion
4) Documentation issue
5) Hardware problem

Some Bonus tips to write a good bug report:

1) Report the problem immediately: If you found any bug while testing, do not wait to write detail bug report later. Instead write the bug report immediately. This will ensure a good and reproducible bug report. If you decide to write the bug report later on then chances are high to miss the important steps in your report.

2) Reproduce the bug three times before writing bug report:Your bug should be reproducible. Make sure your steps are robust enough to reproduce the bug without any ambiguity. If your bug is not reproducible every time you can still file a bug mentioning the periodic nature of the bug.

3) Test the same bug occurrence on other similar module: Sometimes developer use same code for different similar modules. So chances are high that bug in one module can occur in other similar modules as well. Even you can try to find more severe version of the bug you found.

4) Write a good bug summary: Bug summary will help developers to quickly analyze the bug nature. Poor quality report will unnecessarily increase the development and testing time. Communicate well through your bug report summary. Keep in mind bug summary is used as a reference to search the bug in bug inventory.

5) Read bug report before hitting Submit button: Read all sentences, wording, steps used in bug report. See if any sentence is creating ambiguity

that can lead to misinterpretation. Misleading words or sentences should be avoided in order to have a clear bug report.

6) Do not use Abusive language: It's nice that you did a good work and found a bug but do not use this credit for criticizing developer or to attack any individual.

Conclusion: No doubt that your bug report should be a high quality document. Focus on writing good bug reports, spend some time on this task because this is main communication point between tester, developer and manager. Mangers should make aware to their team that writing a good bug report is primary responsibility of any tester. Your efforts towards writing good bug report will not only save company resources but also create a good relationship between you and developers.

                        

Impact on Software development without Testing: 

•  Lot of defects at UAT.
• We have to pay penalty for slippage of delivery.
• High Cost of Defect fixing.
• Dissatisfied Customer.
•  Loss of business.
• Low moral to developer.

Benefits Software Testing:

•  Software Development Perspective
•  To discover defects.
•  To avoid the end user from defect problems.
•  Number of defects detected will tell about  the reliability of the software.
•  To ensure that product works as user expected.

 Business Perspective:

•    To stay in business.
•  To avoid being sued by customer.
•     To detect defects early, this helps in reducing the cost of fixing those defects later.
•  Increase customer satisfaction.

Do’s and Don’ts of Software Testing

                                      Do’s and Don’ts of Software Testing 

 

"A good Test Engineer should always work towards breaking the product right from the first release till the final release of the application (Killer attitude). Following are some Do’s and Don’ts for software test engineer:"

The Do’s:

1. Ensure if the Testing activities are in sync with the Test Plan.
2. Identify technically not strong areas where you might need assistance or trainings during testing. Plan and arrange for these technical trainings to solve this issue.
3. Strictly follow the Test Strategies as identified in the Test Plan.
4. Try getting a release notes from the development team which contains the details of that release that was made to QA for testing. This should normally contain the following details a. The version label of code under configuration management b. Features part of this release c. Features not part of this release d. New functionalities added/Changes in existing functionalities e. Known Problems f.  Fixed defects etc.
5. Stick to the input (reviewed and approved unit test case and test plan) and exit criteria for all testing activities. For example, if the input criteria for a QA release is sanity tested code from development team, ask for sanity test results.
6. Update the test results for the test cases as and when you run them
7. Report the defects found during testing in the tool identified for defect tracking
8. Take the code from the configuration management (as identified in plan) for build and installation Ensure if code is version controlled for each release.   
9. Classify defects (It can be P1, P2, P3, P4 or Critical or High or Medium or Low or anything) in a mutual agreement between the development team so as to aid developers prioritize fixing defects
10.  Do a sanity testing as and when the release is made from development team.

The Don’ts 

1. Do not update the test cases while executing it for testing. Track the  changes and update it based on a written reference (SRS or functional specification etc). Normally people tend to update the test case based on the look and feel of the application.
2.  Do not track defects in many places i.e. having defects in excel sheets and in any other defect tracking tools. This will increase the time to track all the defects. Hence use one centralized repository for defect tracking
3. Do not get the code from the developers’ sandbox for testing, if it is a official release from the development team
4.  Do not spend time in testing the features that are not part of this release
5.  Do not focus your testing on the non critical areas (from the customers’ perspective)
6.  Even if the defect identified is of low priority, do not fail to document it.
7.  Do not leave room for assumptions while verifying the fixed defects. Clarify and then close!
8.  Do not hastily update the test cases without running them actually, assuming that it worked in earlier releases. Sometimes these pre conceived notions would be a big trouble if that functionality is suddenly not working and is later found by the customer.
9.  Do not focus on negative paths, which are going to consume lots of time but will be least used by customer. Though this needs to be tested at some point of time the idea really is to prioritize tests.  

  

  

Capability Maturity Model Integration (CMMI):

Capability Maturity Model Integration (CMMI): 

“To provide guidance for improving your organization’s process and your ability to integrate and manage the development and maintenance of the products and services” 

 

 Level of CMMI: 

•  (CMMI Level One) Initial:    No process is implemented (Ad-hoc Work).

• (CMMI Level Two)Managed: Process is implemented at project level(Human Oriented not Process Oriented.) 

•  (CMMI Level Three)Defined:   Process is implemented at organization level. 

•  (CMMI Level Four)Quantitatively Managed: Controlling and measuring the process. 

• (CMMI Level Five)Optimizing: Continuous improvement.

 

 



Seven Testing Principles

In this article we  are going to discuss seven principles of testing and brief explanation .

Principle 1:

Testing shows Presence of Defect, but can't prove that there are no defects. Testing reduce the probability of undiscovered defects remaining in the software but, even if no defect are found ,its is not proof of correctness.    
 

Principle 2:

Exhaustive testing is impossible,testing every thing is not feasible. If we take an example where one screen has 15 input fields, each having 5 possible values ,then to test all of valid input value combination need ,  5 ¹⁵ 30,517,578 test!. It is unlikely that the project scale would allow for this test.

Principle 3:

Early Testing, testing activities should start as soon as possible in software  in the software or system development life cycle and should focus on defined objectives, Early testing- such as early test design and review activities - finds early on when they are cheap to find and fix. Once code is written, programmers and testers often run set of tests so they can identify and fix in the software.
 

Principle 4 :

Defect Clustering, In  your opinion, Which operations is most likely to cause your Operating system to fail?

I am sure most of you would have guessed, Opening 10 different application all at the same time. So if you were testing this Operating system you would realize that defects are likely to be found in   multi-tasking and needs to be tested thoroughly which brings us to our next principle Defect Clustering which states that a small number of modules contain most of the defects detected.

Principle 5:

Pesticide Paradox,If the same tests are repeated over and over again , eventually the same test cases will no longer find new bugs. This is the another principle of testing called “Pesticide Paradox "To overcome this, the test cases need to be regularly reviewed & revised , adding new & different test cases to help find more defects. 

Principle 6:

Testing is context dependent, which basically means that the way you test a e-commerce site will be different from the way you test a commercial off the shelf application.

 Principle 7:

Absence of errors - fallacy, if you work extra hard , taking all precautions & make your software product 99% bug free .And the software does not meet the needs & requirements of the clients Absence of Error is a Fallacy i.e. Finding and fixing defects does not help if the system build is unusable and does not fulfill the users needs & requirements. 

 

Software Testing As a Career - A Complete Guide

If you plan to make a career in software testing , this is a MUST READ!

What is software Testing?

Software testing is a group of activities that ensure the Quality of Software product.

                                            OR

" An activity to ensure the correctness, completeness & quality of the software system with respect to requirements.

"
Why Testing:

Testing is not limited to the detection of “bugs” in the software, but also increases confidence in its proper functioning and assists with the evaluation of functional and nonfunctional properties. 
Testing is an important and critical part of the software development process, on which the quality and reliability of the delivered product strictly depend.

Skills required to become a Software Tester 

Following skills are indispensable to become a good software tester. Compare your skill set against the following checklist to determine whether Software Testing is a really for you-

•   Analytical skills: A good software tester should have sharp analytical skills. Analytical skills will help break up a complex software system into smaller units to gain a better understanding and created corresponding test cases.    

•   Technical skills : A good software tester must have strong technical skills . This would include high level of proficiency in tools like MS excel, SQL Queries etc. , Testing tools like QTP , Selenium, Loadrunner , Quality Center ,Rational Clear Quest,Jira etc.. and of course deep understand of the application under test. These skills can be acquired through relevant training and practice. Also it's an added advantage that you have some programming skills but its NOT a must.

•   Good verbal and written communication skill: A good software tester must have a good verbal and written communication skill. Testing activities  (like test cases/plans, test strategies, bug reports etc) created by the software tester should be easy to read and comprehend. Dealing with developers (in case of bugs or any other issue) will require a shade of discreetness and diplomacy.        

• Testing at times could be a demanding job especially during the release of code. A software tester must efficiently manage workload, have high productivity ,exhibit optimal time management and organization skills. 

•   GREAT attitude: To be a good software tester you must a GREAT attitude. An attitude to ‘test to break' , detail orientation , willingness to learn and suggest process improvements. In software industry, technologies evolved with an overwhelming speed and a good software tester should upgrade his/her technical skills with the changing technologies. Your attitude must reflect a certain degree of independence where you take ownership of the task allocated and complete it without much direct supervision.  
• To excel in any profession or job, one must have a great degree of the passion for it. A software tester must have passion for his / her field. BUT how do you determine whether you have a passion for software testing if you have never tested before? Simple TRY it out and if software testing does not excite you switch to something else that holds your interest. 

Academic Background:

Academic background of a software tester should be in Computer Science. A BTech(Electronics/Computer Science)/ B.E. , MCA , BCA , BSc- Computers will land you a job easily.
If you do not hold /or have any of these degrees than you must complete a software testing certification like ISTQB and CSTE which help you learn Software Development/ Test Life Cycle and other testing methodologies.

Typical Workday:

On any typical work day you will be busy understanding requirement  documents , creating test cases , executing test cases , reporting and re-testing bugs , attending review meetings and other team building activities.

Career Progression:

our career progression as a software tester (QA Analyst) in typical CMMI level 5 company will look like following but will vary from company to company
QA Analyst (Fresher) => Sr. QA Analyst (2-3 year experience)=> QA Team Coordinator (5-6 year experience> =>Test Manager (8-11 experience) => Senior Test Manager (14+ experience).

Alternate Career Tracks as a Software Tester

Once you have got yours hand dirty in manual testing , you can pursue following specializations

• Automation Testing : As an automation Test Engineer , you will be responsible for automating manual test case execution which otherwise could be time consuming. Tools used IBM Rational Robot , Silk performer and QTP  
• Performance Testing: As a performance test engineer , you will be responsible for checking application responsiveness (time taken to load , maximum load application can handle) etc. Tools used WEBLoad , Loadrunner.  
• Business Analyst: A major advantages Testers have over Developers is that they have end to end business knowledge. An obvious career progression for testers is to become a Business Analyst. As a Business Analyst you will be responsible to analyze and assess your company's business model and work flows ,and especially how they integration with technology . Based on your observation you will suggest and drive process improvements.

Common Myths

  Software Testing as a Career pays Less

  Developers are more respected as compared to Testers

Contrary to popular belief , Software Testers (better known as QA professionals) are paid and treated at par with Software Developers in all "aspiring" companies. A career in Software Testing should never be considered as "second rated".

                   Software Testing is Boring

Software Testing could actually "test" your nerves since you need to make sense of Business Requirements and draft test cases based on your understanding. Software testing is not boring. What is boring is doing the same set of tasks repeatedly. The key is to try new things. For that matter , have you ever spoken  to a software developer with more than 3 years experience ?He will tell you how boring his job has become off-lately.

Okay I am interested ,where to  begin ?

For a complete newbie, here is our suggested approach to learn Software Testing

Read more at qamanualtesting.blogspot.in     

  !!! Happy Learning !!!