Tag: application testing

  • SauceCon Speaker Profile: Adam Carmi, CTO of Applitools

    SauceCon Speaker Profile: Adam Carmi, CTO of Applitools

    Carmi to present a live coding session on testing responsive sites 

    Testing responsive sites and applications can be quite a challenge for development teams. We are fortunate to have Adam Carmi, CTO of Applitools, presenting a session at SauceCon on “Advanced Test Automation Techniques for Responsive Apps and Sites.”

    During Adam’s presentation, the audience will participate in a live coding session to learn how to effectively design responsive page objects, implement generic tests that work for all the layouts of their apps, control the browser’s viewport size to accurately target layout transition points, incorporate layout-specific assertions in their tests, and visually validate the correctness of their app’s layout​.

    Adam is passionate about everything related to software development and testing and is excited to share his knowledge with (and also learn from) similarly passionate practitioners.

    As CTO and co-founder at Applitools, a cloud service for automated visual testing, Adam spends most of his time developing image processing algorithms. However, he loves testing of all sorts, from designing the product to maximize testability to unit and API testing and, of course, automated visual testing.

    Adam regularly speaks about software testing at conferences around the world and organizes the Israeli Selenium Meetup group. He loves to ski and tries to stand on his hands as much as he can! When not working, he enjoys working out, watching movies and playing video games with his two children.

    SauceCon, the first-ever Sauce Labs user conference, is a three-day event filled with training, workshops, best practices and visionary content from the leading minds in automated testing. For more on upcoming SauceCon presentations or to register, visit the SauceCon website.

    About the Author / Rebecca Cramer

    Rebecca Cramer is a writer and communications strategist specializing in technology. With more than 20 years of experience across disciplines including marketing, internal and executive communications at companies such as Dell and Quest Software, Rebecca is passionate about creating and sharing good content of all kinds. In her spare time, she enjoys spending time at the beach and hiking in her native Southern California.

  • Testing: Your Secret Weapon for DevOps Success

    Testing: Your Secret Weapon for DevOps Success

    I spend virtually all day, every day, speaking with IT leaders who recognize that their bottom line ultimately rests on their ability to accelerate the delivery of innovative software. That’s why they’ve invested so much in digital transformation initiatives—including hiring the best and brightest developers, scaling Agile, driving DevOps adoption, automating the continuous delivery pipeline, and all the other components involved in moving from ideation to delivery as rapidly as possible.

    In most cases, this investment has exposed opportunities to optimize culture, process, and tooling—but not yet delivered the level of acceleration and flexibility that IT leaders expect. I’m frequently asked: “Now what? I think we’re ‘doing’ DevOps. But what else is needed to deliver on faster innovation?”

    Something as unsexy as “transform testing” is not what people expect to hear. As someone who’s been in the software testing industry since 2003, I know that software testing is typically seen as a necessary evil, not a strategic advantage. However, I’ve also witnessed how it can be a secret weapon for surging ahead of the competition.  

    The dirty little secret in the IT industry is that despite all the advancements in software development, software testing remains dominated by yesterday’s application lifecycle management (ALM) tools and manual testing—and they simply don’t meet the needs of today’s accelerated development processes. Transforming testing for the modern era represents a tremendous opportunity. It’s a low-hanging fruit that can help you increase acceleration, reduce risk and cut costs.

    Boost Acceleration

    Agile and DevOps initiatives aim to accelerate the process of delivering working software to the end user. However, even organizations that have adopted Agile and DevOps report dismal test automation rates: less than 20 percent for end-to-end testing. This means that after the rest of your software delivery pipeline is automated and optimized, an outdated testing process eventually emerges as the bottleneck. By transforming testing, you can increase your throughput significantly. I’ve witnessed many companies increase time to market by 55 percent by modernizing their testing process.

    Reduce Risk

    Now that software is the primary interface to the business, a software failure is a business failure. Yet, with today’s compressed and continuous delivery cycles, it’s simply impossible to test everything before every release—even if testing is automated. By aligning testing with your top business risks, you can automatically assess the overall impact to the core user experience and instantly determine if the release candidate has an acceptable level of business risk. This is critical for stopping high-risk software from impacting your prospects, customers, and partners.

    Companies still relying on traditional quality processes and platforms are usually covering only about 10 percent of their top business risks with their current test suite. A goal of 80 percent is typically achievable with about three months of effort.

    Cut Testing Costs

    There are hard costs associated with trying to retrofit outdated testing processes and tools into modern delivery processes. Many organizations try to bridge the testing gap by throwing an abundance of manual testers at the problem, typically through a global system integrator. By the most recent estimates, this approach consumes approximately 35 percent of an average IT budget—a total of $30+ billion per year, globally.

    A way to help testers achieve high test automation rates allows you to reallocate a large portion of that testing spend toward creative tasks which advance competitive differentiation. Many enterprises that transitioned manual testers into “scriptless” (non-technical) test automation have slashed testing costs—and eliminated one of the most significant constraints to achieving faster time to market.

    Get the Analysts’ Perspective

    Analysts at Forrester (e.g., Diego Lo Giudice) and Gartner (e.g., Joachim Herschmann and Thomas Murphy) have spent years advocating that transforming testing is a business imperative. If you’d like to get their perspective, I encourage you to review some of their latest research:

     

    About the Author / Sandeep Johri

    Sandeep Johri, CEO of Tricentis, has more than 25 years of experience as a technology executive and serial entrepreneur—including roles at Hewlett-Packard, Appcelerator, Oblix (acquired by Oracle), Blue Lane Technologies (acquired by VMware), and numerous other startups in Silicon Valley and India. Johri earned an MBA from Stanford University, a Master’s degree in Industrial Engineering from Wayne State University, Detroit, and a Bachelor’s degree in Mechanical Engineering from Pune University, India. Connect with him on Twitter.

  • Relevant Continuous Testing: The Primary Key to DevOps

    Relevant Continuous Testing: The Primary Key to DevOps

    My recent blog, “7 Pillars of DevOps,” identified seven essential best practices areas that make up successful DevOps and explained that the pillars are not silos, but rather foundations that need to be kept in balance. One of the pillars is continuous testing (CT).

    For well-balanced DevOps, CT performs tests that are fast enough to just fit within the time budget, yet thorough enough to cover the quality needed for deployment to production. Despite the need for balance, CT can be considered the true backbone of DevOps because testing is the one pillar that proves the validity of changes needed to operate and validate the correct operation of the other pillars from end to end across the pipeline.

    Compared to older testing strategies in which large software changes were tested as a complete product after “release to QA,” DevOps CT strategically tests changes incrementally over a series of DevOps stages. CT begins the moment a change is made in development and continues through all DevOps pipeline stages. Release readiness is judged on analysis of test results accumulated prior to deployment. With Blue-Green, A/B and Canary test strategies, some tests may continue into the live environment after deployment, and the results may influence future CT activities.

    Like continuous integration (CI), frequent, small, incremental testing has many merits. Quick feedback on problems enables a release consisting of many individual changes to be tested incrementally with confidence. The root cause of problems can be isolated much faster when the changes are tested incrementally. The problem is determining which tests are most relevant to run at each stage of a DevOps pipeline with content, with the risk of changes varying widely from one change to the next.

    Given that testing is a stochastic sampling process, there is no such thing as 100 percent testing in any absolute sense. Left unchecked, the content of tests will grow exponentially beyond the content of the product that is being tested. No number of test resources, even if elastic on-demand cloud infrastructures are used, will keep up with the growing demands to satisfy test requirements. The key is to create and choose tests that are most relevant to the changes that are being processed in the pipeline rather than attempting to run all tests with no regard to actual matter what the changes you wish to inspect. A strategy that chooses the most relevant tests at each stage in the pipeline is optimal.

    Several strategies for creating and selecting relevant tests are described below. These relevant test strategies may be used standalone for specific DevOps stages or a plurality of these relevant test strategies may be used end to end across the pipeline.

    1. Choose tests that focus on source code deficiencies. Metrics based on static analysis scans can determine which areas of source code have the highest number of defects. Test creation and selection algorithms can provide higher weight to tests written for those areas. This seems like a good idea; however, there are several limitations. Scan tools are limited to specific languages, may miss critical defects and do not have intelligence regarding the systemwide relevance of a specific defect.
    2. Create and choose tests for areas of the code with low test coverage. This also sounds like a good idea, but it is not. The most obvious reason is that tests probably are not available to select or the coverage would have been higher in the first place. Also, code coverage algorithms, especially at the system level, are limited to simple metrics such statement coverage, which is not a good indicator of system-level performance.
    3. Create and choose tests that match the artifacts of build changes including build dependencies. In this approach, tests are mapped to build changes and tests are selected that match the changes. This sounds logical, but unfortunately, a static mapping between test and build artifacts may not reflect system impacts of changes, as critical failures may occur due to interactions with modules outside the build dependency chain.
    4. Create and choose tests per risk analysis. This approach keeps a running record of code changes correlated to test results. Tests that tend to fail the most when a code module is changed are selected. This approach has several advantages over the other approaches. Test selection is not limited to implementation language or build dependency maps. Empirical experience correlates to risk better than code structures in the stochastic context of testing. The same algorithms can be applied to every stage in the pipeline. And the pipeline metrics can be adjusted dynamically for each pipeline stage run.

    The above CT practices indicate that relevant testing strategies reduces the time for CT execution and reduces the infrastructure cost for CT, without sacrificing quality delivered to production.

    Summary

    What do you think? Do you agree with the above relevant continuous testing practices? Are there others you recommend?

    While DevOps implemented with all seven pillars provides a strong foundation for long-term enterprise business improvements, it is important to understand DevOps is not an island. Enterprises implementing DevOps should be aware that DevOps interoperates with other IT systems and practices. Enterprises are well-advised to put in place governance policies that encourage the selection of tool-agnostic IT partners with solutions that best suit the needs of each unique enterprise and can integrate and evolve DevOps together with all their IT systems.

    — Marc Hornbeek

  • How the Lure of an ‘Easy Button’ Installer Traps Projects

    How the Lure of an ‘Easy Button’ Installer Traps Projects

    As preamble for this post, I wrote about the Unicorn Installer challenge. The challenge is that user needs are too deeply heterogeneous for good reasons to create a vertically integrated way (aka an “easy button”) that works for all users. The problem is not just current diversity, it’s also about how we cope with needed changes in the future that would force users to straddle configurations.

    Don’t despair! There is a practical solution to shared ops on project installers: composability.

    If projects focused on maintaining install modules for their specific components, then the community could collaborate on well-bounded problems that should be infrastructure-agnostic. Even building in multiple scripting DSLs (Ansible, Chef, Puppet, Salt or Bash) is a much smaller-scope problem. Further, all of these DSLs have modularity concepts so it’s feasible to pull in community roles/modules/gains/plays into larger automation script. This approach allows us to decouple snowflaked infrastructure and prerequisite configuration from the project configuration.

    At that point, the proverbial “easy button” becomes an opinionated set of project, prerequisite setup and infrastructure-specific steps. These then become vendor-specific buttons: “Press here for the fast AWS install with Dejour SDN and L8istSh9y O/S” as was showcased to great effect at Dockercon.

    With that said, let’s look at how trying to create an “easy button” installer inside the project backfires.

    Cloud Foundry chose to have an in-project installer, BOSH, that has an opinionated installation approach based on generated images. To work, the installer has to maintain an increasing number of BOSH-specific integrations and image generators. These efforts are redundant with other tools non-core to installing Cloud Foundry. Further complicating the story is Pivotal, a primary Cloud Foundry maintainer, which considered BOSH a product differentiator. This creates ecosystem conflict with other Cloud Foundry vendors. While BOSH helps create robust installations, it also drags along a lot of baggage that keeps those improvements from being more generally accessible. For all of the expected ease of installation for BOSH, Cloud Foundry is still considered difficult to install.

    OpenStack installers are a very confusing story, with multiple competing in-project installers. Starting from the single-node DevStack, which provides all of the continuous integration/continuous delivery (CI/CD) testing to the confusing over-cloud/under-cloud OpenStack-On-OpenStack (aka Triple-O) concept. Neither of these initial in-project attempts created practical, universal installers. In fact, they’ve spawned waves of other installers and configuration scripts. Recently, OpenStack decided to allow many of these attempts into the project (aka “big tent”) without coordinated governance making it impossible for operators to determine which efforts they should be tracking. Having some efforts stamped with “community approved” only makes it more difficult to solve cross-platform issues. The effect is further balkanization, as vendors and advanced operators attempt to build working automation silos against competing interests.

    As a positive example, Linux pre-seed and kickstart options are distribution-specific and support a healthy ecosystem. It would be easy to think of consolidating these installs into a single system; however, the likely result would be to lock together rivals and slow down innovation.

    What we want is a thriving ecosystem around a project without endorsement as one being THE install process.

    Why is lack of endorsement critical? It allows the project to advance without being slowed down by installation entanglements created when a single way is anointed. Worse, it discourages ecosystem activity around the project.

    The first successful installers were targeted at a single vertical stack, such as Kubernetes on CoreOS or a version of Salt Kube-up on Google. These monolithic install approaches are helpful jump-starts but limit community diversity. Yet, if they are presented as “the right way,” then other participants will be discouraged from innovating. It only takes one variation in a vertically integrated process for the whole process to become exception hell.

    Our early experience with Crowbar was that our initial installation ideas were not going to remain useful as the project and targets expanded. It was important that we could maintain Crowbar AND replace it with something better. The fundamental lesson is that operations around projects is an evolving practice.

    Hindering the evolution by selecting winners early actually slows the development process.

    This may be counter intuitive; most projects want to embrace “easy button” installers to reduce start-up costs. These critical builders of initial traction may actually undermine projects as they enter a operational maturity phase by creating a fidelity gap between initial and sustaining use cases.

    — Rob Hirschfeld

  • 7 Reasons to Move to Parallel Testing

    7 Reasons to Move to Parallel Testing

    While development operations are more scalable now than ever, there is one area that continues to constrain the ability of organizations to scale: functional testing.

    Most organizations still rely on sequential tests to deliver quality assurance. No matter how rapidly a business can produce great products, its ability to bring them to consumers quickly is limited by its dependency on a slow, tedious testing process that does not adapt well to changing development needs or ever-faster business processes.

    That, at least, is the way things traditionally have been. But today there’s a replacement for sequential testing: parallel testing, which lets you leverage the cloud and virtualization to perform more tests at faster speeds than your physical infrastructure or homegrown testing grid could support on its own.

    What is Parallel Testing?

    First, a definition: Parallel testing is the process of running multiple test cases on multiple combinations of operating systems and browsers at the same time. The process is automated, and it often runs on virtual machines. For the QA professional, no additional effort is required once the appropriate test scripts have been developed. All the testing solution needs is the test suite and a pool of resources.

    Granted, new does not always equal better. But it is hard to make an argument against parallel testing, especially if you leverage a robust testing cloud. Here are seven key advantages of parallel testing to consider over sequential testing:

    You Can Test for Wider Compatibility

    Because parallel testing is faster, it allows you to test for wider compatibility in the same amount of time. If you’re releasing a new app and want to test the user interface (UI) functionality, you don’t have to limit yourself to testing against only the most popular OS and browser combinations or mobile devices—you can test all the combinations that are important to your users.

    You Can Radically Reduce Testing Time

    Good software testing must be thorough and comprehensive. In a sequential testing environment, it can be (and usually is) a very time-consuming process. Parallel testing can divide invested time (roughly) by the number of test machines being used in parallel, so that overall testing time is a fraction of that required for sequential testing.

    For example, if you are running 10 concurrent tests, you can reduce your testing time by a factor of about 10. This can cut days or even weeks from delivery time. This reduction in testing time also allows you to make more efficient use of your engineering team. They are freed from a set of necessary but time-eating and repetitive tasks, allowing them to concentrate on more forward-looking and innovative projects.

    Parallel Testing Optimizes Continuous Integration and Delivery

    Modern development best practices such as continuous integration and delivery require frequent and rapid functional tests. The execution of pre-scripted tests on a web or mobile app saves considerable time, plus having test data accessible in detailed reports is valuable to development teams who can use this information to quickly identify issues. Parallel testing in the cloud allows you to execute test suites continually as developers submit and integrate code changes throughout the day.

    The Cost per Each of Your Tests is Less

    Because parallel testing is automated and and can run at high concurrency in the cloud, the cost per test is considerably less. Leasing test time on a cloud testing service generally will be much less expensive than building and maintaining your own test infrastructure.

    Even the common practice of using development hand-me-down computers as test machines has its costs and practical limits. For example, as used systems age, they require more maintenance and they become less capable of duplicating real-world deployment conditions. Cloud-based testing grids mean environments have high availability, and they are up-to-date, making parallel tests the better option.

    It Supports Testing Science

    Parallel testing enables teams to focus on making tests repeatable, measurable and accurate. By simply testing faster, you can test more, and testing more produces more actionable data to find bugs and also improve test cases. Automated parallel testing delivers strong data on test results with key indicators of where tests can be improved. The net result is a test process that is more scientific.

    You Can Still Perform Sequential Tests, If and When Needed

    Parallel testing simply offers a different framework for testing, which can easily accommodate most or all of your existing test regime. This means that transitioning from sequential to parallel testing does not force you to sacrifice test targets, strategic testing goals or test quality.

    If anything, moving to parallel testing increases the range and depth of your test program, allowing you to better meet your test goals and it improves the quality of your testing. When you make the move to parallel testing, you are not abandoning traditional software testing. You are simply applying modern development practices and technology to it.

    You Do Not Need to Make the Switch to Parallel Testing All at Once

    The great thing about parallel testing is that you can transition to it in steps, starting with the tests that are most easily converted to parallel, then adapting some or all of the remaining tests after your team has had time to adjust to the parallel testing environment. Once you have started to use parallel testing and have integrated it into your development process, it is easy to expand the quantity and scope of parallel tests as the need arises.

    Conclusion: A Faster Test Run is a Penny Earned

    The faster you run a test, and the more tests you run, the more frequent the releases and the more defects you can find. The math is simple. Parallel testing in the cloud decreases the cost of maintaining test infrastructure, the cost of lengthy testing cycles, the cost of delayed releases and, finally, the branding cost of unhappy customers due to poor application quality.
    Even without changing the way you test, a shift to a parallel testing environment will provide an immediate speed enhancement—which means every test that still runs serially is a cost that can be avoided. And every test run in parallel is an opportunity to test your application better and faster at the same time.

    About the Author / Lubos Parobek

    Lubos ParobekAt Sauce Labs, Lubos Parobek leads strategy and development of Sauce Labs’ web and mobile application testing platform as VP of product. His previous experience includes leadership positions at organizations including Dell KACE, Sybase iAnywhere, AvantGo and 3Com. Parobek holds a Masters in Business Administration from the University of California, Berkeley.