How to: Dummy Credit card # for Testing

Here are list of credit card numbers which we can use for testing purpose. You can use this numbers and give other details like year and month and cvv as dummy ones. These  works for testing purpose.

Credit Card Type	Credit Card Number
American Express	378282246310005
American Express	371449635398431
AMEX Corporate	378734493671000
Diners Club	30569309025904
Diners Club	38520000023237
Discover	6011111111111117
Discover	6011000990139424
JCB	3530111333300000
JCB	3566002020360505
MasterCard	5555555555554444
MasterCard	5105105105105100
Visa	4111111111111111
Visa	4012888888881881

Different types of status in Bug report

Here is the description of all the status with its brief description

1. Bug: When QA files new bug.

2. Deferred: If the bug is not related to current build or cannot be fixed in this release or bug is not important to fix immediately then the project manager can set the bug status as deferred.

3. Assigned: ‘Assigned to’ field is set by project lead or manager and assigns bug to developer.

4. In Process: This is the state of issue when Developer starts working on the assigned issue.

5. Resolved/Fixed: When developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing team.

6. Could not reproduce: If developer is not able to reproduce the bug by the steps given in bug report by QA then developer can mark the bug as ‘CNR’. QA needs action to check if bug is reproduced and can assign to developer with detailed reproducing steps.

7. Need more information: If developer is not clear about the bug reproduce steps provided by QA to reproduce the bug, then he/she can mark it as “Need more information’. In this case QA needs to add detailed reproducing steps and assign bug back to dev for fix.

8. Reopen: If QA is not satisfy with the fix and if bug is still reproducible even after fix then QA can mark it as ‘Reopen’ so that developer can take appropriate action.

9. Closed: If bug is verified by the QA team and if the fix is ok and problem is solved then QA can mark bug as ‘Closed’.

10. Rejected/Invalid: Sometimes developer or team lead can mark the bug as Rejected or invalid if the system is working according to specifications and bug is just due to some misinterpretation.

11. Not a Bug: If the reported issue is not a bug or not for the current build then project lead or manager will set the status to 'NAB'

How to write a good bug report?

Here is the synopsis on writing a good bug report. Hope you all know about Bugs. Here I’ll tell you how can we write better bug reports and how to use bug tracker.

Why we need a 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. If tester is not reporting bug correctly, programmer will most likely reject this bug stating as irreproducible.
1) 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.
2) Be Specific:Do not write a 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.
3) Having clearly specified bug number: When you are talking about the bug, identify it with bug number. Ex: Issue 101 etc. This will help to identify the bug record. Note the number and brief description of each bug you reported.

How to Report a Bug in Bug tracker?
While reporting a bug, don’t forget to mention version, Product, component or module, Platform (Ex: Mention the hardware platform where you found this bug. The various platforms like ‘PC’, ‘MAC’ etc.).
Operating system (Ex: 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.)
Title: Should be easy specific to the bug.
Priority: When bug should be fixed? Priority is generally set from High to Low.
Status: When you are logging the bug in bug tracking system you can find different status, I have given more detail about test status in my blog here.
Comments: 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.

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.

URL: The page URL on which bug occurred is always helpful
All your comments will be seen in chronological order.

Attachments: Any screen shot or related document is helpful for developer or your manager. A picture is more powerful than mere words.

History: History will tell you all the activities related to the issue among the users.

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.

Conclusion:
Your efforts towards writing good bug report will not only save company resources but also create a good relationship between you and developers.