The definition of QUALITY varies in different contexts. On one hand we talk of software quality that means adopting standards and measures to ensure the building of software product that meets all customer requirements (design, interface, business requirements, functional requirements etc.) and ready to deliver. On the other hand when we talk of Project Quality, we mean the standards and measures by means of building (or adopting) to ensure the success in terms of time and revenues of a complete project right from its initiation till the implementation stage that keeps continuing at post implementation stage also.
In context of software – the quality means – software strategy, plan, text cases, test scenarios, test results and fixing of bugs. Inclusion of quality in this context will vary from organization to organization and project to project (within an organization). This will ensure the successful building of software product ready for delivery.
In context of project – the quality would mean – managing quality standards and measures for a project right from its initiation to all stages coming forth. A project lifecycle in standard terms would comprise of Project Initiation, Project Planning, Development Execution, Implementation execution, Project Close-out, and post implementation phase broadly, which remains on-going till the software built is in use by the customer for a period of years.
The subject matter can continue on pages and pages, but the crux is – software quality is merely a subset of project quality, and even if we have world class standards in software quality, it does not ensure a successful project lifecycle.
Certainly and obviously, every business has a set of objectives. Every business strives for survival, growth, revenues, profits, satisfaction and maturity. The clearer the objective are, the easier it is to achieve them. To achieve the objectives, if the destination is clear, it becomes easier to set the direction of the business, to set the milestones, to chalk out the roadmap, to set the drive, to decide the pace and to achieve them. The top 20 end objectives of any software project can be listed as below (note that the hierarchy is not as critical as the understanding of the gravity of each of the objective):
2. Standards and Methodology
4. Stakeholders rights
6. Pro-active approach to avoid post-mortem
7. Universal approach for similar projects
8. Timely completion, sign-offs and payments
9. Customer satisfaction and delight
10. Customer requirements and both end clarity on objectives of the product
11. Team building
12. Roles, responsibilities and accountability
13. Continuous Learning from failures/ overruns – no repetition of same mistakes to achieve continuous improvement overall
14. First time right approach
15. Quality right from start – ongoing – every step
16. Increase in revenue
17. Avoid revenue loss
18. Reduce costs
19. Avoid cost increases
20. Improved service
Following are the top 15 pain areas of a software project. All points listed below appear somewhere or the other in a software project lifecycle. The ratio of pain from a particular below listed item may vary from project to project within an organization, and also from organization to organization. So although the hierarchy may vary, the pain areas somehow remain the same. A lack in addressing any one of the issue listed below may call for a big hiccup in the smooth running and closure of a project. The project size (and in turn the time and team size also) will vary depending on customer and customer requirements. Although all points listed below are self explanatory, but the understanding and perception may vary from individual to individual.
In that respect, I would like to take each of the points below one by one in my forthcoming blogs to explain how much impact each of the instrument listed below will have on the project and how to overcome this pain not only for that projects but for all the projects in that organization to come in future. The most important activity for each individual is, now, to re-arrange the points (with any additions/ or replacements) according to the ratio of pain it is giving, and then learn how to convert that pain into pleasure once for all (in my future blogs for the later part!)
3. Customer requirements understanding
4. Measurement of Overrun is in money terms immaterial of time overrun (time is not measured in terms of money)
5. Frequent Status review in a forum
6. Status of project movement is person based
7. Role clarity to project manager and team on site
8. Risk analysis
9. Team building
10. Customer clarity in terms of milestones and payments
11. Project Repository
12. Learning from Past
13. Post implementation support
14. Quality – man, methods, approach and deliverables
15. Version Control
Recently a US passenger Airbus had a serious problem just after it took off from the Airport. The plane suddenly lost power in both engines, and pilot Chesley Sullenberger judged that it would be too difficult either to return to the airport of departure or to land at a nearby airport. Instead, he decided to land on the Hudson River, which in the middle of winter was frozen over. With hardly any time to think, Sullenberger drew on all his professional experience and self-confidence and made a snap decision. His decision saved the lives of all 155 people aboard the plane. Sullenberger was the last to leave the plane, and did so only after making sure that everyone else had been rescued. He did everything he had to do right through to the end.
Some learning points can be drawn out for the project manager who is the pilot of a project. The problems and failures can be part of any project, but the project is not dead till the Project Manager raises his/her hands against those problems and failures. A good project manager will never give up till the end and apply all his inherent skills to overcome those problems and failures to make that project a success. The learning points from this incidence can be summarized as below:
Don’t lose hope
Use your professional experience to overcome any crisis
Keep your self-confidence up always
Be ‘quick’ in taking ‘right’ decisions
Take responsibility to rescue all on board – your teams, your organization, your management, your customer and your product
Let others cheer individually on their successes/targets achieved but your cheer moment is only after the successful end of a project
Dear Product Manager don’t cheat your customer by bypassing final ‘testing’ of the product before launch
When work pressures are too high, deadlines are on head, we tend to bypass our own standards, procedures and policies. A product manager if affords to skip testing for that purpose, that means he is committing a crime which is quite serious offense. Any management supporting this idea becomes part of the crime. Testing on ‘wish’ of a person (the product manager), depending on time availability or delay in development clearly states there are no plans in reality. If development of the product is delayed, the implementation can be delayed, whatever be the pressure from customer. If customer is befooled by declaring that the product is ready to launch (which has in actual not been tested properly, and customer is unaware of this), that means the customer is being cheated.
The whole scenario calls for a delay or failure, but who cares – there is no discipline being followed and the confidence is – “we will handle any situation”. Had the product launch been delayed by clearly stating to the customer (or to the top management, if pressure if from there) that the testing and fixing of bugs will take some more days, the customer (or top management) would have always welcomed the decision and would surely have understood your compassion (and passion) towards product, organization and the customer. Definitely it is a call for troubles during launch and implementation stage if the ‘testing’ has been bypassed.
If this is so, we still are the same as we were, have learnt nothing from the past and are betting for failure in success. That also means that QA is being displayed as a ‘showpiece’ to customer or to top management.
Endnote – if you have an opinion that ‘testing’ or QC of the product is a useless activity, if you believe most of the bugs reported by the testers are useless, you are as right as your highest level commitment towards the product, development, yourself, your customer and your organization.
During one of my initial management trainings (years back) I learnt the different between hard worker and smart worker. This example I could never forget even after so many years. Example of a hard worker is a person who comes to office in the morning, puts off his shirt, start pushing a wall, and keeps pushing it throughout the day, keeps sweating, keeps management happy that he is working very hard, and goes off tired and weird at the end of the day with no end results. The wall is there as it is where it was in the morning.
The example of a smart worker is who comes to office, smartly dressed, hardly do any work himself, but still the results keep pouring in, the management remains happy with him.
In harsh words – there is a difference between a donkey and a horse.
Every project manager has a project charter, plan and schedule. Every project starts, but very few end in time with complete satisfaction of customer, management and project team members. Why so? Efforts are put in, in all the scenarios, but all do efforts do not fetch good results. Where lies the difference, is an important point to introspect. In most cases, even if the project fails, the project manager do not let the axe fall on him by proving n no. of reasons mostly situational and saves his skin. But at what cost and who is the loser? The management and the customer are the biggest losers in any project failure.
A project manager has to be ‘smart’ all the time to manage the project and for its successful timely completion. Major issue during a project is to be pro-active and smell the issue before it gets out of control. Second major issue is managing everything on your own, and hiding some bottlenecks from the management or customer. Infact by raising your voice and informing them about your problem related to the project will get you the solution faster and better. Taking the problem where you alone are not able to find a solution will enhance your image in their eyes. Similarly tracking your team is equally prime. Managing project is simple if your thoughts are not complex.
Dear Project Manager – your “faith” in 5 pillars of project can get you miraculous success in any Project
I remember a small inspirational story read somewhere recently. A small girl took all the money she had in her piggy bank and went to a nearby drug store. The drug store owner was busy on a phone, and the girl was waiting for him to get free at the earliest. As she got desperate she interrupted the owner – “excuse me – I want to buy miracle, how much it costs?”. The owner kept on talking over the phone with giving an ear to her. She repeated the same again, this time in a raised tone. Owner told her as he is busy talking to his brother staying in a far country after a long time. The little girl literally had tears, helpless as if she wanted something urgently. Another man was standing inside the shop. He got curious by what the girl had asked for. He asked the girl – “what do you want?”. She said I want miracle, and I have money for it. “But what do you need it for” – the man asked her. “My brother is very seriously ill, and my mother says only a miracle can save her” – she replied. The man was the most senior neuro-surgeon of the country. He accompanied the girl by saying – ok, I have the miracle, let us go to your house to see your brother. The boy was operated free of cost and got well. The total cost of operation was “FAITH” of the little girl and some dollars she had in her piggy.
Like the little girl, the project manager has to have this tool with him all the time to win over any situation and to gain success in any project. The 5 pillars of the project where a PM has to put his total faith into are:
5. Customer: The customer is the on whose money your organization, management, your teams, and you exist. Your faith in customer has to reflect in all your discussions, communications, deliveries and product. Chose your words very carefully when you are in front of your customer or even when you are having an off-hand communication through phone conversations, emails etc. Your actions speak louder than your words. So take care of your gestures and bod language too.
4. Management: Your management is banking on you for the building and delivery of the product. Don’t mingle facts with over-enthusiastic assumptions when you present the project report to your management or to your customer. Be realistic and conservative in presenting the facts and projections.
3. Team: Don’t divide your team into doers and non-doers, slow and fast runners, perfect and imperfect. Labels regarding the individuals once set in your mind will drastically and adversely affect the project. Trust them in the same volume as you want them to trust you.
2. Processes: Whatever processes and procedures you adopt for project management, follow them ethically, trust them and they will deliver you the best.
1. Self: This is the prime factor. If you don’t have this, if you don’t trust yourself, you will not be able to adhere to the 4 points mentioned above. You can (deliver your best) only if you think you can.
Miracles do happen but only buying coin is TRUST.
A new project is always divided into small tasks and based on the resources available, the task(s) are allocated to individuals by the project manager (PM). A simple metrics is important to follow to monitor (and manger) the completion of tasks and thereby figuring out at any moment of time – the progress of the project. Completion of all tasks automatically declares the completion of the project.
Customer and management will never be interested to go into the detail of each task, PM (you) and your team may be and should be. But your one of the major task during a project is to keep customer and management updated on what is happening, regarding the progress of the project.
Your team of individual developers, programmers, coders or other technical related functions, although have accountability for the tasks assigned to them in individual for which they put in all their efforts to meet your/their completion plans as per the targets set.
So far so good, but as far as satisfaction, and feel of achievement is concerned, you need to group a set of tasks (the important ones that really give sense of achievement) into milestones. The customer and management will be interested in milestones achieved instead of tasks completed. Your team members will feel motivated, inspired and cheerful on achieving these milestones. And above all you will have time to appreciate and celebrate your team’s achievements that you can not do rightfully in case of tasks.
Milestones have more visibility as compared to tasks.
It is not important what metrics you (the project manager) use, because unless and until you understand the meaning of “task” and “task completion”, you can’t get into the mode of monitoring and measuring it. The progress (or completion) project as a whole is measurable only if it is broken into pieces termed as “tasks”. Based on your resources you can allocate different tasks to different developers/ technical guys. But again the questions arise are – “what do you want to measure?” and on top of it, “do you really want to measure?”. If the answer is “yes” for the second question, then you will start thinking about “how to measure?”.
Metrics or method of measuring is not critical, it is the “what” that matters most here. So when you break up your software project into tasks, those should be measurable and the person doing it has to be accountable for it. Before making your programmer (or the technical person) accountable for a task, you have to evaluate – “is (s)he is fit for the task being assigned?”.
Your method of measurement will decide the clarity of progress of project to you, your team, the management and to the customer. Don’t accept a report from your subordinate declaring a task as completed unless you yourself are convinced. For your conviction you can get it checked by another coder, technical person or quality person, or you can check on your own, depending on the criticality of the task. Since you are going to report to management and the customer about completion of a task, it is important to confirm beforehand.
Transparency about the project progress is as important as the authenticity to both – the management and the customer.
Integrity of task completed is another measure that you have to take into account for your project completion.
Regression testing comes into picture in “re-testing” of a product. The purpose is very clear – a thorough testing. Regression testing has to be as rigorous as possible, for this reason. And regression testing never happens once, it has to happen again and again till the product reaches at a maturity state of release.
The purpose of a regression testing is to manage the risks occurring after the changes done to a product. Changes happen after the bugs have been reported to the development team or if the customer has asked for changes (or a new requirement) in the developing product. In an effort to entertain them many changes are done by the developers. The changes could result in following:
A bug fixed by the developer not actually fixed
New bugs built while taking into account the new requirements or changes from the customer
Earlier fixed bug re-occurring
To handle all this, an extensive and rigorous testing is required to be done by the testers for the good cause of releasing out a “bug-free” product at the end of regression cycles.
The most wrong statement from a Project Manager to the management during a project can be – “Everything is as per plan”. This is never, never possible during a project where a software development is required. If this is the statement from the Project Manager, there could be two realities behind it – one, either he is being cheated, or two, he is cheating the management (and in turn himself!, phew!). This could be due to (again two reasons) – either he is unaware of the facts, or he is trying to hide the facts. The first factor (being unaware of the facts) can be overcome with the help of some discipline and procedures, but if the second reason is surpassing the first one, then organization (both – the customer and vendor) are in trouble.
To overcome the first reason i.e. not to fall in the category of “not being aware of the facts”, the project manager has to follow certain guidelines, the prime could be:
1. Keep an updated project status report with you. (the frequency of updations could be in hours or days, but not in weeks or months).
2. The components of your project status report have to be –
Planned vs. Actual Efforts (mind it, there is a difference between the monitoring of tasks and efforts, and both play a major role in a project. Monitoring of both is essential)
Tasks requiring no “re-do” or “re-look”
Tasks requiring a “re-do” or “re-look”
Efforts/ hours “over spent”
Open bugs, risks, issues
List of customer requirements pouring in after clarification from the customer (during development). (and don’t tell me that there are no clarifications required from the customer during the development phase)
The balance efforts, with time, resources allocation and concrete plan. (this has to be as crisp and realistic as possible)
The young inexperienced or short experienced budding testers are the one who will determine the future of testing. This is the prime thing that the QA head has to keep in mind while grooming and mentoring them. The testers have to have a firm belief that the future of testing is going to be brighter than today and that is why the QA Manager and the testers have to deliver their best efforts to all their endeavors. They have to exert their utmost efforts, contributing to the building of a software product (built by developers, being tested by QC team thereby delivering the best of it!) that properly reflects your spirit and drive in testing.
The key aspect is not to compromise with your fundamental values of Testing, such as clear Testing Mission, Policy, Plan, Procedure etc.
Testers have undoubtedly a strong affinity towards testing that makes them close to the product, development team with a joint mission to deliver a bug-free product.
TDD is test driven development in which the developers coding efforts become manifold. It is not only the development coding that developer has to write. Along with the requirements coding, the developer has to write code for the testing of each of the logic he has built in the product. It is more or less a unit testing where each small unit is tested individually by the developer as soon as he completes writing the code for it. All this is not easy to perform. It requires a different mindset to perform TDD. The developer has to be in a different frame of mind to accept first the extra work required from him. There is no extra technical skill set required in the developer, it is the mental preparedness that matters more. They have to overcome the resistance from within to do some extra efforts in coding. Although this could be a little painful but only in the beginning, afterwards, when the results start speaking loudly in lieu of the extra efforts done, it gives a different level of satisfaction to the developers.
The extra effort done by the developer in return saves a lot of time that is required for testing later since in TDD, the bugs reduce tremendously in such a manner that once matured, the later stage testing can be totally avoided.
TDD can be compared to Japanese companies environment as on-line QC in sub-assembly production instead of having QC of the product in the finished stage.
Sync is very important between a developer and a tester. The confidence and ease of the both has to complement each other and ultimately create a bug-free product. The prime goal is same for the whole organization – to deliver the customer what he is expecting – a totally bug free product. Both have to perform well in their respective areas to achieve the common goal.
Small breaks in-between can do wonders during the high work loads. An open platform where each member from development and testing share their current tasks with the status will cover two areas – update each one about others, and keep them synchronized.
Sometimes it is good to be a little casual and the tester can go straight to the developer with a problem and get it resolved even without waiting for a formal meeting for the purpose.
On the lighter side the equation goes like this:
Let us assume that the developer is developing in such a manner that there is no bug in the software, that means developer is actually developer and tester both.
The equation would look like: developer = developer + tester.
Which can be written as developer – developer = tester
Hence tester = 0.
But the serious aspect is that this is a purely hypothetical state. Tester’s existence evolved only because developer was working only as a developer with less quality embedded in the software. That is why tester has to evaluate the developed product on all quality fronts.
In an organization engaged in software development, usually each software goes through testing process by a separate set of team in the organization know as Testers meant exclusively for the purpose of testing. It matters most what this process is being thought as by the development team, project leads and the management (and also the customer). Testers are taken for granted as Bug Filters and testing as bug filtering process. If that is so, the management is at mistake, more so, if testers or QC department also thinks the same. This sort of culture is good for testing purposes, but is not so for the purpose of improvisation in the development process. Testers are safe as they are able to dig out a good amount of bugs every time. Bug removal time is substantial. Even the targets of product hand over to customer are met.
Isn’t the testing team’s result decrease every time even after increased efforts! That means the development team in maturing with each round of testing and development. This can happen only in case testing is not merely thought as the bug filtering process.
Bugs are often invincible during development, especially in large projects when multiple sub-teams of developers are working on development of different sub-modules of the project. The software developed (or during development) will always appear innocent and bug-free to the team of developers. It is the tester’s tough task to puncture the software and find out the hidden bugs. If bugs during testing phase are not found completely, it may lead to disastrous consequences, depending on the severity of unfound bugs. That is why, for developers and testers it is very important to understand the complete flow, sequence, modules, sub-modules, functional sequence to build accurately by developers and verification by testers.
Testers have to exercise the testing process and they have to ensure that they are following the right process to identify as many bugs as possible.
You not only have to understand the customer but sometimes you have to make customer understand what exactly he requires to enhance his business. Many a times, a customer is not able to chalk out clearly what business requirements he wants to get embedded in the software. He is not clear about what exactly he should get embedded in the software to get the optimum out of the software and business mix. He might be having a broad idea about what he wants to see as a final product, but may not be able to define what the core components of this product are. Customer would say the team to study their business as they are doing it, without getting involved in it. This could be serious and the seriousness if not understood rightly in time (emphasize on ‘understood’, rightly’ and ‘in time’), would lead to disastrous results.
Customer is not for experimentation. Clear and crisp ‘Requirement freezing’ is the right start. Customer may be required to be educated on what business, requirements and rules can be built in the software. A simulations or scenario generation is important to make customer understand how the software will work once completed. Customer needs to understand very clearly at the initial phases – What ease or comfort will the software bring out to business processes by giving out certain set of business results. Customer has to understand very clearly the other part of the story too. The software definitely will require certain extra skill sets, enhancements, or extra efforts once it is completed and implemented at customer site.
Past is not to be buried. It contains a treasure called EXPERIENCE. In software development this treasure is of ample importance for acquiring skills required to handle the unwarranted turns and twists during the development (and implementation) period.
What we can learn from the past is the hiccups that caused delays and stoppages in a development project. We can use that learning as a tool to tackle the problems occurred during the project life cycle. The learning could be in the form of:
1. Handling customer
2. Freezing customer requirements
3. Preparation of documents
4. Selection of a project manager
5. Development Team formation
6. Key users committee formation at customer end
7. Management committee formation at customer and development end
8. Team coordination
9. Tester’s involvement in the development
10. Choosing a right methodology for project management
In software development project what matters most is the timely accurate delivery that gives the benefit of defect free product, customer satisfaction, profits, market edge, growth, motivation across the organization etc. All this is not easy to achieve having so many enemies in and outside the organizations that mars the development progress or a sub-standard product. These negative factors or enemies lead to a low in quality product that faces a tough time at customer end resulting in rejection. To name top 5 quality killers in a software product, I would list them as below:
5. Requirements: customer requirements or product requirements is the foundation of software. Any sort of compromise in this would lead definitely to a disastrous product.
4. Management: Intensity of management’s involvement in the product development throughout spells out the success or failure of a product.
3. Documentation: Development plays an important role during a product lifecycle and so does the documentation.
2. Customer Involvement: The involvement of key users at all levels of development and implementation is quite crucial.
1. Testing: ‘When’ to involve the ‘testing’ team defines the earlier successful completion of a project.
Software development is the easiest task and requires no development or quality standards, provided you are ready to manufacture software which:
– Is full of bugs
– Has no buyer
– Is never ready to launch
– Has success-failure ratio as 0:100
– Is ready for unlimited budget inflow
– Is only for the purpose of keeping teams busy
Top 10 reasons to prove that software development is the easiest task on this earth provided you are ready to follow the guidelines mentioned as below:
10. Develop the software with no requirements in mind
9. Follow no standards
8. Keep the customer away during development and testing
7. Don’t select a good team of developers and testers
6. No follow meetings
5. Keep your developers on their toes. Let them not stick to their work. Keep giving them new work in between, or moving them from one sub-module to another before they completion
4. Involve testing team only in the end that too with too little time in hand
3. Keep top management happy by reporting to them about the happy state of development
2. Don’t divide the work proportionately among developers. Let them chose what they want to do
1. No owners of the product
A reference model is a non-arbitrary model of software that is to be referred to when a new software requirement comes from a customer. The reference model will suit and fit most of the requirements given by the customer. The model is the most ideal scenario befitting the technical and functional requirements. Although the new architecture built may not (and will never) match point to point with the reference model but still it has to be as near to it as possible. Infact the reference model has to be capable to address all technical issues that may arise during the software development. During the development if a new problem is encountered, it becomes the part of reference model too. For development also the different components of the repository of the reference model are picked and absorbed wherever found suitable. So the various components are picked and fixed as it is in the software or are reworked with minor changes keeping requirements in mind.
This process not only shortens the development timeframe but also brings in more accuracy and stability in the product. It also helps the project manager to present the near to exact time and cost estimations. The reference model acts as a block of utilities or functions meant for the software being built. The best suitable blocks are selected and placed as it is. The most suitable blocks are selected and placed with a little modification. This increases the reusability as well. Reference model works as an outline sketch of the new product being developed.
The main tools of a project manager are communication, partnership and guiding his/her team towards success. As long as the project is going smooth, there is no problem. But as soon as there is a crisis, it is the project manager who has to rise to the challenge and seek out the vacuum to be evacuated. Every project manager has to have something in him/her that has brought some time or the other his team out of critical situations and sailed the project successfully.
The key skills required in a project manager including those mentioned above can be summarized as below:
3. Guide the team
10. Right Approach
12. Roles management
13. Capitalization of experience
14. Prepare for transformational technologies
15. Change Management
16. New Business Models
17. Deep understanding of methodologies and technologies
18. Drive business
19. Operate in interconnected world and global economy
20. Work together
21. Leverage each other’s knowledge and experience
23. Be well organized and well equipped
24. Work with extreme ideologies in your sleeves
25. Apply innovation to traditional problem solving
26. Keep analyzing and organizing
27. Have a critical eye to assess the situation
28. Find and place most significant people in your team
29. Recognize the difference between management and leadership
30. Be visionary
31. Drive strategy
32. Market yourself and your product with full heart
33. Think Strategically
34. Do effective delegation
35. Reward performance
36. Develop individuals to their full strength
37. Be transparent
38. Build trust and relationship
39. Measure effectiveness
40. Be influential
41. Understand and overcome holes or flaws in technology you use or the product you make (before your customer finds it out for you!)
42. Don’t believe in product, get it tested by you testers extensively
43. Always believe that when developers and testers work together, with the combination of technology and strengths, the resultant product will be always better
44. Anticipate a problem and find out a solution
46. Provide opportunity to your developers for career development which is a key for job satisfaction, retention and succession planning
47. Be a consistent leader
48. Incorporate best practices
49. Be a role model
50. Don’t accept anything on face value. Question, examine and introspect
In an organization engaged in software development business, timesheet is filled by all developers and testers working on any project. Timesheet a sheet of pre-formatted fields in which daily tasks performed by each person are filled in their individual sheet. The intent of timesheet varies from organization to organization. Some organizations use it for raising invoice from the customer whereas others use it to study the developers pace and engagement with the allocated work. The sheet usually comprises of person’s name, date, project name, plan for the day, and the tasks actually performed against the planned activities. It is not a complex format but it returns valuable information. It can also be termed as daily task sheet of each individual.
Filled timesheet is sent by each developer or tester to their respective leaders routinely. Besides sending it to leader, as per organization directive, a copy may be required to send to HR and/or Accounts department. The frequency may vary from daily or weekly to monthly. It may also be used by accounts person to allocate the resource (developer of tester) to the respective cost centre. In positive sense the purpose of timesheet is not to track the person but to prepare a repository to refer to immediately or later for various purposes. The purposes could be the calculation of total man hours spent on a project, the cost incurred on a project, the engagement/pace/% time of an individual in a project, backlog analysis at any stage during the development, re-allocation of task, requirement analysis etc. It becomes a good tool for HR to find out the vacation trend of an individual. HR or project leader can also schedule the trainings and vacations for each individual based on their timesheet that clearly tells their workload level.
The charter of a project manager or development manager at the start of a new project which requires extensive fresh development comprises of many pitfalls or showstoppers. To win over them, the project manager or development manager requires a well defined charter to adhere to.
The key points of this charter can be:
Software project management plan
Team members with their skills and job allocated
Allocation of resources – hardware & software
Schedule of execution
Risk Analysis with how each one is being addressed
Technical layout and approach
A guidebook for each process
Role of any other product being embedded in this product
Role of product in the overall product line being carried by the organization
Lead the team by way of demonstration in all aspects
Define the purpose and limitations of the software development process
Sensibly tailoring or moulding the development lifecycle standards wherever required with proper documentation and justification
A chart for mapping requirement vis-à-vis the development
Embedment of statutory requirements in the software
Development and implementation in most effective and efficient manner
Trainings at all levels and stages
Measurement of progress
Sign off at various stages
Review, review and review at all stages of progress
A large software development project can become scary for the development manager who is handling the project provided (s)he is lacking the experience and ability to manage people, machines, requirements and time in appropriate manner. A balanced control is the call of the time at this juncture, to give the project a right start by understanding the requirements well and selection of right people for the job. The development process needs to be planned and executed well for which a root level monitoring and control is mandatory. Having good knowledge and skills required to lead the development team goes haywired if these skills and knowledge are not executed timely and properly. The project manager or development manager has to understand the core relationship of software development with overall software product engineering, the estimated time and costs, and above all the software process being followed.
On the basis of the project requirements, the project manager has to decide upon the right life cycle model, requirements analysis, environment in which the product is to be built, control of configuration (both server and client level), development team management, and quality assurance. This is not at all easy, and can be achieved only by winning over each situation.
The goal of any software organization is to develop software applications in-house, or co-develop with an external agency, that meet and exceed internationally accepted quality standards. Every one knows it, that the key role in this is of QA department. With this intention, a dedicated QA department is structured in the organization, for the purpose. But most of the time, the move towards the objective mentioned above is limited or missing at all. Although the development managers too agree that in the software development business software quality is the key to their success.
In view of the above, the development managers need to revisit this area which mostly has not received all the necessary attention it deserves and which is something so crucial that the organization can ill afford to overlook.
Mostly, even if QA is in existence in the organization, it is used to test poorly designed and developed software. The reasons for this are well known, and the major one is that the QC is misconstrued to be a mere testing activity rather than looking at QC from a more holistic perspective. To this extent, the QA/QC department needs to be invited and involved at all stages of the software development lifecycle (SDLC).
To fulfill organization’s expectations and business goal in this regard, the development managers need to have a fresh discussion with QC/QA head to prepare a charter on how they plan to achieve it.
A Testing Certification is an individual tester’s asset rather than the organization’s asset as it increases the employment chances of the individual without apprehensively adding any substantial value to the tester’s job requirement. Definitely, the tester’s skills are enhanced (a bit) with this certification, but there is more increase in his expectations from the organization. Why a tester who is doing well at his job would go for a certification thereby compromising with his performance at job as he will be required to pay attention to studies and learning to acquire this certification. The certificate that is attracting him is for his own sake. Ofcourse, when it is an organization’s requirement to train their testers or display on board some certified testers, the initiative and drive for certification to the individual testers will start from the organization itself.
Certification is not bad. It is an exposure to a new learning. But the testers who get attracted to acquire a certificate have a different goal than a new learning or for the sake of organization. But if the intention is merely to acquire a relevant certificate for a tester, it can be examined by the organization by offering him a course relevant to his job with no certificate at the end of it. This step will display the real interest of a tester, whether he is individual oriented at this juncture or organization oriented.
At the time of recruitment of a tester, the biggest question in front of Quality Manager is to decide on certain factors related to the qualifications, certifications and experience of the candidate. The balance of all three is important. But if there is a demand to sacrifice one (or two) amongst three of these requirements, which can that/those be? Let us take them one by one in the perspective of Quality Head.
Qualification do matter, so the candidate must be having the basic IT degree (or if degree in some other stream, then that degree has to be relevant to IT, and the prospective candidate should be holding an advance IT diploma). When we are talking here of qualifications, we are talking about IT qualifications and not specific Quality/Testing related qualifications, which we would be considering in Certifications.
So, qualifications being the basic criteria, now there is a battle between the certifications or experience. Let us assume here we have three sets of resumes of the candidates. All sets have similar qualifications, and are differing on the basis of Certifications and Experience parameters. First Set of resumes is having Certified testers with no experience, so they are fresher certified testers candidates. Second set is certified testers with good experience in testing (say 2 plus years of experience). And the Third set is group of experienced testers with no certifications. Experience with this group of testers may vary from 2 to 5 years. Definitely the first set expectations in terms of salary would be lower as compared to second and third set of people, whose expectations would be almost at par.
In my view, appointing a tester with basic qualifications and some experience will be better than taking a tester with basic qualifications and certifications but less experience. Certifications, if any required, can be acquired by the tester during the job at a later stage.
When a new project lands into the hands of a project manager for development, he converts the whole project into smaller units and allocates it to different developers. Developers are divided into the groups based on the work allocated. These teams prepare their plan to develop and start working accordingly. Once the development plan is with the project manager, and the developers are tuned into development, the project manager should make least interruptions in their schedule (none unscheduled) thereby helping them in meeting their targets. Different ways in which a project manager can interrupt (which he can and should avoid) can be listed below. These are not in any hierarchy and all lines carry equal importance. The interruption points are:
1. Unscheduled review of the progress of development
2. Discussion related to any past project
3. Discussion related to any future project
4. Allocation of any other task other can the ongoing one
5. Shuffling of developers from one team to another
6. Re-allocating a developer to another project
7. Inviting a new member in a team for development load sharing
8. Approving leave to developer (unless it is too urgent or critical)
9. De-motivating even a single team member of different development team (remember – it spreads like a virus among other members)
10. Don’t forget to appreciate them at each small achievement
Hey my dear Tester, what you are doing is a tremendous effort in streamlining the business of your organization. It is you who understands the business requirements of your customer, learning their business rules, understanding the product built by your development team to cater to those needs, testing the product and finding the lacunae in the product, helping developers to understand those lacunae, and finally testing those fixed lacunae.
So you are playing the key role between the two extremes, the customer who is demands, and the developer, who supplies. It is important to mention here that your role is the most vital bond between the two. Infact during testing, you have to act as a dummy for customer, and examine the product as per customer’s perceptive. Now let us look at the strategy following which you can feel PRIDE in your work, and make your organization realize that. First of all testing should be a mission for you and for each of your mission, you have to be passionate. Your passionate mission every time is to find out the holes in the pot called the software product. Work with development team in collation rather than isolation and move together towards the path of reconstruction. Drive side by side rather than driving in the opposite directions. During development and testing, you and the developer have to work in a manner that if one reaches out a hand, the other clasps it. The final goal is not to pinpoint each other mistakes or shortcomings, but is to find them out and fix them to deliver a strong product to your customer and ultimately expanding your organizations business.
The product has to have the firm roots, and minimal changes, for which right understanding and development by the developers is important. You have to teach this lesson to your developers that any wounds even after complete healing will always leave scars.
Be proud of yourself, be proud of your work, and be proud of your organization… always…
Your work should speak that you are feeling PRIDE in your job, and last but not the least… make your organization PROUD of you. Testing is really a challenging job, and it is you who is doing it. Your organization already feels that you are the best resource available for this purpose.
As a human being we limit ourselves in how much we learn. The learning process is initiated based on certain facts like curiosity, need of the hour, intelligence, openness and related requirements. A tester being a human being carries all the limitations of bounding himself of these facts and thus sometimes may not be able to learn completely about a product that he is going to test as a new testing project. As a human being we tend to learn only the things that we are bound or forced to learn. That bounding or force may be internal (passion, habit, urge, eagerness) or external (work requirement, business demand, customer pressure, management requirement).
A tester for that sake should, at this juncture, think of him as an inhuman, away from all these sensitivities. Then he will not be limiting himself to any boundaries as mentioned above and will be able to learn or know maximum about the software, product or project he is going to start.
After all the accuracy and coverage of testing he carries on the software or product will depend on how much he has learnt or how much knowledge he has gained about this software or product beforehand.
The same thing applies to a developer also before starting development of new software or enhancing existing software in context to understanding the customer requirements and business needs.
A project head has to interact most of the time with inter and intra team members, management, customer key users, customer management and so on. Intra team members include his project leaders, project members, functional consultants, and technical leads. On intra teams front he has to continuously interact with quality head and testers. During development and implementation he has to interact with customer key users who are always interested in project development status and implementation plan. With each of these mentioned, he not only has to interact but at times (or often) he has to interject too. So a project manager has to have expertise not only in interaction but also in interjection.
Let us illustrate some situations in both the scenarios, i.e. interaction and interjection of a project manager with the various agencies (individuals or teams) in and out of organization, being part of the project. An interaction situation could be termed as a normal situation part of routine exercise. An interjection could be a situation where an abnormality has arisen out of normal routine activity and project manager’s intervention in that situation to bring the progress to the normal path.
Examples of interaction and interjection situation can be:
Interaction situations: Review of development, review of testing report, project update to own management, project update to customer management etc.
Interjection situations: Approaching customer management in case of key users interest is getting lost in the project, review of code with developer and educating him the alternative coding path being better, Alarming quality head in case testing is getting delayed or testers not performing relevant important tests.
Usually at the start of a new project, a project manager has to forget the sad points of the previous projects and also to get to ground from the unusual achievements too. At this juncture a project manager is supposed to start afresh with new zeal, a new team or new members in the team, a new working, a new strategy and a new requirement. At the start of any new project and during the project, if the project manager keep track of following 15 checkpoints, he is safeguarding his project towards timely and successful completion of his project. The 15 checkpoints can be listed as below (not in hierarchical manner though):
1. What development or implementation approach are you using?
2. Are you ready for the change?
3. Are you focused on continuous improvement?
4. What metrics do you use to decide the success or failure?
5. Are you using your previous project’s measurements against current project performance?
6. Are you able to prove that your current development or implementation approach is optimized?
7. Is this proof based on objective measures or just an individual perception?
8. Are you aware of any soars in the project?
9. Are you prepared to not let those soars convert into festers?
10. Are you aware when to start measuring project performance?
11. Are you using the right metrics?
12. Do you analyze and document startup problems?
13. Do you document the learning at each step?
14. Are you improvising your practices?
15. Are you measuring effectiveness of each point listed above?
A Project Manager is the key center position for running a successful software project. To run this show successfully, a project manager has to be a possessor of following 10 basic skills as listed below:
- A good HR manager, to manage his team, needs to have strong interpersonal skills so that he is able to maintain a cohesive team who works in collaboration. He has to be a strong bonding agent in his team and the other teams working on the project.
- He should work as a focused manager looking at positive aspects of his team members, without letting any unwanted behavior of his team members affecting the project. He should have a good relationship with his and other team members even if he doesn’t like in person few of them.
- He should be always be in a comfort zone and make others feel in a comfort zone. For this he may have to show a tremendous confidence in himself and others.
- Project Manager should have excellent presentation skills as he is the person who is the window between the customer and his organization. To update, convince and win the customer about the progress of software development, the progress of implementation and the completion of project i.e. sign off from customer at various stages, the project manager has to sell himself by having marvelous presentation skills.
- Project Manager has to inculcate the leadership skills in all his team members so as to make them independent in handling adverse situations and coming out of it successfully. Also in this way he will have to burn less energies in tackling each situation.
- Project Manager has to have strong technical skills so that his team members do not lose confidence in him or do not fool him in technical aspects of the project. Although he doesn’t have to do much of the technical work with his own hands but still having those skills to understand how his team members are doing and whether they are in the right direction, is very important during development and implementation.
- Project Manager should be a firm believer in the Japanese term KAIZEN. He should ensure in making everyone believe that improvement has no end and is a continuous process.
- Project Manager, along with having good presentation skills, should have equally strong communication skills too. During project lifecycle, 50% of his time is the acid test of his communication abilities.
- Project Manager should be a strong estimator, a proactive in this regard. He should be able to estimate the progress of each individual, the skills of each member, the abilities, the show stoppers during the project, the customer delays or any other activity where an estimation is required.
- And last but not the least, a Project Manager should be good parent, in regard to understanding himself, his team members, management, customer, other teams, peers – i.e. all involved in the project. He should have a good understanding of his words he is going to speak to his customer, the instructions he is going to give to his team members, the decisions he is going to take. He should be well aware of impact and effect of each of the activity he does during a project lifecycle.
A project manager is the person who drives a project, here I am particular to a software project. A lot has been written elsewhere on successful project managers, successful projects, the success behind the projects etc. Rather I would discuss here some extraordinary or un-orthodox qualities in a project manager that makes a project successful. And that is why I term them as Maverick Project Managers. This class of project managers is rare, and is under the threat of extinction. There might be project mangers with few of these qualities but since they don’t contain all, so can’t be termed as the complete Maverick Project Managers.
The qualities of a Maverick Project Manager are:
1. Always think himself as successful – a firm believer in thinking himself as Successful.
2. His firm belief in himself usually drives him to success.
3. He will not mind in achieving success by some unusual means (acceptable as long as it is not at the expense of the organization and its customers).
4. He runs the show more on his own logics rather than external observations and discussions.
5. Actions performed on his firm belief system mostly produces the ‘good’ results.
6. His actions and views may be unacceptable to others in the team (internal and external members) but they find nothing to challenge him as the desired results pour in.
7. He is having some qualities at its extreme – such as – self confidence, charisma, persuasiveness, and intelligence.
8. He will inspire people around him in an entirely different manner.
9. He will be followed, supported and worshiped by many around, who believe that he can never go wrong.
10. Even if he fails, he is not blamed for it.
‘Create’ means the first time effort to generate a harmony between a tester and a developer working on the same project. ‘Build’ is the next stage after create to harmonize the professional relationship between a tester and developer. This step will bring the strength in the relationship. ‘Maintain’ is not only the sustenance of this healthy relationship which can be termed as ‘sweet’ harmony, but also calls for an effort from both ends to ‘keep on improving’ this bonding. To create, build and maintain an everlasting harmony between the testers and developers, here are some tips:
1. Share: Sharing is a two way process. Both the sides need to share equally, transparently and openly. The development team needs to share the customer requirements, business rules, relevant documents, design plan, coding, system built. On the other hand the tester needs to share his observations on all these, and the results of his testing. Share problems, thoughts and success together.
2. Raise an Alarm: Tester and developer require raising an alarm in case of any shortfall in above sharing required from both ends. Developer also needs to raise an alarm in case of inadequate testing or if testing is getting delayed due to any reason.
3. Act Jointly: Tester should sit with the developers while they are on job i.e. designing system, and similarly developer whose product is being tested preferably should sit with the tester while he is testing the product. This support will not only strengthen the process and product but will make it more secured.
4. Avoid Protectionism: On the work front, be it of a developer or a tester, it is important to prevent the spread of protectionism and to promote transparency or openness across the organization. If this is not handled properly, it may lead to depression and incoherence across.
5. Accept Framework: Accept each other’s work framework and respect it by heart.
6. Resolve crisis: In case of any crisis on any front leading to adverse effect on the project, take all necessary measures jointly, timely in a coordinated manner. Be more than willing to act in this regard.
7. Tester is a bridge: Tester is a bridge between developer and customer for the purpose of smooth and defect free delivery of product to the customer.
8. Be a great contributor: To achieve great success, be a great contributor in your respective fronts.
9. Encourage: Encourage each other.
10. Remember: Always remember that you have joined hands to achieve a common goal. A good harmony always brings in the ‘success’
A new software release for testing could be a new product or major changes in the existing software. In either case the bugs report should have a new version number for control purposes. Although in case of a new release of existing software, the existing bugs can be referred to but that does not mean to check only for those bugs.
Anyhow before the tester starts testing of this new release (or for that sake of any new release!), (s)he has to make sure of three certain activities:
1. Clinical review of the testing requirements
2. Known bugs (in case it is a chain release) fixed
3. Scope – customer requirements, software requirement and business rules
And above all now tester’s task is to ensure that the software (re)built is completely aligned to the above three.
In today’s scenario when the schedules are tight, budgets are low and different technologies being used, software developers and testers are having great challenges of building/testing/releasing bug-free software by meeting all criterions. The question arises here is – how to cover all the development/testing requirements that to in such a short span of time with high rate of accuracy in development and testing. In such a scenario, the best option would be to use Open Source Test (OST) tools. And why not, when Open Source Test (OST) tools provide most economical solution and on top of it they are more flexible as compared to labeled vendor test tools (or traditional testing tools). So many big corporate organizations these days are using Open Source Test (OST) tools such as Ford, AMD and many more.
Many of the open-source testing tools support most of the technologies being used in development these days. Be it AJAX development or rich internet application (RIA) i.e. Web 2.0 on service oriented architecture (SOA), or any other web/server based application.
Some of the Open Source Test (OST) tools are – PushToTest, HTMLUnit, TestGen4Web, Selenium etc. that take care of functional testing, performance testing, load testing and volume testing. If you see all these testing are not possible to conduct manually and using a traditional testing tool would be never be a cost effective solution.
Once the software has been accepted by customer (user acceptance or software acceptance), on customers approval the software goes to customer site for implementation. A key user’s team from customer end is dedicated to this phase for the complete tenure. From vendor side also a team of technical and functional leads goes to customer site for implementation. The two teams jointly working as a single team start the implementation process by installing server, client software (by vendor technical team), training to respective module key users, test server setup, test run, and then live run.
By now the users should be quite comfortable with the software and also should be familiar with the functionality of the software. This is the period of deployment phase when user team is getting matured in running the software independently.
The vendor team should, even if it is there at customer site, behave virtually as if they are not there and should act only in case of a crisis. This virtual absence or inactive phase of vendor team will increase user’s confidence tremendously.
After implementation, for a period, stipulated and agreed upon mutually, there is a maintenance phase, during which a full remote support is provided by vendor team to the end users sitting at customer end. At times, if not possible remotely, some technical or functional person has to go to customer site during maintenance period.
Software Acceptance or User Acceptance is an exercise that happens once the software has been cleared by QC. So far software has been tested internally only (by developers and testers). But customer also would like to test it and accept it prior to finally start using it. The phase is also important in case if any user requirement has been skipped, misunderstood or wrongly built in the software. Clearance by development team and testing team does not ensure that the product is meeting all requirements specified by the customer correctly and appropriately.
User would like to go through each functionality, process and rule with real data to ensure that the software is behaving as per the needs specified. Users during acceptance testing is supposed to run through each screen built and by trying data of both types – right and wrong to ensure proper handling of exceptions in the software.
Once the key users find software functioning fine, customer (management) accepts the software and then it is finally deployed or implemented.
User acceptance can take place at either of the locations – customer or vendor.
Software Testing is the process to ensure a bug-free, fully functional software meeting all customer requirements. Testing starts right from the development stage. The developer himself is responsible for unit testing, smoke testing and code testing while he is building the code. Once different units, built by different developers, take the shape of a functional product, a need arises to test the product as a whole, each of its unit, each module and sub-module. This part is handled by a separate team known as QC, QA pr Testing Team.
Software Testing is very important to ensure:
2. All business processes have been built appropriately
3. All business rules are working fine
4. Functionally the product is ok
5. Each unit, sub-module, module and finally the product as a whole is meeting all software requirements
6. Exceptions are handled appropriately
7. User manual and software match
8. Software requirements, User manual and software match
Based on software requirements, business process, business rules, software design and customer specifications, the software coding begins. Project manager distributes the coding among the development team members with clear time frame instructions. Coding will begin in two manners – phased or sequential and parallel.
Phased or sequential coding is one in which the next coding part is not possible unless the first part is complete.
Parallel coding is coding that can be started simultaneously for different independent units between which the dependency is not too high.
Software Coding is the process of conversion of software design (concept) into reality.
Software design is the stage that comes next after freezing software requirements. The requirement specifications are given to the team of developers headed usually by a project manager. The project manager or the technical lead decides on the software architecture, OS, front end, back end, database etc. System design or ERD (entity relationship diagram) is prepared once the initial database design is clear with the table structures to be built in the database.
Software design is nothing but the conceptual design of the database, tables and table structures, relationship of various fields of tables with one another. Once conceptualized, it is discussed among the team, make any changes if required and then freeze it. Once the concept is finalized, the database is designed by creating tables and building relationships. The next phase that comes after is the coding.
Security concepts will vary from software to software except few generic requirements that will remain standard for most of the softwares. The major varying requirements will be dependant on following factors:
b. System specific: The other major factor deciding on security concepts to be built in the software will be system design”. What architecture is chosen, what technology, what database, what front end etc.
2. Risk Factor – The gravity of risk involved and what level of security is required will decide on the security features to be built in the software
3. End User – What level or type of user is going to use the software
4. Money Matters – If there are any money related transactions in the software will require a different set of security concepts.
5. Statutory requirements – The outward or inward connection with other legal/non-legal agencies will formulate the specific security specifications. Also will depend on any statutory requirements to be met by the software.
Software requirements are the requirements that are given to the developer based on which they build new software. Software requirements could be functional or technical in nature. Broadly software requirements can be divided in two parts as – business process and business rules. Software requirements lifecycle can be defined in following steps:
1. Initial discussions – in this phase the top officials of the two parties (customer and vendor) discuss broadly the business requirements that are required to be built in the software.
2. Detailed discussions – this phase comprises of a team from vendor side that goes to meet the respective process owners of customer to understand the details of each process and the rules to build in.
3. Documentation – the requirements (process and rules) in the above process need to be documented in a clear manner because this is going to be the basis of software.
4. Forms and Reports – any forms and reports that are in business practice and have to be built in the software will have to be collected.
5. Sign Off – Never forget to get the complete document signed off by customer key users and top management
Here are some quick guidelines for a tester. As and when a new product (software) come to a tester for testing, (s)he should keep following things in mind to ensure the full justification to the purpose of testing. The purpose is to ensure a complete and correct testing of the product.
The guidelines are as below:
1. Assume yourself in customer’s shoe: Treat yourself as customer to run/use the product as they are going to use.
2. Walk with open eyes: When you walkthrough the product, keep your eyes open to observe the minutest variation/deviation in the behavior of each unit of the product.
3. Educate yourself before start walking: Before you start testing, ensure that you have thoroughly gone through the customer/business requirements documents.
4. Don’t compromise with the Docs: Ensure that the documents are complete in all aspects, as any ambiguity in documented business process/rule will have marred the purpose of testing and would lead to wrong results.
5. Don’t cross the red signal: If documents are incomplete or ambiguous, never start the testing.
6. Ensure all passengers are on board: The documents you are studying must be vetted by the customer and project manager before it reaches you.
7. Don’t sleep during flight: Keep your Pen and Paper or excel file ready as soon as you start testing. Keep noting each and every test case results.
8. Don’t take snacks at Food time: Place appropriate screen shots wherever required for your each test case results.
9. Ensure you have a right pilot in place: The project manager/ project team should be available to you while you are testing so as to ensure you all are travelling through the same path.
10. Appreciate the Air Hostess: Appreciate at places where a good job has been done by the developers by putting your remarks.
11. Mistakes are unintentional: Don’t blame the developers for the mistakes (bugs) in the product, purpose is not to punish or fire a developer.
1.Focus on Quality Policy, Strategy, Test Plan, Test Cases.
2.Maintain heartfelt sympathies with developers who are developing Bugs (and their impact!).
3.Raise your anxiety higher for any software coming to you for testing.
4.Your first and foremost priority is to prevent the damage a bug spreads across the product.
5.Investigate the damage (impact of bug, through test cases).
6.Ensure safety of software by ensuring that you are able to catch all bugs.
7.Keep visiting developer’s den during testing to highlight the severe bugs found so far.
8.Work like craftsmen with high precision to attain micron-order accuracy in testing.
9.Be absorbed in your work and not even notice anything else happening around.
10.Be proud of your testing skills.
11.Have uncompromising approach towards ensuring bug free software.
12.Don’t worry about the rising count of bugs in the software (that ensures your job more secured).
13.Use your experience and documents business requirement, business processes and rules in stabilizing software.
14.Mount a fundamental response from developers.
15.Take a leading role.
16.Issue a crisp and clear report of bugs encountered with elaborative screenshots.
17.Ensure through coordination that developers nullify or atleast minimize the impact of bugs reported in your bugs list.
18.Carry out tasks at hand including measures to cope with developers for removing bugs.
19.Respond steadily and quickly to any changes in the documents, business requirements, process, rule or software design.
20.Deadlines remain poised on knife-edge, focus on materializing each task. Remember the old famous saying – “You can’t eat an elephant in one go”.
A bug right from its insertion into the software till its removal crosses through different stages. These different stages of a bug formulate bug lifecycle. Each stage has an action and meaning connected to it. Various stages of a bug are:
Unconceived: A bug that has to come into a future software, not even knowing who is going to write it, and in which software.
Unborn: A bug not yet taken its shape, still lying in the mind of a developer.
Unconcealed: A bug residing in software but unrecognized by a tester.
Open: Any misbehavior in the software identified and recognized by tester is recorded with “Open” status.
False: Not actually a bug but marked as bug.
Disguised: A bug existing but identified with a different behavior.
Accepted: The bug accepted (as bug by project manager and its development team for a fix.
One time: A bug encountered by testers, but not encountered/simulated again. Such bugs are required to be fixed unless encountered again.
Not Accepted: Project Manager or development team may refuse to accept a bug in case it is not critical and seeking too much time to fix it, it is meeting customer requirements, tester has not understood the business requirement well and identified a wrong bug, or in case the same bug has already been reported.
Not to be fixed: The reasons would be same as mentioned in “Not Accepted”.
Pending: A bug accepted by the developer but may not be fixed immediately. It could be due to non severity, other priority or any other reason.
On Hold: Some bugs need to be discussed with customer, or management. Or the reasons may be as mentioned above in “Pending”.
Fixed: As soon as a bug is fixed by the developer, it is assigned as status as “Fixed”. A programmer must always doubly ensure before marking a bug as fixed.
Closed: The bugs marked as fixed once verified by tester and are found fixed are marked with the status “Closed”. Tester must doubly ensure before marking any bug as closed. Tester must also ensure that the bug fixed has not generated any other bugs.
Re-Open: A fixed bug found not fixed by the tester is to be marked as “Re-open”, which goes back to the developer for fixing.
There are three ways of functioning for any software organizations. First ways is to develop software and deliver it into the market. The survival for these sorts of organizations is too difficult and short. Second category of organization has a well placed “Quality” department in place. The quality department is responsible for ensuring a bug free product going out to the customer. The third category of organizations have a well identified and well structured team in place to ensure that every next production of software is going to have far less bugs as compared to the earlier produce. Most software organizations fall in category number two. Very few fall in category one, as organizations falling in this category will either not be able to survive for long, or will live on a very little customer base and profit. This is the third category that we are talking about – that falls in the bracket of “Bug Control Management”.
This organization lying in the third category will be continuously working towards improvising the processes of product development, ensuring lesser and lesser bugs in each of the next release of the product or new product. The progress of this team will purely be objective subscripting the improvement in every next product release. It does not mean that quality department will have no role now. Rather quality department will have a new meaning and more valuable role to perform.
But point to ponder here is – is it just a void promise, a flawed process or process insanity. Or is it just the darker aspect, brighter aspect is being felt by the organizations who have or are in the process of adopting BCM.