Tag: continuous testing

  • Mabl Adds Beta of Desktop Continuous Testing Tool

    Mabl Adds Beta of Desktop Continuous Testing Tool

    Mabl today announced availability of a beta version of a desktop tool for creating tests that can be applied to browsers and application programming interfaces (APIs) using a low-code tool.

    Dan Belcher, co-founder of Mabl, said the goal is to make it simpler to streamline testing processes as responsibility for application quality assurance (QA) continues to shift left within the context of a DevOps workflow.

    Mabl provides a low-code tool for testing desktop and mobile browser applications, alongside the APIs they invoke, using an Electron tool that generates tests in a way that eliminates the need to write scripts. Previously available only via a software-as-a-service (SaaS) platform, Belcher said the desktop platform will make it simpler for developers to test code as they develop it on a local machine.

    Developers using the desktop tool can now also manage and run tests instantly via command line interface, versus having to completely exit from a project to invoke a separate testing tool, Belcher said.

    The Mabl testing tools are already integrated with multiple continuous integration/continuous delivery (CI/CD) platforms, such as Bitbucket and Bamboo, as well as the GitHub repository.

    In the longer term, Belcher said it is clear organizations will need to involve more developers in QA testing, as the rate at which applications are being built and deployed continues to increase. Testing teams, on their own, can no longer keep pace with the rate of change, Belcher noted.

    The challenge is achieving that goal in a way that creates the least amount of friction possible, Belcher added. The Mabl platform and desktop application make it feasible for developers to test both web and mobile applications without taking too much time away from developing application code, said Belcher.

    Testing has become a major DevOps issue because, as developers assume more responsibility for applications after they have been deployed in a production environment, they naturally want to vet applications more thoroughly. Issues that arise after an application is deployed simply result in less time available to write new code. There will always be issues that need to be addressed, but the more of them that are resolved as part of a QA process integrated within a DevOps workflow, the more productive an application development team will be.

    Unfortunately, testing is often given short shrift; it primarily occurs at the back end of the application development life cycle. Developers are typically behind schedule, so there is a natural tendency to reduce the amount of time allocated to testing in the hope of making an application delivery deadline. The vicious cycle that ensues is that, inevitably, there are more bugs to fix after an application has been deployed, simply because not enough testing was done during the original development cycle.

    Of course, some development teams have become conditioned to fixing bugs as part of an agile development process that, too often, encourages them to push known issues off to the next sprint. The trouble is, in the absence of continuous testing, it’s not long before all those known bugs start to pile up. It’s not uncommon for applications to be riddled with bugs that development teams – with mixed success – attempt to address all at once. The earlier those issues are addressed, the less stress there will be later for all concerned.

  • DevSecOps May Be Key to Prevent Data Leaks

    DevSecOps May Be Key to Prevent Data Leaks

    Data leakage has become something of a norm in the digital realm, despite the fact that cybersecurity budgets are growing and more engineers are assigned to these very issues. Nowhere does this seem more true than in the realm of health care, where breaches that expose sensitive patient data are, sadly, a fairly common occurrence. 

    A recent report by Approov illustrates how severe the problem has become. According to Approov’s  All That We Let In research report, many of the mobile healthcare applications in use today are leaking sensitive patient data through APIs, potentially compromising millions of patients. 

    The study tested 30 popular mobile health (mHealth) apps, and the research estimates that some 23 million mHealth users are exposed, at a minimum. The average number of downloads for each app tested was 772,619. Analysts expect that the total number of users exposed by the 318,000 mHealth apps now available on major app stores is likely far greater. Among vulnerabilities detailed in the report:

    • 50% of the records accessed contained names, Social Security numbers, addresses, birthdates, allergies, medications and other sensitive data for patients.
    • 50% of the APIs tested allowed users (medical professionals) to access the pathology, x-rays and clinical results of other patients.
    • 50% of the APIs tested did not authenticate requests with tokens.
    • Of the 30 popular apps tested, 77% contained hardcoded API keys, some of which don’t expire, and 7% contained hardcoded usernames and passwords. Seven percent of the API keys belonged to third-party payment processors that warn against hard-coding their secret keys in plain text.

    “Look, let’s point out the pink elephant out in the room,” said Alissa Knight, researcher and author of the report. “There will always be vulnerabilities in code, so long as humans are writing it. Humans are fallible. But, I didn’t expect to find every app I tested would have hard-coded keys and tokens, and all of the APIs to be vulnerable to broken object-level authorization (BOLA) vulnerabilities allowing me to access patient reports, X-rays, pathology reports and full PHI records in their database. The problem is clearly systemic.”

    The report helps to illustrate a critical point: Sloppy code can lead to data leakage. “These findings are disappointing, but not at all surprising. The fact is, leading developers and their corporate and organizational customers consistently fail to recognize that APIs servicing remote clients, such as mobile apps, need a new and dedicated security paradigm,” said Approov founder and CEO David Stewart. “Because so few organizations deploy protections for APIs – that ensure only genuine mobile app instances can connect to backend servers – these APIs are an open door for threat actors, and present a real nightmare for vulnerable organizations and their patients.” 

    For organizations deploying apps using a DevOps methodology, it becomes very clear that much more must be done on the cybersecurity side to prevent data leakage. However, the general consensus is that data protection falls under the purview of CISOs and cybersecurity teams in the enterprise. Perhaps there is no better argument for adopting DevSecOps than the data leakage problems caused by insecure code and sloppy APIs. The report echoes that sentiment and offers several recommendations for developers creating and organizations using mobile applications. In other words, organizations should take several key steps to protect their customer data and sensitive resources, including:

    •  Address both app security and API security: Recognize that synthetic traffic to the API is an issue, and arises from bots and automated tools, not from genuine apps and legitimate data requests.
    • Shift left and shield right: Secure the development process and harden apps, but ensure that runtime protection is also in place.
    • Protect against X-in the middle attacks: Certificate pinning is critical, but often left undone because expired certificates can block apps and impact customer experience. However, when done correctly, certificate pinning does not impact either performance or availability.
    • Improve visibility into controls: Organizations and developers need to monitor the effectiveness of the controls they implement and adjust them easily – both for compliance with legislative mandates and to sustain data security and privacy.
    • Continuous testing: Penetration testing and static and dynamic code analysis should be performed regularly.

    Interestingly, those recommendations fit squarely into the role that DevSecOps should take in the DevOps process. 

  • Sauce Labs Acquires AutonomIQ to Advance App Testing

    Sauce Labs Acquires AutonomIQ to Advance App Testing

    Sauce Labs is acquiring AutonomIQ, a provider of a scriptless test automation platform based on machine learning (ML) algorithms.

    Matt Wyman, chief product officer for Sauce Labs, said the acquisition of AutonomIQ will play a critical role in enabling Sauce Labs to push testing further left toward developers and, ultimately, “citizen testers” that are becoming part of the DevOps testing tool chain.

    The acquisition of AutonomIQ comes on the heels of the company announcing its intent to acquire API Fortress, an application programming interface (API) testing platform provider. Terms of neither acquisition were disclosed.

    Wyman said the rise of DevOps coupled with an increase in the volume of applications being developed using low-code tools are the primary drivers of a need to shift testing further left. As more citizen developers are building applications, they require access to a testing platform that doesn’t require them to know how to write scripts to test applications, said Wyman.

    The AutonomIQ platform employs machine learning to understand, for example, natural language descriptions of test cases or captured mouse clicks. It then generates synthetic data and test cases that can self-heal when an application changes, said Wyman.

    That approach to testing is more feasible in software-as-a-service (SaaS) environments, where a custom application based on a platform such as Salesforce, ServiceNow, Workday, Oracle or SAP doesn’t tend to change as radically as an application being built from the ground up, Wyman said. Those classes of applications will still require either developers or a dedicated team of testers to build tests using scripts, said Wyman.

    In fact, Wyman said testing those applications is becoming more challenging in the age of microservices. The API Fortress acquisition addresses that issue, because microservices are dependent on APIs to communicate with other microservices, said Wyman. In general, Wyman said Sauce Labs is now moving beyond being focusing only on functional testing of user interfaces.

    It remains to be seen how quickly testing will move to the left. Developers are being held more accountable for the quality of their applications, so testing integration within the application development process has increased. This has led to application testing becoming more tightly integrated with continuous integration/continuous delivery (CI/CD) platforms. Less clear is to what degree those efforts might have reduced the burdens of a dedicated application testing team that typically evaluates applications after they have been constructed.

    Exactly where and how citizen testers are being incorporated into those processes is also unclear. In theory, citizen testers can bring more business process expertise to the testing process. Getting individuals with that level of expertise to make time to participate in application testing while an application is being built can be a challenge.

    Regardless of approach, however, it is already apparent that machine learning algorithms, along with other forms of artificial intelligence (AI), will play a much larger role in application testing in the coming months and years.

  • Continuous Testing: Complementary to Agile and DevOps

    Continuous Testing: Complementary to Agile and DevOps

    Digital transformation brought about by quality software applications and robust hardware platforms helps to create a competitive advantage for enterprises across verticals and geographies. Now it is no longer about choosing between speed or quality of software but to incorporate both when delivering to customers. With Agile and DevOps being embraced by enterprises to stay up to speed on the competitive curve, continuous integration (CI), continuous delivery (CD) and continuous testing (CT) have become the catalysts driving quality digital transformation.

    It goes without saying that continuous testing has become critical and is challenging. CI and CD are primarily tools and team-driven activities, while CT is comprehensive in its scope, including teams, tools, testers and services. The importance of driving and integrating code changes cannot be ignored in the software delivery life cycle. At the same time, unless the automated delivery system can figure out the impact of such code changes on customer experience, CI and CD could become meaningless.

    Rising competition and changing market dynamics have put pressure on enterprises to innovate and change. Agile and DevOps in consonance with continuous testing offer the framework to address the requirement. At the heart of digital transformation lies the need to deliver software quickly, safely and reliably, which can be achieved through continuous testing in DevOps.

    Why Continuous Testing?

    Customers today use software applications across a plethora of devices, operating platforms, browsers and networks. They want the applications to be high-performing, navigable, scalable, secure, intuitive and fast-loading. These attributes can only be fostered if the software development process supports a robust QA mechanism in the Agile or DevOps mold. Unlike in the traditional or manual way of testing, where QA comes after development as a separate discipline, the Agile and DevOps models have QA as part of an integrated team with development.

    In Agile testing, the software is tested for performance, security, usability, scalability and more throughout the various stages of development. Thus, glitches are identified and fixed early in the SDLC, leading to the delivery of quality software. A continuous testing strategy enables enterprises to put in place the processes, systems and automation to accelerate the time to market, install improved feedback loops and deliver desirable business outcomes including high-quality products and services, operational efficiency, responsiveness, competitive differentiation and enhanced customer experience.

    Continuous testing services create a quick and risk-free feedback loop for the QA specialists in the Agile testing pipeline to understand (and act upon) the issues faced by the end customers. These services help to manage business risks borne out of the complexity and pace of application delivery.

    Why Agile and DevOps?

    To thrive in a competitive business environment, enterprises must address issues such as time constraints and resource mobilization to build-test-deliver applications that are higher quality, secure and stable. This engenders a renewed focus on continuous test automation and collaboration.

    • The DevOps approach is ideal for enterprises that struggle to manage demand and implement rapid changes in the SDLC.
    • DevOps allows enterprises to address their acceleration and integration needs by establishing a toolchain that cuts across the realms of development, QA, integration, management and delivery.
    • The silo-driven development and operations teams should be integrated to drive better collaboration. Further, the pipeline should have a built-in mechanism to receive continuous feedback and to generate better quality features and functionalities.

    DevOps: The Extension of Agile

    In the Agile model of software development, developers create user stories comprising smaller chunks of the build to generate feedback loops and to align the product to the market need. It started with small teams comprising developers and QA testers working collaboratively and efficiently. Thereafter came the notion of scale, wherein the software code was developed in short iterations. However, down the pipeline, when it came to deployment and receiving feedback, the silo-driven processes stifled what was expected of Agile.

    Consequently, the process was further refined by automating and streamlining the SDLC and incorporating continuous integration. In CI, code is tested repeatedly and integrated to create a stream of small but frequent releases. However, these challenged the Ops team, which found it difficult to keep pace with development. So, while Agile addressed the issues developers faced with glitches being passed on to the next phase, the DevOps approach turned out to be more effective, as it treated the entire SDLC as a monolith of collaborative processes that generate better outcomes.

    Continuous Delivery and Testing

    To support the strategic business needs, many enterprises have graduated from performing CI to implementing CD. In doing so, they have fine-tuned both processes and technical frameworks. From creating CI builds and executing testing to achieving deployment, the continuous delivery and continuous testing methodologies have covered all dimensions of the organization’s operations. These ensure the quick and frequent deployment of quality software applications to end users. The questions to be asked while implementing a continuous testing framework are:

    • Is the software application deployable during its life cycle?
    • Can the software application be deployed while the team is working on its new features?
    • Can the process receive quick and automated feedback each time a change is implemented?
    • Can a push-button deployment be performed for a software version in any environment?

    How Agile, DevOps and Continuous Testing Benefit Enterprises

    These interconnected methodologies help enterprises in several ways:

    • Accelerated time to market.
    • Better productivity and efficiency.
    • Frequent releases of reliable and stable builds.
    • Capability to build products aligned to the market.
    • Better feedback mechanism.
    • Superior customer experiences.

    Conclusion

    The need for enterprises to be the disrupter in the market by producing or delivering top-quality software products or services has put focus on methodologies such as Agile, DevOps and continuous testing. The complementary relationship among the three methodologies has led to the overhauling of processes and working culture in favor of a new paradigm in which quality deployment is a continuous process.

  • SAP Aligns With Tricentis on Continuous Testing

    SAP Aligns With Tricentis on Continuous Testing

    Tricentis this week announced an alliance with SAP under which a continuous testing platform that employs machine learning algorithms is being incorporated into the SAP Application Lifecycle Management (ALM) portfolio.

    Jonathan Boswell, director of strategic content for SAP and packaged applications for Tricentis, said via this initiative SAP customers will be able to take advantage of a testing platform infused with machine learning algorithms to accelerate the rate at which they upgrade to the latest editions of SAP applications.

    Many of SAP’s customers still run older versions of its software, much of which has been customized. Those customizations make it difficult to migrate to the latest version of SAP applications because in many cases SAP has extended the range of functions provided with SAP applications, thereby eliminating the need for those customizations.

    The Tricentis tools enables IT teams to map existing custom functions to the standard capabilities that SAP provides now under a so-called Model Company initiative. Tricentis identifies the aspects of an upgrade that are likely to have the most risk to the business and surfaces issues involving integrations between SAP and third-party applications. Tricentis automates 90% of tests to help ensure the entire chain is tested, in addition to employing load testing to optimize SAP application user experience, added Boswell.

    While many organizations employ SAP applications extensively, many of them are struggling with upgrades. In an ideal world, more organizations would take advantage of the latest packaged SAP application features to drive digital business transformation initiatives. Right now, however, it can take organizations months to perform an impact analysis on the SAP upgrade process, he said.

    Tricentis shortens that time by employing machine learning algorithms to discover the difference between two application environments versus relying on legacy approaches based on testing scripts, said Boswell.

    Ultimately, he noted, the goal is to enable more organizations to focus more on business processes rather than application quality assurance.

    It’s not clear to what degree IT organizations will continue to customize SAP applications. SAP now provides a separate cloud platform that it encourages organizations to employ to build custom applications that extend SAP applications without ever having to touch SAP application code. Getting SAP customers to make that transition has become much more of a journey for many customers than SAP originally anticipated. However, as best DevOps practices continue to be adopted by SAP, the rate at which custom functions are built should accelerate. The challenge is creating and deploying those customizations in a way that doesn’t impede a SAP packaged application update cycle that happens every quarter.

    Regardless of the path forward, machine learning algorithms and other forms of AI are positioned to play a major role in application testing. They may never replace the need for human testers, but the days when business users needed to be recruited to help test every low-level function in an application may finally be coming to a merciful end.

  • Debunking Five Common Automated Testing Myths

    Debunking Five Common Automated Testing Myths

    There is little argument that automated testing has emerged as an industry best practice. Yet, there remains a wide variety of adoption and maturity in the market. While automated testing is imperative for DevOps maturity and success, I see in my work several popular canards that often stand in the way.

    Reject these five common myths within your organization to improve your testing maturity and propel your DevOps objectives. 

    Myth One: We Don’t Have the Time to Slow Down and Add Automation

    You don’t have the time not to add automation. Your competitors are most likely already automating their test processes, and are reaping the benefits from it. For example, companies like Amazon and Netflix have instituted end-to-end automation that allows them to push builds to production in record time. Organizations like this have become juggernauts as they are able to quickly address customer expectations with new software and services at the speed of the market.

    While Amazon and Netflix are obviously examples of extreme automation, moving down the path to automated tests will begin the process of adding distinct benefits to the organization. Benefits that will grow key business goals like reducing time to market, and growing quality that ensures customer satisfaction. For example, automated testing brings with it higher accuracy rates, greater code coverage, enhanced detection of bugs and greater reusability.

    Myth Two: Automated Testing Is Too Difficult and Frankly, Just Not Worth It

    Automated testing is worth the investment. Much like insurance, the added time and expense to begin integrating automated testing into your processes are necessary trade-offs to reduce business risk. Automated testing helps reduce failures, avoiding all-hands-on-deck type emergencies—and, honestly, at 5 p.m. on a Friday, wouldn’t you rather not fight a four-alarm blaze? That said, automated testing should not be a singularly focused QA effort. Good quality efforts really should be organization-wide initiatives.

    Automated testing is less difficult than trying to engineer quality at the tail end of anything. If you do not have any test automation in place today, consider starting with an assessment. Identify areas where automated testing is needed and begin addressing those gaps in a prioritized manner. While your ultimate goal may be to automate every gap on the list, start small, take steady steps towards your goal and be sure to celebrate early wins. A parallel approach enterprises take when getting started is to build automation into greenfield projects, which gives them automated tests out of the gate.

    Myth Three: We Have to Hire a Specialized Person

    I think the Washington Post would give this claim four Pinocchios as it is blatantly untrue. Anyone on your team can learn the needed skills to start down the path to automated testing. And, honestly, learning and growing in your field is an important skill in-and-of-itself as new trends, technologies and tools emerge on a seemingly daily basis. Learning how to add automation to the testing process can help create a virtuous cycle, too, where you will see dividends paid back in time savings from the time you took to learn these key skills. And, the faster feedback loops will make you and your peers more efficient and effective.

    Some may counter-argue that there are specialty testing types such as PCI testing, for example. And, that a specialist is needed for these. Yes, many teams have special circumstances that require special tests. However, don’t let this myth be an artificial roadblock here, either. For, there are many automated tools on the market that will help ensure success with these special cases. Moreover, many of these tools are platform-agnostic, making for easy adoption.

    Myth Four: We Have to Automate Everything

    This all or nothing viewpoint is just not true as it is not possible to automate everything. While I would encourage some tests, such as unit tests, to have a test for every line of code, other tests like front-end tests would be particularly challenging to automate. The greater the organization’s maturity, the more nuanced their view of when and what to automate. Conversely, an “automate everything” approach is a sign of a less mature enterprise.

    On one hand, I see organizations that have completely automated unit testing and have developed a tailored approach for front-end and performance testing. On the other hand, I see organizations with little to no automation where software is rushed out the door and dev is not given any time to develop unit tests. In these cases, software sent to the market is not fully tested—and while rare, sometimes it’s not tested at all.

    Bad code is risky to a company’s customer satisfaction, reputation and customer loyalty. Going back to test code once it has shipped is a multi-fold lift compared to doing it as an automated part of the development process. Automation also makes it easier to make improvements to existing features in your software or infrastructure. When you have automated tests in place (especially unit tests), you drastically reduce the amount of time refactoring and enhancing takes.

    Myth Five: Continuous and Automated Testing Are Synonymous and We Don’t Have the Resources for Continuous Testing

    While continuous testing and automated testing are related, they certainly are not the same thing. You can’t obtain continuous testing without the help of automation. However, you can have automated testing without continuous testing. On the spectrum of testing maturity, continuous testing is certainly at the far end as it requires DevOps processes, pipelines and automated reporting as prerequisites. If your organization isn’t at this level of maturity yet, that is OK. Start small and work your way toward continuous testing as a gold standard. For example, consider running unit tests with each new build, implementing a fast feedback loop to development several times a day.

    According to a survey by QASymphony and TechWell of testers and QA leaders at mid-size and large enterprises, “widespread test automation adoption still has a way to go, with more than three-quarters of respondents automating less than 50% of their testing.” Yet, it’s important for organizations to speed their processes in order to stay competitive in a quickly evolving marketplace. Dispel these myths within your organization to begin competing more effectively as you progress your automated testing maturity.

    — Elysia Lock

  • Shift-Right Testing: The Emergence of TestOps

    Shift-Right Testing: The Emergence of TestOps

    The concept of shift-left has been a popular trend in continuous testing practices for a while. We are now beginning to see shift-right practices as an emergent trend in testing. 

    Shift-right entails doing more testing in the immediate pre-release and post-release phases (i.e. testing in production) of the application lifecycle. These include practices such as: release validation, destructive/chaos testing, A/B and canary testing, CX-based testing (e.g. correlating user behavior with test requirements), crowd testing, production monitoring, extraction of test insights from production data, etc. 

    Shift-right not only introduces such new testing techniques, but also requires testers to acquire new skills, make aggressive use of production data to drive testing strategies and collaborate with new stakeholders, such as site reliability engineers (SRE) and operations engineers. 

    In shift-right of testing, and in the increased collaboration with operations disciplines, we see the evolution of a new discipline in DevOps that we call TestOps. 

    In this blog, we will discuss the various shift-right testing trends and practices, what’s driving them, the new skills and collaboration required so that TestOps benefits can be realized. 

    Emerging Trends in Shift-Right Testing 

    In a recent survey of continuous testing conducted jointly by Capgemini and Broadcom, testing in production was ranked as the number one practice (with 45% respondents) either currently implemented or planned (see Figure 1). In addition, 39% of the respondents mentioned the use of analytics from operations to determine or optimize test coverage.

    Figure 1.

    When asked how customers measure the effectiveness of continuous testing processes, production data and user feedback and adoption of new functionality were ranked number one and number two respectively (see Figure 2).

    Figure 2.

    Finally, in response to how customers test their digital applications to ensure that they meet real world requirements, almost all of the responses were related to production data (see Figure 3). Use of production data for designing test strategy and chaos testing emerged as new methods compared to similar survey done a year ago.

    Figure 3.

    The survey data clearly indicates that customers are actively practicing (or considering adoption of) shift-right testing techniques. This report has a chapter (with my contributions) dedicated to shift-right that discusses the techniques and recommendations for its adoption, as well as relevant customer case studies.  

    What’s Driving Shift-Right Testing Trends? 

    The goal of shift-right testing is to ensure correct behavior, performance and availability over the production of an application.

    There are several drivers for adoption of shift-right testing trends.

    Customer Experience (CX) Is a Key Quality Metric for Digital Applications

    Unlike classic testing, this takes into account real-world users and their experiences. An application with perfect traditional quality scores (such as FURPS) may still suffer from poor CX if it fails to delight the customer. CX is measured using various metrics such as Customer Effort Score (CES), Net Promoter Score (NPS), Customer Satisfaction Score (CSAT), etc. While it is possible to shift-left some of these measurements to some degree, most CX measurements are deduced from systems in production (or close to production). Examples of CX-based testing include the following: 

    • Requirements validation based on real user journeys, behavior and feedback.
    • Deriving functional and performance test scenarios based on the above.
    • A/B testing and canary testing, to experiment how well customers like (or dislike) changes. 
    • Crowd testing, to better understand real-world user experience.

    In a World of Agile Delivery, It may Not Be Possible to Test Everything Before Release to Production

    Time to market (or lead time for changes) is a top business imperative for digital applications, which is why QA/testing is considered a major bottleneck in continuous delivery. While it is possible to optimize testing effort and cycle time using shift-left practices (such as model-based testing, change-impact testing, test process and execution automation etc.), those approaches may still take too long (or too much effort) during the shrinking release cycle time. In some cases, the exact usage patterns may not even be fully understood before release. The idea is to learn usage patterns from production and use it for better testing strategy within shift-left. 

    Complex and increasingly distributed systems using microservices (using thousands of components) and cloud-native techniques that allow releases at a very granular level make it more and more difficult to test fully in pre-production environments. This is complemented by the fact that since such releases are so granular, they may be backed out easily (rollback) in case they cause problems.

    Hence, enterprises test to assure “good enough” quality (to ensure timely release) and rely on fast remediation (or rollback) to address defects or problems that arise.

    Also, CX measurements (as described above) often provide real-user feedback in shades of gray, unlike the black-n-white pass/fail measurement of classic testing. Which means it is not possible to perfect pre-production test suites to ensure thorough CX coverage. 

    A Hundred Percent Reliability (or Quality) Is Often an Unrealistic Goal

    Related to the above, one of the key principles we learn from the DevOps discipline of SRE is that 100% reliability is not only unrealistic, but often too expensive to accomplish. SRE establishes the concept of service level objectives (SLOs) and error budgets to quantify acceptable risk tolerance in production systems. The same principle applies to testing and overall quality. See my related blog for more on this subject

    Some Validations Are Difficult to Run in Test Environments

    These include large-scale performance tests when the test environments are not appropriately sized (or configured) relative to production environments. 

    Another example is destructive or chaos testing. While it is possible to run isolated chaos testing in test environments by using techniques such as service virtualization (to simulate failure in dependent components), it is difficult to execute for large-scale destructive tests. For example, Netflix does a significant amount of their testing in production.

    Similarly, enterprise monitoring to gather insight about real-world usage patterns and failures is only possible in production. Though we advocate turning on monitoring in test environments (as part of shift-left), such monitoring only helps to do localized monitoring (e.g. of the specific app or system being tested), and that too under test conditions. However, performance test scenarios that have been developed by testers can be re-used in production (shift-right) as synthetic monitors to measure application performance and regression.   

    Lastly, as an extension of monitoring, testing of some AI-based applications may be difficult without access to production data. Some machine learning algorithms, for example, need to be constantly refined based on real world data. While these algorithms are developed using a limited set of training and testing data, they need to be monitored and tuned, based on its performance in production. 

    Developers and Testers Need Easier Closed-Loop Feedback from Production

    Easier closed-loop feedback from operations allows developers and testers to better understand the behavior of the app, predict the success/failure of releases and respond to production incidents (e.g. reduce MTTR).

    Interpretation and use of voluminous production data is often difficult and tedious for development and test teams. Use of shift-right techniques allows developers and testers to access production data more easily in a form that is easily consumable and actionable–by leveraging the right insights from AIOps disciplines. This data collaboration is a key tenet of the DevOps paradigm. For example, synthetic monitors (which are typically created by developers and testers in the dev/test stages) provide means for developers to get monitoring feedback in a form that they are familiar with. 

    In addition, automated root-cause analysis of defects/incidents in production can provide developers and testers insight on failure patterns and trends, their sources (when production data is correlated with development data) and what’s causing them, and how they may be better prevented. 

    Similarly, data usage scenarios (e.g. from database logs and RR pairs from service transaction logs) can be used for generation of relevant test data.  

    In essence, shift-right testing practices are necessary to create a continuous feedback loop from real user experience with a production application back to the development and testing process. 

    The Evolution of TestOps Discipline

    It is clear from the customer survey data and drivers discussed above that there is an evolution toward shift-right practices. 

    Just like we did with shift-left testing, in order to make these practices sustainable and to realize the benefits, we need to also evolve tester use cases, skills, tools and collaboration patterns with people and disciplines to the right of the application lifecycle, i.e. operations. In other words, a new discipline needs to be established—we call this new discipline TestOps—a sub-discipline within the broader DevOps context. 

    Though the term TestOps (like all the X-Ops sub-disciplines within DevOps) implies the collaboration between testing and operations, it isn’t simply about shift-right. Why? Because with DevOps, operational disciplines themselves have shifted left (such as shift-left of monitoring, configuration management, SRE, etc.). Hence TestOps—true to the principle of continuous testing—refers to better collaboration with operations disciplines across the DevOps lifecycle.  

    Let’s consider some of the key practices in TestOps shift-left (see Figure 4). 

    Figure 4.
    • Early reliability testing: this includes static scalability analysis of the system architecture, as well as performance and stress testing.
    • Configuration quality and testing: this includes testing of “as-code” (anything “as-code” can and should be tested as such, just like application code) environment and deployment configurations, as well as deployment testing (to test the correctness of deployments) and rollback testing (to ensure that rollbacks can be done quickly and successfully).  
    • Early monitoring: includes monitoring of systems early in the lifecycle (e.g. in development and test environments) as well as development and testing of synthetic monitors before they are deployed to production.
    • Early AIOps insights: this includes early use of AIOps techniques (in the dev/test environments) to glean testing and quality insights, for example for defect and release risk prediction.

    Below are some of the key TestOps shift-right practices (see Figure 5).

    • Chaos engineering: this includes testing the reliability of the system through the injection of controlled failure scenarios.
    • A/B testing: consists of a randomized experiment with two (or more) variants to study which are more effective with users.
    • Canary releases: consists of techniques used to reduce the risk of introducing a new software version in production by gradually rolling out the change to a small subgroup of users, before rolling it out to the entire platform/infrastructure and making it available to everybody.
    • Synthetic monitoring: includes monitoring techniques using an emulation or scripted recordings of transactions (that reflect typical user behavior).
    • CX testing and analytics: includes extracting of CX data to understand customer experience as well as to derive insights from it (such as customer problems, new feature requirements, etc.).
    • Other testing in production: includes performance tests and testing of AI-based applications.
    • Testing insights from AIOps data: as described above, a rich variety of testing insights can be gleaned from operations data.
    Figure 5.

    Key TestOps Skills and Tools

    Let’s consider the new skills required for the key TestOps practices. This includes the following: 

    • Data analytics skills: Since most of the production data is both voluminous, diverse and often temporal, testers must now pick up data analytics so that they quickly glean insight from such data, as well as perform correlations with other datasets to identify actions. Advanced analytics skills (such as predictive analytics or machine learning) are also necessary to predict events (e.g. release quality). While these analytics skills are well understood within the operations community (with the increasing adoption of AIOps), these are relatively new for developers and testers. 
    • CX skills: As we discussed, CX is now considered a key metric for measuring quality in production. New types of CX testing include A/B and canary tests as well as crowd testing. Like other operational data, CX data is also typically voluminous and often unstructured. While CX teams specialize in such principles, testers need to acquire sufficient skills to glean insight from the CX process and data, and collaborate effectively with such teams.
    • Monitoring and operations skills: Understanding of monitoring principles (e.g. creation, testing and deployment of monitors and use of data from monitors) is a key skill required for TestOps. Similarly, testers must also understand operations principles (incidents, failures, alarms, MTBF, MMTR, configuration definitions, etc.) so that such information can be leveraged for testing purposes as well as for collaboration with ops teams.
    • Reliability skills: Reliability is also another key operational quality attribute that testers need to be familiar with. This includes chaos/resiliency testing, deployment and rollback testing, and configuration testing. The discipline of SRE has evolved within DevOps to address reliability, and many of its principles overlap with TestOps. 
    • New tools skills: In addition to using traditional testing tools, TestOps also requires the use of additional tools such as monitoring, data analytics (for production and CX data), CX testing (such as A/B and canary testing) and reliability testing. Technology innovations that support testers with these new capabilities include RunScope (a lightweight API monitoring tool that can be used for monitoring both in test and production environments), Blazemeter (for performance testing for CX and reliability), Optimizely for A/B testing. For data analytics, technologies such as automation.ai simplify the work of data aggregation and modeling so that testers can more easily extract actionable insights from data collected across the lifecycle. 

    Key TestOps Collaborations

    In addition to new skills, testers must now learn to collaborate better with additional stakeholders as alluded to above. These include: 

    • Collaboration with data science and AI/ML engineers: This is necessary for testers to tweak or build out new algorithms and models required to perform the analytics needed for TestOps.
    • Collaboration with CX engineers and teams: This is necessary for testers to monitor the appropriate CX metrics and data, and to study the impact of their testing/QA activities on CX.
    • Collaboration with Operations engineers and teams: This is fundamental for TestOps to not only support all the shift-right testing activities, but also to gain access to production data that is required for TestOps analytics. This is analogous to how testers collaborate with developers as part of shift-left. 
    • Collaboration with SREs: As mentioned, there is a fair degree of overlap between SRE and TestOps principles, and hence collaboration with SREs is key for testers. See my blog on how testers and SREs can work better together to improve reliability. 

    Conclusion

    Hopefully, this article has provided readers with some insight into the emerging discipline of TestOps. As we build increasingly distributed microservices and cloud-native systems, and as the discipline of SRE matures, we expect to see more of shift-right testing practices that enrich TestOps.

    — Shamim Ahmed

  • DevOps Chats: Solving Complexity in Continuous Testing, with Sauce Labs

    DevOps Chats: Solving Complexity in Continuous Testing, with Sauce Labs

    SauceCon 2020 by the good folks at Sauce Labs is just about a month and half away (April 27). As part of our lead-up to the show and our coverage including live broadcasting on Digital Anarchist, we caught up with newly minted Chief Product Officer, Matt Wyman.

    Matt discusses how continuous testing, automation and DevOps has led to better testing. With that though, we are more complex and sophisticated than ever in how, what and when we test. Can’t we just keep it simple? Do we want to keep it simple? Have a listen to what Matt has to say, as well as why he is so excited about this coming event.

    If you are interested in testing at all, do check out the great lineup for SauceCon. Hope to see you there.

    [soundcloud url=”https://api.soundcloud.com/tracks/770790922″ params=”color=#ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true” width=”100%” height=”166″ iframe=”true” /]

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel for devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat is meant to give you a little bit of a flavor, a preview for the upcoming SauceCon put on by Sauce Labs, which will be at the end of April. So, about a month and a half away, almost two months—well, a little less than two months away. It promises to be another great event from the folks at Sauce, and they have, really, just a packed lineup of speakers from a wide range of enterprises and startups and tech companies, manufacturing companies. I mean, just a whole gamut.

    Anyway, speaking with me today about SauceCon, about maybe some new developments and trends in the testing market is Matt Wyman. Matt is chief product officer at Sauce. And Matt, welcome.

    Matt Wyman: Thank you. Glad to be here.

    Shimel: My pleasure. So, Matt, let’s get this out of the way first. You recently joined Sauce in, like, January, correct?

    Wyman: I did, January 6th. I am a recent addition to Sauce Labs, and very excited to be here. I’ve been in the DevOps community for some time, worked as the head of product for CircleCI, so definitely a space that I know well.

    Shimel: Sure

    Wyman: But I see this massive opportunity and impact around test, and this fragmented space, and hopefully, we’ll get into this and talk about complexity a little bit. But it just really seems like a huge opportunity and a company that I love and a great reputation, so I’m excited to be here.

    Shimel: Very cool. You know what’s interesting? I mean, of course, CircleCI is in and of itself a great company, too. We’ve—you know, I’ve done a couple podcasts with Rob, the CTO over there.

    Wyman: Yep.

    Shimel: And, you know, they recently, they raised a bunch of money, they’re really becoming a player in the CI/CD space. But it’s interesting that you moved from CI and CD to testing here, and you know, when we look at, let’s say, CloudBees, right, and Jenkins, the Jenkins founder, KK, you know—I’m not even try to pronounce his name; let’s just call him KK. But anyway, KK recently left CloudBees and the Jenkins community to start a new company also focused in the testing space.

    So, I think your move here, KK’s move—I think it shows that, as the whole CI/CD, you know, software delivery pipeline type of industry and community matures, people are recognizing that testing is kinda where it’s at right now, right? That’s the new battleground. And maybe it is, as you mentioned, Matt, because you know, the mission has grown so much more complex than, you know, let’s say pre-DevOps, right?

    Wyman: Absolutely.

    Shimel: So, why don’t you—if you don’t mind, give me or give our audience an idea of where you see or how you see testing has become, you know, more complex.

    Wyman: Absolutely. So, speaking to the CI/CD platforms just for a moment, orchestration in CI/CD has become a very complex problem, and that’s reflective of changes in the software landscape and how people build software, which itself is a reaction to where we started.

    So, we had all these monoliths, these, you know, large systems, we’ve all talked about it, they still exist out there in the world. Most every system that says that they do microservices actually has a monolith somewhere, like, micro-monoliths all around.

    When you’re in the monolith world, testing is all about end-to-end testing. You’re trying to put all the pieces together, validate that everything works top to bottom, and that’s really where quality and test have their roots. And as much as possible, it’s all about trying to automate those difficult processes and make it easier and more efficient to move through all your different test cases.

    But as those entities split up, and as we started to recognize that each component of a larger application needed different types of tests, testing itself became more complicated. And furthermore, it became more than just clicking buttons. At one point, testing was about validation, that if you click a button, you go to the correct page. If you click a button, the right business logic executed.

    But these days, it’s a lot more than that. It’s also validating that the CSS is correct, that the experience is performant and is wonderful and delightful. Companies that have bad user interfaces and bad user experiences don’t win.

    And so, you have this testing world that, on the one hand, is trying to move faster, dealing with a more complex software landscape, and on the other hand, is now broadening in the types of tests that are being run, not just functional testing, but also, if you will, delight testing and trying to validate that the user experience, the customer experience is going to be an excellent experience at the end of the day

    Shimel: Yeah.

    Wyman: And so, that’s how I see this space splitting up.

    Shimel: Absolutely. I don’t disagree with you there. You know, Matt, I almost wanna put myself in the shoes of the test professional and the QA person who, you know, maybe six or seven years ago was hearing that DevOps and this move, you know, agile to DevOps and beyond was gonna somehow make them obsolete. And then other people were saying, “Oh, no, it’s not gonna make you obsolete, it’s gonna free you up to do higher level kind of tasks that are more worthy of your talent and skill set.”

    And I think that has come true, certainly. I think what we’ve seen with test automation has freed up testers to do higher level stuff, but I also think it shifted the—not the burden, but the emphasis on people who know how to set up automated testing, right? You’ve gotta know maybe a little bit of coding, a little bit of scripting, you gotta know some of these open source tests.

    Wyman: There’s a bit of all of the above, don’t you think?

    Shimel: Yeah, it is. That’s exactly it.

    Wyman: The—and it’s further complicated by the fact that the number of devices and environments we’re testing on has also fragmented and increased. And you can’t run the same type of test in every environment, so most software applications have some sort of mobile component to them.

    Shimel: Yeah.

    Wyman: And yet, mobile testing is not automated in the same way that you would automate browser testing. And in fact, in some cases with mobile testing, it’s more effective to be manual and to go through it piece by piece, or to use visual testing to go through it.

    And so, you have to pull together all these different techniques. I think there’s often this perception that, with any new technology or any new change, that it’s going to somehow upset the apple cart and suddenly everyone who has a job doesn’t. And it just doesn’t typically work out that way. I think what we’ve seen is just this increasing complexity, and then also the opportunity to use the right type of testing in the right place. Meanwhile, a lot of the people out there doing quality testing continue to do so, because the number of applications has only multiplied.

    You know, the fact this whole digital transformation and all the buzz words that you hear about that—fundamentally, it’s true. Every business is now a software business, and one of my favorite examples recently is, where I live, there’s a highway called 101, a pretty big highway, and there’s a big billboard on the side that has a, it’s from Wells Fargo, and it has a mobile app on it. And the billboard is not advocating or talking about Wells Fargo’s core business, they’re not talking about loans or lending or savings accounts, it’s talking about their mobile app and the experience of their mobile app. And you better believe that they care about testing it, right?

    And so, it’s more than just—again, I covered this earlier, it’s more than just feature function right now. You have—you need more people who need to look across all the different touch points and then utilize the right type of testing in each area. And so, there isn’t one test solution that solves all of it. You have to use different techniques, because ultimately, you’re managing business risk, and you have to do it all the way from the moment a developer checks in code all the way through to production and validate, if you will, a virtual user. Someone has to go validate that it’s actually working as expected when a customer reaches out to interact with the tool.

    Shimel: Yeah, yeah. And, you know, Matt, you hit on a couple—you hit on web testing, mobile testing. I think one of the things, you know, thinking back to when I was running software companies, testing was always something that meant that we were a day late and a dollar short with, you know?

    Wyman: Absolutely.

    Shimel: It seemed like we never had enough budget to do all the testing we thought we should do, and we never had enough time to finish the testing at least we were going to do. But when I look at the kinds of testing and the amount of testing that goes in today, and all of it pre-deployment and everything—yeah, it’s grown more complex, but I think just beyond pure complexity, I mean, would you say we’re testing more now than we did before.

    Wyman: Well, I think part of the answer there is to dig in on what does it mean to test. So, these days, it’s about risk management. And so, if we’re going to have developers able to check in code and 10 minutes later update production, then we’ll need mechanisms to ensure the production is safe. And typically, that’s done with feature flagging, it’s done with canaries. There’s all sorts of ways to ensure that each change doesn’t blow out production.

    But along that path, it’s also about automating as many of the different possible negative outcomes as you can. And that is what we would typically call testing. So, there’s visual testing, there’s browser testing, there’s unit testing, there’s end to end testing, integration testing. All these are necessary, and you’re trying to compress them all into that 10 minute window, which—you know, most organizations can’t hit that kind of number, but that’s the gold mark if you can hit that 10 minutes from change to production.

    And so, I believe that it’s a matter of thinking about risk and saying it’s not about quote-unquote test coverage with a go/no go meeting where you look at the test coverage—and frankly, there’s so much peer pressure to go that typically organizations do. It’s more about saying, “What is the possible negative outcome, and how do I ensure that I have appropriate coverage for each of those negative possibilities?” And in some cases, you’re going to build tests to simply block and fail that particular change, and in other cases, you’re going to provide monitoring and observability to ensure that, if something negative happens, you can pull it back quickly.

    And if I go very meta for a moment and go well above even what Sauce Labs is doing as a platform, I would suggest that all of that is a part of the overall test or risk management perspective. And ultimately, I think our goal is to then create visibility across the whole thing, so you can manage your risk, manage your test all from one place.

    Shimel: Got it. Makes sense. Now, Scott—Matt, excuse me—let’s talk a little bit about SauceCon. How is all of this manifesting itself, you think, at SauceCon?

    Wyman: Well, one of the fun things for me is, this is gonna be my first SauceCon. So, I haven’t had the opportunity to see—

    Shimel: Oh, you never went? Okay.

    Wyman: I’ve never been, so, this is gonna be my first one. I mean, I’ve seen the lineup, it looks fantastic. I’m hoping to see not only a whole series of really good conversations within our existing community, but also, there are quite a few people that are coming who are Selenium, who are Appium users, developers and whatnot, to share in some of their experiences.

    I know, as a product person, one of the conversations I’m very eager to have is in how we help people shift left. And so, it’s more than just running Selenium tests, it’s about the headless tests, it’s about getting earlier upstream so that we can provide a little bit more of a developer oriented experience. And so, I’m very excited to go have those conversations, and I think the lineup looks good to have it.

    Shimel: I agree as well. So, I’ll tell you, my experience is, you know, if you’re looking for conferences around testing and how—like, what’s pushing the frontiers there, right, and also pulling in the open source testing community, SauceCon is one of the best. And I’ll tell you what I like about what Sauce Labs has done there is, you will see other testing companies represented, mentioned, participating, right? I remember, you know, CA who had bought BlazeMeter, for instance, was involved in SauceCon. I don’t know if BlazeMeter will be there this year or not, but they were there. I know the Tricentis folks also like to participate.

    And part of the reason is because testing is such a big world with so many different facets today, you know, everyone kinda does—you know, they’re not necessarily head on competitors. A lot of this is sort of complementary. And so, it’s really nice to see the community come together. You see it a lot—and maybe this is something that is specific to DevOps in general, I don’t know, but you see it a lot at these DevOps events where, yeah, it’s Sauce Labs throwing the party, but the whole testing community partakes. And that, I think, to me is one of the things that makes SauceCon really special.

    The other thing is, is just the speakers. I mean, you know, like in any vendor/user type conference, you’re gonna get the CEO, the CTO, and I’m sure Matt, you’ll do some presentation. But when you look at the speaker lineup here, you know, you have everything from, like, Google kind of engineers to startups to large enterprises, you’re really getting a good 360 degree view.

    Wyman: What excites me is that the way in which we think about this event, we don’t see it as a sales event. We’re not sending salespeople there.

    Shimel: Right.

    Wyman: A number of my product folks will go, because we’re interested in having conversations. The test market overall is fragmented, but it’s fragmented for a good reason, which is, there are a lot of different use cases, a lot of different problems that people are trying to solve, and quite a few of those folks are going to be there, and so, it’s a good chance to have a conversation if you wanna do, if you wanna know more about visual testing, if you wanna know more about how to use headless effectively or deal with the grid.

    So, there’s this opportunity to share that information and share that knowledge, and I think that’s really what we’re aiming for is an environment that’s a practitioner’s environment. It’s [Cross talk].

    Shimel: Yeah, definitely, in years past—in years past, you know, SauceCon, that’s exactly what it’s been, and I think Sauce Labs has done a great job fostering that, right? It’s good stuff, all around.

    We don’t have a lot of time left, but you know, you just joined in January, you’re fairly new, your first SauceCon, you’re getting a handle around product. But do you feel up to giving us a little projection, maybe, of what we’ll see coming out from Sauce Labs over the next, you know, six months?

    Wyman: Well, I don’t wanna give away too much, but we will have something that I expect to be quite exciting, a new beta labs experience that I think people will be able to go get their hands on and play with, something that moves, let’s call it shift left, a bit.

    And we’ll continue to talk a bit about our analytics and in particular, there’s a new report that we are going to be showing. I think some folks may be aware of it already, but it’s relatively new, it’s called Failure Analytics, where we’re able to aggregate all of the different log outputs and provide intelligence and cohorting of different common errors so that, instead of having to hunt through hundreds, potentially, of failures, we will highlight the common problems, which gives developers an easier time of going and fixing things. Also, it makes it a lot easier to debug across large automated test suites.

    So, we’ve got quite a bit that we’ll be showing from a product standpoint, and like I said, there is gonna be a pretty exciting unveil around a beta project that we’re moving forward with.

    Shimel: I think that’s enough of a tease right there. Hey, Matt, you may not know this, but I’ll mention it for our audience—anyone interested in going to SauceCon, it’s actually SauceCon, S-A-U-C-E-C-O-N dot com, and you can go on there and you can still register to attend. I should also mention that our MediaOps, devopsy.kinsta.cloud team will be there under our Digital Anarchist platform. We will be broadcasting live interviews from SauceCon.

    So, if anyone listening is going to be in Austin for the event—hey, come find the Digital Anarchist broadcast booth or me, and we’d love to hear what you have to say and maybe interview you. You never know. So, yeah, please do that, but check out SauceCon.com for more information.

    Matt, before we wrap up, anything else you wanna add?

    Wyman: I think this is great. I appreciate the opportunity to have the conversation.

    Shimel: Well, now that you’re part of Sauce, you know, we’d like—we do these DevOps Chats pretty regularly, so maybe we can have, maybe we’ll do another one even before SauceCon itself.

    I’d like to—you know, I didn’t wanna put you on the spot today, [Laughter] but maybe in the future, I’d like to hear, what are your top three sessions at SauceCon that you’re looking forward to. You don’t have to answer now, though, but I’m gonna give you a chance to do a little digging, but I’m gonna invite you back on in about two weeks and let’s talk about it.

    Wyman: That sounds great. I think it’d be a good idea to, I assume that we’re at the end, here?

    Shimel: Yeah, we’re wrapping up, and you know what, for our next one, Matt, I’m gonna pick three, too. So, folks, there you have it—stay tuned for our next chat with Matt where, between us, we’re gonna highlight his three and my three—

    Wyman: That sounds like fun.

    Shimel: Favorite talks for SauceCon that we’re looking forward to. Sound good?

    Wyman: Alright, sounds great. I look forward to it.

    Shimel: Alright! Hey, Matt, welcome aboard to Sauce Labs, I think—and you already know it, but you joined a great outfit, a great bunch of people there, and looking forward to seeing you in person at SauceCon.

    Wyman: And likewise—thank you.

    Shimel: Okay, and we’re looking forward to seeing you, our listeners, there at SauceCon, but if you can’t make it, do log onto digitalanarchist.live and you can follow along with us from there.

    Until then, this is Alan Shimel for devopsy.kinsta.cloud, and you’ve just listened to another DevOps Chats. Have a great day, everyone.

    — Alan Shimel

  • How to Successfully Adopt Mobile DevOps Practices

    How to Successfully Adopt Mobile DevOps Practices

    Mobile DevOps is more than simply adopting a new set of tools and practices. It also comes with the need to adopt a completely different mindset, in the form of a cultural-organizational change. The approach is based on the Agile methodology, but takes its practices further— not only by getting other teams more involved, but by replacing function-based teams with product- and project-oriented teams as well. The main idea behind this is that nothing inspires collaboration like having a common goal and working together towards reaching it. 

    Let’s take a look at the key elements of Mobile DevOps practices.

    Continuous Communication and Planning

    The goals and purposes of Mobile DevOps correspond with the original DevOps principles, such as customer satisfaction, sustainability, enhanced teamwork and shortened software development lifecycles. Similarly to DevOps, it aims to resolve problems by using common sense and implementing a culture of shared responsibility, transparency and shorter review cycles. In mobile development, constant and interaction-based communication between developers, website, product and QA teams is particularly important in order to accelerate feedback loops and consequently, resolve issues faster. In Mobile DevOps, there is more focus on transparent, traceable documentation, which can be achieved by using a source control system that helps keep track of documentation of code changes and details of the whole process. Raised visibility also helps teams share the workload—especially when it comes to unexpected work—and to fix incidents, and unblock the release pipeline rapidly. 

    Continuous Integration, Delivery and Deployment

    The Android and iOS operating systems are dominating the current mobile landscape, and both of them—especially Android—are incredibly fragmented. For this reason, it is necessary for developers to maintain separate builds, depending on the many supported versions, device types and platforms. A stable CI/CD tool ensures that the codes created by different teams are compatible with each other and new ones can be integrated into previous ones with no issues. These tools eliminate the manual aspects of app development from planning, code testing, integrations to deployment and monitoring, and automate as much as possible throughout the entire lifecycle of app development, which ensures the seamless merging of codes and reduces the risk of errors. Device fragmentation is the main reason why Mobile DevOps and CI/CD automation are inseparable in any team that wants to automate their app development, their testing and their monitoring processes. 

    Continuous Testing and Monitoring

    Mobile applications have to go through rapid iterations and more frequent releases than web applications. This results in new features in the app which are not always supported in the production environment at the time of the release. To understand the quality level and potential risk of each new release, mobile app companies can conduct different types of tests—ranging from automated unit and UI interaction testing, all the way to manual QA testing—depending on the maturity of the app and the size of the team. Besides implementing an iterative process for testing, adding monitoring and real-time performance tracking tools are all crucial in mobile app development. Not only do these enable teams to find the root cause of failures faster, but to save on hardware costs as well. Adding third-party SDK, performing crash reports and continuously monitoring both the app performance and the feedback in the app stores all help developers constantly improve the quality of the app. 

    Conclusion

    DevOps is just as much about the culture as it is about technology. Successfully adopting Mobile DevOps requires all teams at app companies to make important technical and business decisions, have a hard look at their processes, identify the bottlenecks and be prepared to make significant changes. The essence of Mobile DevOps not only lies in a mindset change and choosing the right tools, but also in close-knit teamwork that allows teams to focus on market needs, user behavior, feedback and other factors that significantly affect the product perception.

    — Nóra Bézi

  • DevOps Places Software Testing in the Crosshairs

    DevOps Places Software Testing in the Crosshairs

    To keep up with the pace of innovation, testing must play a larger role in the software development life cycle

    The speed of digital transformation is already staggering, and it’s only going to increase. To put this into some very concrete terms, consider that:

    • There are 7.7 billion people in the world.
    • 5 billion have regular access to a toilet.
    • 5 billion own a mobile phone.

    All of a sudden, a huge number of people jumped from a very provincial lifestyle straight into digital times—creating a tremendous demand for more, and more innovative, software.

    The traditional ways of developing and delivering software aren’t adequate for meeting this new demand. Not long ago, most companies were releasing software annually or bi-annually. Now, iterations commonly last two weeks or less. While delivery cycle time is decreasing, the technical complexity required to deliver a positive user experience and maintain a competitive edge is increasing.

    testing

    In terms of software testing, this brings us to an inflection point. In most organizations, testers were already racing to keep pace when delivery cycles were longer and application complexity was lower. Every quarter or so, the development team would pass a release candidate over the wall to QA, who would then scramble to validate it as thoroughly as possible in the allotted time—largely with manual testing.

    Now, digital transformation initiatives such as Agile and DevOps are pushing traditional methods to their breaking point. Organizations are releasing much more frequently—from monthly on the low end to multiple times per hour on the high end. And as organizations increasingly edge toward continuous delivery with automated delivery pipelines, intermediary quality gates and the ultimate go/no-go decisions will all hinge upon test results.

    Is your organization’s testing process up to the task?

    We Have a Testing Problem (Two, Actually)

    In most organizations, testing delays application delivery while providing limited insight into whether the applications are meeting stakeholder expectations. It’s not fast enough to help teams find and fix defects when it’s optimal to do so. And it’s reporting on low-level failures (e.g., 78% of our tests passed) rather than providing the business-focused perspective needed to make fast release decisions (e.g., Only 38% of our business risk was tested … and 25% of that didn’t work properly).

    Let’s take a quick look at each of these problems in turn.

    The Speed Problem

    DevOps is all about removing the barriers to delivering innovative software faster. Yet, while other aspects of the delivery process are streamlined and accelerated, testing consistently emerges as the greatest limiting factor.

    A recent GitLab survey that targeted developers and engineers found that testing is responsible for more delays than any other part of the development process.

    Where in the development process do you encounter the most delays?

    testing 2

    The same conclusion was reached by a DevOps Review survey that polled a broader set of IT leaders across organizations practicing DevOps. Again, testing was cited as the No. 1 source of holdups in the software delivery process. In fact, it “won” by a rather wide margin here—63% reported that testing was a major source of delays, while the second-highest source of delays (planning) was cited by only 32% of the respondents.

    Where are the main holdups in the software production process?

    testing 3

    Why is testing such a formidable bottleneck? That could be the topic of an entire book. For now, let’s summarize some key points:

    • The vast majority of testing (over 80%) is still performed manually—even more at large enterprise organizations.
    • Approximately 67% of the test cases being built, maintained and executed are redundant and add no value to the effort.
    • At organizations that have significant test automation, testers spend 17% of their time dealing with false positives and another 14% on additional maintenance tasks.
    • Over half of testers spend five to 15 hours per week dealing with test data (average wait time for data = 2 weeks).
    • 84% are routinely delayed by limited test environment access (average wait time for test environments = 32 days).
    • The average regression test suite takes 16.5 days to execute, but the average Agile sprint is two weeks, from start to finish—including planning, implementation and testing.
    • The average application under test now interacts with 52 dependent systems—which means that a single end-to-end transaction could cross everything from microservices and APIs to a variety of mobile and browser interfaces, packaged apps (SAP, Salesforce, Oracle, ServiceNow…), custom/legacy applications and mainframes.

    The software testing process wasn’t working perfectly even before the advent of Agile and DevOps. Now we’re asking teams to “just speed it up” at the same time that modern application architectures are making the process even more complex. Given that, it’s hardly surprising that speed expectations aren’t being met.

    The Insight Problem

    Only 9% of companies perform formal risk assessments on their requirements/user stories. Most attempt to cover their top risks intuitively, and this results in an average business risk coverage of 40%. Would you feel comfortable driving a race car with blinders on? That’s essentially what you’re doing if you’re rapidly delivering software with insight into less than half of your total business risk.

    Moreover, most organizations can’t immediately differentiate between a test failure for a trivial issue and a business-critical failure that must be addressed immediately. Most results look something like this:

    testing 4

    What insight does that really provide? It’s clear that …

    • There’s a total of 53,274 test cases.
    • Almost 80% (42,278) passed.
    • Over 19% failed.
    • About 1% did not execute.

    Maybe the test failures are related to some trivial functionality. Maybe they stem from the most critical functionality: the “engine” of your system. Or, maybe the most critical functionality was not even tested at all. Trying to track down this information would require tons of manual investigative work that yields delayed, often-inaccurate answers.

    Today’s go/no-go decisions need to be made rapidly—even automatically and instantaneously. Results that focus on the number of test cases leave you with a huge blind spot that becomes absolutely critical—and incredibly dangerous—when you’re moving at the speed of digital business.

    Closing the Gap

    How do you evolve from the slow, burdensome testing that delivers questionable results to the lean, streamlined testing that provides the fast feedback required to accelerate innovation and delivery?  That’s what I aim to explain in my new book, “Enterprise Continuous Testing: Transforming Testing for Agile and DevOps.” This book is targeted to senior quality managers and business executives who need to achieve the optimal balance between speed and quality when delivering the software that drives the modern business. It provides a road map for how to accelerate delivery with high confidence and low business risk.

    — Wolfgang Platz