devopsy.kinsta.cloud

Tag: Quality Assurance

  • So Many Options, So Little Time

    So Many Options, So Little Time

    So many language/framework options, so little testing time, that is.

    Recently, two projects I was working on drove me to check out a breadth of languages and/or frameworks to handle cross-platform development. While Unity and Unreal have traditionally been my game platforms of choice and I typically use Xamarin for cross-platform (though native development is more common for us on both Apple and Android), I decided I needed to do the occasional sweep to find out what is new out there.

    The two projects are a game on which I’m helping a new game developer learn and a graphics-heavy application that is unsuited to web development. Both would work best in a cross-platform environment; both would benefit from a game engine’s graphics manipulations. But both could be done in any language that supports graphics, as there isn’t a heavy physics requirement to the game.

    So I went looking at what’s available now and how it fits. From React Native to Godot to Flutter and even Kivy, I kicked the tires on each, got them running, ran and traced samples, wrote some code of my own, even talked with friends that were using them to get their opinion.

    Alternate frameworks languages

    The one thing that came through loud and clear? There is no way that security and testing are keeping up with this language/framework proliferation. Kivy has a language (more of a specification than an actual language, but still—source code) that can run on top of Python (it’s not required to use the framework, but it’s kind of assumed you will if the app gets beyond a certain size); Godot has a language that is integral to the framework and that you use pretty much everywhere. React has a ton of add-on code and both Flutter and Dart are new languages.

    I like stuff from each of them. I don’t like that we’re going to use them in ever-increasing amounts and we’re going to expect testing to stay on top of those implementations. Each of these platforms/languages/environments has a large following that is doing some of the testing, but since they’re all relatively new, “How much testing?” is a valid question. And tests have to be done in those languages, implying that those writing need to know them and so do testing teams.

    Where did we end up? We haven’t made a final decision yet, but taking input from the person I’m mentoring, coworkers and those who are using each of the above, we’ll probably end up using Godot. For 2D apps, it is the bomb. Our team is small, so I can offer my knowledge of Godot to shore up testing and everyone agrees that its Python-like language is acceptable, while the graphic design element is nicer than the competition. Both applications will benefit from Godot’s graphics processing capabilities and the game will benefit from game elements built into the Godot Engine.

    Here is an interesting side note: All of the products we looked at are open source. Both of the default products that we (and just about everyone else) would choose for the game are commercial. That’s interesting, but we don’t need the weight of those commercial solutions for a simple 2D interactive game/app.

    For you all, the questions might be harder to answer. With larger projects come larger requirements for source size, test, you name it. Choose carefully, with an eye on the future. Personally, I think React Native, Godot and Flutter would all be good choices for cross-platform applications, with Godot the best solution for cross-platform 2D games. And all three are likely to be around with a good size following for a long time, making them safer choices. That is less clear with Kivy, though the popularity of Python appears to be driving growth in Kivy use.

    Whatever you choose, plan for all phases of development, not just writing code. That’s true of everything, but new cross-platform tools are complex beasts, so it is worth reminding you all.

    And hey, if you have a cool app you developed with one of these tools, point me to it. Always good to see what you all are doing, and nice to see the breadth of solutions these languages can create.

  • Swinging the Pendulum of IT Back to QA

    Swinging the Pendulum of IT Back to QA

    I was reading Nuria Manuel’s excellent article about quality assurance (QA), and it got me thinking about the wide variety of ‘pendulums’ that impact IT. I call them pendulums because they follow the rule of “every action has an equal and opposite reaction,” and they work on fundamental truths of IT. For example, the one that has probably been going on the longest is centralization/decentralization of IT and its assets. No sooner is everything consolidated and cost savings realized than adaptability concerns and needs of individual business units start the process of decentralization. Then, once decentralization is realized, everyone is painfully aware of the chaos that fifteen miniature IT departments, each going their own way, can cause … and centralization begins again.

    Quality assurance is another such pendulum. Much like soldiers in peacetime, most people don’t recognize the value of QA efforts when things are going well. And when they’re not going well, then it is considered a QA failure—assuming there is a true QA function. Otherwise, it becomes the impetus to launch a formalized QA function … until things are going well and budgets are tight. The problem with QA is that for years, timelines, budgets and Agile management styles have all conspired to swing that pendulum away from a formal QA function. Oh, companies pay the price, but they quite often don’t see it as a cry for a valid QA function, and just treat this particular issue as a one-off that they should make sure doesn’t happen again. Unfortunately, issues in production have become both commonplace and accepted because of this. The only issues in production that seem to actually generate angst are ones that keep users from accessing the product. Anything short of that and workarounds or delayed fixes are seen as okay.

    But the apps you are rush-building today will still be around in 10 years—or, at least, some of them will. Some of them won’t for a variety of reasons–including quality issues. Those that are around in 10 years are going to have to be maintained. QA now can save you over the years, so why all the resistance to it? QA might delay the release of new app. It is understandable that delays are to be avoided if possible, but so are bugs, so maybe constraining how long QA can delay the release and building that number right into the schedule would be a decent compromise.

    That way, QA is looking at the most important/used parts of the app, but not getting buried in the weeds (where there might be bugs, but the ROI for addressing them probably isn’t there). The app will be delivered on time because QA’s time was built into the schedule. This does require that we not allow the traditional and abhorrent practice of shortening the QA window to make up for developers not meeting deadlines. Let us be very clear about this: when developers are rushed because they missed deadlines, that is precisely the time that you want QA to look very closely at their code before release. The last thing you should do is less testing in this scenario. The absolute last thing.

    This is completely doable in your environment. The only really difficult part is holding the line on QA. Business owners are going to want to meet their original timeline, but cutting any phase of testing to get there is just a bad idea, so the struggle will be to hold the line. And figure out why devs missed the deadline in the first place so that the issue can be avoided for the next project.

    You all are rocking it. Make sure all that sweet code-and-deploy work is not undermined by quality issues! Go ahead, implement a QA policy and make it an actual policy. Keep rocking it, get accolades from the rest of us. Maybe even from your employer. Maybe. But definitely from us. Because you’re killing it, month after month.

  • Why IT Should Focus on Quality Over Velocity

    Why IT Should Focus on Quality Over Velocity

    Quality assurance (QA) isn’t a new phrase for developers. Most know it as a staple part of the software process that is crucial for producing quality code. But throughout the pandemic, with extreme pressure for businesses to digitally transform quickly, it’s a discipline at risk of being dismissed by organizations and tech leaders as a last-minute, box-ticking exercise – but at what cost? Many have neglected QA in search of that quick app launch or new digital service, leading to an unwanted surprise or customer disappointment when the apps and features don’t work.

    We all know the old adage: ‘quality over quantity,’ but when considering software development, CIOs should have quality over velocity in mind. Although producing software at speed is clearly a necessity for business success–whether startups pivoting during a pandemic or enterprises keeping up with these nimbler competitors–QA must become more than a forgotten principle for internal IT teams. To achieve the necessary standards at the speed required, tech leadership must embed QA as a specified requirement of any software project, rather than an afterthought.

    Quality Assurance = Customer Satisfaction

    Quality assurance is about monitoring the software development process and method to ensure that the output adheres to the project requirements, as well as industry security and compliance standards. With QA at the core, businesses can gain a better understanding of the status of their product, which allows them to assess, improve and consistently enhance its output for better outcomes and know whether the output meets the business requirements.

    In order to draw out a strategy that ensures quality at each step, businesses need to understand their customers’ needs, user journey, expected target markets, and how they expect the software to perform. Without this, businesses will struggle to not only meet and ensure customer requirements but also business goals and expectations.

    Without QA, it is difficult for businesses to assess the functionality of the product or service and it becomes extremely difficult to track critical defects that become costly to address once found post-production. Poor QA can also lead to several other challenges, including delayed product releases, unhappy customers, reduced brand reputation and increased technical debt.

    Quality Shouldn’t be Assumed

    In its infancy, software development took on the best practices used in the hardware/manufacturing industry, which largely relies on assessing quality at the end of the product life cycle before release. As a result, much of the technology sector adopted outdated strategies which then became common practice. In fact, there are still hundreds of CIOs and CTOs I speak to that expect QA processes to be an add-on at the end of the software development process.

    Many technical leads believe it’s developers who drive quality in a software project throughout its life cycle. And this is true, to an extent – there are some fantastic, talented developers out there! But this perspective can teach bad habits and can mean QA is an expectation of individual developers rather than a specified requirement for the entire project.

    That’s because it’s easy to forget that developers aren’t quality engineers; those are, in fact, two entirely separate roles that should be working side-by-side throughout any digital project. A developer’s role involves writing and maintaining the source code, which usually includes implementing unit and integration testing to ensure that the code matches the requirements. However, they are not involved in performing functional and non-functional testing or reporting defects to the development team.

    It’s a People Problem

    Any business embarking on a digital project based on software needs both developers and QA testers—you can’t have one without the other. But tech leaders can struggle to hire both good developer talent and QA engineers—whether due to expense or lack of availability of skilled workers. Recruitment is a lengthy and costly process, especially when recruiting skills that are already in high demand.

    In light of this landscape and paired with the impacts of the COVID-19 pandemic, which has caused many businesses to slim down their in-house teams, IT departments are increasingly stretched. This means processes like QA, which many companies don’t view as a necessity or a priority, can be neglected. But putting quality assurance at the heart of the software life cycle can actually save time, helping to avoid clearing code with errors that will end up coming back to be updated.

    Ultimately, businesses don’t just need to build software, they need to improve it and make it work and evolve with its needs and goals. Quality assurance makes this possible.

  • Continuous Testing Practices (Part 1)

    Continuous Testing Practices (Part 1)

    In my prior blog, Continuous Testing – The Quest for Quality at Speed, I described five tenets and some of the practices for continuous testing (CT) to help those understand what continuous testing is. In my consulting work, I find it necessary to use 15 categories of practices to assess an organizations’ continuous testing capabilities. Given the large number of practices, I am publishing the complete list in three parts.

    This article is part one, which covers the following categories of continuous testing practices:

    • Continuous testing tenets
    • Leadership
    • Culture
    • Test strategy and plans
    • Test management

    Continuous Testing Tenets

    • The continuous testing principle “shift left” is practiced, in which tests are conducted as early in the pipeline as possible.
    • The continuous testing principle “fail early” is practiced, in which tests are arranged so that the most likely problems are found in the early stages of the pipeline.
    • The continuous testing principle “fail often” is practiced, in which tests are run frequently and with many different conditions such as different variations of operating systems, production topologies, browsers and production versions of services.
    • The continuous testing principle “test fast” is practiced, in which tests are run in quick cycles to get to a verdict as quickly as possible.
    • The continuous testing principle “be relevant” is practiced in which tests are focused on the most important tests and results for each purpose and stakeholder.

    Leadership

    • Leaders establish a definition and vision for software quality.
    • Leaders establish a definition for test coverage.
    • Leaders clarify how everyone’s roles fit with the CT strategy.
    • Leaders establish incentives for CT performance.
    • Leaders proactively sponsor quality assurance testing as a strategic element of their budgets and operations rather than viewing testing as a cost to avoid. This includes budgeting time and money for DevOps test training, test resources, test frameworks, test tools, test management and establishing policies for assessments.
    • Operational and capital expense budgets are planned together with all stakeholders to ensure all stakeholders agree there is enough opex and capex budget for the organization to accomplish quality goals for the budget period being planned.
    • Cost accounting practices ensure the capex and opex expenditures are tracked and made visible to stakeholders.
    • Schedules for CT improvement projects are identified and tracked.
    • Skills development programs provide individuals and teams opportunities to learn CT practices.
    • The performance of continuous quality assurance programs are monitored and made visible to stakeholders.
    • Leaders participate in creating and maintaining guidelines for codifying and tagging business risk priorities.

    Culture

    • Quality is everyone’s concern. Responsibility for attaining high quality software products is shared by everyone on a cross-functional team.
    • Cross-functional team members collaborate for testing. This reduces confrontation and friction between people who find failures and those who fix the code.
    • Dev teams embrace the creation of good tests and analysis of test results.
    • Ops team members contribute to test planning, test creation, test execution and test results analysis.
    • Policies for test creation and test coverage are agreed upon by the cross-functional team including Dev, QA, security and Ops team members.
    • A test architect is a role within the organization. The role has expertise in CT practices and helps cross-functional teams understand and apply them.

    Test Strategy and Plans

    • Test strategies and plans are created for each product or service and reviewed by cross-functional teams including development, QA, Ops and security teams.
    • Test strategies and plans identify the type of tests, and the extent of testing activities, for each stage in the value stream.
    • Test requirements and tasks are included in agile planning procedures for each theme, epic and user story.
    • Test strategies and plans define a test coverage standard, test case standards, and input/output criterion for each pipeline gate.
    • Test plans identify the test cases and all the supporting requirements to implement and execute the test cases as required satisfying the test strategy and test management goals.
    • Test strategies and plans identify the approach for system and acceptance testing.
    • Test strategies and plans identify any tests that are to be conducted in production.
    • Test strategies and plans identify any tests that are to be conducted for security testing.
    • Test strategies and plans identify a target for test automation and manual testing for each type of testing. For example, 100% of all tests in the integration stage and 85% of test in the pre-production stage is a typical goal.
    • The test strategy requires that changes to a database or changes to an application that uses a database have tests defined for the database and the application use of the database.

    Test Management

    • All aspects of test management, such as test planning, test guidelines, test code version management and version management of test results are handled by tools that are well-integrated into the continuous delivery pipeline and any test framework being used for test automation.
    • Schedules for all test tasks are identified and tracked.
    • New features have a scheduled task to ensure test goals are met for each new feature.
    • Each test case has associated attributes that can be used to find tests according to the attributes. For example, an attribute could be type of test and the feature purpose of the test.
    • Test environments and resources needed to satisfy requirements to run each test are identified and available programmatically for scheduling purposes.

    What This Means

    Continuous testing practices are critical to success with DevOps. Many organizations underestimate both the importance and the practices needed to engineer continuous testing. This article is the first in a three-part series that provides a comprehensive list of practices that can be used to understand and assess an organization’s continuous testing capabilities. To learn more about my blueprint for continuous testing, refer to my book Engineering DevOps.

  • History of Quality Assurance

    History of Quality Assurance

  • Synopsys Advances DevSecOps via IDE Plugin

    Synopsys Advances DevSecOps via IDE Plugin

    Synopsys has extended the static application security testing (SAST) and software composition analysis (SCA) of the Code Sight plugin it makes available for integrated development environments (IDEs).

    The latest iteration of Code Sight adds the ability to analyze declared and transitive open source dependencies to identify components with known security issues alongside SAST findings without having to exit their IDE.

    Delivered vis the company’s Polaris Software Integrity Platform, the update enables developers to also review known vulnerabilities of flagged components to verify the risk and determine remediation options using vulnerability information from Black Duck Security Advisories (BDSAs). That information is based on data provided by both Synopsys and public CVE records gathered in the National Vulnerability Database (NVD).

    Patrick Carey, director of product marketing for the Software Integrity Group at Synopsys, said the Code Sight plugin enables developers to easily identify and select the best fix for vulnerabilities by providing detailed remediation guidance that directs them to more secure component versions.

    Code Sight also helps developers optimize component selection by including, for example, information regarding open source license risks and potential security and license compliance violations of an organization’s predefined set of open source policies.

    In general, Carey said Code Sight is designed to make it easier for developers to address a broad range of cybersecurity issues while an application is being developed instead of after it’s deployed. The goal is to make it easier for developers to discover and address cybersecurity issues on their own as part of the overall shift toward adoption of best DevSecOps practices, he said.

    The challenge, of course, is most developers have not been trained to identify potential cybersecurity issues in their code. Code Sight fills that gap by surfacing vulnerabilities as developers write code, said Carey. Synopsys plans to continue building on that capability by adding more analytics capabilities to the Code Sight plugin over time, he added. For example, Synopsys earlier this year acquired Tinfoil Security, a provider of dynamic application security testing (DAST) and application programming interface (API) security testing tools that will be employed to surface additional analytics in Code Sight.

    Eventually, the goal is to make identifying cybersecurity issues a natural extension of the quality assurance process within any application development and deployment life cycle, Carey said.

    It’s hard to say with certainty to what degree DevSecOps will be driven by a set of well-defined best practices versus simple evolution of how applications are developed. There’s no doubt cybersecurity professionals have a vested interest in making sure fewer vulnerabilities make it into production application environments. As such, communication between developers and cybersecurity professionals clearly needs to improve. However, the biggest DevSecOps strides any organization might make may simply come down to making the right tools available in the most frictionless way possible to developers.

    In the meantime, there’s no doubt application security has become a major area of focus in the age of digital business transformation. The challenge now is limiting the number of vulnerabilities that might be exploited as more code than ever is developed and deployed at increasingly faster rates.

    — Mike Vizard

  • The Bug in Production: What You Don’t Know Can – and Will – Harm You

    The Bug in Production: What You Don’t Know Can – and Will – Harm You

    Despite the risk of unplanned downtime, many organizations that develop software and services push them live without adequately testing for bugs that will manifest against production traffic. This is a huge gamble: Those bugs could lead to errors that bring down the service altogether. Pushing live without sufficient testing can be detrimental to your business.

    The Problem of Going Live With Bugs in the Code

    Software downtime leads to loss of revenue and of reputation. In fact, Gartner analysts have estimated that the average cost of downtime is $5,600 a minute—that’s well over $300,000 an hour. To provide a real-life example of what this looks like, Microsoft Azure suffered a major outage in November 2018 caused by issues introduced as part of a code update, lasting for 14 hours and affecting customers throughout Europe and beyond. With migration from legacy systems to micro-environments in the cloud, outages and downtime pose a growing and serious problem.

    As companies switch to DevOps and CI/CD models to move faster and provide application updates sooner, software developers continually release new features and often push code updates as fast as they’re written. The classic six-month development timelines of dev, quality assurance (QA) and beta testing have been compressed to days and sometimes hours. Gone is the time when teams could beta test with customers for extended periods to flag real-time bugs.

    With current quality testing tools, developers don’t know how a new software version will perform in production—or whether it will even work in production. The Cloudbleed bug is an example of this problem—in February 2017, a simple coding error in a software upgrade from security vendor Cloudflare led to a serious vulnerability discovered by a Google researcher several months later.

    Flaws can lead to serious security issues later, in addition to having the immediate impacts mentioned above. Heartbleed, a vulnerability that arose in 2014 and stemmed from a programming mistake in the OpenSSL library, left large numbers of private keys and sensitive information exposed to the internet, enabling theft which otherwise would have been protected by SSL/TLS encryption.

    Standard QA Testing Isn’t Enough: Test With Production Traffic

    The way QA testing is typically done is no longer sufficient for today’s increasingly frequent and fast development cycles. Traditionally, DevOps teams haven’t been able to do side-by-side testing of the production version and an upgrade candidate.  The QA testing used by many organizations is a set of simulated test suites, which may not give comprehensive insight into the myriad ways in which customers may actually make use of the software. Just because upgraded code works under one set of testing parameters, doesn’t mean it will work in the unpredictable world of production usage.

    As in the case of the Cloudflare incident, the error went entirely unnoticed by end users for an extended period of time and there were no system errors logged as a result of the flaw. Just as QA testing isn’t sufficient, relying on system logs and users also has a limited scope for what can be detected.

    It is estimated that fixing flaws after a software release can be five times as expensive as fixing them during design—and it can lead to even costlier development delays. Enabling software teams to identify potential bugs and security concerns prior to release can alleviate those delays. Clearly, testing with production traffic earlier in the code development process can save time, money and pain. Software and DevOps teams need a way to test quickly and accurately how new releases will perform with real (not simulated) customer traffic and while maintaining the highest standards.

    By evaluating release versions side by side, teams can quickly locate any differences or defects. In addition, they can gain real insight on network performance while also verifying the stability of upgrades and patches in a working environment. Doing this efficiently will significantly reduce the likelihood of releasing software that later needs to be rolled back. Rollbacks are expensive, as we saw in the case of the Microsoft Azure incident.

    Some organizations stage rollouts, which requires running multiple software versions in production. The software teams put a small percentage of users on the new version, while most users run the status quo. Unfortunately, this approach to testing with production traffic is cumbersome to manage and costly, and still vulnerable to rollbacks. The other problem with these kinds of rolling deployments is that while failures can be caught early in the process, they are—by design—only caught after they’ve affected end users.

    This brings more questions, including: How do you know whether the new software is causing the failures? and, How many failures does the business allow before recalling or rolling back the software, since the business does not observe side-by-side results from the same customer? This disrupts the end user experience, which ultimately affects business operations and company reputation. And staging may not provide a sufficient sample to gauge the efficacy of the new release versus the entire population of customers.

    Cost is still an issue as well. If you stage with 10% of customers on the new version and a failure costs more than $300,000 an hour, then a failure affecting 10% of users could potentially still cost more than $30,000 per hour. The impact is reduced, of course, but it’s still significant—not counting the uncertainty of when to rollback.

    Looking Ahead

    Standard QA testing is no longer enough. To reduce the risk injected into the software development life cycle by today’s rapid iterations, DevOps teams can test in production and evaluate release versions side-by-side. This will help prevent costly rollbacks or staging while still releasing a quality, secure product. The old way of doing things is not sufficient, but fortunately, there is a better way.

    — Frank Huerta

  • DataStax Announces DataStax Distribution of Apache Cassandra

    Continues Commitment and Engagement with Open Source Community with Industry-Leading Code Contributions, Coaching and Conference

     SANTA CLARA, Calif.–(BUSINESS WIRE)–DataStax, the leading provider of the always-on, Active Everywhere distributed hybrid cloud database built on Apache Cassandra™, today announced DataStax Distribution of Apache Cassandra (DDAC). DDAC is a new subscription offering designed for running a certified version of open source Apache Cassandra for development and production use cases that do not have the higher enterprise demands better served by DataStax Enterprise.

    The DDAC release reinforces DataStax’s engagement with the open source community. DataStax enables and supports data professionals who want to build applications on Apache Cassandra. DataStax does this by hosting frequent community events nationwide and by also hosting the premier Apache conference—DataStax Accelerate—where Cassandra practitioners, experts, and developers come to learn and share ideas.

    DataStax is now making it easier for professionals and enterprises to obtain and use the production-certified version of Apache Cassandra from DataStax.

    DDAC consists of a production-certified release of Apache Cassandra with drivers, bulk load utilities, and professional support. It combines the benefits of open source software with professional software maintenance and the expert support needed by customers who wish to deploy open source software in less critical production or development environments.

    Deploying DDAC enables enterprises to:

    • Apply premium features and performance with no lock-in while standardizing on open source software (OSS).
    • Scale environments and manage costs effectively to compete in a dynamic marketplace.
    • Streamline operations and support by removing a patchwork quilt of in-house, regional integrators or partners and third party vendors providing Apache Cassandra support and services.
    • Access the best-in-class Apache Cassandra software, support and services from the experts.

    “Many organizations are interested in using open source software when there are concerns about cost, vendor lock-in and availability of developer skills, but most organizations also want to use products that are backed by commercial support,” said Doug Henschen, Vice President and Principal Analyst, Constellation Research. “DataStax Distribution of Apache Cassandra addresses both concerns, building on open source software while leveraging the company’s experience and expertise supporting high-scale Apache Cassandra-based database deployments.”

    “We’ve put DDAC through rigorous testing to offer enterprises a production-ready release of Apache Cassandra with maintenance management and support from DataStax and our team of Apache Cassandra experts,” said Amit Chaudhry, Vice President of Product Marketing at DataStax. “We believe DataStax is the only company that has deployed the world’s best distribution of Apache Cassandra at hundreds of real-world enterprises. Our expertise, services, and support are unmatched in the industry when it comes to Cassandra.”

    DataStax Distribution of Apache Cassandra includes:

    • A certified version of Apache Cassandra that goes through the same rigorous quality assurance (QA) and certification testing process as DataStax Enterprise.
    • Business day, 8×5 support or 24×7 worldwide support.
    • DataStax Bulk Loader Utility for making data loads and migrations easy.

    “When enterprises deploy just open source Cassandra, we find that over time they run into security, support and compliance issues. DDAC solves this. Enterprises now have an option to deploy a production-certified release of Apache Cassandra with DDAC,” concluded Chaudhry.

    DDAC is available for download now at:
    https://academy.datastax.com/quick-downloads

    To learn more about DDAC, please join DataStax at DataStax Accelerate, The World’s Premier Apache Cassandra Conference, on May 21-23, 2019 in the Washington D.C. Area. To register, please visit https://www.datastax.com/events/datastax-accelerate.

     

  • In DevOps, Quality is a Team Effort

    In DevOps, Quality is a Team Effort

    Technology is changing every industry; we can all agree on this foundational premise. If you disagree, I believe the rest of this post is going to do nothing for you, so feel free to stop reading now. If you do agree, then you know that apps, the internet of things (IoT) and APIs are table stakes now. Businesses need strategies for each, and the forward-thinking executives are already adapting. The ones that aren’t risk alienating a channel in their overall digital strategy. It’s not all about strategies for building new types of functionality and partnerships; organizations also need to validate they will work specifically with their customers’ use cases in mind.

    When we study software development, the history books teach us that waterfall strategies followed a linear path. In the past, this pace may have worked, but the future seems bleak with the evolution of technology and its disruption of traditional, manual business processes advancing at an exponential rate. Over time, the stages in the software development life cycle (SDLC) may remain the same, but organizations need to focus specifically on becoming more efficient at completing more work in less time. With this “do more with less” mindset, it’s no wonder many organizations see a backlog of work piling up. This point is especially true for quality assurance and quality engineering teams.

    First, let’s unpack the software development stages from a traditional sense. Historically, organizations would get an idea and that idea could come from the businesses stakeholders (sales, marketing, customers, etc). The business would prioritize/stack rank all of their ideas by which carried the most merit and how much work those ideas would require for implementation. This is known as the “planning” phase. From planning, the idea would progress to be built. “Building” is the part of the life cycle where your artists/engineers live. You know, the creative people, the developers. They build the technology according to specifications that come from the planning phase. Most importantly, they are incentivized based on the project being delivered on time.

    After the technology is built and packaged, it is passed on to the team that has been traditionally responsible for quality—quality assurance (QA). QA has their time with the product to validate the product works as intended, can scale to the appropriate demand levels, is secure and meets all the use cases without error before they pass it over to the team that will deploy it to the hands of their customers. Finally, the business is measuring feedback and customer sentiment, and then rolling that feedback back to the plan stage for improvement.

    As time has passed, we have also seen another major trend develop. Organizations have developed agile/iterative SDLC strategies that are focused around bringing smaller chunks of functionality to their users/customers faster. Just like “lean manufacturing,” this concept has been focused predominantly around helping the developers get their projects completed faster. The primary challenge with waterfall development strategies is that by the time an organization brings the plan to market, the needs and priorities of the customer will have already changed. The speed of idea generation outpaces the execution of said ideas. That being written, while development has kept pace, quality has not, unfortunately.

    Now I pose a simple, albeit, extremely important question: Who owns responsibility for ensuring quality of the finished product? If your answer is QA (like stated above), and I can see why that would be the instinctual response—the process is set up for failure. Here’s the fundamental reason why: if quality is so important to the process, then why is it the third phase in the SDLC? This implies planning and building without quality in mind is an acceptable process.

    Quality should be owned by everybody in the process. QA/QE teams are your enablers of embedding quality throughout the SDLC. The distinction is more about instituting an ideology or culture based on quality.

    With a culture focused on driving quality, when the planning team works on creating a specification for the idea, they should work with development and QA/QE as they are designing the flows, behaviors of the application. This allows for QA/QE teams to understand what to validate much earlier in the process. Teams are always looking for ways to factor more automation into the process. QA teams are also looking for ways to make their test environments more closely resemble the production environment where their customers interact with the business.

    Unfortunately for QA/QE, they feel pressure from the business to execute within a constrained time frame with better results. This typically means inadequate windows of opportunity to start building automated tests or an incomplete environment that doesn’t quite resemble what the end user will face.

    The last frontier to validate is performance which answers the important question: Will the app scale for the expected user population? This is often the last step before flipping the switch and shipping the product to your customers. But what happens if the application doesn’t scale? Organizations need to drive performance validation earlier. Better yet, they should engineer the application for the desired performance, and that means—yes, you guessed it—taking care of this earlier in the life cycle.

    What if it were possible to drive more improvement?:
    1. … To start building functional test plans and test automation at the time when planning happens?
    2. … To ensure that development and test environments more accurately have access to the constrained downstream resources that cause unexpected “wait time”?
    3. … To ensure that the automated testing that will be executed in the testing phase, has the right data to power the tests?
    4. Finally, … to make sure that performance isn’t just an afterthought but a strategy to scale to the changing landscape of a digital business?

    It’s more than possible. It’s obtainable. This process is known as continuous testing. It’s about the validation that needs to occur earlier—not just within a window of allotted time within an overall life cycle. It’s also important to understand that it’s a maturity curve, and it will take work to evolve your individual process.

    Can your organization embrace continuous testing strategies? If not, what’s stopping you? If so, where can we begin to improve? Driving quality isn’t just about your company’s KPIs—it’s about your customers’ perception of your brand and what you do for them. You never get a second chance to make a first impression. Let’s build the right impression today!

    — BobbyMelwani

  • The Role of QA in the DevOps World

    The Role of QA in the DevOps World

    The need for faster time to market and superior quality is getting intense in the software development process. Software trends for 2017 suggest that DevOps will grow as a trend and become more widely accepted across enterprises. Organizations are reaping the benefits of DevOps approach and are incorporating the rules within every aspect of software testing. A case in point: DevSecOps—security testing integrated with DevOps—is an emerging concept and is being considered by enterprises to execute application security testing.

    The underlying objectives of adopting DevOps are to make the testing and development process more collaborative, ensure software quality and to help launch the product faster to the market. This makes quality assurance (QA) a key component in the DevOps methodology. New-age applications need real-time changes and updates to meet the growing demands of the consumer. This requires continuous testing, continuous development and continuous delivery/deployment. DevOps enables teams to constantly upgrade and deliver.

    In 2016 a number of enterprises adopted DevOps. According to industry experts, 2017 will see more defining moments for DevOps. The idea of accepting DevOps is to consider a cultural shift and not just a technical shift. As digital transformation expert Jeff Sussna says about DevOps, “The key to following the continuous delivery path is to continually question your own assumptions about what’s possible.” Currently, DevOps is on the route of being questioned and defined at every level. It will result in bringing more value to the methodology.

    Every enterprise and its style of working differs. The way they would adopt DevOps will differ, too. But digital transformation and the need to be available for customers all the time with new updates is transforming the way enterprises adopt new practices and methodologies. Every enterprise has to evolve in a sustainable manner, so quality is at the core of every practice, including DevOps.

    Why is QA Integral to DevOps?

    In the DevOps scenario, QA integrates into the testing and development process and takes the collaborative approach. Quality is ensured throughout the testing and delivery cycle and both the testing and development teams are responsible for it. In the traditional pattern, quality creeps in toward the end, but with DevOps it comes in at every level.

    In terms of code development, the QA team pushes the new development code into production and DevOps facilitates to ensure a seamless deployment of infrastructure and tools. Thus, it helps in releasing a code on a consistent basis and the responsibility to ensure quality is not just limited to killing the bug; it is built in the overall application release.

    In the current scenario, hourly releases are required to meet the demands of the consumers and deal with competition. Web/mobile applications such as an ecommerce or financial services application need to be updated frequently. It is a key business requirement. DevOps helps to make this possible, but with QA involved, the quality of the release is ensured. Moreover, with DevOps, the reality check can happen in real time rather than taking the code offline and testing it.

    On the whole, the popularity of DevOps over the years has intertwined quality into every engineer’s responsibility, which is a positive sign. This helps in addressing the needs of the market and ensure that customers do not suffer. QA further enables and directs teams to check the application for performance and quality before it is delivered.

    The role of QA in the current software development process is changing, where the customer comes into focus and the needs of the customer are brought into perspective while delivering the application. Releasing new and functional builds at any point through the application’s life cycle can become a disaster if quality is not ensured constantly. Automation of tests plays a critical role to guarantee quality and bring speed.

    Building a QA strategy with the necessary best practices is essential for organizations that are embracing the DevOps movement. This will help in delivering effective software development and operations to achieve user experience. DevOps practices are adopted to improve the regularity of the releases and reduce the defects. It is a methodology that boosts rapid, short, iterative development and deployment of applications.

    So, the idea of incorporating QA is to ensure continuous improvement in the delivery process. DevOps helps digital enterprises to meet the needs of the competition and enable overall business growth. As a result, enterprises are able to streamline and pace up the delivery of applications with changes and innovation.

    Best Practices for Incorporating QA in DevOps

    The key aspect to consider while merging QA with DevOps is that the QA and testing teams must team up with the technical teams. In this way QA becomes an enabler for ensuring quality in the software development cycle. In addition, it is important to define tangible aspects of the quality that are expected from the project/application. This helps in achieving results within stipulated time frames.

    Putting down the quality metrics is absolutely critical in DevOps, which helps teams to identify bugs early in the development cycle. Defining the metrics also enables teams to integrate them within the organizational culture at various levels. In this way, quality is ensured at every level and development teams also get enabled.

    The idea of DevOps is to make the developer think in line with testers and constantly check the code for potential errors. On the other hand, a tester who holds the responsibility to test the application/software with various testing tools and methodologies also needs to fix the code. In this way, enterprises with an inadequate QA or testing strategy cannot ensure continuous testing and continuous delivery.

    In Conclusion

    The application scenario is changing and it is getting very complex. DevOps can speed up the development, but what can you expect without a robust QA strategy? QA is absolutely integral to the DevOps process. Continuous development and delivery is impossible without a comprehensive QA/testing strategy.

    This blog has been drafted in collaboration with Cigniti Technologies, an independent software testing company. Click here to read more blogs on DevOps.

    About the Author / Komal Lopez

    Komal Lopez works with Cigniti Technologies and is instrumental in helping enterprises take better decisions related to Quality Assurance products, tools and services by leveraging research and content. She specializes in writing about technology trends, testing trends and has been in the Marketing and Communications industry for over a decade. Connect with her at komal.lopez@cigniti.com