Oct 24 2008 10:15AM GMT
Posted by: Jaideep
software quality assurance,
software testing,
Project Management,
software,
software quality,
Quality Assurance,
Software testers,
SDLC,
software qa,
Bug,
developer,
Project Lifecycle,
software testing cycle,
software testing tips,
softwaretesting,
STLC,
tester,
Bug Management,
Bug Control Management
Bug Management and Bug Control Management are two separate aspects in software development. Bug Control Management seeks a higher maturity level in terms of organization, developers, project managers and all others involved. On the other hand, Bug Management starts in organizations with low maturity level. Organizations that attain the Bug Management level and keep it for years, stop maturing and keep a particular level of maturity sustained within them. There are organizations that move (over a period of time) from Bug Management to Bug Control Management. These organizations keep improvising and seeking improvements in their processes and procedures.
Usually a software organization life starts with software development. Gradually with the increase of business, increase of experience of developers, and increase in customer expectations an increased level of reliability in the software from all directions is expected. To cope up with this pressure, the organization creates a department called as Quality Assurance. This department takes care of testing of software, finding out bugs and getting it verified after the bugs are fixed by the development team.
Bug Control Management is a management initiative to involve all concerned to form a steering committee. The responsibility of this committee is to ensure that lesser and lesser bugs are generated in the software while development.
Oct 22 2008 10:11AM GMT
Posted by: Jaideep
software quality assurance,
software testing,
Project Management,
software,
software quality,
Quality Assurance,
SDLC,
software qa,
Bug,
developer,
software testing cycle,
software testing tips,
STLC,
tester,
Bug Management
In simple terms BLC or Bug lifecycle can be defined as the different stages of bug. BLC or Bug lifecycle will consist of all these stages starting from the birth of a bug till its removal from the application. The various stages of bug lifecycle or BLC can be listed as below:
1. Bug induction or generation in the software
2. Bug identification
3. Bug behavior study
4. Impact study
5. Bug classification
6. Bug admittance
7. Bug removal assignment
8. Bug removal
9. Verification
The birth of bugs is unintentional, uncontrolled and hidden. A bug is prone to take birth while a code is being written. A bug is not a bug until it is identified or recognized.
BLC or Bug Life Cycle starts with an unintentional software bug or unwanted behavior and ends when the assigned developer fixing the bug.
Oct 8 2008 10:35AM GMT
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.
Oct 6 2008 10:18AM GMT
Posted by: Jaideep
software quality assurance,
software testing,
Project Management,
software,
software quality,
Quality Assurance,
Software testers,
SDLC,
software qa,
Project Lifecycle,
software testing cycle,
software testing tips,
softwaretesting,
STLC,
tester,
project manager
In my previous blog we tried to understand what can be termed as a Bug. Here we will (in continuation to that) try to find out the reasons of causes of generation or occurrence of a Bug.
A Bug shall occur in consequence to:
An effort to write a perfect code in terms of performance and/or function
An effort to embed business requirements in the software
A complex code structure in place of a simple code structure
Complex customer requirements
Repeated code change
Unclear understanding of business requirements
Unclear or incomplete customer specifications
Unclear or incomplete documentation
Multiple programmers working on the same set of coding over a period of time
Incompetent programmers working on a code
Improper coding tool selection
And sometimes a bug is passed as it is (uncaught or unhandled) in the final product released to the customer due to improper testing which can have very serious repercussions.
I will address to this issue in one of my next blogs on how to ensure that the customer gets a total bug free product.
Sep 29 2008 10:44AM GMT
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
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.
Sep 24 2008 10:39AM GMT
Posted by: Jaideep
software quality assurance,
software testing,
Project Management,
software,
software quality,
Quality Assurance,
software engineering,
Software testers,
SDLC,
software qa,
developer,
Project Lifecycle,
software testing cycle,
software testing tips,
softwaretesting,
STLC,
tester
Let us understand what is the purpose of bugs report or defects report? Is it serving its purpose? How much?
The purpose of a bugs report or defects report is to make the intended recipients of this report to understand each and every bug reported in its perspective view. A bugs report has to be quite elaborative in explaining the developers if any business or customer requirement has been failed to meet or has been built wrongly.
Logically defects or bugs report is a report card of testing process. This is the only way to find out how extensively and perfectly testing has been performed. How well have the business rules and customer requirements been understood by testers is reflected by the test cases performed. It also reflects how well Business requirements or customer requirements been documented.
The bugs or defects report not only reflects the total health of the system built but also shows how perfectly has been the testing performed, how well the requirements have been documented and how well the documented requirements been built into the system.
The quality of the product fails its purpose if the testing is not performed well. On the other hand a good testing of a bad system will not be of much use in ensuring a perfect system meeting customer’s requirements.
The bugs should be written so elaborative that they are quite clear to the development team to understand and act on it. These bug reports can be referred to any time in the future too. The more is the clarity or simulation required by the development team from testing team, the less is the purpose of bugs report being served. All it indicates is that the report needs improvement.
Sep 19 2008 10:55AM GMT
Posted by: Jaideep
software quality assurance,
software testing,
Project Management,
software,
software quality,
Quality Assurance,
Software testers,
SDLC,
software qa,
Project Lifecycle,
software testing cycle,
softwaretesting,
STLC,
tester
A bugs report or defects report is a list of bugs found out by testers while testing a software product in testing phase under a testing environment. The test environment is created at development site similar to the actual environment in which the software is supposed to work or run in live situation at customer site. Environment built for testing is supposed to be an independent entity meant only for testing team to perform testing without any development changes happening on it.
Bugs or defects report is the most vital tool for developers to understand where the product that has been built by them is lacking its functionality or performance. Testers have to be very careful in studying business and customer requirements while building their test cases and test plan. The quality of test cases will clearly enhance the core performance and functionality of the product built.
Aug 18 2008 10:18AM GMT
Posted by: Jaideep
software testing,
Project Management,
Development,
software quality,
Quality Assurance,
software engineering,
SDLC,
software qa,
Project Lifecycle,
software testing cycle
This is in continuation to my earlier blog “Project Management – A Sad Story” http://itknowledgeexchange.techtarget.co…). Keeping all the character names same as described there, I will update my readers on what happened to this particular project headed by Roberts. Although Roberts is new to these projects but is trying his best to get into each issue and address it appropriately keeping ‘common sense’ part intact while making a decision. Roberts knows and often tells others that project management is not only about the management of a project, it is about managing people working under you, it is also about customer. The story takes a couple of twists and turns and moves altogether differently.
Julia, the project leader, accepts her defeat, and resigns from the organization. Linda, Lisa, Paula, Edger and Alex are doubtful about the success or completion of this project. The issues that arose at customer site were majorly two as stated by the customer – one is that Julia is not competitive enough to understand business requirements and embed them into the software, and second is that Team has no purpose in staying at customer site till the product is complete. So they sent the team back to their country. Julia’s resignation is accepted as management also feels she is one of the reasons of this failure. Sandy, the QA head, is given an additional charge as project leader of this project. Sandy has a good record or project management and has been 100% successful in all the project he handled so fat prior to becoming the QA Head. One would wonder when he was so successful in Projects, why he became QA Head. Probably he knew that this Quality of ‘quality; of a product in him is one of the key factor for all his project management success. Sandy accepts this challenge but with an apprehension that before Julia stops coming to the organization, she atleast explains him the complete picture at customer site about project, requirements, and customer. Sandy has to not only take care of all customer needs to be built in the product, but also to ensure the quality aspect of it. The project is delayed by 20 odd days. Development team is working in the customer requirements. Sandy is overall now is the linking part between offshore customer and his development team (and also for his testing team).
Only apprehension Sandy has now is that if the fresh requirements brought by Julia were complete and exact or still if he has to face the similar situation again!
Let us wait and watch!
By the way – what is your opinion on this – what would happen to this project – SUCCESS or FAILURE!
