Home » 9/1/07 - 10/1/07
Priority in Bug Tracking !!!

Priority is used to organize the work.This field describes the importance and order in which a bug should be fixed.

The field only takes meaning when owner of the bug

P1 - Fix in next build
P2 - Fix as soon as possible
P3 - Fix before next release
P4 - Fix if time allows
P5 - Unlikely to be fixed

 Default priority for new defects is set at P3.

Under: , , ,
Severity in Bug tracking !!!

This field describes the impact of a bug. The submitter of the bug should consider carefully their view of the bug severity, i.e. the impact to them as the end user.

 Blocker - Blocks development and/or testing work
Critical - crashes, loss of data, severe memory leak
Major - major loss of function

Normal - Minor loss of function.Unfriendly behavior that is hindering, but workable, for the user or service
Minor - Minor loss of function.Unfriendly behavior that is merely annoying to the user
Trivial - cosmetic problem like misspelled words or misaligned text
Enhancement - Request for enhancement

Note : The default severity is Normal.

Under: , , , , , , ,
Bugs in software testing !!!

Bug:
An Error found in the development environment before the product is shipped to the customer.

 Bug Reporting :
A person who uses a product Reports a Bug/Malfunctioning ..etc to a person who developed the product

 Bug Tracking :
Managing and Reviewing a bug and its status

 Bug Tracking System :
This is a system designed especially to manage software problems, enhancement, change request during software development life cycle.

Under: , , ,
Application Binary Interface !!!

A specification defining requirements for portability of applications in binary forms across different system platforms and environments.


It describes the low-level interface between an application program and the operating system, between an application and its libraries, or between component parts of the application.

Under: ,
Process in Agile Testing !!!

Process in Agile testing:
***************************
1) Conversational test creation
2) Coaching tests
3) Providing test interfaces
4) Exploratory learning

 Conversational test creation
*****************************
* Who should write tests
* Defining test is a key activity that should include programmers and customer representatives.
* Don't do it alone.

 Cooaching Tests
*******************
* A way of thinking about acceptance tests
* turn user stories in to tests
* Tests provide
1) Goals and guidance
2) Instant feedback
3) progress measurement
* Tests are specified in a format:
1) That is clear enough that users/customers can understand.
2) That is specific enough that it can be executed.
* specification by example

 Providing test interfaces
**************************
Developer are responsible for providing the fixtures that automate coaching tests.
2) In most cases XP teams are adding test interfaces to their products,rather than using external test tools.

Test Interaction model
**************************

Exploratory learning
************************
Plan to explore the product with each iteration
Look for bugs , missing features and opportunities for improvement.
we don't understand software until we have used it.

Under: ,
Agile testing !!!

Agile Testing
***************

 * Testing practice that follows the agile manifesto, treating development as the customer of testing
* Testing practice for projects using agile methodologies.

Under: , ,
Test case for Database testing !!!

Steps to writing test cases for database testing
***********************************************
1) Learn the functional requirement of the application (SRS) completely

 2) Find out the back end tables used, joined used between the tables, cursors used (if any), triggers used(if any), stored procedures used (if any), input parameter used and output parameters used for developing that requirement.

 3) By knowing all these things write the test case with different input values for checking and comparing the actual results with the expected results for the application.

 Note : For writing test cases for back end operations, the tester must know the white box testing.

Under:
Stages in Database testing !!!

Stages in Database Testing
****************************

1) Testing the data in the database with respect to front end transactions.

 2) Testing the constraints (primary key,forien key ....).

 3) Testing the performance of the procedures.

 4) Testing the triggrs (execution of triggers).

 4) Testing the transactions (begin,commit,rollback).

Under: ,
Database testing !!!

Database testing
*****************

This is the process of testing the input data collected by the clients side with the inbuilt database activities. For example, testing that the datas to be save are going correctly to the database or not, correct datas to the database types are entering or not etc.

It includes the following process
**********************************

1) Data validity testing using SQL queries
2) Data Integrity testing by knowing the referential integrity and different constraint.
3) Performance related to data base. ( considering the table structure and design )
4) Testing the Procedure,triggers and functions.

Under: , , ,
Ad hoc Testing !!!

Ad hoc testing
***************

 It is performed without planning and documentation. The tests are intended to be run only once, unless a defect is discovered. Ad hoc testing is a part of exploratory testing, being the least formal of test approach. In this view, ad hoc testing has been criticized because it isn't structured, but this can also be a strength: important things can be found quickly. It is performed with improvisation, the tester seeks to find bugs with any means that seem appropriate. It contrasts to regression testing that looks for a specific issue with detailed reproduction steps, and a clear expected result. Ad hoc testing is most often used as a complement to other types of testing.

