devopsy.kinsta.cloud

Tag: DevOps QA

  • How Test Automation Can Help Drive DevOps Success

    How Test Automation Can Help Drive DevOps Success

    Testing can be one of the more time-consuming aspects of the DevOps process. It can be exhaustive, frustrating, requires a lot of hands-on labor hours and people seldom enjoy it. But testing is vital, and no developer should simply skip it.

    Recently, a strong trend has emerged wherein DevOps experts encouraged developers to automate their testing procedures. Test automation can bring your DevOps projects to the next level, save time and maximize pipeline capacity for continuous testing.

    Test Automation: Definition and Benefits

    Test automation minimizes the amount of human labor required in testing. In test automation, tools and frameworks write testing “scripts” that work to ensure the high quality of your application.

    DevOps can use test automation in a variety of different ways–it can even take advantage of test cases and detect bugs in your code. This automatic testing procedure speeds up the process, getting your product to the market much more rapidly. The automatic quality checks can also practically eliminate the risk of human error in the process of continuous testing.

    Test automation can also ease the burden of the repetitive nature of some DevOps testing, simplifying and speeding up the process significantly. Finally, automation promotes a high degree of reliability throughout your testing process. Test automation can also optimize your process.

    Test Automation in the Context of DevOps

    DevOps is all about continuous development—the product is created, deployed, tested, and sent out to be consumed by the end users.

    Since it came on the scene, quality assurance (QA) has gained importance. The traditional approach to QA (wait until the product deployed to go through regression and functional testing) was much improved with the advent of DevOps. DevOps integrates the QA team into the whole of the development process, merging all players into a unified team. This integration requires a great deal of coordination across the different stakeholders.

    This also allows for a high degree of agility and speed in the process, speed which the DevOps methodology then magnifies through a high amount of automation in continuous testing (which can then be configured to run automatically).

    Deciding on the Best Tools for You

    To build up an effective test automation process, you must find the right software workflow tools for you and your DevOps team. These tools should support and manage your test assets from a central location, passing your product through the testing process much more quickly and maximizing efficiency. That said, as helpful as having an automated testing process can be to enhance the efficiency and effectiveness of your software, using tools that don’t fit with your team and goals will present potentially significant problems for your organization. There is a staggering array of test automation tools available on the market, and they all have their strengths and drawbacks. No single tool will satisfy every need related to automated testing, so your goal needs to be to find the ones that will work the best with your unique needs and desires.

    What to Keep in Mind When Choosing a New Tool

    Cost (for both licensing and support): Budget is an eternal tyrant, and your team needs to go into this procurement work with a solid understanding of your financial limits. If you have stringent limits there, there are some types of open source software like Selenium that could be useful. These tend to require a substantial degree of technical skill, so they may not be as helpful for you—if that’s a weakness of your team.

    Type: There are several different types of DevOps testing tools. Language is one of the more important factors when deciding on one–make sure the tool operates in either the same language as your application or at least one in which your team can efficiently operate. The intended platform for the tool is also notable, as is the intended audience (i.e. whether the product aims more towards developers or testers).

    DevOps integration support: It’s always important to double-check that your tool supports both DevOps tool integration and continuous integration. If you don’t effectively coordinate your tools, it will undoubtedly slow down your process.

    Training: Depending on the level of expertise within your DevOps team, you’ll need to ensure that there is an appropriate degree of training on how to use the team—for the people who will be using it.

    Quality test reports: Test reports with both depth and breadth are crucial to success in continuous testing. These help notice defects and their root causes, then allow you to test the effectiveness of your analysis.

    Excellent customer support: You will want to use a tool that will serve your needs well. That means a tool that understands your specific situation and can help you work through complications.

    The Necessity of Automation Skills

    All of this aside, you cannot just rely on the strength of your test automation tools to get you through the testing process. If you decide to implement test automation without having people on your team with the skills to manage it, you may end up in a challenging position riddled with inefficiency.

    Here’s what you need from a test automation software engineer: They must have a broad base of knowledge that encompasses test automation tools. Beyond that, they need to understand how to dive deep into software testing functionality and the technical complexities that undergird the project. They should also know how to write scripts alongside development, collaborating with both operations and development teams. That collaboration between test automation, development and operations will have a deeply important role in writing test scripts and maximizing the coverage of your tests.

    A test automation software engineer’s skills offer invaluable stability. Indeed, tools are often built on a foundation of skills. If you have a resourceful and capable software engineer on hand, you’ll be much more prepared for the fluctuations of the market than if you’re relying on a single tool. If you decide to focus on only one tool, your team risks limiting itself and potentially falling behind the times and needs of your customers.

    The Dangers of Automation

    Automation is one of the foundations of DevOps’ success. But even so, you must strike a delicate balance. If you automate too much, you may end up hurting your product.

    When you start connecting too many different tools to your project, you begin to risk unwanted outcomes that practically cancel out the investment you made in DevOps in the first place. If you try to automatically test things that automation can’t effectively measure (general user experience, for example), you’ll end up with worthless data. Your various automation tools can start to create more work than they’re resolving if you need to spend a great deal of effort in managing them.

    That said, if you under-automate, you’ll be losing out on workflow efficiencies that your competitors are using, making your team less competitive. Thus, it’s necessary to try and balance the two. The first step to striking this balance is having a thorough understanding of your requirements vis-a-vis testing, development and deployment. If you have that under your belt, you can find the automation tools that work best for your goals. Once you have the right combination of automation tools, you’re golden.

    Also, test automation doesn’t negate the need for manual testing—and it isn’t designed to. Of course, certain kinds of manual testing can be eliminated by automation (especially the repetitive kinds).

    But you still need manual testers behind the wheel examining your product more thoughtfully and at a deeper level than an automated program. That deep-level variety of manual testing can often discover issues that automatic testing failed to see. It can also provide a more thorough level of insight into the user experience that automatic testing will seldom be able to provide.

    Benefits of Test Automation

    We’ve covered a lot of deep ideas in this piece. But at the end of the day, test automation is beneficial for a few simple reasons: it reduces human error, simplifies your tests, allows you to deliver products much more quickly and leads to a much more reliable quality assurance structure.

    That said, test automation won’t be a panacea for all your team’s ills. It will work, but only if you’ve chosen the right tools and you have people on your team with the skills to use them effectively. Once again, don’t rely on continuous automated testing as the be-all and end-all of your quality assurance practice. Several QA questions show that a human presence is much better at resolving certain types of problems and over-automating can cause significant inefficiencies.

    Test automation can be a wildly useful tool if you use it well. These tips will help you take your organization to the next level of efficiency and excellence.

  • Why IT Should Focus on Quality Over Velocity

    Why IT Should Focus on Quality Over Velocity

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

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

    Quality Assurance = Customer Satisfaction

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

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

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

    Quality Shouldn’t be Assumed

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

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

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

    It’s a People Problem

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

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

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

  • All Day DevOps: System Hardening with Ansible

    All Day DevOps: System Hardening with Ansible

    The DevOps pipeline is constantly changing.  Therefore, relevant security controls must be applied contextually.

    We want to be secure, but I think all of us would rather spend our time developing and deploying software. Keeping up with server updates and all of the other security tasks is like cleaning your home: you know it has to be done, but you really just want to enjoy your clean home. The good news is you can hire a “service” to keep your application security up to date, giving you more time to develop.

    At the recent All Day DevOps conference, Akash Mahajan (@makash), a founder/director at Appsecco, discussed hardening your system’s security with Ansible. In addition to his role at Appsecco, Akash is involved as a local leader with the Open Web Application Security Project (OWASP).

    Misconfiguration

    During his presentation, Akash mentioned the OWASP Top 10 Security Vulnerabilities list, zeroing in on No. 5: Security Misconfiguration. To determine if you comply with the guidelines, No. 5 on the list asks:

    • Is any of your software out of date?
    • Are there any unnecessary features enabled/installed including ports, services, accounts, pages or privileges?
    • Are default accounts and their passwords enabled/unchanged?
    • Are security settings and libraries not set to secure values?

    I am sure no one reading this article still uses the default administrator password, but can we say the same of your peers? Have you gotten around to installing the latest software patches on your server?

     

    Automation

    If a task can be automated, developers automate it. So we should automate our security tasks too, where we can. OWASP provides guidance here, suggesting you should:

    • Have a repeatable security hardening process.
    • Ensure your development, QA and production servers are configured identically but with different passwords.
    • Automate the process to minimize the effort required to setup a new secure environment.
    • Implement a process for deploying all new software updates and patches in a timely manner to each deployed environment.
    • Run scans and audits periodically to help detect future misconfigurations or missing patches.

    This is all part of security hardening, which is, “the process where we identify default configuration present on a system and apply changes that will change the configuration to secure values.” This can be applied to your network, transport, application, and kernel networking parameters.

    Ansible Playbooks

    Ansible is one of the solutions Akash likes to work with, but there are others solutions on the market that provide similar value. Without trying to endorse or evaluate one solution over another, let me share perspectives from Akash’s experience with his toolset.

    Why does he like it? It boils down to playbooks. An Ansible playbook is a codified security document, allowing you to describe the desired state of a system, rather than the specific steps of how to get to that state. As Akash points out, things change—it is better to have the end state described rather than have to change commands when the system changes.

    Other advantages of playbooks include:

    • Playbooks are written in YAML providing us with structure that we can learn and train on
    • Playbooks are text files, so we can use Git for version control
    • Managing playbooks is just like managing any software project
    • Playbooks are infrastructure as code but for security
    • Playbooks consist of roles, a key aspect of security
    • Numerous playbooks are available as open source

    The bottom line is you can—and you should—automate your security hardening process. Your users and other stakeholders will thank you and, most of all, you will thank yourself because you can spend more time on the things you love to do.

    Ansible is just one example of a solution that can be used to automate your security tasks. If you want to know more, Akash goes into further detail on getting started with Ansible in his full All Day DevOps conference session (just 30 minutes). The other 56 presentations from the All Day DevOps Conference are also available online, free of charge here.

    This blog series is reviewing sessions from the All Day DevOps conference from November which hosted over 13,500 registered attendees. Last week I discussed, “DevOps at Massive Scale.” Next week, look for “Operationalizing a Red Team for Fun and Profit,” delivered by Intuit’s own Ian Allison.

    — Derek E. Weeks

  • QA in the DevOps Era

    QA in the DevOps Era

    In software approaches that produce monolithic applications, it is not uncommon to find siloed teams, with development, testing and operations each an island unto themselves. The responsibilities of test and development are distinct from each other and are not meshed into a hybrid team as you might see in advanced DevOps shops.

    “QA (quality assurance) always comes late in the game to verify or test the software developed by the development team against the predefined specifications know as software requirements,” says Venkata Vinay Pandella, team lead at Nisum Technologies Inc.

    That’s the view inside and among these teams in which legacy development approaches still flourish. The rest of the enterprise sees these teams altogether differently from how they see themselves. “Even in a traditional software engineering organization, folks outside the engineering team generally consider Development, QA and Operations teams as a single group with a single responsibility to deliver a quality software product,” says Pandella.

    Even when Dev and Ops do embrace each other, the rest of the enterprise often maintains the same POV it had when Dev, Ops and QA were three entities and not one. How do DevOps and QA see QA after the shift?

    DevOps as a Foundation for the New QA

    Enterprises, the business units, Dev and Ops all expect DevOps to propel software using continuous integration (CI), continuous delivery (CD) and ultimately continuous deployment techniques that are fueled by and gain traction using automation. The more processes that Dev and Ops teams are able to automate, the more that DevOps accelerates the process of software delivery and deployment to the delight of software consumers and the business.

    DevOps enables teams to push software out weekly, daily and hourly through continuous software improvement. This negates the many obvious downsides of applying the traditional software development approach, which requires excessive planning, cross-team coordination, staging, testing and releases of monolithic blobs of software all at once. “Given that companies organically adopt DevOps together with agile software development practices, business managers are able to fulfill the objective to get high-quality software out to market faster,” says Pandella.

    To meet the goals of DevOps, QA must feed into the automated development process and help teams to achieve increasing software quality and faster time to market.

    QA: The Quality Icing on the DevOps Cake

    According to Pandella, QA specialists and teams have a number of roles and responsibilities in DevOps:

    • QA should prevent software defects at the earliest point during the software development process rather than find and report on software bugs after DevOps has produced the software. This will help to ensure that customers experience as few defects as possible.

    • QA takes ownership of and responsibility for continuous software improvement and software quality tracking throughout the software development life cycle.

    • Every QA team member is responsible for identifying problems not just in the product but also in the process, and recommending changes wherever they can to improve the continuous delivery of quality software.

    • Tests must be in code, based on the designed release cadence to publish a new release every week, every day or every hour. There is no room for manual testing—QA must develop automation systems through code that can ensure quality standards are maintained.

    • Automation rules: QA should automate anything that can be automated.

    • QA testers are the quality advocates, influencing both developmental and operational processes. They don’t just find bugs; they look for any opportunity to improve the quality of software through the software development process.

    • QA must move beyond functional testing, because even a small, nonfunctional defect introduced into a critical transaction process on an e-commerce website can bring a business to its knees. Many organizations have mature processes for automating functional testing; they are only beginning to apply these practices to other areas of testing such as security and stress testing. In particular, load testing and stress testing are critical disciplines for DevOps organizations that move at high velocity.