For IT development companies, and organisations developing computer and digital devices (smartphones, tablets, digital diaries, etc.) software projects, one of the most important, and also the most troublesome issue is encountering “bugs” or defects in the code functionality when a particular application, or a system, is deployed and used in a live environment. Software bugs can be very common. Ever since computers were designed in the early years, bugs have inadvertently, or otherwise, kept on troubling coders and project managers, and have tested their ingenuity to resolve them to the fullest extent possible. Ask any seasoned programmer – He or she will tend to initially confer, and eventually say that the word “Bug” is aptly named – It tends to “bug” you!

The etymology of the word “Bug”

It is interesting to know how the terminology “bug” was first coined, and used to describe a state of functioning in which an error or a flaw in coding can lead to flawed results, or “outputs” in IT jargon. There are several stories as to how the terminology came into existence. A theory most subscribed to involves the pioneering programmer, Grace Hopper, who was a young Naval Reserve officer working on a Mark II computer at Harvard University. In 1944, she related an incident in which the computer had malfunctioned – an actual moth had, in fact, “managed” somehow to get itself embedded between two electrical relays, causing the computer to halt in its functioning. She explained that the cause of the malfunction was a “bug” which was later removed by a technician. The famous bug was exhibited by the Navy for many years and is now owned by the Smithsonian Institute.

Bugs and software regression

In a broad sense, a software bug can be understood as an error, failure, flaw, or even a fault in the code designed to develop an application or a computer-based system. Bugs typically create unexpected and incorrect results or outputs, which cause the functionality of the particular application to stop, or function in a manner other than so desired. Bugs generally arise owing to reasons such as:

• Mistakes carried out while encoding a program
• Designing an improper code structure or logic
• Utilizing the functionality of the code in a manner other than that recommended
• Technical errors in the code compilers and/or interpreting resources and agents

Of course, the above are not the only causes which give rise to bugs, however, they constitute the major reasons why bugs tend to occur in the majority of the cases. When the numbers of bugs increase significantly, the overall functionality of the application may be compromised upon to a considerable level, rendering it useless and non-productive. This can cause severe financial loses, and even force businesses to face litigations from troubled end-users and consumers. Broadly, the word “regression” means to return to a former, or a lesser developed state. So, how can regression be understood in terms of “software regression” pertaining to software development? In practice, developers write down or generate code, to develop a particular functionality as requested by the end-user or the client. During the coding stage, the developer not only develops the code but also checks it and ensures that it is working properly. This is a standard practice followed by most experienced programmers and developers. However, at times, the testing process may not be carried out properly, or the code functionality might work properly in most cases, but fail to work under certain circumstances and situations. A second scenario is the code may be developed and properly tested at the time of creation, and the application deployed in a successful manner. However, a newer version of the deployed functionality may be subsequently re-developed to include even more features and functionality, to replace the prior one. The reason could be a need experienced by end-users to use the functionality for a more specific purpose. The newer version may cause some of the older functionality to stop working. This, in a rough sense, can be understood as software regression. For example, you could encode a program to display “Hello World” on the monitor. It might work perfectly, and display the message each and every time it is executed. Later on, the same code may be re-developed to accept the user’s name, and display it in lieu of “World.” The objective of the new code might be to display “Hello John” rather than “Hello World”. However, once the newer code is developed and deployed, it actually ends up displaying the user’s name only – “John” – instead of the actual greeting “Hello John”. In this case, some of the older functionality associated with displaying “Hello” in the greeting is curtailed due to some coding reason and “missed out” by the newer code. This is software regression.

Knowing a “bit” about what is Agile Scrum framework

Agile is a framework. It offers guidelines as to how software-based projects can be effectively developed through the consistent and sustained delivery of software functionality through short bursts of development activities known as“sprints”. ” Agile is based upon certain principles which suggest how the framework ought to be ideally understood and interpreted by people, and how the framework should function in an ideal working environment. One of the Agile principles states “Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.” To support this principle, the Agile framework supports an iterative (repetitive) product incremental cycle (a process through which smaller components or parts of the actual product are individually developed, and later integrated to form the complete product). At the end of one product increment cycle (sprint), Agile events known as the “Sprint Review” and “Sprint Retrospective” are held to ascertain the reliability of the code functionality developed during the sprint, and whether it satisfies the acceptance criteria so it can be considered as “bug free” and fully functional. Agile promotes “shippable” product increments i.e. small pieces of code offering a certain functionality that is complete, perfectly functional, and free of any “manufacturing” defects. It is worth knowing about the actual Agile process, events, roles, and artifacts which can help to eliminate bugs and control the factors causing regression in software code. People new to Agile concepts and principles may find the framework difficult to understand. This article does not aim to educate the reader in Agile or Scrum framework. Rather, it aims to explain some of the important Agile characteristics which make the framework a very good choice for developing software projects. The objective is to describe how Agile can help to reduce regression levels during the development process. To understand how Agile can do this, it is important to know a “bit” about Agile first.

