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'

 

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.