software testing projects

Oct 8 2008   10:35AM GMT

Bug Management - Major Concerns being felt across the Globe

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, software quality, Quality Assurance, software engineering, Software testers, SDLC, software qa, Bug, Project Lifecycle, software testing cycle, software testing projects, softwaretesting, STLC, tester, project manager, testing environment, Bug Management

Senior Management including CIOs, QA Heads, CEOs, Development Heads, Project Heads, Customers, Vendors and/or sub-contractors related to software Organizations across the globe has repeatedly displayed their concern over the Bugs Management Process from time to time.

These concerns could be grouped as below:

1. The results of the Testing process are regularly inconsistent: This means that if same code is being tested by different group of testers under different leads, the results will vary always. Also the same team performing testing on different products will result in different performances.

2. The test results do not lead to more effective coding: The coding is always prone to create bugs (programmers are always as overconfident as ever).

3. The identification and quantification of a Bug is highly dubious: All the efforts by testing team in identifying and categorizing a bug is not always able to meet the seriousness it is meant for. Moreover sometimes a bug becomes an issue of debate over its category (critical/ severe/ desirable etc.).

4. Quality managers and testers often appear to have a limited knowledge of the code and business concepts and related issues.

5. Excessive focus and reliance on quantitative bug analysis is dangerous.

6. Bugs with a low probability occur more often than would be expected.

7. Bug management leads directly to bug avoidance.

8. Bug prioritization by Test managers is usually a simple ranking showing little or no understanding of the business process or customer requirements.

Most of the time the goal of testing is to diagnose the cause of bugs and produce better solutions. Instead the focus should be more on avoidance of bug generation at the code level so that least changes happen in the code once generated.

Sep 29 2008   10:44AM GMT

Role of tester while verifying the closure of bugs

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, software quality, Quality Assurance, SDLC, software qa, Project Lifecycle, software testing cycle, Software testing methodologies, software testing procedure, software testing process, software testing projects, software testing tips, softwaretesting, STLC, tester

When a product gets completed, it is released for testing to QC department along with the relevant documents. The QC department based on the scope of testing, availability of testers and the time at which the product is estimated to be released to customer, prepares its test plan. After studying the business and customer requirements, test cases and test scenarios are built by testers, based on which bugs or defects are reported. Once the bugs report (or defects report) is released to development team by the testing team, it is the development team that comes into the action. They based on the category, validity of a bug divide among themselves the bugs to be fixed and inform the testing team the estimated time required to close or address all the bugs/ defects. Once all the defects are fixed, the product goes back to testing team, for verification of closure of bugs.

The question arises here is that what is now the scope of testers for a re-released product. Does it suffice the purpose if testers just validate the closure of bugs? No, it is never going to be a fool-proofed product. What about the complete re-testing of the product for the two main purposes:

1. The bugs skipped in the earlier round of testing
2. The new bugs arisen during the fixing the earlier bugs reported.

This is very crucial phase and the testing in this phase needs to be more exhaustive and extensive than the earlier round of testing.

Sep 26 2008   10:42AM GMT

What next after Bug Report (or Defect report) is released?

Posted by: Jaideep
software quality assurance, software testing, Project Management, software, software quality, Quality Assurance, SDLC, software qa, Project Lifecycle, software testing cycle, software testing process, software testing projects, software testing tips, softwaretesting, STLC, tester

As soon as a bug of defect report is released by Quality department to Development Team, the first task of the development team is to call for a meeting inviting all those involved in the development of the product, the project head, the quality head and the testers who have performed testing. Prior to this meeting, it is good if the development team just have a go through of the list submitted to them. The purpose of this meeting is – to clarify if there is any understanding gap regarding a bug reported, to assign the tasks to developers (who is going to fix the bugs), the time frame. And at the same time mark the bugs that need simulation, clarification, need not be fixed, duplicate bugs reported, false bugs, incorrect bugs (the design is meeting the customer requirements but falsely reported as a bug by testers).

Spending time in this meeting with most of the people required is going to be very fruitful. This meeting places all involved on the same mindframe.

Immediately after the meeting (or during this meeting, if possible), the development team should fill in the estimate time required for fixing each bug (time required is to be filled against each bug). Then arrive at a conclusion when the product tentatively is going to be handed over to the test team again for verification of closure of bugs, or finding out any new bugs.

Aug 14 2008   10:35AM GMT

Twelve essential Steps of Software Testing Life Cycle (STLC)