Under: , , ,
Exploratory testing !!!

Exploratory Testing
*********************
Exploratory testing is an approach in software testing with simultaneous learning, test design and test execution. While the software is being tested, the tester learns things that together with experience and creativity generates new good tests to run.
Exploratory testing has been performed for a long time, and has similarities to ad hoc testing.

When performing exploratory testing, there are no exact expected results; it is the tester that decides what will be verified, critically investigating the correctness of the result.

 Advantage of Exploratory Testing
***********************************
1. The main advantage of exploratory testing is that less preparation is needed, important bugs are found fast, and is more intellectually stimulating than scripted testing.
2. Exploratory testing is extra suitable if requirements and specifications are incomplete, or if there is lack of time. The method can also be used to verify that previous testing has found the most important defects.
3. It is common to perform a combination of exploratory and scripted testing where the choice is based on risk.

 Disadvantage of Exploratory Testing
**************************************
The tests can't be reviewed in advance (and by that prevent errors in code and test cases), and that it can be difficult to show exactly which tests have been run.

Under: , ,
Tips for Bug Tracking !!!

1. A good tester will always try to reduce the repro steps to the minimal steps to reproduce; this is extremely helpful for the programmer who has to find the bug.

 2. Remember that the only person who can close a bug is the person who opened it in the first place. Anyone can resolve it, but only the person who saw the bug can really be sure that what they saw is fixed.

 3. There are many ways to resolve a bug. FogBUGZ allows you to resolve a bug as fixed, won't fix, postponed, not repro, duplicate, or by design.

 4. Not Repro means that nobody could ever reproduce the bug. Programmers often use this when the bug report is missing the repro steps.

 5. You'll want to keep careful track of versions. Every build of the software that you give to testers should have a build ID number so that the poor tester doesn't have to retest the bug on a version of the software where it wasn't even supposed to be fixed.

 6. If you're a programmer, and you're having trouble getting testers to use the bug database, just don't accept bug reports by any other method. If your testers are used to sending you email with bug reports, just bounce the emails back to them with a brief message: "please put this in the bug database. I can't keep track of emails."

 7. If you're a tester, and you're having trouble getting programmers to use the bug database, just don't tell them about bugs - put them in the database and let the database email them.

 8. If you're a programmer, and only some of your colleagues use the bug database, just start assigning them bugs in the database. Eventually they'll get the hint.

 9. If you're a manager, and nobody seems to be using the bug database that you installed at great expense, start assigning new features to people using bugs. A bug database is also a great "unimplemented feature" database, too.

 10. Avoid the temptation to add new fields to the bug database. Every month or so, somebody will come up with a great idea for a new field to put in the database. You get all kinds of clever ideas, for example, keeping track of the file where the bug was found; keeping track of what % of the time the bug is reproducible; keeping track of how many times the bug occurred; keeping track of which exact versions of which DLLs were installed on the machine where the bug happened. It's very important not to give in to these ideas. If you do, your new bug entry screen will end up with a thousand fields that you need to supply, and nobody will want to input bug reports any more. For the bug database to work, everybody needs to use it, and if entering bugs "formally" is too much work, people will go around the bug database.

Under: ,
Bug Tracking !!!

A bug tracking system is a software application that is designed to help quality assurance and programmers keep track of reported software bugs in their work.

 Many bug-tracking systems, such as those used by most open source software projects, allow users to enter bug reports directly. Having a bug tracking system is extremely valuable in software development, and they are used extensively by companies developing software products.

 A major component of a bug tracking system is a database that records facts about known bugs.Facts may include the time a bug was reported, its severity, the erroneous program behavior, and details on how to reproduce the bug; as well as the identity of the person who reported it and any programmers who may be working on fixing it.

 Typical bug tracking systems support the concept of the life cycle for a bug which is tracked through status assigned to the bug.A bug tracking system should allow administrators to configure permissions based on status, move the bug to another status, or delete the bug.

 In a corporate environment, a bug-tracking system may be used to generate reports on the productivity of programmers at fixing bugs. The severity of a bug may not be directly related to the complexity of fixing the bug. There may be different opinions among the managers, architects and the developers about the relative ease of fixing bugs.

 Local bug trackers are usually a Computer Program used by a team of application support professionals (often a help desk) to keep track of issues communicated to software developers.

Under: , ,