Conservative Innovation: How to Modernize Your Development Organization Without Introducing Risk

Even risk-averse companies must evolve their development and testing methodologies to stay competitive.

Risk Aversion Can Hamper Innovation

To keep pace with marketplace demands, many organizations are seeking to rapidly release software to market. They are evolving their software development lifecycle by adopting agile methodologies to enable continuous software development and delivery. Yet some organizations are slow to embrace new methods, and fear of releasing low-quality software hampers their innovation.

Contrary to popular belief, it is possible to innovate software development and delivery processes while minimizing risk. Incorporating quality assurance (QA) and testing throughout the development lifecycle is a great place to start.

Embrace Continuous Testing and Integration

No matter what development method an organization adopts, testing may always be seen as a bottleneck. That’s because testing is usually perceived as less important than developing code. As a result, it’s traditionally given the shortest window in the software development timeline, which puts testers in a time crunch to find and address any quality or security issues.

Continuous integration and continuous delivery (CICD) is a newer approach that helps avert this issue. It can help expose bugs earlier, when they are easier to fix, by allowing QA to test code while developers are still writing it. In other words, CICD enables testing to occur earlier and expands the testing timeline, giving QA more opportunities to identify and address risks before a release.

In some cases, tests can run automatically overnight or during the day while testers are manually performing other tests. With automated functional unit testing, the test team can test each element –or functional unit – in development. This isn’t possible to do manually; it would be like testing a few lines of code at a time. With functional unit testing, testers can more easily identify individual units that don’t work as expected. Testing code in pieces as it is developed instills testers with more confidence once they test the complete application.

CICD also enables organizations to quickly respond to customer demands and market changes. That’s because it takes less time and effort to update, test and release smaller functional software units than a single, complex application.

It’s worth noting that not all organizations are set up to support this model. CICD hinges on a collaborative approach between development and testing.

Control the Test Environment

Risk-averse organizations can establish another safety net by incorporating traceability into the quality assurance (QA) process. Traceability allows testers to see the association between each test case and the application requirements. This direct line of sight helps testers more easily validate requirements, and identify and isolate the areas of the application that do not meet them. Testers can then further test these risk-prone areas, provide their feedback to development and focus on testing these requirements earlier in the next development phase.

Another way organizations can minimize risk is by only allowing access to code as needed. They can do so by allocating permissions and tasks according to user role and responsibility. For instance, testers should have read-only versus full access to requirements. This mitigates the risk of someone changing a requirement by mistake.

A large, risk-averse software gaming company recently contacted QASymphony to discuss shifting to an agile approach. The organization introduced the application lifecycle management tool Jira along with a test case management tool to better align developers and testers. To enforce data security, the team established user-based permissions to projects, data and tools. With these measures in place, the organization ensured that only authorized users could access the system, and that each user only saw testing data that was relevant to them.

Get DevOps Right

Some organizations are embracing DevOps for more efficient, faster software development and deployment. This is a step toward upgrading their development methodologies without introducing risk. However, to realize this benefit, companies must get the definition of DevOps right.

Collaboration between groups is the key to reducing risk with DevOps. To that end, organizations need to think about DevOps as a mindset rather than as a development role or methodology. When viewed this way, it is easier to grasp the need to incorporate security processes and tools into DevOps. As the organization develops and deploys code, it can perform security checks and manage change control in a low-risk manner.

As John Balena explained, ͞Real DevOps transformation doesn’t mean that you give everyone new jobs, instead, it’s about creating an environment where teams can collaborate together with a common language and where information is immediately available at the point of execution and in a context unique to each team…the goal is…to take the discrete silos of people, tools, information and automation, and create a continuous delivery environment through facilitated collaboration and communication. This will drive the cultural and operational transformation necessary to enable IT to respond to business needs with agility while ensuring operational stability and quality.”

To date, developers, business analysts and testers have operated independently. Developers and business analysts can share issue tracking software, while testers usually call upon their own tools. This disconnect introduces risk to the feedback loop in a DevOps environment. The solution is to automate communication and integration between these tools.

Address Security in the IT Architecture

As they embrace a DevOps mindset, organizations should not forget that Operations is part of the DevOps equation. Software code runs on servers in the operating environment. That means organizations need to deploy the right infrastructure to keep their code secure. According to McKinsey partners, it starts by defining the network perimeter and what is and isn’t exposed to the public cloud. The main goal is to limit the attack surface by, once again, only allowing authorized access as needed.

Manage Vendors and Tools

Some organizations incorporate third-party tools to develop their cloud-based applications. As a result, they must prioritize vendor management since third parties are managing their application-related security. It’s essential to ensure these vendors are applying stringent security measures. At the same time, organizations need to ensure close collaboration with the partners in their software ecosystem.

Assume an organization’s software is compatible with a certain third-party application. That partner could release a new software version that renders the compatibility obsolete. In such cases, the organization must scramble to upgrade its software. It’s better if the partner notifies the organization before any changes. This enables the software vendor to keep pace with its partner’s development roadmap.

Give Forethought to Security

Even Microsoft once treated software security as an afterthought. In 2001, the Code Red worm was the first major exploit of Microsoft’s software. Other exploits soon followed, prompting the software giant to shut down and then re-launch Windows development under the new Microsoft Security Development Lifecycle (SDL) framework. Microsoft still uses SDL, which prioritizes security over features. Since then, Microsoft has evolved SDL to integrate critical security practices into the agile methodology. One of the the world’s largest software companies found a way to balance innovation and risk management. Smaller organizations can follow suit by modernizing their software development lifecycle while prioritizing software quality and ensuring the proper security controls are in place.

Continue Reading

We just need a little info from you.

More Great Content