Tag: continuous testing

  • Tricentis Expands Scope of Cloud-Based Testing Tools

    Tricentis Expands Scope of Cloud-Based Testing Tools

    Tricentis this week extended a suite of cloud-based testing tools that promise to make it simpler to both develop cloud-native and mobile applications and migrate existing applications to the cloud.

    New capabilities added to the portfolio include integrations for cloud-based planning tools and a wider range of testing capabilities for mobile applications. DevOps teams can now, for example, deploy Tricentis qTest platform for managing the testing process within a Kubernetes cluster. Tricentis has also made it simpler to configure and update its Tosca suite of application testing tools.

    In addition, Tricentis added additional capabilities for testing SAP applications running in the cloud that previously were deployed in an on-premises IT environment.

    Martin Klaus, vice president of product marketing for Tricentis, said the goal is to make it simpler for DevOps teams to integrate continuous testing for various types of applications within their DevOps workflows. DevOps teams have the option of invoking the Tricentis suite of testing tools via a software-as-a-service (SaaS) platform or deploying them on a cloud platform themselves using templates provided by Tricentis.

    While developers are clearly getting more involved in testing, Klaus said it’s critical for testing capabilities to be integrated within a DevOps pipeline. Each developer is typically only working on a component of a larger application. Unless testing is conducted on an end-to-end basis, an organization won’t be able to determine the real quality of the application experience before deploying software in a production environment, he noted.

    As a result, the decision about what tools to use as part of a continuous testing process is now being made by DevOps team leaders rather than individual developers, added Klaus.

    Ultimately, the goal is to automate as much of the continuous testing process as possible. Achieving that goal will require increased reliance on artificial intelligence (AI) technologies, though to varying degrees, said Klaus. Those capabilities, however, are not likely to eliminate the need for dedicated testing professionals; instead, AI will enable those teams to more efficiently test increasingly complex application environments, he added.

    In fact, it’s becoming practically impossible for testers to manually inspect every element of an application without the help of, for example, algorithms that apply computer vision to analyze a user interface, noted Klaus. There will always be higher-level tasks that require a human, but AI technologies will play a significant role in enabling testing at scale as organizations start to build more applications, he added.

    In the meantime, it’s clear that there’s a lot more riding on testing as organizations continue to launch digital business transformation initiatives. In many cases, organizations only get one chance to convince end users that a new application being rolled out is better than the processes they previously employed. As such, the need to streamline testing within the context of a DevOps workflow has become critical—there is little tolerance for bottlenecks that slow down the rate at which applications now need to be built and deployed.

  • How SREs Benefit From Feature Flags

    How SREs Benefit From Feature Flags

    When you think of who uses feature flags, your mind most likely goes to software developers. In general, feature flags are closely associated with software engineering.

    But site reliability engineers (SREs), too, can benefit. SREs may not be the ones to create feature flags, but they should work closely with developers to ensure that the applications their teams support include feature flags.

    Here’s why feature flags benefit SREs, and what SREs can do to make sure their organizations take full advantage of them.

    What Is a Feature Flag?

    A feature flag—also sometimes called a feature toggle—is a technique in software engineering that allows developers to turn specific features on or off at application runtime. In other words, they let you control which features are available within your application when it’s deployed to production.

    Feature flags can be configured in such a way that they enable features to be toggled on or off for specific sets of users, rather than an entire set of end-users. This is useful if, for example, you want to turn on an experimental new feature for users who have agreed to test it without exposing that feature to your general user base.

    Usually, developers and SREs use feature flags to turn features on and off manually. But you could automate the process by, for example, writing a script that automatically shuts off a feature if your observability tools determine that the feature is causing a problem for users.

    Why Developers Love Them

    The main reason why feature flags are popular among developers is that they make it easy to implement and experiment with new features while keeping the development pipeline simple.

    Without them, developers would have to create a new application release every time they wanted to implement new features. If any of the features in that release turned out to cause a problem, they’d have to remove the features from the code or fix the buggy features, then deploy a new release. This approach is tedious and it leaves teams prone to delayed releases and application rollbacks.

    But with feature flags, developers can continuously add new features to an application without worrying that bugs within those features will lead to a rollback or a delayed release. If one feature has a problem, developers can simply turn it off using a feature flag, without having to do a new release.

    How SREs Can Benefit

    It’s not just developers whose lives are made easier—SREs, too, can leverage feature flags as a way of supporting the core SRE goal: Maximizing reliability.

    That’s because feature flags minimize the risk associated with fast-moving software development pipelines. They allow teams to experiment with new application functionality—which is important if they want to keep pushing out application enhancements to delight users—while at the same time providing a safeguard against buggy feature implementations.

    Imagine, for example, that you’re an SRE and you discover that the latest release of an application you support has a severe latency problem due to an issue with a new networking feature in the app. If that feature is controlled via a feature flag, you can remediate the issue very quickly by simply switching it off. You don’t have to wait for developers to fix the underlying code issue before you can solve the problem for your users.

    Limitations

    This doesn’t mean, of course, that feature flags are a cure-all against reliability problems.

    They won’t help you if the root cause of your reliability issue lies within your infrastructure rather than your software. If an app crashes because you misconfigured your Kubernetes clusters or you ran out of server capacity, for instance, you can’t simply turn the problem off with a feature flag.

    Note, too, that feature flags can only be applied to specific features. In other words, they can only control application functionality if developers deliberately created one to control that functionality before releasing the app. If you discover a bug that’s not managed by a feature flag, the only way to remediate the issue is to redeploy the application (or microservice, if the problem is limited to just one microservice).

    How SREs Can Encourage Feature Flag Use

    As an SRE, you most likely don’t have direct control over the software development process. You’ll therefore need to collaborate with developers to ensure that they build feature flags into their applications.

    Doing this is simple enough. Start by educating developers and making sure they understand the benefits. Be sure, too, to identify which features are most likely to create reliability issues, so that developers can prioritize creating feature flags for them. And consider factoring them into your incident response playbooks, which will ensure that incident response teams remember to take advantage of them when possible to remediate issues quickly.

  • Testing Challenges in 2022 – Techstrong TV

    Testing Challenges in 2022 – Techstrong TV

    Stephen and Alan discuss the biggest testing challenges in 2022, along with the tools and methods needed to solve them. The video and a transcript of the conversation are below.

    Recording:              This is Digital Anarchist.

     Alan Shimel:            Hey everyone. Welcome to another Techstrong TV interview here. My guest for this segment is Stephen Feloney of BlazeMeter. I think it’s BlazeMeter by Perforce. Is that correct Steve?

     

    Stephen Feloney:    That’s correct.  

     

    Alan Shimel:            Yep. And for those who aren’t familiar of course Blaze Meter was originally founded by a friend of mine Alon Girmonsky. Great story around one of the pioneers in open source testing and continuous testing. Blaze Meter was acquired I guess it had to be six years ago, maybe more, by at the time called CA or CA Technologies, Computer Associates. Then it always kind of operated kind of semi autonomously. And then I guess it was last year they found a great home with the folks at Perforce who have also been around a while. And Perforce is of course a leader and really expanded their capabilities from code repository to testing and so many other things. So it was a good match, Blaze Meter and Perforce. We’re happy to see it. Steven so I gave the Blaze Meter story but I can’t give the Stephen Feloney story. I need you to do it.

     

    Stephen Feloney:    Oh well we’ll need hours to give my story.

     

    Alan Shimel:            Give us the short version.

     

    Stephen Feloney:    So I’ve been in testing more or less for 20 some odd years. I came to CA must have been seven or eight years ago. And I was part of the team responsible for acquiring Blaze Meter into CA. And I always had plans for Blaze Meter. And as you mentioned it sort of ran autonomous inside of CA. And then CA was acquired by Broadcom and then once we were in Broadcom I was able to expand Blaze Meter to go beyond performance and we added a multitude of features, virtual services, API testing, API monitoring, grew all that. And now as you said we found a very good home with Perforce and that acquisition happened right at the end of October of last year.

     

    But I’ve been doing product management work for, I don’t know, about 15 – 16 years almost exclusively in the testing space, a little bit in the mobile space and a little bit in the monitoring space. And what’s interesting is moving around going from testing to mobile development and mobile testing and then into monitoring I now have all of that with Perfecto and Blaze Meter coming together at Perforce. So I have the monitoring. I have the mobile. I have – it’s all coming together. So everything I’ve learned over the years I can make it all come together and work in one spot.

     

    Alan Shimel:            So give us your best Dr. Evil and tell us isn’t it great when something comes together like that?

     

    Stephen Feloney:    Yeah. It’s fantastic and I hope to make one billion dollars.

     

    Alan Shimel:            Absolutely. Good stuff Steve. So look. Let’s first of all we’ve had the pleasure of talking to several of the Blaze Meter folks since the acquisition by Perforce. And it really does seem to be a good match. But what I wanted to kind of focus in on today is maybe the state of continuous testing if you will and then a little bit of what specifically at Blaze Meter what’s new. What’s coming down the pike that we can be on the lookout for here.

     

    Stephen Feloney:    Sure. Sure. So Blaze Meter historically has been a performance testing solution built upon open source as you mentioned and we were, we play two different roles. We work with centers of excellence who are doing large, massive load tests. And then we work in a shift left world with agile teams. And we were noticing struggles when it came to testing with the agile teams. So when you’re looking at continuous testing, continuous testing is well, a continuum. So it starts off with the development and the agile groups, works along sometimes into a full end to end testing and then continues into production.

     

    And so if we talk about that continuum we look down at the agile teams and we noticed that they were struggling. They weren’t testing as much as they should. And we interviewed dozens of different companies to try to understand what were their challenges with this. And there were a multitude of challenges. One is they didn’t like using multiple different tools to try to get all the testing done, whether it’s a functional test, a performance test, an API test, unit test, all different types of testing, all of these different tools. Some have to be downloaded onto our devices. Some are in the Cloud. They all have different UIs, reporting. That’s a challenge. And then another challenge was we don’t have time to get data. I mean think about it. When you’re testing you need data.

     

    Alan Shimel:            Yeah.

     

    Stephen Feloney:    But it wasn’t just data to run the test because why can’t you do that. Then I need data for the back end system and then I need data if I don’t have my full environments and I’m using mock services or virtual services I now need data for that. How do I get all that data in and make sure it’s all in sync? Because when I’m developing code I have a very limited time to develop that code and get it out the door and if I have to spend time trying to figure out get all this data and sync all this data together, that’s a challenge.

     

    And then well with that challenge as I mentioned I don’t have my full environment. So now I need virtual services. Where do I get those? Who is developing those? And then I have to figure out what data did they put in? So the mock services, the virtual services as well as the data, two big problems that are hindering people from getting their testing done. And then we have other issues around how do I generation my test. I just want to develop. I don’t want to spend my time creating all these tests. So those are challenges there and then on the flip side if I’m trying to do continuous testing and I’m trying to continue the testing into production what tests do I set up.

     

    How do I monitor? How do I test in production when I don’t know what I tested, when there’s not a full collaboration across the entire value stream? How do I know what to test in production? Who is creating those tests? Do you have your ops team and are they monitoring or testing the same things that I wanted to test or that I did test in preproduction? So those are quite a few of the challenges that people run into when they’re trying to do continuous testing and continuous testing at scale.

     

    Alan Shimel:            Absolutely and emphasis on that scale because really that’s where you start seeing the cracks. That’s where you start seeing – when you’re not at scale sometimes you could muscle it. Right? Or fake it even. But when you start hitting scale man, it’s like whatever your weakest points are they’re going to just come right to the forefront.

     

    Stephen Feloney:    That’s correct.

     

    Alan Shimel:            You’re doing to say oh my goodness. This doesn’t scale. Right?

     

    Stephen Feloney:    No. That’s right because you could have like one group, one team, one service that’s able to do something that’s special, unique and they could get that out the door in their own special way. But when you’re trying to scale that either that service or application has grown or you’re trying to scale it in an enterprise as you just said all the cracks show. The whole thing falls apart.

     

    Alan Shimel:            Agreed. All right. Let’s talk about what’s new at Blaze Meter then. What are we doing to help?

     

    Stephen Feloney:    Well surprisingly a lot of the challenges I just mentioned we’re able to solve just coincidental.

     

    Alan Shimel:            I’m shocked.

     

    Stephen Feloney:    I’m shocked as well. I mean I didn’t know this was coming. Yeah. So one of the things we actually just released on February 3rd was our Blaze Meter test data piece of Blaze Meter. And this combined the ability to whether it’s for performance testing, functional testing, API testing we can generate the data that you need. And that data that gets generated is not just to generate the data to drive a test. We’ll also generate the data if you’re using mock services or virtual services, generate the data for that as well and generate data for system undertests.

     

    And the idea is all that stays in sync. And we’ll generate the data at the time you want to run the test. So now you don’t have to worry about managing, maintaining the data sets. You don’t have to worry about that. We will generate the data on the fly and to run the tests and to ensure that all that data is in sync. That takes away a lot of the false positives that you’ve seen in the past where things are failing. Oh but it turns out it was the data in the virtual service or the system under test wasn’t set up the right way. And so all of that goes away and you don’t have to put any thought into it.

     

    Alan Shimel:            Crazy. It’s crazy that no one has thought of this before or kind of implemented this before when it seems rather elementary at some level. Like of course if you want to do this. But I had a conversation with the last guest here on Tech Strong TV and we spoke about the issue is maturation issue. Right? Until your devops processes, until your CICD processes are at such a level of maturity. Right, you don’t even run into this problem because you have problems that pop up before it that kind of take your focus away.

     

    Stephen Feloney:    Correct. Yeah. So in the past what’s happened is when you were handing it off to a testing team the testing team was used to the problem and they had time to get the data. They had time to set up the data. They had a gold copy of the data sitting around that they would use. They were familiar with it. But as you’re saying the CICD process, the shift left process happened the data problem, the virtualization problem is completely exacerbated. ‘Cause they don’t have the time. They don’t have the ability. They don’t have the skill set. They don’t have the desire to do all that. They want to get their code that they developed and they want to get that out the door as quickly as possible. And testing is sometimes seen as a hindrance. It’s a necessary evil – going back to Dr. Evil. A necessary evil if you will.

     

    And so anything that we can do to accelerate that and make it much easier for them that is the challenge. So yeah. You could say why wouldn’t someone have done this whole data thing. There are synthetic data generators. Right? There’s open source synthetic data generators. That’s fine. But that just generates the data in one spot. You still have to figure out how to take that, pull that out, put that here, put that there, put that there. And we’re taking care of all of that for you.

     

    Alan Shimel:            Got it. Very cool. Hey. For people wanting to get more information on that Stephen where can they go?

     

    Stephen Feloney:    They can go to blazemeter.com.

     

    Alan Shimel:            Just straight up right on the front page?

     

    Stephen Feloney:    Yeah. Just right on the front page. It’s our newest part of our release so you’ll see it there. You’ll see blogs. You’ll see help. We have multiple discussions on it. Yep.

     

    Alan Shimel:            Very cool. Hey. We’re coming up on time here. Anything else coming down the pike or you wanted to let our audience know about?

     

    Stephen Feloney:    Yeah. So there’s actually quite a few things that are coming down the pike. But one of the more interesting things that we are working on is one of the challenges that I had mentioned is generating tests. So they don’t want to spend the time to even generate the tests. And there’s two things that come with that. One is just generating your API tests. So we’re going to have coming soon an API test generator to help with that and that is combined with our well synthetic data gen. So those two are combined together to help generate that. The next thing that comes which is a natural evolution is you don’t just want positive tests. You need negative tests as well.

     

    And so that data gen is going to auto generate negative tests for you whether it’s negative data driving a test, putting negative data into your system test or having negative things happen with those mock services or those virtual services. So you want to delay a virtual service. You want to knock a virtual service so it doesn’t respond or just provide different types of data sets to see how well and how robust your system is. And once you do that the next step is all right. So I have negative testing. Then you combine the positive and negative together and now you have chaos testing. And so those are coming down as well.

     

    Alan Shimel:            Cool. Love it. Any – I don’t want to hold your feet to the fire, make you say anything you’re not supposed to say but what’s timeframes on those if you can talk about them?

     

    Stephen Feloney:    Well I’ll say this. By the end of the year you’ll see this. I don’t want to give solid timeframes but this year those will be coming out the door.

     

    Alan Shimel:            Ok. I think that’s fair Stephen. Hey. I want to thank you for coming on and updating, getting us up to speed here.

     

    Stephen Feloney:    Yeah. Thank you very much.

     

    Alan Shimel:            Continued success. We’re hoping maybe at some point we’ll see Blaze Meter at a real live conference.

     

    Stephen Feloney:    Oh I’m hoping to get to real live conference. As much as I enjoy maybe not traveling as much. But the interpersonal interaction.

     

    Alan Shimel:            Yeah, no. We all miss it.

     

    Stephen Feloney:    Yeah. I mean it’s a needed. It’s a must.

     

    Alan Shimel:            Absolutely man. Hey. Steve Feloney. BlazeMeter powered by Perforce here on Techstrong TV. We’re going to take a break and we’ll be right back with another guest.

     

    Stephen Feloney:    Thank you very much.

     

    Alan Shimel:            Thanks Steve.

     

     

    [End of Audio]

     

  • The Benefits of Crowdsourced Testing

    The Benefits of Crowdsourced Testing

    Charlene O’Hanlon and Rob Mason from Applause talk about how crowdsourced testing is a highly effective method for testing applications and its benefits to DevOps teams. The video is below followed by a transcript of the conversation.

    O’Hanlon: Hey, everybody. Welcome back to TechStrong TV. I’m O’Hanlon, and I’m here now with Mason with Applause. Rob is a return to TechStrong TV. Rob, welcome back. So good to see you again.

    Mason: Thank you, and thanks for having me on again.

    O’Hanlon: All right, so we had a great conversation, what was it, a couple of months ago?

    Mason: Yeah, a little while ago.

    O’Hanlon: I think so. Yeah, yeah, so time flies when you’re having fun, I guess. But, at that point, I did invite you to come back on so we could talk about the topic of continuous testing, which I think is something that is gaining a lot of traction in the DevOps space, and it’s certainly garnering a lot of conversation. Sorry, not continuous testing, crowdsource testing. Oh my goodness, my brain this afternoon, what am I going to do? Sorry about that. Yes, crowdsource testing, and it, too, is something that a lot of DevOps teams or a lot of organizations are considering as an alternative, I guess, or maybe a complement to the way that they’re doing testing these days. You are the expert in the field, so I want to talk to you about it and kind of get a download, if you will, on crowdsource testing. What you’re seeing in the space right now, who’s talking about it and what organizations, how they could benefit from it?

    Mason: Right. Thank you. Yeah, so Applause is the largest crowdsource testing company in the world. _____ [inaudible due to audio distortion] quality testing for some of the largest companies in the world, like Google, PayPal, Walmart, Amazon, Facebook, a lot of those different types of companies, and we do that digital quality testing by using a crowd. Applause actually started off as uTest about a decade ago, _____ the name uTest, so anyone could test. Basically, if you go to uTest.com, you sign up to become a tester. Today, that community is over 750,000 people from 233 different countries around the world, and they’re making money from testing products from the company, or the companies I mentioned before, as independent contractors. They bring their own computers, they decide what they work on, what they don’t work on, they bring their gear, they decide when they want to work.

    You start off by going to uTest.com, you sign up, and then we put you through all sorts of training. We have what we call uTest Academy, lots of great videos, training courses. It’s all free. You don’t have to pay anything for it. Joining the community is free. Once you join the community, you start to level up your skills as a tester, and you become better and better at writing great bug reports, with _____ the attachments, the steps to reproduce them, learn now to execute test cases, how to do payment testing or accessibility testing. We train you on all sorts of things around testing because we know there are not enough tests going on. We know there is not enough quality in our products today. It could always be better, and so ‒

    O’Hanlon: Yeah ‒

    Mason: Go ahead.

    O’Hanlon: No, no, you go ahead.

    Mason: I mean, with how fast the technology landscape is changing, you guys see it firsthand every day, it’s very easy to switch from one bank to another or from one app to another, and so it’s very important that that first experience is first class. More and more big brands are very much aware and very in tune with those first experiences and the ongoing experience of their users, so we use a very large community of real people in the real world, around the world, every country you can imagine. You know, 233 countries, as I mentioned. They level up over time to become more and more expertise. As they progress in their learning and participation, they get invited into more projects, so they get opened up to more ability to earn money, basically. When they tell us ‒ voluntarily, of course ‒ about themselves more, what devices they have, do they have an iOS device, android device, what kind of laptop they have, they get invited to more projects.

    The more they tell us, the more that we can match them to projects. We use machine learning algorithms to match testers to projects based on past experience, so we’ve got a data science team, and machine learning algorithms that match based on performance. It’s not based on demographics or race or ethnicity, it’s all based on what you can do, and what you can do is behind a screen. The machines don’t know. It’s based on did you turn up on time for the project, did you execute ‒

    O’Hanlon: Yeah.

    Mason: ‒ _____ well, were your bugs well written? It’s all based on pure scoring, which is great. Some of our projects do require physical presence, it will be like a test for Starbucks, and you have to go in and buy a coffee and prove that you can order it online and pick it up, and all that sort of stuff. But, most of them are remote, and you can work wherever you are, from your couch with your dog sitting on your lap, and still execute great testing for the customers. That’s what the community is really a lot like. Some of the projects do have demographic requirements, but mostly those are in the medical space or in fitness. For instance, we’ll be looking for a specific age class for testing online fitness classes for some of our customers, and so sometimes there are demographic requirements. But, for the most part, it’s pretty wide open for anyone to participate. What’s nice is in some of these communities, or sorry, in some of these countries, it’s hard to find jobs. Especially during COVID, we had about 50,000 coming in per month during COVID.

    O’Hanlon: Wow.

    Mason: That’s trailing off now with less people coming in, but with all the people that were out of work, you can make money at Applause. Some people do it as a moonlighting job on the side, just to earn some extra money, maybe some play money. Some people make a living out of it. As an independent contractor, again, they make their own time and everything, but they’re making a living off of Applause doing testing for these customers full time. Again, anyone can do it, so if you’re in a country where maybe women can’t get jobs because it’s old-school and it’s sexist there in that country or what have you, or you’re in a demographic that it’s harder to find work, uTest doesn’t care, like bring your skills, bring your abilities, and anyone can get work. If you look at our community, we’re incredibly diverse across, again, all those countries, but also in our global community, we have a high ratio of women in the community.

    Not everyone, obviously, tells us what gender they are, but 35 percent of our global community are female. We have top-rated testers in the community, 41 percent of our gold-rated testers, that’s the highest level tester we have, 41 percent of those are women, 40 percent of our silver testers are women, 40 percent of our bronze testers are women, so you can just see that across the board it’s, again, based on performance. It has nothing to do with gender or anything else, which just levels the playing field for a global economy, and for global testing of enterprise products. I’m sorry. I’ve been talking ‒

    O’Hanlon: No, that’s awesome. I love to get the download, so it’s like you kind of take it from there and just run with it. Wow. That’s really cool stuff. I think that the last time we spoke, you guys were working on a couple really cool projects, but it seems to me that this would be a great technology, or a great service, if you will, for organizations that really don’t have maybe an in-house testing environment, or maybe organizations that do have an in-house testing environment but really kind of want to go that extra mile and make sure really that all their bases are being covered. How much of your customer base, then, are those companies that maybe already have testing abilities in house but they’re just looking to kind of up their game, if you know what I mean?

    Mason: I would say probably almost all of them have QA ‒

    O’Hanlon: Really?

    Mason: ‒ of some sort, but the difference is QA in a lab with a relatively small team is very different than real world QA. If you have some simulators or some real devices in the lab, some browsers based in your lab, it’s very different than browsers around the world. Probably a lot of the enterprise companies have their sites localized into different languages. Probably in your lab in your local team, you may not have all those native language speakers, so that’s _____, so localization is one. Currency testing, payment instrument testing, all those things that happen in the real world, you know, poor networks, flaky networks, different flavors of Samsung devices or android pixels, all that sort of stuff. A lab test is great, and it’s a great way to make sure the base foundations of your applications are good on your mobile apps, but it’s very different when you get out in the real world, and that’s where the customers judge you.

    They don’t judge you for your lab experiences, they judge you when you get out in the real world, that’s important. Almost all of our enterprise customers have their own QA teams, but they admit, and these are big companies ‒ it’s Google, it’s Amazon, it’s Facebook ‒ they admit that they don’t have a big enough team, even at their size, to cover what they really need to do to test their applications. You need a company that can bring resources from around the world, speaking all the different languages, all the different currencies, all the different types of devices. I think the last time we counted, there were about four million different devices in the hands of this community, because everyone ‒

    O’Hanlon: Wow.

    Mason: ‒ has got a phone _____ [inaudible due to audio distortion], what have you, so you take all those devices and you bring them to bear on some of these huge problems of the large enterprise, and it changes the dynamics. It’s daunting if you want to build a product and launch it globally and have it be successful, and not know that it’s going to work the first time. Even if you get a great, large outsourcing firm based in India or over in Europe, they’re based in one area, in one region. They all speak probably the same language, a very similar language, they’re in the same area, the same currency. How do you get that global test? The answer is crowdsource testing. There is no other way to do it. It’s just not practical any other way. If you have to manage those masses of people, like how do you make sure that it’s not just total chaos, and that’s what Applause has really specialized in for more than a decade, is making sure that we give great quality in what we give back to our customers, it’s actionable, it’s precise. Every bug report from us has to have an attachment and a video, it has to have reproduction steps.

    Again, we don’t just do bugs for customers, we do all sorts of testing, like we test smart phones, we test smart TVs, smart cars, IoT, AR/VR. We do machine language, data collection, data collection from machine learning ‒ I said machine language, but machine learning ‒ so all sorts of things we do for our customers using this global community. When you think about it, I have 750,000 people I can bring to bear on your problems to improve the digital quality of your applications. Sometimes you need more data, sometimes you need _____ [inaudible due to audio distortion], sometimes you just need a lot of people to bang on a website, sometimes you need people to go deep and look for those hard-to-find bugs. It varies greatly, so we cover pretty much every area that you could expect of digital quality testing with that crowd, and we _____ [inaudible due to audio distortion] so you don’t have to think about it. That just allows us to scale, but what we’re really proud of is just how successful our community has been, how diverse they are, how broad and how deep they get.

    They are true experts, and a lot of these people in the community, some of them are just people moonlighting after working some other kind of job, but some are true QA experts that have been in the industry for decades and have just chosen this new way of life, because it’s flexible. You always work at home, or wherever _____ [inaudible due to audio distortion]. You can be on the beach and doing the job. It doesn’t matter to us, as long as the job gets done. It is the new world, and as COVID removed some jobs for some people, at least temporarily, we got an influx, but also people are now looking for that new way of working. We see the industry moving out of the offices, and that’s what we’ve been at Applause for a decade. Our community, the people doing the testing for us, have been outside of offices since we started, and so it is the natural way for us. It’s like welcome to our party, but now you have to figure out how to work ‒

    O’Hanlon: Right.

    Mason: ‒ _____ [inaudible due to audio distortion], and we’ve been doing that _____ for a long time.

    O’Hanlon: That’s very cool. On average, how many testers do you have on a particular project?

    Mason: It varies greatly, like sometimes we’re doing a global payment instrument test that’s making sure something like an android pay or an Apple pay works across the globe when they’re rolling out a new feature. There, we have to engage a lot of people to do that, to make sure that all the different banks, all the different currencies work around the world. Sometimes, it’s a point release, a patch release from a customer with a new version of their mobile app, they made some targeted changes, they’ve told us what they are, some regression testing around the area, a specific testing in that area, so it’s a smaller team, so anywhere from a handful of people to thousands of people at times. We don’t generally go much larger than thousands on a single project unless there is a very specific need. We do have some that spike up there in very large numbers, but, for the most part, we’re in the tens to hundreds range, less so in the thousands on a given, specific, what we call test cycle.

    For most of our customers, in fact all of our customers, it is subscription-based at this point, so they’ll sign up and have us test a digital asset over a long period of time, and so those assets go through their cycles. The first release is different from a patch release versus a new, major update, a new, major feature. Again, the size of those teams vary over time, and we can pull as many as we need into it. If there are different skill sets, like maybe a customer has a mobile app and now they’re focused on accessibility, and so they’re going to do a release 100 percent focused on making their application more accessible, we’ll bring in an accessibility group from our community and have them focus on accessibility. These are people not only that know accessibility testing well, but they’re people with real accessibility limitations, so it’s real people with real disabilities testing your application to make sure it works in the real world, because there is nothing more frustrating than trying to use an application that claims it supports you and then finding out it doesn’t.

    O’Hanlon: Right, right. Well, it sounds like great stuff, and you guys have been doing this for ten years or so?

    Mason: Yeah, just over 11, coming on 12 now.

    O’Hanlon: That’s great. How did you guys come up with this idea? I mean, I think it’s really kind of fascinating because it really does address a real problem that is in the industry, and that is being able to test all the things, if you know what I mean. Is this something that your founders just decided one day like, “Well, you know what? The best way to do it is let’s just ask everybody to do it, and everybody to help us out.”

    Mason: Yeah, our founders were engineering managers from the past, they were engineers, and they had the experience of building and testing applications in their own labs, and then going out in the real world and finding out that things were different when they got out to the real world. They said, “We have to change the model. The model isn’t going to work, and it’s only getting worse over time.” They said, “We have to go and turn this model upside down,” and they were far ahead of their time when they launched the company. Now there are some other much smaller companies out there doing some similar things, but they’re much more niche. But, they saw what was coming. The real world matters, and the differences are just ballooning and you just cannot keep up, even as a large company in the lab, so great foresight there. It took a lot of work to get to the point where you can manage that many people and have it be successful.

    Obviously, if you just put random people on a project and say, “We’ll do stuff for you,” you’re going to get terrible results and just waste your time. Obviously, places like Walmart and Facebook and others like that will not tolerate that, so you have to have a very good system and process around it. We have a special enterprise grade platform that our customers and community interface on, so we do software development to make our own platforms to allow those groups to interact with each other, and then we’ve got a great team of community management around them, recruiting people, training them, helping them learn how to be great testers. Ultimately, we’re making careers for people. We’re helping people make livings working for themselves wherever they want to be.

    O’Hanlon: That’s great, and we’re going to need to wrap this up here very soon, but have you heard of any stories of folks that joined the platform to do testing here and there, and ultimately decided that, “Hey, this is what I want to do for a living. This is what I want to do all the time,” and they ended up actually doing a career change because of this?

    Mason: Absolutely. In fact, we’ve hired several of those.

    O’Hanlon: Oh, really?

    Mason: It’s not generally the model, to hire from the community, because the community is our model, but sometimes they rise up so far and they’re such stars in the community, and we’re looking for additional help in managing the community, or elsewhere in our business, that we find them and bring them in. A lot of our great employees we have at the company are people that we found through the community, because they’ve come in and shown what they can do. There are others that have gone off and moved on to full-time positions in companies. Some of them do have full-time QA positions, and then work for us moonlighting. Some of them, like my daughter is in the community, anyone can be in the community. My daughter is in the community, and she makes a few bucks on the side and buys herself snacks or whatever _____.

    So, it really is a very diverse community of everyone who is just getting started or learning about testing, giving an appreciation for what it takes to make digital quality products, and what companies go through to test them, so I think it’s a great experience for everyone. I encourage every single person to sign up at uTest.com. Again, it’s free. We pay you, not the opposite, so you can make money. All you have to do is experience some digital quality products, give us good feedback, and help us make these products better for the planet, basically.

    O’Hanlon: That’s awesome. Well, Rob, thank you so much for walking me through this. I love the idea of pretty much crowdsourcing anything, because I truly believe in the collective intelligence of the populations. Anything that we can do to kind of encourage that and really take advantage of that at the end of the day, really capitalize on that collective intelligence and the ability of crowds to really do some good, I think is good for everybody. Thank you, again, and it was great having you on TechStrong TV again, and hopefully we’ll see you again in the future.

    Mason: My pleasure. It was great talking to you.

    O’Hanlon: All right, everybody, please stick around. We’ve got lots more TechStrong TV coming up, so stay tuned.

    [End of Audio]

  • ServiceNow Acquires DotWalk to Gain AI for App Testing

    ServiceNow Acquires DotWalk to Gain AI for App Testing

    ServiceNow today revealed it has acquired DotWalk to gain an artificial intelligence (AI)-infused application testing capability that runs natively on its software-as-a-service (SaaS) platform.

    Joe Davis, senior vice president for platform engineering at ServiceNow, said that testing capability will be made available free of charge to all organizations that build custom applications on the company’s platform.

    The number of custom applications being built on the ServiceNow platform has risen sharply since the start of the pandemic. Many organizations have taken advantage of the low-code tools provided by ServiceNow to build a range of applications that use the company’s SaaS applications as a foundation. That approach enables them to more quickly build applications that drive a wide range of digital business transformation initiatives.

    Davis said ServiceNow is committed to enabling organizations to improve the quality of those applications using a DotWalk testing capability that eliminates the need for developers to build and run tests themselves or for organizations to hire dedicated application testing teams.

    ServiceNow

    ServiceNow decided to acquire DotWalk because the company built a testing platform using machine learning algorithms specifically for the ServiceNow platform, noted Davis. The DotWalk tools also analyze logs in the background to identify and validate error sources that can arise during any application upgrade process.

    While there are a large number of professional developers that build applications on the ServiceNow platform, the company is also trying to encourage more so-called citizen developers to build applications. The challenge is many of the end users building applications lack an appreciation for design, security and what it takes to make sure an application scales as more users employ it. Testing tools infused with AI should make it easier for developers, regardless of experience, to build enterprise-class applications.

    Of course, professional developers will also benefit from AI-infused testing tools. Many developers have a tendency to cut short the application development process as they rush to meet application delivery deadlines. The end result, however, is that an application must be updated almost immediately after it has been deployed in a production environment. Testing tools that make use of AI will enable professional developers to more easily run tests they don’t have to build and then maintain, said Davis.

    One way or another, the number of custom applications built on SaaS platforms will increase as organizations digitize more processes. In the last year, more organizations have become adept at extending these platforms using a wide range of low-code tools that automate many aspects of application development. A significant percentage of those organizations are now also adopting DevOps best practices to better manage the pace at which those applications are developed and deployed.

    In the meantime, it’s too early to say precisely how AI will transform application testing. However, one thing that is certain is that even as the number of custom apps grows, applications will be more thoroughly tested before being deployed in a production environment.

  • Google Makes Fuzz Testing Integration Tool Available

    Google Makes Fuzz Testing Integration Tool Available

    Google today made available a ClusterFuzzLite tool that makes it simpler to incorporate fuzz testing into a DevOps workflow.

    Fuzz testing refers to an automated software testing technique that involves providing invalid, unexpected or random data as inputs to an application to discover issues such as potential memory leaks.

    Jonathan Metzman, a senior software engineer for Google, said ClusterFuzzLite is a lighter-weight version of a tool that Google makes available to its internal development teams. It is not a fuzz testing tool itself, but rather a tool that makes it easier to surface the results of a fuzz test within a DevOps workflow. Once those results are surfaced, it then becomes easier for developers to address issues before an application is deployed in a production environment.

    Core capabilities enabled by ClusterFuzzLite include continuous fuzzing, sanitizer support, corpus management and report generation tools. The goal is to make fuzz testing more accessible to a broader range of developers as part of an overall effort to embrace DevSecOps best practices, noted Metzman.

    ClusterFuzzLite currently supports GitHub Actions and Google Cloud Build, but Metzman said it is easily extensible to other DevOps platforms. It is designed to run as part of a DevOps workflow by adding a few lines of code to a continuous integration/continuous delivery (CI/CD) workflow.

    Google has already made ClusterFuzzLite available to open source projects, but is now providing additional access for commercial developers. Since its release in 2016, over 500 critical open source projects have integrated into the Google fuzz testing program for open source software, resulting in over 6,500 vulnerabilities and 21,000 functional bugs being fixed.

    In the wake of recent guidelines issued by the U.S. National Institute of Standards and Technology (NIST) that were themselves in response to an executive order issued by president Biden, the number of organizations using fuzz testing is expected to increase now that NIST has determined that fuzz testing is a minimum standard requirement for code verification.

    For several years, Google has been making a concerted effort to improve the security of open source software. The challenge for all developers is finding a way to build more secure applications without slowing down the rate at which they are deployed. Fuzz testing makes it possible to identify issues much earlier in the application development life cycle versus just before an application is deployed.

    Less clear, of course, is whether developers are starting to use these tools on their own or if the increased adoption is because of a concerted effort by their organization to embrace DevSecOps best practices. Regardless of the motivation, however, the overall state of application security should continue to improve as it becomes simpler for developers to invoke more advanced testing tools.

    In the meantime, organizations of all sizes are reviewing how they construct software in the wake of a series of high-profile security breaches. In theory, at least, increased focus on software supply chains should prevent issues from arising after deployment when they become much more costly to remediate.

  • CircleCI Adds Test Insights Module to CI/CD Platform

    CircleCI Adds Test Insights Module to CI/CD Platform

    CircleCI today announced it has added a Test Insights capability to its continuous integration/continuous delivery (CI/CD) platform to make it easier to identify tests that are either taking too long to run or simply exhibiting some form of anomalous behavior.

    Dawit Gebregziabher, product manager for data insights at CircleCI, said Test Insights is designed to make it simpler for IT organizations to shift more responsibility for testing further left toward DevOps teams that identify issues as applications are being built on the CircleCI platform.

    Each organization will still need to determine what tools to employ to create a test, but once it starts running, the Test Insights module will be able to surface the tests that, for one reason or another, are problematic to execute, he added.

    Test Insights, for example, will flag flaky tests and identify the longest-running and most failed tests. It will also enable DevOps teams to identify performance changes over time to pinpoint changes in application behavior.

    Finally, DevOps teams can track benchmarks at the organization, workflow and job level, as well as metrics for mean-time-to-recovery, throughput and durations for 24-hour, 7-day and 30-day windows of time.

    The challenge DevOps teams often encounter is a test may be run even when it’s apparent the application will fail. Test Insights makes it feasible for DevOps teams to manage the testing process much more efficiently, said Gebregziabher.

    It’s not quite clear how far testing is shifting left. There’s no doubt more developers are testing their code before it is loaded into a production environment to hopefully avoid issues that will only become more expensive to fix later. Other organizations have dedicated software engineers to create testing processes that are tightly integrated with CI/CD pipelines, noted Gebregziabher.

    However, many large enterprise organizations continue to also hire and retain dedicated application testing teams that are trained to identify issues that might either adversely affect the end-user experience or run afoul of compliance requirements.

    Regardless of who does what kind of testing, however, it’s clear there’s a lot more focus on addressing issues earlier when they are much less expensive to fix. The goal should be to make it easier to optimize when tests should run based on probabilities that ultimately reduce the time wasted running tests that either will fail or are, for one reason or another, flawed.

    Developers, of course, are all equally committed to running tests, so organizations will need to determine for themselves how far to shift that process left. However, at the very least, DevOps teams should be able to identify patterns that might indicate there is a need for additional developer training. After all, it’s unlikely a developer is going to understand there’s an issue until some meaningful metrics are shared.

    In the meantime, the more testing that occurs at a faster rate the more likely it becomes that an organization can provide a superior application experience the first time—and every time—an application is built and deployed.

  • 5 Steps to Succeed With Blue-Green Deployment

    5 Steps to Succeed With Blue-Green Deployment

    By allowing teams to maintain two production-ready environments at the same time, the blue-green deployment technique can significantly boost reliability. But blue-green deployment can also be difficult to execute and manage. Let’s unpack how blue-green deployment works, why it’s important and which best practices to follow for blue-green deployment success.

    Blue-Green Deployment, Defined

    Blue-green deployment is a software deployment technique in which teams maintain two identical but distinct environments that are capable of hosting a production application. One environment is “live” and actively serving users, while the other is kept in reserve.

    When it comes time to deploy a new version of your application, you deploy it to the reserve environment. You then test and validate it to make sure it meets performance and reliability requirements.

    If it does, you reconfigure your DNS or load balancers so that user traffic is directed to this environment, which becomes the new production environment. Meanwhile, the previous production environment is placed in reserve.

    Benefits of Blue-Green Deployment

    The blue-green deployment technique can boost reliability in several ways:

    • Environment parity: Because the reserve environment in which you test your application becomes the live production environment, blue-green deployment ensures parity between testing and production. In turn, it reduces the risk that configuration differences could cause unforeseen problems in production.
    • Failed deployments: If a deployment fails, it doesn’t impact your users because you deploy into the reserve environment. You can fix the issue while a stable user-facing version of your app continues to run in the other environment. 
    • Redundant environments: Although blue-green deployment is not a data protection or disaster recovery technique, having two production-ready environments available is useful in the event that one of your environments is wiped out by an event like a data center failure. In that case, you can restore operations quickly by using the other environment (provided it’s hosted in a separate data center, of course).

    How to Use Blue-Green Deployment: Steps and Best Practices

    While blue-green deployment is a great way to increase reliability, it does present some challenges. The following best practices can help you to handle them.

    Use Scalable Infrastructure

    One obvious potential downside of blue-green deployment is that it can essentially double the amount of resources you need to host your application since you have to maintain two identical environments. That can double your hosting bill.

    One way to reduce the cost impact of blue-green deployment is to create environments that can scale rapidly without changing their core configuration. You could do this using cloud-based virtual machines (VMs) and autoscaling or via containers and an orchestration engine (like Kubernetes) that can scale them.

    Using this approach, you can set up two environments that are effectively identical except that the production environment includes more VM or container instances than the reserve. Although you could argue that this is not quite a blue-green deployment because the environments are not perfectly identical, that semantic downside is outweighed by the benefit of not wasting a bunch of money on infrastructure you don’t need.

    Chaos Engineering

    Typically, chaos engineering entails experimenting with a production system to test its reliability. Chaos engineering offers many benefits, but it presents the obvious risk of creating a problem in production that impacts your end users.

    Blue-green deployment allows you to work around this risk by practicing chaos engineering in the reserve environment. Of course, because you won’t have real users, performing chaos engineering under these settings may not allow you to test every aspect of your production application. But you can still test many of the configuration variables by issuing requests yourself within the reserve environment—all without worrying about breaking things for actual users.

    Managing Database State

    Keeping databases in sync when you switch between environments is one of the biggest challenges of blue-green deployment. Even small discrepancies in database state could cause big reliability issues.

    The simplest way to address this issue is to turn off the database before switching and perform tests to ensure that databases in both environments are identical before they are reenabled. Of course, this approach may impact application functionality, because the app may not work properly if the database is turned off.

    Another solution is to sync databases between your two environments. This should ensure that database state remains identical even as you switch from one production environment to the other. But it also means that problems with the database will affect both environments.

    The bottom line: There is no simple way of managing database state in blue-green deployment. You should evaluate the different options available and consider which one best meets your needs. If you can tolerate a little downtime, stop the database and restart it during the switch. If you need total continuity, use syncing, but be sure to manage the associated risks.

    Change Load Balancers, not DNS

    There are two main ways to manage where traffic is directed, and hence which is the production environment: You can change your DNS configuration when you want to switch. That’s easy to do—you would simply change the mapping for yourapp.com from one IP address to another, depending on which environment is the live one.

    You can also use load balancers to manage traffic. Load balancer configuration is more complex than simply changing DNS entries, but it also enables more sophisticated and granular control.

    In general, it’s a best practice to manage blue-green deployment switches via load balancers, due to the extra control they provide.

    Prepare for the Unexpected

    While blue-green deployment can reduce the risk of user-impacting disruptions, it’s no silver bullet. You must also be sure that you have the reliability management tools you’ll need to detect and remediate issues within both of your environments.

    Blue-green deployment is a powerful reliability engineering technique. But to get the most out of it, you must optimize the way you handle requirements like infrastructure management, traffic routing and database state. 

  • Perforce Charts Testing Course After BlazeMeter Acquisition

    Perforce Charts Testing Course After BlazeMeter Acquisition

    Perforce Software has acquired BlazeMeter from Broadcom as part of an effort to extend the scope of its testing tools beyond the Perfecto tools for testing mobile and web applications it acquired in 2018.

    Broadcom gained control over BlazeMeter after it acquired CA Technologies in 2018. CA Technologies acquired BlazeMeter in 2016. Terms of the latest acquisition involving BlazeMeter were not disclosed.

    Tim Russell, chief product officer for Perforce, said BlazeMeter adds a complete platform that spans everything from load and performance testing to application programming interface (API) testing. The goal is to enable DevOps teams to push continuous testing further left as part of an effort to accelerate the development and deployment of applications, added Russell.

    The need for continuous testing has become more pronounced as more organizations launch multiple digital business transformation initiatives, noted Russell. The real challenge will be finding ways to embed continuous testing within DevOps processes at a sufficient level of scale, added Russell.

    In fact, the quality of the digital experience those applications provide ultimately determines the degree to which those efforts are likely to succeed, which Russell noted is why so many enterprise IT organizations are reengineering their application testing processes.

    In general, organizations are taking two paths to shift testing further left. Some are giving application performance testing tools to developers to employ during DevOps sprints while others are trying to bring application testers into the application development process earlier. In some cases, organizations are doing both as part of a comprehensive effort to discover issues before applications are deployed in a production environment. Those issue are naturally more expensive to fix after an application has been deployed.

    Perforce, for now, expects to continue to make BlazeMeter and Perfecto available as a set of complementary cloud-based services with some cross-pollination of capabilities occurring over time, said Russell.

    In the longer term, it’s apparent that more artificial intelligence (AI)-based analytics will be embedded within cloud-based platforms that can collect enough data to build meaningful models of development processes. IT teams should also expect to see testing tools make greater use of computer vision algorithms to surface issues.

    One away or another, the entire application testing process is about to become a lot more automated as more organizations are simultaneously building multiple applications. That may not necessarily reduce the need for either a developer or tester to create and manage that process, but it does mean the amount of testing time required for each application should continue to steadily decline in the months and years ahead.

    Hopefully, all that effort will lead to better application experiences being provided to end users more consistently. There is nothing quite as frustrating for any application development team than to discover that 90% of the functionality of an application is not being used because end users are not able to easily surface it. Worse yet, of course, is when an application turns out to be too slow once it is deployed. In either case, it’s difficult to regain that initial end-user enthusiasm for any new application experience after it’s been lost, simply because no one thought through all the use cases that should have been tested much earlier in the application development life cycle.

  • Best Practices for Codeless Test Automation

    Best Practices for Codeless Test Automation

    Low-code and no-code development platforms have revolutionized how companies think about application development. The same can be said for software for quality assurance (QA), where codeless test automation solutions handle the burden of coding for organizations that can’t allocate extra programming resources or keep up with extensive writing and maintenance of automated tests.

    Codeless test automation can be a big win for companies that are resource-challenged and trying to get applications to market quickly. A recent Applause survey of more than 2,000 digital experts revealed that nearly 54% of organizations have strategic plans to purchase a codeless test automation tool in the future.

    Despite the heat in the market, though, it is not a fit for every type of application or use case. It is not, in most cases, a replacement for scripted automation, but rather should be used as a complement to traditional automated testing and manual functional testing.

    An example of this is with dynamic content in applications, which have unpredictable or even subjective outcomes. Consider a streaming media platform. An automated solution might validate that the “Play” button triggers the code to play a movie, but it cannot validate that the movie plays without audio or video glitches.

    In complex cases that aren’t a fit for either codeless or traditional automated methods, manual testing is a better alternative.

    When to Use Codeless Test Automation 

    Test automation is not going anywhere, even as codeless tools become more prominent. That’s because automation enables brands to move faster and meet the fast-moving target of building and testing software that is both high quality and able to be released to end users quickly. The downside of traditional test automation, however, is that building and maturing the process can be time-, cost- and resource-intensive.

    This is because traditional automation requires experts in coding, not only to write tests at the outset but to also maintain them over time. The complexity and need for different tools—like Appium, Selenium, Apple simulators, Android emulators, element locators, locator strategies and so on—all contribute to the complexity of traditional automation and the need for specific expertise. Plus, software development engineers in test (SDETs) are constantly being taken from QA teams and moved into development roles, which often means that these projects get stuck halfway through and never fully completed, which can then result in a tremendous waste of both time and money for companies.

    The overarching value of codeless test automation, on the other hand, is that anyone can do it. With a codeless solution, a user simply moves through a test case and the codeless tool can then transcribe that experience into an automated test. And, while codeless test automation tools originally addressed only web applications, more tools now offer the ability to run sessions and create automated tests on mobile apps—on both Android and iOS—as well as web applications.

    What it all comes down to, though, is that organizations shouldn’t be thinking of codeless tools and traditional automation as an either/or scenario. Codeless test automation tools are great for less-involved scenarios—like smoke tests or portions of a regression testing suite. Using codeless tools in this way allows SDETs and dedicated automation resources to focus on higher-priority and more complex automation. Ideally, manual testing should be used alongside both traditional automation and codeless test automation solutions as a way to maximize the speed, scale and quality at which software can be delivered to end users.

    As a rule of thumb, every organization should balance test automation and codeless test automation and consider automating when the following factors are in play: 

    • Repeatable task 
    • Time-consuming testing activity 
    • A stable testing environment with little change anticipated 
    • Repetitive test(s)