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.
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.
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:
2. Bug identification
3. Bug behavior study
4. Impact study
5. Bug classification
6. Bug admittance
7. Bug removal assignment
8. Bug removal
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.
This is in continuation of my previous blog where I listed the 10 most important must-dos for customer to have clear software requirements in first go. Ten most important must-dos for vendor to have clear software requirements according to me would be:
2. Ensure that management selects the right person(s) for the purpose.
3. Ensure that management at back office is continuously involved in the whole process as per plan.
4. Ensure that customer management is clear in their goals to be achieved by this software.
5. Ensure that customer has identified the right people who are actually the process owners and not the subordinates of the process owners.
6. Do not hesitate in analyzing the each sub process station.
7. Ensure that analyst gets process owner’s ample time to document each and every process requirement well.
8. Don’t trust on your mind. Document along with the understanding of the process or soon after it. Keep getting it vetted by the process owners.
9. Keep updating customer management after the finish of each process.
10. Don’t compromise with time and documentation.
Note: Please do not hesitate in giving your valuable add-ons. I might have missed out certain important points (if! Any!!).
Having clear software requirements is very important as it is going to be the foundation of the software to-be-built. Having clear software requirements in first go is equally important especially in case of overseas client. Few things are very well known to all:
2. Documents collected and prepared are the vital asset of software requirements.
3. Selection of right person for the customer/software requirements study is very crucial (and sometimes it hurts at a very late stage)
4. Travel and time is a cost that is affecting the overall Project Cost, Margins and Profits – irrespective of whether customer or vendor is bearing it in the beginning.
Keeping all this in mind, the 10 must-do to have clear software requirements in first go, which I am listing below. There could be many more (which I would like to be added in the comments section), but these come to my mind as most important:
2. Ensure that management is continuously involved in whole process.
3. Ensure that the vendor representative(s) coming for the purpose is the right person(s). They should not only be the master of their domain but should have fairly good number of years of business exposure too.
4. Ensure that the process owners are the right persons to explain the process.
5. Ensure that the process owners have their process charts ready with them, the document is going to help really.
6. Ensure that the processes are sequenced in proper fashion.
7. Ensure that the time should not be the constraint for process owners. Devoting 6-8 hours for 2 days is always better than devoting 2 hours per day for 10 days. After all more time spent by the vendor representative is equal to more cost to the customer (overall project cost).
8. Ensure that the analysts (vendor representatives) keep updating their documents during the understanding of process or at the finish of a process. Let not a lot remain in the mind and be documented later.
9. Ensure that both the managements (vendor and customer) finally sign the document finally prepared (both have equal ownership on whatever has been documented).
10. Do not get bogged down by the size or volume of the document. Let it is as elaborative and explanatory as possible. Just be sure that it is crisp and to-the-point. Attach hand written papers, reports, formats, legacy manual with specific markings of important features required to be built in the new software.
Note: Please do not hesitate in giving your valuable add-ons. I might have missed out certain important points (if!). A similar set of guidelines for the vendor end, I would be posting in my next blog.
Broadly there are two main loopholes in case of unclear software requirements – vendor and customer. Unclear Software Requirements could lead to disaster not only for the vendor but for customer also as I stated in my previous blog. To vendor it may cost money, time, reputation, business and at worst the closure of business. To customer it costs time, money, employees trust in its management, management confidence in selecting a vendor and at worst a decision to not to streamline their business in terms of a new software.
The main reasons of unclear software requirements could be:-
The vendor representative’s tenure is too short at customer site to study its business and requirements
The vendor representative is not curious enough to dig down each process at customer site
The vendor representative being poor at documentation
The vendor representative thinks collection of relevant forms and reports is a waste
The vendor representative keeps more in his mind than documenting (the business rules, processes and requirements)
Business clarity is delivered by the person other than actual process owner
Process owners too occupied
Process owners depute their subordinates and perceive they will explain the correct picture
Management before signing the final documents do not vet each process and business rule
Poor management’s involvement
Wrong perception that vendor will build a strong software that will meet all their requirements on its own
Unclear Software Requirements could lead to a disaster. It may lead to a dead end or deadlock from where there is no way back, with zero possibility to move ahead. The situation may cause the company a huge cost in terms of understanding the requirements again, rebuilding the software, re-testing, re-configuring and re-implementation. The cost involved sometimes is small enough that the company is able to absorb it or adjust it, else sometimes it is so huge that it effects not only the current project(s), but has a recursive disastrous effect. Sometimes companies are never come out of this crisis and gradually have to bear huge losses.
Usually it is lose-lose situation for both the vendor and the customer in this scenario. The loss at both the ends could be in terms of money spent on customer visits (travel and stay cost, borne by vendor or customer, but it is spent and has gone waste), time consumed by vendor in development of the product based on these unclear or incomplete requirements, the reputation of vendor (which is somehow irreversible if the name goes bad, and has recursive effects), confidence of staff at both the ends (customer and vendor), management’s trust (in each other).
The reasons for this situation could be many but the ultimate result is always the same – DISASTER.
In normal scenario when an order is finalized between a vendor and a customer, for building new software by the vendor, the payment terms are set in such a manner that some percentage of the project cost is paid soon after the completion of customer requirements study, generally on finalization and submission of customer requirements document (CRD) by the vendor to the customer. The completion of this phase shows that the vendor has clearly understood the customer and business requirements and is capable enough to build all those requirements in the software product that he is going to build for the customer.
Customer’s ultimate goal is to acquire or purchase the final product that fully meets its functional and business requirements. Then why customer should pay out of his pocket for something at a stage that is of no use to the customer. The requirement study is the need of vendor and not the customer. Customer finally needs a product.
What if the product built is incapable of meeting customer’s requirements. Then why not customer pays to vendor just once at the time of product delivery, User Acceptance and implementation completion?
Do we buy a complete car or pay in parts – for steering, for body, for brakes, for seats, for belts… and so on…
Just a thought…
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:
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.
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 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.
Any defect, shortcoming or error in software (built to perform a specific function or set of functions) is known as a Bug. A bug is usually an unexpected event encountered by a tester (or sometimes a programmer himself) while testing a unit, module or a complete product. This unexpected event could be due to a coding error, a code defect, code fault, flaw in coding, imperfect coding, erroneous coding, or improper coding.
The purpose of a code is to perform a pre-defined or pre-conceived function or set of functions. Once the desired function is not performed or is performed with some errors, the code is known to contain bug(s) which need to be fixed. The ultimate goal of a code is to perform as it is intended to perform under all circumstances.
The software built is meant to perform perfectly under all scenarios/ customer requirements/ business rules built in the software to satisfy all functional and business requirements of the customer.
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:
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.
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.
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.
Based on the above facts, the bugs or defects report’s content has to be very effective in conveying the intent of the testers performing the testing.
The components of an effective bugs report would be:
Reference Number: Give a unique number for referring to it any time in the future. Treat it like a ticket number generated against a complaint.
Reference Documents: Mention all the documents being referred to, for building your test cases, scenarios and test plan.
Scope of Testing
Initiated by: Write the name of the person who has initiated the test process
Initiated on (date)
Test Setup prepared by: Name of the person
Test setup prepared on (date)
Handed over by: Name of the person who handed over the product and documents to test team
Handed over on (date)
Schedule of testing (from what date to what date)
Test team composition: Persons involved in testing and their roles
Test cases/ Scenarios
Testing started on
Testing completed on
Summary of bugs: Total bugs, bugs count category wise (like show stopper, severe, critical, desirable etc.)
List of bugs with their reference to test cases/ scenarios (against one test case there could be no. of bugs): the list would have the columns – S.No., Module, Sub Module, Description, Screenshot reference no., test case reference no., Category, Status (to be filled later by development team once they start acting on bugs), Remarks.
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.
What is a test environment? – I have already explained in my earlier blog (http://itknowledgeexchange.techtarget.com/quality-assurance/what-is-a-testing-environment-for-software-testing/). Also I stated in my previous blog – “why build a separate test environment” (http://itknowledgeexchange.techtarget.com/quality-assurance/why-build-a-test-environment-for-software-testing/) from which two major parties being benefitted are customer and quality testing team of the vendor. Here let us try to understand five essentials to be adhered to while building a test environment for software testing. Let us also understand that these are not the only essentials, there could be many more, I am taking the five top priority factors of them.
1. Customer’s Environments: Understand clearly the environment in which the customer is going to run this software. This has to be checked not only for server but also for the user’s machines. The environments factors could be the hardware, OS, Database, Front end tools, browsers etc. Take care of all the versions of OS, browser the customer machines that are going to run this application.
2. Test Server: Build your test environment as much as possible a replica of customer environment. This is to be applicable to Server and client machines as well.
3. Separate Test Server: Build the test environment on a separate server free from development and dedicated exclusively for testing purposes.
4. Understand business requirements well: The testers and test lead should be very much clear about the customer requirements based on which the test cases are to be built. More understanding, more coverage. Much clearer understanding, wider coverage.
5. Documentation: Aesthetically document each and every test that the testers perform for a unit, module or integration testing of the product.
In continuation to my previous blog – “what is a test environment?”, let us understand here why a test environment is required for testing a software product? I see two major purposes for this, one purpose catering to customer end, and the second purpose catering to the vendor end quality testing team.
The vendor or supplier who is preparing or supplying a software product to its customer must be very clear that in what environment his customer is planning to run this product. The environment could be the hard side – i.e. the hardware configuration comprising of hardware server and users PC components viz – hard disk size, its speed, RAM – size and speed, Processor, bus speed etc. in the soft side it will comprise of the Server/ Users PCs Operating System and its version, OS Patches requirements, Browser – which all browsers are supported and which versions, IIS server specifications at server end, Database Server – What database and which version or release. Any other software components required at server or users computers. The purpose is to run this software as if it is being used by the client at his site. In a way it is the simulation of client site.
The second purpose to have the test environment separate to development environment is to restrict developer’s intervention in test environment during the test phase. This is to be done so that the test results are clear, real and non-ambiguous.
Any other reason coming to the mind while reading this blog that comes to my readers – is most welcome in the comments section.
A testing environment is a setup of software and hardware on which the testing team is going to perform the testing of the newly built software product. This setup consists of the physical setup which includes hardware, and logical setup that includes Server Operating system, client operating system, database server, front end running environment, browser (if web application), IIS (version on server side) or any other software components required to run this software product. This testing setup is to be built on both the ends – i.e. the server and client.
I remember a case where an application was built strictly as per customer requirements by a software vendor without understanding or taking it seriously that what database version the client is intends to use for this software. The vendor developed the application on Microsoft SQL Server x version and the client purchased the new server with the next version of MS SQL. When the product was completed at vendor side, he did a fantastic testing and made the software functionally very strong meeting customer’s all business needs. And when the product was launched at the customer location on the next version of OS and database, the product misbehaved (or did not perform) in few of the instances for which the technical team had to be sent to the customer site to fix the gaps and make it run hassle free. Now this not only affected the product cost but delayed the project deadlines in a major way. This small ignorance at both client and vendor end made a recursive effect at the vendors profits and next few projects.
The production or development team when completes a product development at their end, have to produce this test environment for testing team prior to loading their newly developed product on that environment for testing.
A Project Manager is mostly sceptical to the testers that they unnecessarily try to increase the bugs list just to keep quality department on top. He also feels that it is intentional and many bugs can be avoided to be mentioned which are not very important. Many Project managers in general also feel that quality department is not necessary to exist in an organization. The quality can be maintained by hiring good developers, is what they feel. Then why a separate battalion of testers is required in most of the software organizations across the globe.
Many factors, I would say are responsible for this. Customer getting more cautious towards quality and delivery of product, timelines, competition, increase in internal and external expectations, benchmarks, awareness, prospects, continuous improvement, survival of the fittest, revenue growth and timely returns are few of the top most of them.
There is another side to this coin – A project manager’s skepticism initially may be due to a fear that his team’s development weaknesses will come into light. One more weak area could be the incomplete or inaccurate documentation or study of customer requirements. But with positive signals from Testing Team, Project manager has to gradually understand and admit that all the efforts being done by testing team is not to highlight the weaknesses of his team or product, but to strengthen his team and product.