Work breakdown structure (WBS) is yet another very important aspect and deliverable of the project planning process. In this stage, you break the project into small and atomic individual activities that can be managed efficiently. In a work breakdown structure, you need to identify the smallest units of the work items that can be started and completed as a unit. A work breakdown structure provides a bird’s eye view of the project and helps identifying various dependencies in the project. Work breakdown structure is the key deliverable of the project planning and forms an input for various planning activities.
For the project management team, a work breakdown structure is a key deliverable. It is a decomposition of a project into smaller components. Each component by itself has a well defined deliverable and might be an input for another component. Creating a work breakdown structure enables the team to organize the entire work of the project into manageable sections and avoid any ambiguity.
According to the Project Management Body of Knowledge (PMBOK) guide, the work breakdown structure is defined as “A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.” A component of element of a work breakdown structure can be data, product, service, or it can be a combination of these elements. A well defined work breakdown structure not only provides you with a framework that you can use to create a detailed cost estimation and control, but also enables you to create a detailed schedule and help controlling it.
When you create a work breakdown structure, it is essentially a hierarchical decomposition of complex project into simple phases, deliverables, and work packages. It is usually an inverted tree structure; with each branch of this tree you indicate a subdivision of efforts required to accomplish an objective. To create a work breakdown structure, you start with the final objective of the project and then subdivide it into manageable components. You can define these components based on the size, duration, and responsibility. Each component includes all steps that the team needs to perform for achieving the objective.
One of the most important objectives of creating the work breakdown structure is to provide a framework for dividing work into definable units of work. You can use this structure for overall planning and control of the project and even to define the statement of work. Further, you can use the work breakdown structure to establish schedule, cost, and labor hour reporting.
A work breakdown structure also enables you to sum subordinate costs of the tasks and materials of the components into the tasks and materials of the parent component. You must provide a description of the tasks to be performed for each element of the work breakdown structure. You can also use the work breakdown structure to define the complete scope of the project.
One thing you must keep in mind is to focus the work breakdown structure around product of the project and not around the tasks needed to perform to produce the product.
Before you start a project, you must define its scope. This is very important stage of the project management because the scope of the project defines the entire course of the project and its life cycle. It is a general practice that stakeholders tend to change their requirements or even attempt to push new requirements to the project. This not only adds to the work but can also impact the morale of the project team if the changes or additions of the requests tend to change the complete course of the project. Therefore, it is not only important but a must to finalize the scope of the project before you start it.
When you define a scope of the project, the main concern for you is to decide on what is inclusive and what is exclusive for the project. Additionally, you must decide on the deliverables of the project.
To define the scope of the project, you take inputs from the project charter, requirements document, and any information available about the risks, constraints, and assumptions associated to the project. It is important to understand that the project scope forms the axis of a project and defining it is an important stage of project planning. Any ambiguity and lack of clarity in the project scope is capable in making the complete project a failure. However, a well defined project scope accepted by the stakeholders can guarantee a success.
One thing you must keep in mind is that any stage of the planning process is iterative. So is true with defining the project scope. You use the project management processes to determine the schedule and budget of the project, which are the integral part of the project scope. It is not always that the management and stakeholders agree to the budget and schedules at just first or initial few iterations. If the project schedule and budget does not meet the management and stakeholders’ expectations, then you might need to balance the project requirements, which in turn is the project scope, with respect to the schedule, budget, and other constraints in the project. This process might need you to fast track some of the activities or schedule compression. After balancing the requirements, you need to present the redefined project scope to the management and stakeholders. You might need to iterate this process several times to come up with the project scope that meets cost, schedule, and scope objectives of the project before the management and stakeholders agree to the project scope and signs it off. The final result of these iterations is a realistic schedule and budget that can accomplish the scope of the project.
However, it is important for you to understand that not every change or additional request is rejected during the life cycle of the project. Changing market conditions and competition products might make it compulsory to make changes to the ongoing project scope. You keep iterating the process of defining the scope of the project throughout the life cycle of the project depending on the requests received from the stakeholders. In this process you keep deciding what is inclusive and what is exclusive for the project.
According to the PBBOK guide of the Project Management Institute, the outcome of this process (the Define Scope process) is the Project Scope Statement document. This document clearly states what an approved project is and what is the scope of the product – the final outcome of the project. The Project Scope Statement document is not an outcome of a day or two but you might take several days to complete this document. To finalize this document you might need to seek expert judgment of several stakeholders within the organization as well as experts from outside the organization. When creating this document, you must identify the areas that some stakeholders want in the scope, but were not approved for adding to the scope of the project. Additionally, in this document you must clarify the ambiguous areas that are capable of adding any misunderstanding to the scope of the project. Therefore, in the Project Scope Statement document, you should not only specify what is included in the project, but also what is not included in the project and such additional are not allowed to be added to the project.
A typical Project Scope Statement document consists of the following sections:
After you have collected the requirements by using either manual methods or using software utilities, you move a step forward towards defining the scope of the project. As the next step, you collate the requirements you have collected from the stakeholder. It is not that all the requirements from every stakeholder makes into the final list of requirements. You have to meticulously study each and every requirement before you decide to include it in the final list. Depending on the merit of the each requirement, you include the requirement for the project.
To collate stakeholder requirements and finalize the project requirements, you must complete the following tasks:
After you have collected requirements from all the project stakeholders, you must collate all the requirements at single location so that you do not miss out on any of the requirement. As discussed earlier, it is not that every stakeholder requirement can make it to scope of the project. You must make decision on the merit and importance of each requirement before selecting it for the project scope.
The requirements you have collected form the stakeholders might have several conflicting requirements. Therefore, you must review, analyze, accept or reject, and prioritize the requirements you have collected. To complete this exercise, you can either get a consensus to nominate a person, maybe yourself, or create a group of reviewers to make the decision of accepting or rejecting the requirements.
Assigning one person to make decision on behalf of the entire group is known as dictatorship method. It is simple and faster method. However, it can negatively impact the decisions because of biasedness, if any. Additionally, some of the stakeholders might not buy in to the decision made by a single person.
Opting to create a group of reviewers to make decisions is known as plurality method. In this method, a decision to accept or reject a requirement is made by taking majority approach. Usually, the group chooses the requirement that is backed by more than half of the members. However, if there is a fractured mandate, then the group goes with the decision that has largest number of supporters.
Create the Requirements Document
After you have collected and finalized the requirements, you must document these. The document you create as a result is known as Requirements Document and is an outcome of the Collect Requirements process defined in the PMBOK guide. Creating a Requirements Document makes sure that the requirements are clear and unambiguous. You can use this document to verify the requirements with the stakeholders and get their acceptance.
Balance the Stakeholder Requirements
As a project manager, it is very important for you to balance the stakeholder requirements. To balance the stakeholder requirements, you must make sure that you can meet the requirements within the objectives of the project. If you cannot meet the stakeholder requirements within the objectives of the projects, then you need to consider adjusting the scope, time, cost, quality, resources, risk, and customer satisfaction of the project. To balance the stakeholder requirements, you also need to prioritize the requirements and resolve conflicts, if any, among the requirements.
In the interest of the project, you must balance the stakeholder requirements that might or might not match the project or other stakeholder requirements. You must balance and resolve such requirement conflicts in the interest of the project. However, you must have clear project objectives before you can balance or resolve conflicts in the stakeholder requirements. Otherwise, it could become a very difficult task for you to balance and resolve stakeholder requirements in absence of the clear project objectives. Additionally, it would be easier for you to balance and resolve conflicts in the stakeholder requirements if you have identified prioritized all the requirements you have collected form all the stakeholders.
This is an ongoing process you would find in a real world projects. You might keep getting new or modified requirements from the stakeholders throughout the life cycle of the project. However, in the interest of the project, you must balance these requirements.
Resolve Competing Requirements
Different departments involved in the project life cycle have their own objectives and priorities set for the project. As a result, requirements from one department might conflict the interests of another department. For example, the aim of the development department might be to keep the defects in the project to be low even if they need additional resources. On the other hand, the objectives of the finance department could be to keep the budget or cost of the project as low as possible, thereby, conflicting the requirements with that of the development department. However, you must manage the requirements keeping the project as a whole in the mind and not according to the requirements of an individual stakeholder. Even if you need an intervention from the management, you must resolve such conflicts in the interest of the project.
When resolving conflict, you must keep in mind that you should accept only such requirements that comply with the business case for which the project was started, project charter, project scope statement, and project constraints. If the stakeholder requirement does not comply with these, you must reject the requirement. You must also reject a requirement that does not add something related to the business case of the project.
Create a Requirements Management Plan
As is the case with any activity of managing a project, you must plan to manage project requirements. When creating the plan to manage the requirements, you must describe the methods you plan to use to identify the requirements. Additionally, you must specify how you intend to analyze the requirements, prioritize the requirements, manage the requirements, and track the change requests for the requirements.
Create a Requirements Traceability Matrix
One of the biggest conflicts seen between the customer and project team is that the project delivered to the customer does not map to the actual expectations of the customer. This issue mostly arises when you do not have the requirement traceability matrix. This matrix helps you to track the requirements through out the life cycle of the project and makes sure that the actual requirement is addressed in the product.
When you start the process of identifying requirements, it might result in further refinement of the requirement. This, in turn, might completely redefine the requirement and you might lose track of where the actual requirement came from. To avoid such situations, you can create a requirements traceability matrix in a tabular form. The table contains an identification number for each requirement, its source, person assigned to, and the status of the requirement. Such matrix can help you to trace each and every project requirement and help you manage the customer expectations accordingly.
Before you start planning for a project, it is important for you to finalize the scope of the project. However, you cannot finalize the scope of the project unless and until you know the requirements of the project, which you need to collect from all the stakeholders of the project. Requirements are defined as the outcome or capabilities that the stakeholders want see in the product to be developed in the project. In addition to the outcome or capabilities of the product, the requirement might even state other expectations, such as the quality standards of the product. Therefore, when collecting requirements from the stakeholders, you not only need to collect the product requirements but also the overall expectations of the stakeholders from the project.
The project charter that you receive from the Project Management Office already contains the high level requirements from the stakeholders. Therefore, the aim of collecting requirements at this stage is to get elaborated and specific requirements from the stakeholders. Collecting such information is very critical for the project because if you miss even seemingly small requirement, it can be capable of changing the entire course of the project and raising conflict throughout the course of the project, which ultimately might result in the complete failure of the project.
One of the methods to collect requirements from the stakeholders is by using various software utilities, wherein; you need to use certain software applications or tools to collect the requirements from the stakeholders. You can use any of the following software utilities and techniques to collect the detailed requirements from the stakeholders:
Mind Maps:Mind map is a graphic utility that you can use to understand the requirements, and arrive at the scope of the project. Even though you can manually create mind maps for the project requirements by using pen and paper, there are many automated utilities available in the market that you can use to create mind map for the project. Mind map is a graphic representation of the flow of ideas or requirements for the project. It is a diagram that you use to visually organize information. You generally create a mind map that joins various information and requirements on a project and shows the relationship among the different requirements. To start with, you create an image or just a simple box depicting the project. Now, you start with a branch that depicts an idea for the project and keep branching it by adding further ideas or requirements till it reaches the minute level of information on requirements for the main idea or requirement. Similarly, you repeat the process of depicting other major ideas on the mind map. You must connect all major ideas or requirements directly to the image representing the project. After you have completed the mind map for the project, you can read each branch like a story when explaining the requirements for the project.
Delphi Technique: Delphi technique is a method that you can use to estimate the probability and outcome of the future events. It is a quantitative technique you use to arrive at a consensus. In this technique, as a facilitator, you seek information from a group of experts who participate anonymously. After you receive responses from them, you compile the same and send the results back to the group for review. You iterate the process until you arrive at a consensus.
Questionnaires and Surveys: Questionnaires and surveys are the methods you can use for a large group of stakeholders. When preparing a questionnaire, you create a series of questions and prompts relevant to the project, and provide sufficient space for response. After conducting surveys with the stakeholders using the questionnaire, you collate the information and arrive at the requirements for the project. You can use various online as well as offline survey utilities to collect requirements from the stakeholders.
Prototypes: Prototype is yet another effective method of collecting requirements from the stakeholders. You create a functional or non functional prototype according to the initial requirements you could gather and understand. You demonstrate this prototype to the stakeholders and, at times, let them play around with it, and seek feedback from them. Base on the feedback from the stakeholders, you might need to update the prototype for a few iterations until the stakeholder requirements are finalized.
Observations: Observations is a method in which you might need to use the job shadowing technique, where you must observe the potential user of the product working with the existing system that includes the manual system if it is still not automated. At times, this method might also require you to participate in the work to understand and identify the requirements.
Affinity Diagrams: Affinity diagrams are considers as on of the seven effective tools for management and planning. Affinity diagram is yet another graphical utility that you use after you have gathered requirements by using other methods discussed earlier. Here, you get all the requirements sorted and bucketed into groups based on the similarities. You assign title to each bucket or group of requirements for its identification. The sorting and bucketing the requirements makes it easier for you to identify the set of requirements as well as additional scope, which might have gone unnoticed earlier. This method also helps in identifying some of the risks associated to the project.
Before you start planning for a project, it is important for you to finalize the scope of the project. However, you cannot finalize the scope of the project unless and until you know the requirements of the project, which you need to collect from all the stakeholders of the project. Requirements are defined as the outcome or capabilities that the stakeholders want see in the product to be developed in the project. In addition to the outcome or capabilities of the product, the requirement might even state other expectations, such as the quality standards of the product. Therefore, when collecting requirements from the stakeholders, you not only need to collect the product requirements but also the overall expectations of the stakeholders from the project.
The project charter that you receive from the Project Management Office already contains the high level requirements from the stakeholders. Therefore, the aim of collecting requirements at this stage is to get elaborated and specific requirements from the stakeholders. Collecting such information is very critical for the project because if you miss even seemingly small requirement, it can be capable of changing the entire course of the project and raising conflict throughout the course of the project, which ultimately might result in the complete failure of the project.
One of the methods to collect requirements from the stakeholders is the manual method, wherein; you need to use certain tools to manually collect the requirements from the stakeholders. You can use any of the following techniques to collect the detailed requirements from the stakeholders:
Expert interviewing: Also known as interviewing, in this technique, you need to interview the stakeholders to identify their specific requirements for the project. The specificities include the ones for just a project work, product, or even the entire project. Depending on the convenience, you can interview stakeholders either individually or in batches. You can conduct interviews by using various mediums, such as in person, emails, letters, phone calls, or any other convenient medium. Even though this technique might take a lot of time, it gives you an opportunity to understand individual requirements in greater details. Additionally, the technique gives you an opportunity to develop good rapport with the stakeholders of the project.
Brainstorming: In this technique, you gather the stakeholders in a room and start the ideation process. During brainstorming, there is possibility of getting further ideas generated from the ones proposed by a stakeholder. You must facilitate the discussion during the session and keep capturing the ideas generated during the meeting. Make sure that you do not interrupt the process and note down the idea, irrespective of its level of relevance because even such ideas might give rise to another better one in due course of time. Even though there are chances that the meeting might turn into utter chaos if you are not able to manage it properly, this technique has a capability of generating great ideas that might get triggered from another idea.
Nominal group techniques: In this technique, you the participants of the brainstorming session rank the most useful requirements. Depending on the availability of time, you can either merge this session with the brainstorming session itself or conduct an individual session at a later time. Whereas the brainstorming session provides you a huge list of ideas, this technique enables you to create a meaningful set of requirements from the ideas generated during the brainstorming session. It is always advisable to reserve a time period for nominal group techniques immediately after the brainstorming session for two major reasons. First – the ideas are fresh and there are high chances of missing on some of these if the nominal group techniques session is delayed for a later time. Second – it might be difficult to come up with a common time convenient for all stakeholders because of their prior or ongoing commitments.
Focus groups: In this technique, as against the brainstorming session where you invite all stakeholders, you invite only a specific set of stakeholders who are subject matter experts. In this meeting you seek requirements usually on a specific aspect of the project for which the stakeholders have expertise. While you moderate the meeting, the stakeholders can discuss the requirements among themselves. Creating focus groups can help you to understand the requirements for the specific section or feature of the product because the stakeholder invited for the meeting would be having expertise in that area. Additionally, this technique can help you focus your energy and efforts at a feature at a time.
Facilitated workshops: In this technique, you organize workshops where you bring together stakeholders that have different perspective on the project. The stakeholders discuss project requirement from their perspective, which can be from various teams like product designers, developers, end users or any other stakeholder team members.
Even before you start with the project, the first activity that you must perform is to define the scope of the project. Managing the scope is an activity of the project management, which has two aspects – the scope of the project and the scope of the product. Scope management as a whole defines the process of collecting information to start a project and define the features of the product that would meet the stakeholder requirements.
According to the Guide to the Project Management Body of Knowledge guide (PMBOK Guide) published by the Project Management Institute, the scope of the project is defined as the work you need to accomplish to deliver a product, service, or result with specified features and functions. However, the PMBOK guide defines the product scope as the features and functions that characterize a product, service, or result.
The definitions of project scope and product scope distinctly indicate that while project scope is completely work oriented and completely focused on the tasks that you must perform to accomplish the goal; the product scope is more oriented towards the functionality of the product. To simplify the understanding, the project scope is the “How” part of the overall scope management while the product management is the “What” part of the scope management.
Now the big question raises is that why do you need scope management as an individual activity of the project management. Well, the scope forms the backbone of the project and is something that is capable of making or breaking the entire project. It is typical of a project that if you do not finalize the scope of the project and product, you might keep getting request to make changes to the project. This not only adds to the rework in the software product, but also adds to the dissatisfaction and demotivation of the team, especially when changes are too many and very frequent.
For an enterprise software project, the number of stakeholder is very large, which includes management, customers, sales and support teams being some of them. As a result, every team has its own set of requirements and tries to push their requirement as a priority. It is the responsibility of the project manager to manage and finalize the scope, ensuring the all stakeholders are on the same page.
Even though it is assumed that the scope of the project is finalized in the beginning of the project life cycle itself, it is not the situation in the real life. In real life projects, there are high chances that the project requirements might change over a period of time. This could be because of the varied reasons, products from the competition is one of the main reason to push such changes. Politico business requirements also play an important role in requests for changes in scope. Therefore, it is very important for you to plan how to handle any requests in the change in the scope of the project.
To manage the scope of the project, you must perform the following activities before you finalize the scope:
Determine the requirements: To come up with the solution, the first requirement is to understand the problem statement. Therefore, you must make sure that you understand requirements of all the stakeholders, and then map these requirements to the business need of the project as described in the project charter. You must weed out the seemingly and projected to be important requirements depending to the business needs of the project.
Define the scope of the project: After understanding the requirements and mapping the same to the business requirements of the project, you must define the scope of the project. The project must exclusively state the inclusive and exclusive items of the project scope.
Create a work breakdown structure: Work breakdown structure (WBS) is the process of breaking the scope of the project to smallest manageable pieces of tasks.
Verify the scope: You must verify that the work being done is according to the planned scope of the work.
Measure the performance: Make sure that you measure the performance of the project according to the scope of the project at regular intervals. If needed, adjust the scope to accommodate the additional work required.
After the management of the organization has initiated the project, the project is assigned to a project manager. As a project manager when you receive the project, you start with the thorough planning on how the project should be managed and completed. It is rightly said that failure to planning is like planning to failure. The success of the project completely depends on how well you have planned the project. A thoroughly planned project forms the basis of the success of the project. However, a poorly planned project is destined to be doomed.
In a well planned project, you take care of planning each and every aspect of the project, right from the scope of the project to the quality of the deliverables. The plan must consider the viability of the project in terms of the financial aspects. Following is a summary of various aspects around which you must put your efforts when planning a project. Most of these activities flow in a sequential order. Each of the following aspects are covered in details in an individual or a series on articles on these aspects of a project:
Plan the planning:The first thing you must consider when starting the project planning is how you are going to plan for the project. You must consider the areas that the project is going to or would be getting impacted, and plan to handle each of these areas effectively.
Finalize the requirements: Even before you start putting your efforts in a project, you must finalize the requirements. If you do not finalize the requirements right in the beginning of the project, frequent change requests from the stakeholders not only hamper the project progress, but also add a lot of rework and resource wastage.
Scope planning:Scope management is another important aspect of the project. Here, you define the items that are within the scope of the project and the ones that are out of scope for the project. To make the project successful, you must plan to manage the scope of the project to make sure that stakeholders know exactly what is the outcome of the project.
Resource planning:You must identify the resources that you need to complete the project, which includes movable and immovable resources. Additionally, it includes the duration for which the resource is required for the project.
Purchase planning:When creating a purchase plan, you must identify the resources that you can use in-house, the ones you should rent, and the ones for which you need to make an outright purchase from the market.
Work breakdown structure:Work breakdown structure (WBS) is yet another very important aspect of the project planning. In this stage, you break the project into small and atomic individual activities that can be managed efficiently. In a work breakdown structure, you need to identify the smallest units of the work items that can be started and completed as a unit. A work breakdown structure provides a bird’s eye view of the project and helps identifying various dependencies in the project. Work breakdown structure is the key deliverable of the project planning and forms an input for various planning activities.
Team planning:After understanding the project requirements and the work breakdown structure, you must identify the team required to complete the project. This includes the size of the team as well as the expertise you need to complete the project. Depending on the expertise and experience, you need to assign various roles and responsibilities to the team members to get the work done.
Communication planning:You must plan how the team would be communicating within as well as outside the team. It is important to establish a protocol as well as the mode of the communication to avoid any communication issues during the project and even after the project is completed.
Risk mitigation planning:You must identify and define the probable risks associated to the project, however big or small these might be. Mere identification of the risks would be of no use unless and until you plan on how to mitigate the identified risk. Success of the project is also based on how well you have planned to identify and mitigate risks at each and every stage of the project.
Project execution planning:After you have planned the complete project, you must also plan how to execute the plan. You must plan all the nitty gritties of the project. This includes how you are planning to actually implement the plan you have created for the project.
Project kick off:You must get the project plan approved and signed off by the stakeholders to make sure that everyone is on the same page and there is no communication gap. After the project plan is approved, you must hold a project kick off meeting with all stakeholders and present the detailed project plan. A project kick off meeting marks the formal start of the project plan.
Verification and testing are two other software engineering terminologies that need to be explained for a better understanding. Both of them play a significant role in the development of a program that will satisfy the end user and maintain high quality.
What is software testing?
Software testing refers to the process of executing an application or program with the intent of detecting potential software bugs. It also has the objective of helping the developers to find out whether the software is working according to the intended purpose. During the testing process, the end user’s area of application will be considered and the software will be subjected to a series of tests to ensure it satisfies the needs of the end users.
This will include several testing for several factors that may affect the performance of the system such as the presence of a bug, programming error, and other hidden dangers to the software. When these shortcomings are detected during the testing process, they will be corrected without delay before the completion of the software system.
There are different types of system testing techniques. These are static testing, dynamic testing, unit testing, integration testing, and other testing techniques. All these testing techniques have a single function: to ensure that the software does not fail to meet the expectations of the end users, the people who the program is designed for.
The testing can either be done manually by the programmers. This will require that they will go through the program to hand pick the errors for correction. The automated can also be used for testing but it functions by using some tools and scripts. Although the techniques are different and have their advantages,
On the other hand, we have software verification, another important tool they each constitute a great way of identifying the errors in a program. There are contributory factors to the high quality of a software program. What is it?
What is system verification?
Before a system is developed, there must be a design where the basic requirements for the system are well spelt out. During the development of the system, verification is done to consider whether the system is developed according to the requirements and specifications. This may include all the activities that are combined to make sure that high-quality software is released for use to the end users.
Some of the processes that make up system verification are:
Inspection
Specification analysis
Testing
Design analysis
The verification process is usually at the beginning of a development process and all the processes above will be done for the evaluation of some important plan, code, and specifications. The objective of verification is to answer the question “Are we developing the software according to the specification and requirements?”
For instance, banking software will be expected to be used for processing customer information, balance the account in case of withdrawal or otherwise, and other related functions. If verification is to be performed on the software, the testers will test whether these functions can be performed effectively by the software. If a banking software can update a withdrawal but cannot do the same for saving, it will generate a lot of problems. If verification is performed, such problem will be easily corrected. If any of the features of the software malfunctions, the defect will render the performance of the system useless.
While there is a stark difference between system testing and system verification, one of the system verification methods is system testing. It is testing the software that will reveal whether it is developed in conformity with the laid down design and purpose.
Software testing and software development are two distinct terms in computing. They are two different and important stages in the life of a software program because they perform different functions that support the existence and efficiency of a program. It is important to define each of these terms and identify the various roles they play.
Software testing
Software testing is the process of confirming the correctness, quality, and completeness of a computer software. It involves carrying out some specific activities that are designed to spot the errors in a software program so that it can be corrected before it is released and distributed to the end users.
The test helps the developers to check whether the result of the test will correspond with the expected result as well as check if the software is error free. How is this done?
To test a software, it is operated under some controlled conditions to see whether the output is the expected output, study the behavior of the program, look for errors, and check whether the software will meet the needs of the user or not.
For instance, if a program is designed to process the payroll of a company, during testing, the various stages of processing of payroll will be tested on the program. Different parameters may be tested in the program to ensure that it functions in all the areas where it is expected to be used by the end user. The program may fail or show some flaws such as inaccurate calculation or omission of some data, factors that can have serious effects on the output of the program. When this occurs, the program will be taken back to the software programmer to correct all the errors. That is the essence of software testing.
Software development
While software testing involves analyzing software program to determine its efficiency and errors in addition to evaluating some features of the software, software development refers to how the software program is developed. It is simply the process of writing a computer code and maintaining it. In a broad sense, software development involves all the developmental stages of the software from the conception of the idea to the launching of the programs.
While software development may sound simple, the process may involve an extensive research, prototyping, re-engineering, developing an extensive algorithm, drawing a flowchart, several modifications, coding for hundreds of hours, debugging both serious and minor errors, and other processes that may contribute to the existence of the software program. Software development is also called application development, enterprise application development, designing software, platform development, and the likes.
This brings out the difference in the two terms. While software development refers to all the processes that culminate in the existence of a software program, software testing is checking the software to see areas of improvement, detect potential errors, test the software for accuracy, or any other activities that will ensure the successful launching of error-free software. It is a way of finding out whether a program is functioning in conformity with the objective of the software when it was under development.
Software programs are tested by software developers who are also called programmers while a software program can be tested by a software tester, test lead, test administrator, test designer, automation tester, or manager.
Although the testing is not a part of the software development, it serves as the guide to the developer to see what can go wrong and render their efforts useless.
In essence, software development precedes software testing. Without developed software, there is nothing to be tested. On the other hand, without well-tested software, a program is nothing.
These two terms are used interchangeably by some individuals due to the seeming similarity in their functions. However, they are quite different in meanings and depend on each other. A little explanation of the two terms will aid your understanding of them. I will start with testing.
What is testing?
Testing is the process or a way of determining that a software program is devoid of any error that may affect its efficiency. It is also done to find out whether a program performs according to the objective of building it. An effective testing can be done by changing the input of a program or run it on different platforms to see its response to these inputs and platforms. Sometimes, testing may reveal a huge flaw or bug that may influence the output of a program if not promptly corrected before its distribution to the many users who will subject the program to different conditions on a variety of platforms.
During testing, different techniques way be used. This includes providing both correct and incorrect inputs, intentionally wrong inputs, and other different inputs with the objective of assessing the response of the program to different situations. While testing a program using different data, the program may flag a bug that needs to be corrected. That raises the question “What is a bug?”
A bug is a programming error that affects the execution of a program. The program may not function properly or does not execute at all. Some of the bugs may be caused by the omission of a code or the use of a wrong one. In either way, the program will not execute in line with the objective of developing the program. The result of the execution may be at variance with the expected result. This brings about the concept of debugging.
What is debugging?
When an error or bug is detected in a program, it must be corrected. Otherwise, the objective of developing the program is defeated. Nobody will feel comfortable processing the payroll of his employers with a flawed program, neither will one trusted a program filled with errors for information on construction, lest people’s lives are put at risk.
The process of removing or correcting these errors is called debugging, derived from the word “bug.” Wikipedia defines debugging thus “Debugging is the process of finding and resolving of defects that prevent correct operation of computer software or a system.”
Debugging varies in the degree of complexity. There are some simple debugging such as a small program designed for in-house use and some other related programs. Due to the relatively short length of the program, the debugging done by a programmer will be relatively simple.
Contrary to this, the code for some big conglomerate like Facebook or Google will run to millions of lines of code. In this case, debugging may be complex and difficult because the debugger may need to trace the origin of all the bugs before correcting them. Either way, debugging still remains an important part of a robust and well-functioning program.
How do programmers detect bugs? The answer is simple: through testing. As discussed above, one of the reasons for testing a program is to identify potential bugs that may impede the smooth execution of a program. When these bugs are detected during testing, the developer immediately takes over to correct all the errors, in another word, to debug the program.
Debugging can be strenuous and time-consuming. Each of the errors will be read and understood before debugging takes place. This requires much time and effort on the part of the programmer if he wants to be credit for a good job and meet the needs of the users.