Posted by: Jaideep
software quality assurance, software testing, Project Management, software quality, Quality Assurance, software engineering, Software testers, SDLC, software qa, Project Lifecycle, software testing cycle, Software testing methodologies, software testing procedure, software testing process, software testing projects, software testing strategy, software testing tips, softwaretesting, STLC

STLC (Software Testing Life Cycle) is an integral component of SDLC (Software Development Life Cycle). Gone are the times when any software was made on the basis of its requirements and the moment it used to get completed by the development team, it got released to the customer. But now, Testing has become a distinct phenomenon during and after the development of software. No software is released to the customer without a comprehensive testing by QC or Testing team in the organization. The Scope and Methodology may vary from product to product, customer to customer, and organization to organization. There are certain aspects of Software Testing Life Cycle. To name top few among them, I would like to list twelve essential steps of Software Testing Life Cycle.

The Steps are to be followed from the start of Testing of software to the end of the testing as follows:
1- Before the dynamic testing, there is a static testing. Static testing includes review of documents required for the software development. This includes following activities:

(a) All the documents related to customer requirements and business rules that are required
for software design and development should be handed over to QA. These documents
should be complete and dually signed by client and representative of the company
(usually Project Manager).

(b) QA reviews these documents. The reviewing of documents includes comprehensive and
thorough study of the documents. If any discrepancy is found then it should be noted
and raised in the review meeting with the Development team.

(c) After this there should be a formal meeting between the QA and development team
regarding these documents, the agenda of this meeting mainly includes what is missing in
the document, QA queries to be answered by Development/Project Team and/or
clarification required for any confusions.

2- After the Software development or build of a module, QA starts dynamic testing. If during the development the requirement has been changed on customer demand or due to any other reason, then that should be documented and a copy of this revised document is given to the QA and also discussed as explained in point 1 above.

3- Development and Testing environment should be made clear to the QA by the Development team. It include the following activities:
(a)- Server to hit for Testing
(b)- Installation of latest build on the test server.
(c)- Modules/Screens to test.
(d)- Test duration as decided by test manager and project manager mutually based on scope
of work and team strength.
(e)– Demo of the software on test server by development team to the QC members.

4- After this Test cases and test scenarios are prepared and then the Test execution by QC.

5- A comprehensive Report of Bugs is prepared by the Testers and a review/verification by QC/QA/Testing Head takes place. Before handing over this report to Development Team there is a thorough review of Bugs List by Test Manager and in case of any clarification required on a bug submitted, the Testing Head discusses the bugs with the assigned tester.

6- Release of bug report by QC Team to Development Team.

7- Discussion/simulation of bugs by QC with development team if development team requires and time required for fixing the bugs should be made clear by Dev team at this stage.

8- Feedback from Development team on reported bugs with the stipulated time frame required to fix all bugs.

9- Any changes in the software being made in respect to fix these bugs should be made clear to the QA team by the Development team.

10- Testing team then Retests or verifies the bugs fixed by the development team.

11- Submitting the retesting bug report to the Test manager and after this the step 5 to step 10 are followed until the product has reached a stage where it can be released to customer.

12- Criteria for ending the testing should be defined by management or Test Manager Like when all major bugs are reported and fixed. Major bugs mean the bugs that affect the Business of the Client.

Aug 12 2008   11:00AM GMT

Eight Checkpoints for Testers during Software Testing

Posted by: Jaideep
software quality assurance, software testing, Project Management, Development, software quality, Quality Assurance, software engineering, Software testers, SDLC, software qa, software testing cycle, Software testing methodologies, software testing procedure, software testing process, software testing projects, software testing strategy, software testing tips, softwaretesting

Testing is a process of facilitating development team/ project team in improving the quality of software before it is released to the customer for use. Some key essential steps are always there that need to be followed by the Testers during Software Testing to streamline the process. The most important checkpoints for testers during software testing, in my opinion, would be:

(1)- Complete document of customer and business requirements specifying all the requirements for the development of the product.

(2)- Latest completed build and URL of the application to hit for Testing.

(3)- Software requirements for installing the application on PCs for testing or for database connectivity.

(4)-Training/Demo of the project by development team to Testing Team so as to understand the flow/functionality of the software.

(5)- Scope of testing should be made clear by the development team/Head.

(6)- If the build comes for retesting, then it should be accompanied by the revised document which includes the updated changes incorporated in the software.

(7)- Clarity regarding which member of development team should be contacted in case of any clarification required during the testing phase regarding the functionality of the module or if testers encounter a showstopper in the Software.

(8)- After release of the bugs list to development team, how much time they will require for fixing the bugs.