The product owner “PO” (Role)

He or she is the person who “owns” the project on behalf of the stakeholders or project owners. The person represents the interests of the stakeholders in the Agile project and ensures that the project delivers a certain business value (importance in terms of market value and financial implications) at all times while the product is being developed. The individual is primarily responsible for the success or failure of the project.

The product backlog (Artefact)

It is a master list mentioning all features and functionalities to be developed in the software project and to manufacture the software product in totality.

Product backlog item “PBI” or user story Artefact

In an Agile scrum, the actual product is “broken down” into much smaller, manageable, and developable parts known as product backlog items “PBIs,” or user stories. Each developable sub-unit or product item exists independently in the backlog. Moreover, each PBI is defined to include:

• An index or a reference number to uniquely identify the PBI
• A description stating the functionality to be developed
• An explanation describing what the functionality is supposed to deliver, how it is to be delivered, and why it is needed
• A list of acceptance criteria which needs to be satisfied for the PBI to be considered as “perfect” and “complete”
• A short explanation describing what must be “done” for the PBI to be considered as “shippable” and ready for immediate use

Sprint planning meeting (Event)

The iterative product development cycle (sprint) is initiated by an Agile event known as “sprint planning.” This meeting is important from the development point of view. The meeting is held in two parts. In the first half, the PO selects important PBIs or user stories for development purposes from the product backlog, and a temporary list known as a “sprint backlog” is prepared to hold the user stories for development purpose. The PO then explains to the development team how the stories should be developed, and what activities team members should carry out to make the development “acceptable.” The acceptance criteria are properly explained to the team, so each developer becomes familiar as to how the actual development activity should be carried out, and what the management expects out of the proposed development. In the second half of the meeting, the development team discusses how user stories should be distributed amongst the developers on the team. Stories are generally distributed based on the expertise and skill sets possessed by the developers. Individuals are assigned development tasks based on their familiarity with the development process and their experience levels.

Sprint backlog (Artefact)

It is a temporary list created by the PO during the sprint planning meeting to hold the PBIs, or user stories, for development purpose. In Agile, development is always carried out in short bursts of activity known as sprints, and at any given time, a small subset of the product is actually developed. Unlike the traditional waterfall method, development is never carried out as “whole.” The entire sprint backlog is processed for development during the sprint.

The sprint review (Event)

It is an Agile event held immediately after a particular sprint, or a product increment cycle is completed, and a certain code functionality in the form of a user story is developed by the team. The meeting is headed by the Product Owner who verifies the development and ensures that the user story satisfies the definition of “Done” as mentioned in the PBI. If the user story fails to satisfy the acceptance criteria so stated, it is sent back to the product backlog for re-development. If it is accepted by the PO, the user story is presented to the stakeholders in the succeeding sprint review event for their acceptance and opinions.

Sprint retrospective (Event)

Held immediately after the sprint review event, the stakeholders preview the user stories developed by the team. The stakeholders offer their opinions regarding how much of business value the user stories actually offer after their development, and whether the stories can be, in fact, considered as “shippable.” The main purpose of the retrospective is to reflect upon what mistakes occurred in the Agile project in the past, and what needs to be learned from prior mistakes. The retrospective offers an opportunity for the Agile team to communicate with the end-users and project owners, and to get “first hand” information as well as knowledge as to what the stakeholders actually need in their project, and how they had actually envisioned their project at the time of its inception.

How can Agile Scrum framework help to reduce or eliminate bugs and software regression?

Software regression is identified if it exists in the code functionality, checked, rectified, and re-tested during the Agile development process. This is how it happens.

1. Starting with the software development process using Agile

