Tag: QA

  • Creating Career Opportunities in Quality Engineering

    Creating Career Opportunities in Quality Engineering

    Software testing is the thread that connects code to customers, ensuring that the code created by development teams works for users and supports customer loyalty. But as the demands of software development are transformed by DevOps and customer expectations rise, the career and role of the software tester is evolving rapidly. Customer expectations have made it imperative for applications to work seamlessly, necessitating evolution in QA and testing.

    As the QA and software testing sector progress—and “quality engineering” becomes the de facto term for creating agile, customer-centric software teams—QE is attracting a more diverse pool of leaders as the career skillset widens. The more quality engineering becomes the differentiator between elite software teams that thrive in a DevOps world and teams that struggle to adapt, the more important it becomes to elevate diverse leaders in the industry.

    Understanding this, mabl recently held a panel discussion with QA and software testing industry veterans who discussed the new era of quality and how these changes are transforming who enters the field.

    The Evolving Role of the Software Tester: Building Professional Confidence

    The constant evolution in software testing and quality engineering, though exciting, also presents a challenge to QA professionals: How to consistently build the necessary skills as well as the confidence to succeed. As quality engineering becomes a multidisciplinary career role that encompasses engineering, functional and non-functional quality management and the customer experience, the question for QE professionals becomes one of continuous learning and the confidence to broach, if not lead, challenging discussions.

    LaDeitra Lee, chief technology officer for Sparx Studio, understands how confidence can sometimes feel elusive—especially for younger pros just getting started. But her message is meant to encourage those just starting out to speak up: “QA knows the most about the product because we know the customer’s perspective, and we’re testing the full product from the front end that everybody sees all the way to the backend … the main thing: You want to make sure you have the confidence in your work,” Lee said.

    When quality engineers have confidence in their skills, they’re better able to collaborate with the rest of the software development team to improve testing strategy and triage defects. But building confidence can be challenging, especially as software testing has embraced coding skills to the point where software developers can specialize in quality as SDETs. However, that doesn’t mean that coding experience is the most essential skill in a quality engineering career. Since quality engineering is all about connecting code to user context, soft skills like empathy are just as critical for the next generation. So, even if QE professionals aren’t expert coders, they can build confidence in their skills by understanding their unique place in the software development process.

    Marjie Carmen, software engineering manager at Arch Insurance, agreed. “When I started out, it was commonly believed that software testers didn’t need programming skills or software engineering skills since the focus was on manual testing. But today, I see QA working hand-in-hand with and having almost the same skills as a software engineer; sometimes even more. I really see quality assurance as equal because they have to know the business side and the perspective of the users and where the industry is going. They have to make really good recommendations about how the product should be and need the confidence to go to the engineering side and say, ‘What’s the fastest way I can get this product tested and in the hands of the user?’”

    Creating Unconventional Career Paths in Software Development

    How has hiring for a tester today changed in the last decade? As quality engineering continues to grow as a profession, many in the field are creating new career paths by moving between different roles throughout the software industry. By supporting these unconventional candidates, Maaret Pyhäjärvi, principal test engineer and prominent QA speaker, said that software development organizations can grow internal talent and help quality engineering develop as a field.

    “We hope that there’s more of this openness for moving from one technical role to another,” said Pyhäjärvi. “There’s always the possibility of learning small slices of technicality. Some of my favorite architects these days are so good at software testing; so good at programming and can really bring the whole team together. So we need to allow that kind of movement where people get to try things and break away from stereotypes.”

    Susan Marie, president of the Triangle Software Quality Association (TSQA) said, “I love the capital-Q quality emphasis because it gives me leverage to do well—that’s just one area of quality. I hate the idea that the job title is the one thing that you’re allowed to do; you need to be giving guidance around what’s expected of you and what other people can expect from you.”

    While technology is always evolving, former Slack senior engineering manager Karine Sully said the main characteristics for the job have been consistent—even as far back as a decade ago. “I always look for people who are curious and who have good communication and organizational skills, especially coming in at entry-level or lower-level. All you need is to be able to think critically and organize your thoughts and be able to communicate what it is you’re doing. Then, you can push beyond that and grow.”

    Given the challenges inherent to working with multi-disciplinary teams, Lee said, “I think what helped me the most is having a sponsor. So my advice for anyone on my team, or anyone that’s looking to grow in their career, is making sure you have someone a few levels above you looking out for you.”

    Fostering Diversity in Software Testing Teams

    Growing responsibilities equal a growing number of requirements and skills for quality engineering careers. Navigating the hiring process is never easy, but succeeding in a rapidly changing field can feel like running a marathon at a full sprint, especially when trying to foster more diversity in software development and testing.

    “…Diversity and inclusion are definitely very dear to my heart, and I feel you have to go where people don’t look like you. So if you want to hire more Black or Hispanic engineers, you have to go to areas where you see more of them,” Lee said. “If it’s engineering that you’re looking for, do your research and find those schools that specialize in that particular area. I’m a part of the National Society of Black Engineers, so I tap into that network if I’m trying to help build a diverse team.”

    Carmen agreed that hiring managers need to look closely at areas where there may be holes to fill. “I got into management by looking at gaps and filling them—it was always my goal to find a gap and say, ‘Hey, I can take that off your hands and in the role.’ So it’s a natural evolution to get the different roles that I’ve had by saying yes to more and different responsibilities.”

    Conclusion

    Though the QA and software testing fields are in the midst of several transformations, the change is opening the door for more people to have successful careers in software quality. Though their role is to ultimately improve the product, that road to quality is usually filled with bugs and unpredictable challenges. When quality engineering professionals are confident in their work, it’s easier for them to lead constructive conversations on improving the product—and facing down the engineering teams, if necessary. Building a diverse and confident next generation for quality is essential to building delightful digital experiences for all.

    “I heard from a very famous pioneer in the engineering industry about QA that ‘We don’t have a magic wand; we can’t test quality into your product, but we can test your product.’” Pyhäjärvi said. “The whole concept of QA engineer, QA quality assurance, QE, I think gives people the illusion that we can do something impossible. We can only show light to the areas of the product that need work.”

  • What Is User Acceptance Testing and Why Is it so Important?

    What Is User Acceptance Testing and Why Is it so Important?

    Anyone involved in software development knows how important it is to ensure a positive end-user experience. One way to do that is through the use of user acceptance testing (UAT). 

    UAT is one of the types of testing that you can execute as part of your overall quality assurance process. 

    Source

    It’s essential in helping you determine if your product is market-ready and if it can perform effectively when used by real end-users. 

    UAT helps you avoid implementing software, iterations, upgrades, or customizations that are filled with pesky bugs that can destroy the user experience and render your software unusable (not to mention the damage done to your business’s reputation). 

    When the stakes are so high, it’s clear to see why businesses need a process such as this. In this article, we take a look at user acceptance testing, why it’s so important, and six ways brands can use it to their benefit.

    What is User Acceptance Testing (UAT)?

    User acceptance testing (sometimes known as end-user testing, user acceptability testing or beta testing) is the last step in the entire testing process of any software.

    In product management terminology, acceptance testing takes place as beta testing whereby a small group of early adopters test out the platform and provide user feedback to let you know if the solution meets user expectations and business requirements. 

    It’s done after the system, functionality and all other tests are completed and before the product is launched. 

    The image below shows some of the quality assurance (QA) tests that precede user acceptance testing. 

    Source 

    As you can see from the image, as development work moves forward, UAT progresses from unit testing to integration testing, then system testing and, finally, acceptance testing.

    This final stage is arguably the most crucial element of software development because it ensures a positive end-user experience. 

    As its name implies, it helps you determine if your platform will be accepted by end-users. 

    Testers (end users) work from a checklist of expected outcomes from the test platform and then record what happens when they attempt to execute the different tasks, such as:

    • Logging into the user’s account
    • Placing an item into a shopping cart
    • Checking out 
    • Buying multiple items that qualify for free shipping

    … and so on. 

    If the expected outcomes are achieved when each task is executed, then the software is approved for release. If not, it’s sent back to the developers. 

    This testing process requires collaboration between different stakeholders including project sponsors, business owners, analysts, QA teams and developers. 

    Why is UAT Important to Software Development?

    Although there are many ways projects can benefit from UAT (some of which we’ll look at below), this process is often overlooked by developers. 

    Many see it as a time-consuming and unnecessary process, which is unfortunate because acceptance testing can actually help improve software quality as well as the overall acceptance rate of any newly implemented software. 

    Think about it: You would never drive an untested car, would you? Similarly, businesses should not take risks by implementing software that has not been tested. 

    Considering the time and money you stand to save by ensuring that your software works in accordance with a predetermined test plan, it’s clear that this is something developers need to take more seriously. 

    In fact, far from being the time drain that many developers think it is, UAT can actually gain you a lot of time. How? By preventing unnecessary waste. 

    And far from being a one-off when you come to the end of the project, user acceptance testing extends beyond business application projects because of factors like additional phases, hotfixes, releases/further modifications or customizations and upgrades. 

    Take a look: 

    • Additional Phases: If you choose to roll out at this stage or upgrade an existing application in a phased approach, each phase can have different types of users, different companies (for parent companies, acquisitions, mergers, etc.), additional locations, etc., and you’ll need to plan and conduct separate additional acceptance tests for each individual phase.
    • Hot Fixes: Bug reporting or developer testing during regular day-to-day operations can lead to hotfixes. However, these bug fixes will have to be tested by end-users to make sure that they actually solve the problems originally reported.
    • Further Modifications: Software creators regularly release updates, including limited distribution releases (LTR) and general distribution releases (GDR). LTR releases usually fix issues in a specific problem area, whereas GDR releases are typically heavily tested before release. Both need to be tested to ensure that they fit users’ real-life scenarios so you can achieve your business objectives.
    • Upgrades: Everyone wants to offer their customers the best and most advanced experience. That’s why, for the most part, brands update software regularly to follow industry trends and keep up with the latest innovative technology. Regardless of the upgrade approach you take, whether it’s a little or a lot of customization, it’s crucial that your plan is completed according to business requirements. This will help ensure that the project’s end result is in line with the original business requirements.
    • Privacy Policy Updates: Many end-users may enjoy the overall functionality of the software, but they may desire increased integrations with other platforms or the ability to use a different payment method than that which is currently accepted. While these upgrades and modifications may be easily completed, you may need to alter the information you input into privacy policy generators to ensure that your users legally consent to any new use of their data or access to it by third parties.

    Now that you understand what UAT is and why it’s so important, let’s look at some of the benefits of user acceptance testing to give you a better idea of all the different ways you can leverage it in your own business. 

    Benefits of User Acceptance Testing

    At its core, user acceptance testing will be pivotal in the successful launch and/or maintenance of any type of online platform, whether it’s a simple mobile app or something more complex, such as an eCommerce website. 

    If the test object doesn’t work as desired, the faulty business functions are documented and the item is sent back to developers for repair. 

    Going through this final check ensures that your platform is well-built and performs as expected and that users accept the finished product. 

    Listed below is a summary of the top benefits of UAT: 

    • Benefit: The UAT process allows you to demonstrate that the software’s required functions are operating in a way that’s suited to real-world use and circumstances. As such, acceptance testing focuses on software performance and user behavior to ensure that interactions between the test software’s functionality and the end user’s thought process are aligned. 
    • Benefit: Furthermore, you’ll be getting a much better piece of software because it will be tested and verified by the same people who will be working with it every day. You’ll get optimal opportunities to quickly identify and repair any broken features. So, it’s easy to see how the time you invest in these beta testing cycles will lead to significant improvements in the quality of your software.
    • Benefit: Not only that, but the quality review provided by UAT is also a great way for stakeholders to secure a healthy return on investment (ROI) out of projects. Also, it keeps maintenance costs low and it’s cheaper and faster to fix usability/functionality issues early on.
    • Benefit: You’ll also be able to ensure that your software integrates with third-party platforms including various website builders, email marketing software, project management tools, communication apps and everything else you or your end-users might need to effectively use the software. If your software is supposed to allow for social media sharing, for example, you want to ensure that end-users are able to easily share without going through multiple steps that decrease an otherwise positive experience with the software.

    As you can see, user acceptance testing is vital to the successful deployment of new business applications and software enhancements, as well as to ensure organizational efficiency and success.

    The process helps you to mitigate risk and boost the ROI of your project. But most importantly, UAT ensures that your customers don’t end up being acceptance testers by default, which would have a negative impact effect on your business.

    6 Ways to Use UAT

    Here are six ways you can use this process to achieve better outcomes.

    1. Use user acceptance testing for internal development.
    2. Use the testing process to review new features.
    3. Invite users to take part in the tests to help them become more invested in the brand and become brand ambassadors.
    4. Use beta tests as a premium feature to convert subscribers to higher tier packages, increasing sales for the company.
    5. Share information about UAT and its results on social media platforms, email and other channels as part of your digital marketing campaigns.

    These are just a few of the different ways your organization can benefit from UAT far beyond the initial goal of the testing process. 

    And remember, it’s all about the users. 

    UAT isn’t just another testing technique. This test puts the user at the center of the discussion to answer questions such as:

    • Are users able to use the software without error(s)?
    • Does the solution meet promised specs? Does it behave in an expected way?
    • Does the software continue to work when users take unexpected actions?

    …and so on. 

    Whether the platform is constructed in-house or by a third-party company, all solutions must go through user acceptance testing because your users are the ultimate audience who will pay for your solutions. For this reason, it’s worth taking the time to ensure that your software solution meets both user expectations and business requirements.

    Planning and Managing the UAT Process

    The key to a successful UAT testing process is to understand the needs of your target users and their expected behavior. This way, you’ll be able to develop defined acceptance criteria so you can come up with efficient tests to complete the testing process fast. 

    Also, since the goal is to assess the market readiness of the product, it’s important to record all evidence and track progress with the dev team as well as report to stakeholders so everyone is on the same page. 

    With that said, here are five steps to help you plan and manage the user testing process: 

    Step One: Planning. The user acceptance testing strategy mainly includes a time frame outlined during the planning step.

    Step Two: Designing Test Cases. Test cases cover the core functional frameworks of the platform in real-world usage. When designing test cases, you need to do the following: 

    • Determine the needs of target users and stakeholders 
    • Design test cases according to the user journey and product specifications 
    • Summarize test runbook, acceptance criteria, etc. 
    • Prepare test data, e.g. registration, three days in use, one week in use, etc. 

    Step Three: Setting Up Your UAT Team. The acceptance testing team is comprised of real-world end-users or users who are not part of the development or testing phases to ensure objectivity. You should never use developers to test their own software as they may bring bias (albeit unintentionally) into the testing process. 

    Step Four: Executing and Documenting Test Cases. The UAT team executes the test cases, together with relevant random exploratory tests, after which all bugs are logged into the bug tracker along with steps to reproduce.

    Step Five: Bug Fixing. Once you’ve executed the test cases, you need to keep track of the tickets and user feedback. The development team can account for all the bugs found by the testers and start fixing bugs depending on severity. 

    Step Six: Confirm Fixes and Get Stakeholders to Sign Off. Once all UAT tests have been run and the results are in hand, the acceptance decision can be made. If all users are satisfied, then it’s a go. If not, it’s a no-go. 

    Last But Not Least

    UAT is the last stage in the software development life cycle. But, it’s also one of the most important things you can do to ensure the success of your software. Just keep in mind that for this process to be effective, it should be viewed as validation and not verification. Use your test procedures to validate functionality in both smaller scope (as a way to test functionality) and in a larger context (to simulate real-world processes) so you can get an end-user vision of your product which will ultimately help you increase the robustness and usability of your software.

    Are you ready to use UAT to get feedback on your software so you can increase end-user happiness? Share your thoughts below!

  • Where Has All the Testing Gone?

    Where Has All the Testing Gone?

    Testing has long been a problem child of IT in general, AppDev in particular, and now it is DevOps’ problem. There are things that DevOps can do to improve the chances of tests actually occurring for your application(s). Interestingly, there are some that think we no longer need testing; the argument is that because new releases can be cranked out so quickly if something needs to be fixed that it is irrelevant. Combining feature flags with the ability to roll out a new version and, well, there may be some truth to that—at least for a limited subset of testing.

    If an organization implemented feature flags for user acceptance and new feature testing and then standardized on test-driven development for DevOps development teams, that would leave systems and security testing. Systems testing could, theoretically, be replaced by the ability to roll out a new version. Although systemic issues can be complex and difficult to fix, this is a riskier proposition than extending test-driven development to the systems level. For the sprint, assign a person responsible for the overall integrated system and have the rest of the team support them through the process of making certain all works as expected.

    Testing—particularly systems testing—slows releases. I get that. The rate at which most of us can iterate once DevOps systems and processes are in place is fast enough that you can afford a bit of slowdown. This leaves security testing as the last standalone bit. But some security validation can happen during the development process if DevSecOps tools are being utilized. That still leaves some security issues to test for but does remove a large chunk.

    The key to these last bits is to get them integrated into the process/toolchain. DevOps runs straight through, over and over. Any bit worked into the “runs straight through” will be executed. If today’s iteration falls for the “We ran over, we’ll make the deadline with less testing” mentality; not an issue—it’s one iteration. Just don’t let that become the default answer to someone not completing an iteration’s work on time. Development can have unexpected speed bumps that delay delivery and acknowledging that and documenting what it was for future reference is important. Covering it up by reducing testing time risks a less stable product and does not help overcome the issue in the future.

    So start thinking in terms of DevOpsTest. Make sure the product you are delivering represents the massive time investments you’ve made producing and maintaining it. You’re rocking it—and something like integrated testing ensures that users see how great you are rocking it and not an error page.

  • Swinging the Pendulum of IT Back to QA

    Swinging the Pendulum of IT Back to QA

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

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

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

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

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

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

  • Why QA and Monitoring Need to Merge

    Why QA and Monitoring Need to Merge

    Customer expectations for speed and reliability have upended the software development life cycle. Whereas developers used to develop a product and send it to quality assurance engineers for testing before widespread release, customers now demand new versions and features on a quicker timeline. In an era with little available time to run QA in the traditional development process, what’s the alternative?

    Fortunately, modern automated infrastructure provides a solution. Infrastructure-as-code (IaC) toolchains that deliver continuous observability with AIOps let SRE teams overlook the entire process, from the first piece of code through the software product’s public release.

    This merger of the traditional roles of QA and monitoring is enabling quicker speeds within the delivery cycle, a development that improves the customer experience but also ignites business innovation.

    The Benefits of Speed in the SDLC

    Observability delivers the data necessary to eliminate traditional QA, but teams still need help. With intelligent observability — where you apply AI to the data — teams can better focus their efforts and analyze information much more quickly.

    Finding and fixing software issues after deployment unnecessarily stresses SRE teams. But through observability with AIOps, DevOps practitioners and SREs monitor from early development through daily performance. QA is omnipresent. Teams can identify root causes of issues instantly, and AI surfaces the most actionable steps to quickly resolve impacts on the infrastructure.

    The DevOps team used to leave QA engineers with the tedious and time-consuming task of pinpointing issues amid a sea of data, creating a bottleneck within the development process. The continuous learning and intelligent collaboration approach, on the other hand, merges traditional QA and monitoring and yields a CI/CD pipeline that actually works.

    Integrating observability with AI into the development cycle allows teams to spot change almost instantly. If the platform starts acting oddly after its release, SREs and DevOps practitioners can jump in immediately without the need to wait for a QA team. If the issue is where a change in performance is expected, AI and machine learning often still can reduce what’s needed from your teams. If, for instance, you’re monitoring with an adaptive thresholding algorithm, you can let the algorithm retrain and learn the new behavior instead of relying on the DevOps team to communicate the expected change in performance to the QA team.

    As QA shifts left – as evidenced by the growth of software development engineers in test (SDET) – it’s natural that monitoring and assurance capabilities should shift left, too.

    A Principled Approach to QA

    The merger of quality assurance and monitoring throughout the software development cycle follows the three guiding principles behind DevOps practices.

    • Flow/system thinking. The approach eliminates workflow silos and instead creates a holistic view of the development process. The continuous oversight negates typical quality hazards, such as the handoff that can occur despite a known issue or the optimization for local efficiency only.
    • Amplifying feedback loops. A merging of QA and monitoring eliminates the need to loop feedback through multiple teams with various processes because teams are given consistent feedback throughout software development and delivery.
    • A culture of continual experimentation and learning. DevOps teams, no longer in a position to just pass software down the line to QA, will build constant improvement into their processes as they learn from bugs along the way. This also provides more opportunity to take risks and experiment. The approach is a more holistic product cycle versus quick development.

    Improving the Q in QA

    Removing QA as a singular step in the software development process initially may seem like removing quality assurance itself. But QA is actually heightened by integrating observability with AIOps into the development cycle.

    Observability with AIOps allows teams to see into systems as they are being built but also allows them to gain actionable insights to resolve issues on the overall structure. Actionable insights empower the merging of traditional QA and monitoring to drive a whole new speed of delivery, which yields better customer experiences and gives businesses the ability to quickly launch competitive, innovative services.

  • Why Browser and API Testing is Shifting Left

    Why Browser and API Testing is Shifting Left

    For developers working with cloud-native technologies, software testing and quality assurance is a key part of product development. For most teams, testing has “shifted left,” so the quality of the code can be assessed as it moves through the CI/CD pipeline. This approach to quality assurance reflects the rise of DevOps and other modern development practices – developers today own their applications from end-to-end, and conducting testing early in the product life cycle is how they find potential bugs, save their organizations time and money and build products that delight their customers.

    More recently, developers have added end-to-end API and browser tests into their CI/CD practices, extending the scope of their testing and quality assurance practices. By testing how code performs on different browsers and how it interacts with important data sources, developers have added another layer of quality testing to the early stages of their development processes. This has brought added benefits to other “shift left” practices, such as unit testing and security testing, and has led to a new understanding of quality assurance.

    Traditional Approaches to QA Can’t Support the Pace of the Cloud

    As companies have migrated to the cloud and adopted agile development methodologies that align with DevOps practices, they’ve encountered conflicting priorities between releasing code quickly and maintaining the highest level of quality on each release. Traditional manual testing techniques were not built for agile workflows, but instead supported older waterfall methodologies, in which testing could be conducted as a discreet instance before code went to production. With agile development, having a specific team in charge of all testing right before production is not the most sustainable approach, as it hinders the rapid pace of development that the cloud enables. This is why testing is “shifting left” to earlier stages of the development process, and why manual testing is being done by people embedded within each engineering team.

    Cloud-Native Teams Have Shifted Left Into CI/CD Pipelines

    As part of these agile methodologies, companies have moved toward leveraging CI/CD practices to ensure code is always in a state where it’s ready to be deployed. As code moves through these pipelines, developers want to ensure they are able to catch bugs earlier in the development cycle. To do this, they’ve taken to testing earlier and more often.

    In particular, developers have increasingly recognized the value of end-to-end testing throughout their CI builds. API tests allow teams to verify end-to-end workflows by chaining HTTP requests and API calls, so they can validate all the layers of their systems from worldwide locations. Browser tests capture the user’s view during critical transactions, so teams can understand how UI changes are impacting web applications. Shifting both left into CI/CD pipelines saves time and money, as fixing a bug earlier in the development lifecycle is much less expensive than trying to fix it at the last minute, when it has grown in complexity and scope.

    It also means many issues are caught by the developers, without the intervention of another engineer manually validating their work. This reduces the number of cycles required to find a bug, allowing the code to be circled back to developers, fixed and re-deployed to a testing environment. When regressions are caught early, developers can focus on the details that will make the product great.

    Visibility of Metrics, Traces and Logs Drives Value

    Running browser and API tests in your CI pipelines is beneficial, especially when teams can correlate these tests with data from across their stack – front end and back end, application and infrastructure. With correlated metrics, traces and logs that can be accessed easily without toggling between different products, teams will have the full context necessary for both detecting and troubleshooting failed tests. Detecting the failed tests allows for the rollback of bad code before it goes to production, and the correlated full stack data can be used to troubleshoot and fix any issues not caught during the development stage. This creates a new culture of quality assurance, in which maintaining quality is a holistic process that involves every part of the development cycle, and draws on data from every part of the stack.

    Consistent Quality Requires Collaboration

    This change in quality assurance goes beyond the practice of shifting browser and API testing left, and represents a fundamental change in how engineering teams collaborate within an organization. Testing happens before code goes to production, continues with robust monitoring once code is live, involves data from across the stack and is the responsibility of teams from various parts of the business. With this collaborative approach, for example, a front end engineer can easily identify an issue in the integration of their latest changes with the way the back end APIs are structured. They can then engage with the back end team owning this service to collaboratively iterate and find the best solution to resolve the issue. It may start with a shift left, but, ideally, it ends with the removal of silos and the opening of communication channels among teams.

    Automated QA Delivers Customer Value Faster

    A fully operational approach to quality assurance means that issues are resolved faster, or even resolved while code is still in development, so they never become issues at all. This creates a virtuous cycle – fewer regressions means less downtime, which makes customers happy, and frees up engineers to build new products, which makes customers happier still. That baseline of reliability and customer experience enabled by effective quality assurance is what allows for new innovation that delivers value to customers.

  • Maintaining Progressive Delivery Quality With Feature Flags

    Maintaining Progressive Delivery Quality With Feature Flags

    How does Netflix know exactly what you want to watch? How do social networks ensure major software updates are smoothly deployed across millions of users? The answer, in part, lies in progressive delivery. Progressive delivery, the incremental introduction of new features, has become key to rolling out new features. By testing unproven features on a small subset of users, platforms can advance quickly while keeping rapport with the main userbase. But, where does QA fit into the progressive delivery cycle?

    As software development teams face the need to iterate rapidly, the role of QA engineers is evolving as well. QA teams are increasingly assigned to support new customer experience initiatives and meet developer consumer needs. They must do so while understanding which customer metrics to monitor as developers introduce new features.

    I recently chatted with Jeff Sing, lead software QA engineer at Optimizely, recently acquired by Episerver, to explore how feature flags could be used to maintain quality and respond to user feedback throughout a progressive delivery life cycle.

    Defining Progressive Delivery and Feature Flags

    Progressive delivery is is a software release style that emphasizes very early code pushes and rapid feedback. By testing features among small subsets of a greater user base, developers can quickly gauge what works and what doesn’t.

    Feature flags are a necessary component to make progressive delivery work. Also called feature toggles, feature flags are switches that enable developers to turn a feature off or on, helping engineering teams test unfinished features or alpha features while avoiding maintaining multiple branches. “Feature Flags are a powerful technique, allowing teams to modify system behavior without changing code,” wrote Pete Hodgson in a post on MartinFowler.com.

    Feature Flags Enable Experimentation

    Adopting feature flags for progressive delivery allows for a lot of experimentation, said Sing. For example, companies could test a new user interface adjustment on a small subset of users. If it works well, the team could further and optimize it for specific user tastes.

    “Why would you want to build something that no one wants to use? How do you know you’re building the right thing?” asked Sing.

    Iterative release strategies are nothing new—and they go by other names: canary release, A/B testing, targeted rollouts and feature gating. However, what seems unique about feature flags is the ability to optimize granularly.

    For example, if you compare a friend’s Amazon home page with your own, you will likely find the dashboard, product recommendations and overall UI vastly different. These companies are continually “running active experiments on a per-user basis,” said Sing. This enables them to personalize experiences to niche user tastes, in real-time.

    Many other companies are utilizing progressive delivery tactics. Blue Apron, for example, adopts experimentation to find and refine business value. Experimentation is core to how HelloFresh distills its customer experiences. Compass also uses progressive delivery tooling to enable feature flagging within a suite of apps serving various platforms.

    For QA teams, this means shifting right—from business testing to nano-testing at the pace of constant delivery. Thus, QA teams must have an active role—“continually test customer feedback and continually reiterate on that feature,” said Sing.

    Implementing Feature Flags: QA Shifts Right

    By adding customer feedback into the continuous delivery loop, feature flags aid incremental deployment strategies and become essential for DevOps. So how do we implement feature flags in our application development processes?

    If we’re testing a single function within a small product, an obvious idea would be to comment out or uncomment code. But, that doesn’t scale well. Developers could, instead, program a conditional variable. However, there is still more dynamic feature-toggling options. More advanced solutions may involve a toggle router and/or a UI-driven alternative.

    Sing described a system using switches written as YAML files and adopting a visual dashboard to toggle on/off features. This setup can enable a process whereby the developer checks in code and passes it to site reliability engineers (SREs) or QA managers. They can then initiate testing in production, view data from beta users in real-time and respond accordingly.

    Integrating with a CI/CD pipeline would be the next logical step. Each build could carry many potential features within each build. If a flag in the code is on, the system would execute all code and components can easily be turned off or on remotely. This way, engineers “can control how things are represented in real-time without a code deploy,” said Sing.

    Melding feature flags and progressive delivery returns extremely valuable data, Sing said. If teams can see metrics such as system behavior, bounce rate, customer NPS score and business conversions, they can better increase the quality of future deployments. “You can’t argue with hard data,” he noted.

    Benefits of Feature Flags

    Utilizing feature flags within continuous development appears to afford many benefits. In the process, QA plays a more present role in how engineering teams roll out (or roll back) new features. “QA must understand the business impact and customer story,” said Sing. “It’s not just about uptime; it’s the experience, too.”

    As you can see from the use cases above, progressive delivery with feature flags brings many benefits:

    • Quick validation: Bring new product features and proof of concepts faster to market faster by improving testing.
    • Experiment and iterate: Release incremental software versions. Experiment with new or unfinished features that consider fringe cases.
    • Development: Avoid constant merging of branches.
    • Reflect customer journey: Gather more heuristics on the customer journey to test and measure customer data.
    • Optimize per-user: Test and optimize for user tastes. “Why would you want to build something that no one wants to use?” For Sing, targeted rollouts can answer that user imperative immediately.
    • Limit blast radius: If new features introduce outages, easy togglable capabilities mean they can quickly be turned off and put back into development, thus increasing service reliability.

    Drawbacks of Feature Flags

    Feature flags introduce many efficient methods for testing new features, but they don’t come without side effects in other areas. One potential drawback of feature flags is supporting a vast number of intricately defined user scenarios.

    With each segmentation comes new optimization requirements and support must adapt to a quickly growing archive of various feature sets. Companies need advanced tooling to support the easy addition or removal of features. “You need the power to understand what’s going out and how you manage it,” Sing noted.

    A fractured ecosystem with thousands of microservices can become difficult to support continuously. Engineering teams must draw the line somewhere between endless optimization and retaining a cohesive product. Ideally, developers can reuse base components but represent them in different ways.

    Another negative side effect is public opinion. With the release of Social Dilemma and related tech industry critique, many user-facing tech networks are under harsh criticism due to the unethical use of user data to develop hyper-targeted ad campaigns. Optimization tactics that disrespect users should be frowned upon.

    This is not to mention regulations around user data and privacy. If users do not grant consent to share user data to “improve the user experience,” engineering teams won’t have the necessary metrics and tracking data required to decide which features to implement.

    While feature flags appear to help optimize business value, there are many potential “gotchas” to carefully consider before implementation, from technical logistics to service fragmentation, user ethics and legal ramifications.

    Final Thoughts

    “As with any new technology, if you don’t use it correctly, it’s almost better if you don’t use it,” said Sing. If progressive delivery isn’t managed correctly, with a QA mindset, it could come back to bite them.

    As we continually build new tech to ship faster and smarter, it’s also important to consider customer needs. “Automation is great, but a computer can’t understand what a customer really wants,” Sing noted. To avoid the technical hurdles and social dangers of hyper-personalization, QA should be customer champions that consider customer happiness.

  • Why Is QA so Important in Executing a DevOps Implementation Strategy?

    Why Is QA so Important in Executing a DevOps Implementation Strategy?

    In a rapidly growing global digital landscape, enterprises are facing many challenges. These include changing customer behavior and the need to be in line with the latest technology trends. To address these challenges and to stay up the competition curve, enterprises are adopting a slew of strategies. These comprise expanding the capacity of processes, quick quality checking and delivery of applications and timely marketing of the applications. This is where DevOps comes as a one-stop solution to the aforementioned requirements. 

    When it comes to assuring the quality of software applications, the Agile and DevOps model of testing is favored over the traditional waterfall model. This is because software applications need to be tested across a swathe of platforms—devices, browsers and operating systems. In the DevOps scheme of things, software builds are continuously integrated and deployed in the development pipeline by using test automation. It involves the development and implementation of new features along with the streamlining of processes. 

    What Is DevOps?

    DevOps is an amalgamation of terms “development” and “operations” and is underpinned on four basic pillars—culture, tools, collaboration and practices. Combining processes and philosophies, the DevOps approach helps enterprises deliver quality builds in the SDLC. Here, development and operations teams no longer work in silos but in close coordination with each other. As a result, quality becomes a shared responsibility and a culture of accountability gains ground. DevOps implementation leads to the quick development and deployment of quality builds, faster solving of critical issues and engendering greater trust and confidence.

    Let us understand the best DevOps implementation strategies to derive outcomes such as continuous integration (CI) and continuous delivery (CD). To begin with, getting the QA basics right the first time and every time should be considered as part of the strategy. This is due to the fact that in a pure DevOps ecosystem, the lines between development and QA are blurred.

    Test Automation

    Since the software needs to have an omnichannel interface with third-party applications to perform optimally, the test process should be automated. There should be a smooth QA-DevOps alignment to detect and mitigate glitches early on in the SDLC. Thus, DevOps testing may involve choosing automated tools that are either open-source or commercial. 

    Teams Merge

    To derive DevOps transformation, the integration of the QA team with other technical specialists becomes important. The final DevOps team should adapt a culture wherein identifying glitches becomes a shared responsibility. 

    Metrics

    Since DevOps testing is all about quick identification and fixing of glitches, the metrics should be defined at the beginning. It will help the DevOps team to stay focused on the challenges and requirements. This calls for the QA engineers to setup test requirements into the workflow and guide the team therein.

    Virtualization

    The software application should be tested across a slew of platforms—devices, browsers or operating systems. Since it is well-nigh impossible to test the codes for numerous users (during usability testing), the same ought to be created virtually. The QA team can virtualize every test requirement to emulate the behavior of software components. Moreover, it helps to do away with the need for dependencies and addresses constraints faced in interdependent environments.

    Choose the Right Tools

    To enable DevOps automation, the QA team should choose the right test automation tool. The main criteria for choosing the tool should be the team’s expertise in using it. The tool should offer the ease of writing the test script in a single programming language. It should allow the testing of applications across operating platforms and browsers.

    Continuous Integration and Continuous Deployment

    These are the outcomes of any DevOps methodology. DevOps continuous integration and deployment encompass adding code changes in a repository and creating automated builds. This leads to an early recovery from failures as well as testing and delivery of products within fast turnarounds. Continuous integration based on test automation leverages regression testing and a version control system when a new code is added. Further, DevOps continuous deployment is about the capability to add new features to the existing applications. This makes enterprises follow a user-driven improvement of software and agile approach.

    Conclusion

    With the quality of software applications becoming the final arbiter in making an enterprise successful, taking the DevOps approach is crucial. However, since the whole process is hinged on executing comprehensive quality testing, the QA basics should be done right.

    — Akshaya Choudhary

  • Agile QA at Scale: Software Testing Strategies for Enterprise Teams

    Agile QA at Scale: Software Testing Strategies for Enterprise Teams

    Change is hard; it’s a universal truth not many people would disagree with. When you’re forcing (or strongly encouraging) change in a group of people, it’s especially hard. Even if that group is small, there’s bound to be miscommunication, disagreement and other friction points that make the change hard to implement.

    Now, multiply those difficulties by a factor of five. Now 10, 20 and so forth. This is the challenge of growing and expanding an organization. While you need to bring more people on board to fuel your growth, build a better product or improve the leadership, you also need to manage the complexity introduced by a skyrocketing headcount.

    More and more teams are accepting the challenge of switching to agile QA because it saves time, improves team collaboration and results in a superior product in a consistent, repeatable way. But most of the how-to articles and strategy guides out there only focus on small teams. What about the enterprise team ready to make the switch?

    Let’s look at a few software testing strategies for enterprise teams who have—or are in the process of—adopting agile QA in their organization.

    Outline a QA Strategy that Is Scalable

    Scalability starts early. You don’t want to set off running with a strategy that doesn’t fit your current team or is unable to expand with your team as it grows in the future. It’s key to adopt an approach that is flexible in all areas, from the technical aspects (tools and infrastructure) to team hierarchy and how resources are managed. If you don’t have a QA expert in-house, you may consider hiring a QA vendor to mentor you on testing approach, scalability best practices and team structuring.

    Bring on the Right Skill Sets

    Know what your business priorities are, what types of skills and technical expertise those priorities require and hire the right team for the job. With a solid team in place, you can scale up or down as needed. It helps to bring in both generalists (people who can handle a bunch of different domains) and specialists (people with a niche focus or specialty area). As you grow, your rock-star engineers will, too—they’ll move into management roles, continuing to motivate, lead and challenge their direct reports.

    Choose Metrics that Make Sense

    If you don’t measure progress and team output, you won’t know when it’s time to scale—or in which area that scaling is required. Be sure to invest time and care into the process of defining your success metrics, as they’ll have big implications for how your team is structured and how it grows in the future. Also be aware many success metrics focus too narrowly on code coverage and the number of tests executed. These are important numbers, but not as important as the overall quality of the product, which should be your “North Star” metric.

    Automate What You Can

    One of the easiest ways to scale without immediately adding headcount is to invest in automation testing. By automating regression testing and other intensively manual tests, you can free up engineers to work on higher priority projects, save more of the team’s time and cut resourcing costs. Plus, automation can help improve the quality of the product by reducing the number of human errors.

    No experience with automation testing? There are QA vendors out there offering expert automation teams who can learn your product, culture and processes in no time flat.

    Monitor and Maintain

    If you can spare it, devoting headcount specifically to monitoring the errors and alerts that arise during testing can help expedite the rest of the team’s work. When engineers don’t have to go back and work on every little fix or patch, they can focus on driving through their higher priority workload. Nitpicking the small stuff just isn’t feasible at the enterprise level, especially if you’re employing gifted and talented engineers.

    Here’s What You Need to Know

    1. How to Scale Your QA Team Effectively
      • Involve QA as early as possible
      • Design effective test strategies
      • Focus less on narrow metrics; more on product quality
      • Switch to smaller, more frequent releases
      • Test based on real-world user experiences
    2. Attributes of Agile QA at Scale
      • Automation is a part of the process
      • Engineers take ownership of their modules
      • Quality is top priority (“North Star”) of the whole team
    3. Strategies for Scaling QA
      • Understanding business priorities
      • Building a skilled team that reflects those priorities
      • Creating a roadmap for troubleshooting quality issues
      • Implementing technical and managerial strategies that scale

    Wrapping Up

    Everyone knows change is hard, especially when it requires people to work differently, work harder or work together in ways that are new, inefficient (only at first) and potentially uncomfortable.

    Successfully scaling agile QA is one of the best ways to ensure you’re consistently delivering a quality product to market. No wonder why teams small, large and enterprise-level are taking on the challenge—and with these strategies, you can too.

    — Anand Ramakrishnan