Software for Quality Management in 7 Steps

Naturally, new ideas for standard software don’t come out of nowhere. Usually, there is already a foundation and a high level of expertise that can be expanded by new and thrilling ideas. At Babtec, Product Management is the hub in which these ideas are developed. By observing the market intensely, we continuously identify user needs. Here, we pay particular attention to the emergence or modification of standards that production needs to react to immediately. But the occurrence of new problems and challenges within industrial production can also inspire us to new ideas for solutions. One particularly user-oriented path to find ideas are the change requests that have been submitted to our support ser- vices. We receive about 50 such requests every month. These are analyzed with regard to need and feasibility; if a change request is found relevant, we pursue the idea.

Whether it was inspired by market observations or a change request, the product manager now presents the idea to the Portfolio Board, which consists of three decision makers. They discuss the idea and analyze it with regard to the company and product strategy. If the Portfolio Board gives the go-ahead, the product manager creates a concept on the product idea. In this step, the product manager depicts economic aspects in addition to explanations on need and a draft design. At the end of the initial design phase, entirely new products are depicted in a PEP sheet, which is discussed with Babtec’s managing directors. They then decide whether to implement the product. The team of product managers decides whether to realize modifications and further developments of existing software elements.

We now enter the phase of theoretical development. The product manager dives into the depths of the new feature and describes exactly what it should look like and how it should behave. In doing so, the product manager acts as the customer’s attorney, taking their point of view and asking how the user would like to experience using the feature. In this early phase of product design, the product manager already creates the Product Backlog Items, PBI for short. The large amount of information that is gained in the design phase and needs to be processed is divided into small work packages for the developers. Every PBI contains its own concrete objectives and exact descriptions on how it must behave in each action that has been planned. Acceptance criteria that have been defined in detail are the foundation for quality assurance during software development as well as for the successful release by the product manager. New features can contain a multitude of PBIs. These PBIs are the foundation for taking a product’s design off the drawing board and into practice.

In the transition phase from theory to practice, cooperation between the product manager and the development team is essential. That’s why a meeting is held for every PBI in which participants can give additional explana- tions and answer open questions. After all, software developers can only program the product optimally if they understand the product manager’s targets, descriptions and desires exactly and take ownership of them. The same applies to quality as- surance, which is why the person who will be responsible for testing at a later stage is already involved at this point. After exchanging thoughts on the respective PBI, the development team estimates the time required for programing and testing, which is recorded for the item. Once all this has taken place, the PBI is officially entered into the developers’ product backlog.

The terms “PBI” and “product backlog” are used in the agile development method SCRUM. We program the BabtecQ software and the cloud-based services included in Babtec Qube according to this method, with the aim of always being able to flexibly adapt the course and to continuously question our own actions. In the product backlog, the PBIs result in a task list for developers. Developers program in two-week sprints, for which they drag their PBI from the product backlog into their respective sprint backlog. Every day, a stand-up meeting is held at the SCRUM board. Here, every developer reflects on the progress of the past day and the team can make necessary corrections immediately. Another important part of the development process is the code review, during which codes are reviewed by another developer in accordance with the dual control principle. Finally, the source code of the software and cloud solution is rebuilt every night and new items are implemented in a process called Nightly Build.

Five testers are responsible for the qual- ity assurance of newly encoded items. They perform a test case based on the acceptance criteria. In these test cases, an exemplary application is carried out in accordance with a test description that is drafted prior to the test. During the test, the item must behave in exact accordance with the acceptance criteria. The test case is documented precisely; if there are any deviations, the item is returned to the developer. They are then required to resolve the deviations and to run through the code review pro- cess once more before handing the item to the software tester. As soon as the tester has approved the item, it is handed over to the responsible product manager. The product manager then inspects the item once more to ensure it corresponds with their ideas, which have been captured in writing. If the re- sults are positive, the item is approved and its sprint ends here.

Of course, a two-week sprint doesn’t result in just one item. Our teams work on several features with many individual PBIs at the same time. The new software and cloud-based features are each released in a major release every six months. These great annual milestones are always preceded by what is known as a code freeze. From this moment on, the source code is “frozen”; changes are no longer scheduled. Now we test the behavior of the new features within the entire software or cloud solution and complete the written documentation for the user. And then the moment finally comes. The Head of Product Management approves the release and a new version of the solution is provided to users as an update, fol- lowed by optimizing service packs every six weeks.