In Agile, the actual development starts with the creation of the product backlog. Based upon how the stakeholders and project owners have envisioned the software project, and what they desire in terms of product functionality, the PO initially “breaks down” the entire project into PBIs or user stories, which are small, individually developable functional units. Once the master list or the product backlog is created, the PO assigns a business value to each PBI, so that important user stories having a higher “market value” can be developed first. The PO than proceeds to conduct a sprint planning meeting which is attended by all. In the sprint planning meeting, the PO selects some of the important PBIs from the top of the product backlog and transfers those stories to the sprint backlog so the development team can start with its coding activity. It is important to know that developers and programmers only develop those user stories which have been transferred to the sprint backlog, and none of the other PBIs stated in the product backlog. The developers then break down the PBIs into individually developable even smaller tasks and distribute them amongst themselves. Each programmer or developer prepares a smaller list which includes all tasks to be developed by him or her during the sprint.

2. Carrying out the actual software development

The actual product development is carried out through sprints. During the sprint, each developer takes up tasks allotted to him or her and proceeds with their development. At a time, one task is taken up for development. Once the task is completed, it is marked as “Completed” and another task is subsequently taken up for development. The process is repeated until all the tasks are developed. Once a particular task is completed, it is tested for its reliability, consistency, and accuracy by team members specially appointed to carry out the testing process. Some Agile processes maintain a separate team for carrying out the Q.A. related activities. Each task is painstakingly checked for any errors arising through improper coding practices, wrong usage of coding language, flawed design, and other regression related parameters. Agile teams can also use specially developed regression testing software to identify any flaws in the coding, designing, or functional aspects. Once the regression checking is over, the user story is verified whether it fulfills the benchmark and acceptance criteria mentioned in the PBI. After the story is thoroughly checked, it is marked as “Completed” and its status updated in the Agile process flow. It is important to complete all the tasks allotted to the team members during the sprint.

3. After the development activity

After all user stories have been developed by the development team during the sprint, an Agile event known as the sprint review is held to present the development carried out to the PO. During the sprint review, the PO scrutinizes each user story and re-verifies whether they fulfill the acceptance criteria and whether they, in fact, meet the definition of “Done.” If any user story fails to satisfy the PO, it is transferred back to the product backlog from where it may be taken up for re-development at a later stage. The only bug-free, well documented, and “shippable” user stories should be accepted as “final” during the sprint review. The objective of the event is to check for any regression related issues at a “micro” level. Once the sprint review event is over, another Agile event known as the sprint retrospective is held to further ascertain whether the user story functionality is acceptable from the market point of view. The stakeholders, project owners, end users, and other technically oriented staff members attend this event. The user story functionality is demonstrated to the participants, who minutely scrutinize the functional aspects and working to find any flaws or incorrect functioning of the user story. The participants also determine how much worth the functionality is from the saleability and market point of view. Once the stakeholders are satisfied with the results, the user story is accepted as “Done” The aim of this event is to check for regression related issues at a “macro” level.

Agile Scrum and software regression

Each task, when completed by the team during the daily sprint, can be individually tested for bugs, design flaw, and regression. In Agile, the user story cannot be accepted until it fulfills the acceptance criteria and meets the benchmarks. At the time of development, the developer initially checks the user story for any bugs or errors of any kind. Once the development team Okays the functionality, it is checked and verified again by the PO. POs are usually experienced Agile professionals and have the knowledge, as well as the ability to find any bugs or flaws overlooked by the team. This is how bugs are eliminated at a micro level. Once the PO acknowledges the user story, it is exhibited to the stakeholders who are familiar with the market trends and conditions and know what kind of functionality a particular user story should offer to satisfy the end user’s requirements. They again check the functionality from the end user’s point of view, and if it does not proffer to fulfill what the end users need, they reject the user story. When any user story reaches the sprint retrospective stage, it will not possess any bugs or coding errors, which are detected in the preceding micro level stages. The development is checked at a macro level during the retrospective, and accepted by the end users.

In Agile, development of the project is carried out using PBIs or user stories. A user story comprises a smaller, dedicated, software code offering a specific functionality, which is subsequently woven, or integrated to form the actual product. It is much easier to check small pieces of code as to whether they function properly or not, and if they contain any type of errors. Moreover, it is also more convenient and feasible to verify small chunks of code rather than the whole repository containing the entire project code. When individually developed project functionality is checked for regression, the integrated final product will possess a lesser probability of exhibiting any types of regression. This is one of the major advantages of the Agile Scrum. Regression is identified and rectified at a micro level – while small “pieces” of functionality are actually being developed.