Archive for April, 2016


April 20th, 2016

Agile, DevOps, Shift-left…we’ve heard these buzzwords to describe evolved software development practices and principles for almost a decade now. Yet, achieving the optimal agile state continues to escape the grasp of the vast majority of businesses.

CEOs want to roll out products and services at a quicker clip to meet the demands of the digital economy. And, they understand that embracing these elevated techniques is what it takes.

One of the main reasons is that nearly half of the IT enterprises using agile remain captive to waterfall testing methods. To be more specific, we often see nine testing related challenges that hold enterprises back from realizing quality goals and business value from agile implementations:

Lack of a proven test strategy that works in agile

Many organizations harbor wrong conclusions about agile. New agile organizations often feel the ‘big bang’ adoption of agile testing practices is difficult, which ultimately leads to an inaccurate assessment of agile’s ability to ensure quality. Moreover, testers are not engaged early in the agile process, which leads to a lack of clarity in requirements / user stories / defect fixes. Frequently changing code requires a higher frequency of testing.

Siloed team discipline

Everyone knows that testers and developers are accustomed to working in silos. These self-erected walls prevent teams from working as a single unit to complete tasks. When collaboration is limited, delays frequently set in. The point of Agile is to unite all the right people with the right skills.

Insufficient skills for agile testing

Enterprises face a triple whammy when it comes to finding testing talent to fulfill the promise of agile. First of all, testing isn’t considered sexy. People want to do the development work. Secondly, agile requires special testing skills. If that isn’t enough, domain knowledge is essential to success as well. Finding highly skilled, collaborative testing talent with relevant domain knowledge is important to streamline automation and set up and manage integrated test environments, work “shift-left”, and work with agility. One company we know used a third party offshore testing provider whose staff did not have relevant financial systems knowledge. As a result, testers only exercised “happy path scenarios during sprints, resulting in higher defect counts during user acceptance testing.

Loose “done criteria” of user stories

Nothing is more disruptive to the flow of process than user stories with little or vague acceptance criteria. The result is partial (even wrong) coding and ineffective functional testing. Developing and receiving team consensus on the appropriate “done criteria” is challenging.

Difficulty applying test automation at appropriate levels in agile projects

Identifying defects early can buy you time, and a continuous integration framework is critical to achieve this goal. Yet, inefficient tools, skills shortages, and an inability of testers and developers to work together in shift-left make it difficult to apply test automation at appropriate levels in agile projects.

Lack of test data management inhibits building reusable test sets

Without rigor, test data management procedures inhibit the repeatability, traceability, and efficiency required to effectively execute testing in a time-boxed iteration. Quality organizations often fall short in investing and navigating technical challenges in virtualized test environments, which leverage proper test data management techniques. The ability to pivot between different testing phases within agile iteration is key. This flexibility is made possible by creating and utilizing virtualized infrastructure.

Product prioritization is compromised under open defects

Open defects from previous iterations can hold agile teams hostage when they try to remediate most of the open defects in the iteration that follows. This kicking the can down the road approach is contrary to the big picture iteration planning. Every effort for the upcoming iterations (including defect remediation) should be prioritized and planned from the product backlog. For instance, one of our client’s agile team planned resolution effort of all defects from the last sprint into the next sprint. Simple, right? Wrong. The client believed that resolving defects immediately in the next sprint is the right thing to do. However, they were not pleased to learn that their higher priority business user stories from the backlog got automatically pushed out as lower priority defects were remediated – priority here is by product roadmap.

Stories are written ‘wide and flat’ vs. ‘narrow and deep’

Another piling up happens on the integration front. When stories are written horizontally vs. vertically across layers, integration is delayed and so is integration testing. Integration issues aren’t addressed along the way. Instead, problems accumulate at the end and prevent project completion in a timely fashion. More importantly, a product owner doesn’t know how to accept such a story to ensure that business value is met. It’s a challenge to write stories vertically from upstream to downstream so that the team functions from end-to-end and product owners understand how to accept such stories.

Knowing the difference between “quality” and “business value” There’s a difference between quality and business value. Agile focuses on the latter as do product owners. Yet, IT / development / testing organizations, focus on driving “quality,” which puts IT at odds with products owners, customers as well as the agile process itself.

In the digital age, customers expect rapid delivery of quality products and services. Moving from waterfall to an agile model for testing is critical to meet market expectations.

For More info:

Get started on SAP Fiori development

April 13th, 2016

Get started on SAP Fiori development

Fiori brought big changes in how SAP applications are developed. An expert outlines the new tools and techniques — plus some old standbys that work well with Fiori.
Fiori is SAP’s current and future offering for user experience concepts, design and implementation. As Fiori rolls-out to more of SAP’s apps and users, the question of how to best approach SAP Fiori development becomes central to the business strategies of SAP users and partners. Let’s review where we are and what is coming up:
The current state of SAP Fiori development:The Fiori user experience is centered on the Fiori Launchpad. It is the entry point to Fiori apps in most implementations and provides a browser-based, “personalizable,” dashboard-style view of the apps that a user has access to and workflows they’re involved in.
Grasp the essentials of design thinking: The biggest change to come with Fiori is the approach to requirements gathering and gap analysis that is possible in SAP Fiori development. It was, and unfortunately still is, common for developers to approach requirements gathering too narrowly, focusing on the immediate pain points that are easiest to define.
Configuration before extension before customization: Once you do get to the phase of the design thinking process where you are building your application, avoid the next most common pitfall of SAP development: unnecessary customization. There are a large number of Fiori apps that cover a wide array of processes and reporting needs.
Get up to speed on SAP Fiori development technologies: For SAP Fiori development, it’s important to become proficient in browser-based development and JavaScript debugging as well as the Gateway and HANA debugging features, to be able to track down problems quickly.
Understand implications of system landscape decisions: Because the Fiori Launchpad exposes services and apps from multiple systems and exposes them all in a single browser-based UI, it can be very sensitive to system landscape decisions.
Fiori 2.0 and the future of SAP Fiori development: Fiori is under active development, so current work should take into account upcoming Fiori 2.0 features, such as overview pages, object pages and enhancements to the Launchpad. It’s possible that extensions or custom app development can be avoided by waiting for an upcoming release, so keep an eye on SAP’s Fiori roadmap.
For More info: