bugs report

Jul 20 2009   10:00AM GMT

Responsibility of a tester - a different perspective

Posted by: Jaideep
tester, Development, Software Project, software product, Project Management, customer requirement, test case, testing report, test report, bugs report, quality control, QC, quality, product quality, software quality, developer, development team, code writing, coding

The responsibility of a tester is to ensure the peace of mind of the end users who are going to use the software product. Another target should be to safeguard customer’s investment in the product. In order to discharge this responsibility, the tester should focus all his skills on understanding customer requirements and measures to map it with product built by writing appropriately comprehensive test cases, performing test and preparing a detailed self-explanatory test report. Complex business requirements will require extraordinary level of understanding. Keep in mind the budget and time constraint for performing testing without compromising with the coverage or quality.

The overall impact of testing should be clearly visible on the product built. The bugs reported should bring a sense of belonging with the developers and customer users. Clarity of bugs in testing report should not only help developer to fix defects properly but guide him not to repeat the same type of issues in future releases. This may happen slowly but gradually should help in increasing developer’s performance and quality of code writing. After all the development team should start taking testers as their best friends and well wishers instead of someone who is trying to find out the weakness in code writing.

Jul 15 2009   10:00AM GMT

Who owns the Q-Tag in a software development company?

Posted by: Jaideep
Quality Assurance, Q-tag, quality control, Software Project, Project Management, stakeholder, project methodology, project management framework, project implementation, software build, software implementation, product approval, Quality-tag, project team, development team, implementation team, testing team, team, QC, QA, business analyst, re-testing, testing, Bug, bugs report, test report

In any software development and implementation company there is always a need of quality assurance and quality control people who own the responsibility of setting the right methodology and framework for development and implementation (QA), bugs identification and product approval (QC). Usually everyone in the organization has an inherent feeling that the quality is the responsibility of only these few persons belonging to this Q-department of the organization. Business analysts understand the customer and business requirement, hand it over to development team for building the product. Development team develops the product, and hands it over to QC team. QC team tests the product, finds out the bugs, and submits the report to development team. Development team fixes the bugs and returns the product to QC persons for re-testing and verification. After few exchanges between development and QC team, the product is declared as defect free and is released or launched for implementation.

If top management, development team, business analysts, implementation team and all other stakeholders think that quality is just the responsibility of only the persons belonging to quality department, they all are wrong. If Q-tag is limited to only a limited persons belonging to Quality department among all stakeholders, a product can never be built with great control on quality aspect.

Q-tag has to be on each of the stakeholder in a software project. When each and every person wears a Q-tag – the analysis, building, testing and implementation will be more justified. Otherwise there will always be a big question at the time of failure of a product build – that who is responsible?

Mar 6 2009   9:42AM GMT

Why software testing effort estimation is important after functional specifications finalization phase?

Posted by: Jaideep
software testing effort estimation, software testing, testing effort, functional specifications finalization, functional specifications, sizing of software testing effort, test case, testing time-line, testing timeline, testcase, quality standards, tester, testing, Test Plan, testing plan, test result, test report, development team, developer, software development, bug report, bugs report, testing guidelines, test plan guidelines, test estimation guidelines, testing knowledge, business rule, business process, functional coverage, bug-proofing

If we go by quality standards the sizing of software testing effort has to be done before the tester(s) start writing the test cases for the purpose. The estimate will clearly draw out of the functional specifications signed off between the customer and vendor. Without sizing the Testing manager can never create a testing plan based on which he will decide the number of days and persons required to write test cases, perform testing, draw out the testing results, submit the result report to development team and get the reported bugs resolved. The plan will comprise of time-line and no. of persons required for each of this phase in the sequence mentioned above.

To calculate a reasonable testing time-line estimate based on functional specifications there are certain guidelines that need to be followed: the person who is planning has to have ample business and testing knowledge. Unless (s)he has the right business knowledge (s)he will not be able to select the right persons for writing test cases, or able to guide them on the critical business rules and processes written in the software to hit upon. In that case the best of the test cases will lack the complete coverage and accuracy in testing. The software may lack bug-proofing at the end and customer will be the sole sufferer. Ultimately it is going to effect the software, and the organization that built it.