SAP is changing many aspects of how customers consume and act on business information. In the past, we have often tried to look backwards to forecast tomorrow’s weather, leaving room for interpretation of what changes might impact a business. We usually make good decisions, but sometimes significant changes are required to calibrate our business processes.
SAP development has always been structured to slow down change, ensuring that more eyes can set focus on the potential effects downstream. This is true for both the technical aspect in how changes are introduced as well as the change processes SAP customers implement to mitigate risk and enforce compliance. While this is a noble effort, it often requires a lot of back and forth to move software changes that appear simple at face value.
The two key factors that determine whether a software change will be accepted are price and implementation time. How much will it cost? And how long will it take? More often than not, the best people to answer these important questions are the ones doing the work.
As you can imagine, the developer will say and do anything to give him or herself a good lead in this situation. I think we all can agree that this practice doesn’t benefit anyone. Transparency, trust, and due diligence form the ideal recipe for fending off (or at least standing up to) the tigers.
You’ve likely seen a chart like this before. If we accept it to be true, then the solution is simple: get it right the first time with zero defects. This is a wonderful goal to reach for, but nobody is perfect. Defects will be found, designs won’t always meet requirements, and there will be issues with data accuracy. All of these factors (and the variation that is associated with each) will cause changes. It is a mistake to attempt to rigidly control change. Accept that change and variation are constant, and do everything in your power to flex with them.
How might we change this?
Wouldn’t it be nice to see the cost of change flatten out? To do this, we need to create a plan that fosters our ability to adapt. This would mean reducing the time it takes to effectively respond to change when it costs the most.
Fortunately, development of an effective adaptation plan is completely possible. To mitigate the effects that change will have is to conform to a process of software delivery that ensures quality and adaptability. It forces designers, developers, and testers to think about what kinds of tests a solution would need to adhere to.
Test-Driven Development
In part one of three of The Value of Continuous Delivery blog series, we will look at the first step to embracing change and driving towards Continuous Delivery. Since the developer is often the hinge for creating software changes, this person must embrace change… like it or not. The first step towards mitigating the pain of change is an Agile development paradigm known as Test-Driven Development.
Essentially, developers will write a unit test (that serves as a test specification) to evaluate a specific portion of code. Then the developer writes the code to satisfy the test. As more and more tests are created, the code must become more robust, and this process allows the developer to identify defects that might not have surfaced until later (when it would be more costly to fix).
It’s not enough to simply think like a developer. Analysts and QA tester tend to think of the function as a whole. So if you follow an Agile methodology, your user stories should be granular enough to indicate individual functions that would serve as your Acceptance or Integration tests. This adds another layer that will begin to satisfy your functional and QA testers. Testing how these different lines of code interact is the main purpose of this system. Here we test functionality, performance, and reliability, and the results are recorded and compared to proposed test cases.
For ABAP, there are frameworks that support this paradigm. ABAP unit and eCatt have been around for some time and are often overlooked as beneficial steps to reduce maintenance and regression when testing custom code.
To a web developer, SAPUI5 is just another Javascript framework. It heavily relies on JQuery and DOM manipulation. Consequently, there are several test frameworks that could be used. SAP recommends QUnit for unit testing, and there are several examples to show you how to use this framework. Check out SAP’s walkthrough document. https://sapui5.hana.ondemand.com/#docs/guide/e1ce1de315994a02bf162f4b3b5a9f09.html
Are you considering incorporation of Test-Driven Development? Leave a comment or shoot me an email if you would like to discuss it sometime!
View our LinkedIn, here.
