Tag: speed to market

  • 3 Reasons Why Traceability Should Be a DevOps Priority

    3 Reasons Why Traceability Should Be a DevOps Priority

    Traceability in DevOps is about ensuring clarity, accountability and the best possible end product for customers

    There’s a lot to think about when it comes to mobile DevOps. For a start, there’s the need for effective cooperation between members of different teams, perhaps even via team collaboration software for remote workers. With so many people working on DevOps, it’s easy for some to become siloed from their colleagues, hampering communication and undermining teamwork.

    Then there’s the wider question of DevOps strategy—deciding on a vision, setting goals and working out how to measure your success (or otherwise, as the case may be). One thing that has to be central to your strategy is traceability. You may have come across the term a few times before. It’s commonly used elsewhere in the business world, especially with regard to supply chains. Basically, what it means is keeping track of a commodity or product at every stage of the production process.

    Records of the product’s entire manufacturing and distribution history are kept so that the sources of any problems can later be determined and dealt with. Traceability thereby ensures that suppliers can act quickly and decisively in the event of a product recall, for example.

    Another advantage of traceability is that it provides additional transparency, which helps to maintain consumer confidence. As consumers are becoming increasingly aware of how products are sourced and manufactured, this is now an important consideration. It reassures consumers that manufacturers and suppliers are aware of their concerns and that they’re looking out for their best interests.

    traceability

    You can see already, then, how much of this also applies to mobile DevOps. Traceability in DevOps is about ensuring clarity, accountability and the best possible end product for the consumer. But it’s especially important in DevOps because speed is of the essence—there’s constant pressure to get apps developed, into the hands of users and then incorporate feedback as soon as possible. It goes without saying that this can lead to oversights and slip-ups that might otherwise be avoided.

    In addition, DevOps teams have sought to accelerate this process by allowing for greater decentralization and autonomy among their teams. The logic behind this is that it allows for quicker delivery and deployment. Screenshare solutions and other such technological fixes can help to facilitate closer collaboration. However, this easing of control can nevertheless create some potential for confusion in the development process. That may make it more difficult to maintain consistent coordination between developers and testers, and so on.

    Here we’ll list three of the key reasons why traceability should be a leading DevOps priority. All are based on the experiences of development teams and the challenges they’ve encountered.

    Cutting Down on Defects

    As we’ve already discussed, the pressures for faster software rollout and feedback can make it more likely for certain bugs to not be addressed as quickly or as effectively as might otherwise be the case. We’ve noted further that buggy apps can do a lot of damage to companies’ reputations by providing a shoddy and unreliable user experience.

    This can have serious repercussions—after all, word travels fast, especially on social media. It’s therefore in your interests to take whatever steps you can to make sure your software runs as smoothly and reliably as possible.

    Experience strongly suggests that the more rigorous your traceability processes are, the less prone to faults your apps will be. The completeness of your captured traceability information makes all the difference here.

    So, for example, EMR software developers will get great value out of more complete traceability info, as it will contribute to reducing the likely defect rate. This correlation between detailed traceability and defect rate can help to produce more reliable apps and improve efficiency by cutting out avoidable errors and bugs. You should actively solicit feedback from users where appropriate, and integrate this into your wider customer support package.

    Ensuring Compliance

    In other industries, thorough traceability is often a requirement set by regulatory bodies. This can be so that, in the event of a product needing to be recalled, the entire supply chain can be re-examined and the cause of the problem discovered. For example, food and feed businesses operating in the EU have been subject to compulsory traceability requirements since the General Food Law came into force in 2002. Similarly in DevOps, developers have to take regulatory compliance into account.

    Thus, robust and detailed traceability helps DevOps firms working across a variety of sectors in their efforts to comply. There are numerous industries where this is relevant, whether it be financial services (a well-known regulatory minefield), HR software, insurance or public sector contractors and healthcare firms, any of which may be subject to stringent traceability requirements.

    Tracing code is a common prerequisite insisted upon as part of compliance frameworks. For example, you won’t be able to complete the SOC 2 process integrity requirement unless you’re able to provide a complete, evidenced account for each code alteration in your application’s source code.

    Improving Speed Without Sacrificing Quality

    We’ve already discussed how there’s a delicate balancing act that needs to be struck in DevOps. That’s the balance between software rollout speed and the reliability of its performance. We’ve also noted how the increasing autonomy of different sections can hamper coordination between them; thus providing some benefits in terms of speed and rollout but often at the cost of the reliability and quality of the end product. The key here, then, is to find a way of threading the needle, ensuring that apps can be produced at a consistently quick rate while maintaining rigorous standards.

    This is where traceability comes in. It helps to not just enhance speed but also drive up standards. It allows developers to execute tasks more quickly while simultaneously improving the standard to which they do so.

    This also has a positive effect on overall efficiency levels, freeing up resources (i.e. members of the team) to take on other tasks for which they might be needed. Engineers working on contact center software, for instance, can benefit from better-maintained code by reusing or altering existing code depending on their needs.

    It’s worth noting again here that requirement-to-code traceability may be mandatory from a regulatory standpoint. It will depend on the industry in which you’re working. But even if it isn’t, it’s something that’s still worth doing. It can lead to dramatic improvements across the board, leaving as its legacy sharpened and more efficient processes that enhance your team performance, benefits clients and consumers, and—most importantly—deliver real gains for your bottom line.

    Having taken all this into consideration, then, you’ll need to think about exactly how to implement DevOps traceability. Certainly, when introducing traceability processes, you must do so with real care and consideration. Being too rash about implementation can either create bottlenecks, thus exacerbating or even causing problems which traceability otherwise ought to help resolve, and slowing down the overall speed of production.

    Make sure, then, that traceability is implemented in a way that takes the needs of developers seriously. To start with, draw up a guideline document offering developers a clear and concise explanation of what’s expected of them. Outline the traceability process and how it ties in with key objectives. Furthermore, give developers some autonomy in the choice of tools they use for traceability purposes. You might, for instance, make astute use of automation (such as automatic code checks, for example). This should help everyone reap the rewards of traceability and avoid any unnecessary implementation hiccups.

  • The 4 Keys to Effective Continuous Testing

    The 4 Keys to Effective Continuous Testing

    In the digital era, products no longer can win on capabilities alone. Speed to market and buyer experience now matter just as much to customers as the extent to which a product meets a pressing need or outperforms competitive offerings. Against this backdrop, software developers find themselves under increasing pressure, left with no choice but to develop apps that provide everything customers want, are delivered on time and are continuously updated, all while ensuring a user experience that’s never short of flawless. There’s simply no margin for error, and that’s why more developers than ever are turning to continuous testing.

    Unlike the traditional approach of testing performed at the end of the development cycle, where it can potentially cause production delays should issues or bugs be uncovered, continuous testing involves running tests throughout the entire software development process. That enables developers to identify and resolve existing issues immediately—and, more importantly, deliver continuously updated and always flawless applications to their customers.

    Fundamentally changing something you’ve always done a certain way is never easy, however, and continuous testing is no exception. There’s no single lever to pull, but rather a series of steps and best practices necessary to effectively implement it within your development team. Let’s walk through the four most critical of those best practices.

    Make a Cultural Commitment to Collaboration and Quality

    As with any transformational change, people come before processes and developing the right mindset comes before developing the right tactics. Effective continuous testing requires a teamwide, cultural commitment to collaboration and quality. The notion that developers own development and QA owns testing inevitably leads to the types of problems—namely, delayed releases and flawed user experiences—that businesses simply can’t afford in the digital era. Instead, developers and test engineers must have a mutual understanding of the baseline level of quality and efficiency they collectively intend to maintain throughout the development process and a shared understanding that testing is everyone’s responsibility.

    Apply a Broad Range of Tests, Anchored by Automation

    As mentioned earlier, continuous testing isn’t about pulling any single lever, but rather about applying a broad range of tests throughout the testing process, including unit testing, integration testing, automated end-to-end and regression testing and production testing. By continuously administering tests at various points throughout the delivery pipeline, you can identify and fix issues spanning functionality, performance and security, and do so before they morph into the kind of roadblocks that delay your release and cost your business money.

    Though you should strive for variety when it comes to the types of tests you implement, you should strive for consistency when it comes to the concept of automation. If you’re serious about succeeding with continuous testing, automation is a necessity. Automated testing, which involves writing a test script (typically in Selenium or Appium) that interacts with the functional elements on a web page without requiring human intervention, not only helps you deliver better scalability and reliability than manual testing, but it also frees your manual testers to focus on more value-add activities such as exploratory testing.

    Leverage Cloud for Breadth and Scalability

    Just setting up and maintaining the infrastructure, physical or virtual, necessary to test across the ever-expanding universe of browsers, operating systems and mobile platforms is both costly and complex. And that’s before you consider the need to scale your test environment to run tests in parallel. It’s a daunting challenge for even the most mature enterprise development team.

    Enter cloud. In many ways, continuous testing and the cloud were made for each other. By leveraging a cloud-based, cross-browser testing platform, development teams can offload all the infrastructure-related headaches they’d otherwise be forced to grapple with on a daily basis, test across virtually any browser/OS combination (leveraging both real devices and cloud-based simulators and emulators) and ensure they have the scale necessary to keep their test times to a minimum.

    Develop a Strategic Approach to Analytics

    Continuous testing, applied optimally, requires a strategic approach to analytics. Developers should actively look to integrate a layer of analytics within the testing process, such that insights can be applied across the product team. Smartly layered analytics can shed light on a number of functional issues, including which browsers and mobile platforms are most often experiencing failure and whether an application’s test results are consistent.

    Beyond just functional testing, teams also can leverage analytics to assess user experience and performance, examining, for example, how the user experience is impacted by heavier traffic loads and how overall application performance is impacted by new updates to the code. Having this added layer of analytic insight enables developers to better understand the entire quality picture and deliver improvements that can be applied both in real-time and to future tests.

    The Digital Age Demands Continuous Testing

    In the digital age, your ability to attract and retain customers is directly tied to your ability to build the best products, deliver them faster than your competitors and keep them continuously updated with all the latest features and function—and do it all within the context of an impeccable digital experience. It’s a tall order, but it’s one made considerably less daunting by the effective application of continuous testing.

    — Lubos Parobek