Tag: Quality Assurance

  • mabl Adds Load Testing Tool to Test Automation Suite

    mabl Adds Load Testing Tool to Test Automation Suite

    mabl today added a load testing capability to its portfolio of application testing tools that it makes available via a software-as-a-service (SaaS) platform.

    That capability promises to make it simpler to streamline testing within a DevOps workflow by making available load testing tools that measure application peformance alongside existing mabl tools accessible via a test automation platform.

    Dan Belcher, mabl CEO, said the goal is to make it simpler for developers to run functional and non-functional tests as early as possible within the software development life cycle.

    It’s not clear how much responsibility for testing is shifting left toward developers, but as it becomes simpler to run these tests it is more likely they will be run, noted Belcher. One of the core issues that plagues application development today is the inadequate level of testing. That issue is largely because it takes too much time to create and run relevant tests, he added.

    mabl streamlines that process using a test automation platform based on a low-code tool that makes it simpler to create and manage the testing process. Those tests can be configured to run independently or be integrated with a DevOps pipeline, noted Belcher.

    Shifting testing further left toward developers doesn’t eliminate the need for a dedicated team of testers, but it should reduce the number of routine errors being made. That reduction should free those development teams to focus more of their time and effort on more complex quality assurance (QA) issues, said Belcher.

    Of course, more testing processes will become automated as artificial intelligence (AI) continues to evolve, so most organizations will soon find themselves revamping those processes. In theory, SaaS platforms that aggregate testing data should be in a better position to apply AI models to testing. That’s critical because the pace at which even more complex applications are being built and deployed shows no sign of slowing down.

    In the meantime, DevOps teams should assume they will soon be held more accountable for security issues that arise after an application is deployed. It may be a while, but the number of legislative initiatives focused specifically on application security has increased; it’s only a matter of time before laws that hold organizations liable for security are going to be passed. At the same time, the level of tolerance application software consumers have for issues that arise because some trivial mistake led to, for example, a SQL injection attack, is dropping. The expectation is that application testing is soon going to be a lot more thorough than it has historically been.

    The issue, of course, is that too many development teams tend to view security requirements as obstacles to be overcome rather than as intrinsic elements of the QA process that is supposed to ensure expectations are consistently met and exceeded.

    At this juncture it’s clear that application testing is going to improve. The only thing left to determine now is how much friction will be experienced on the way to achieving that goal.

  • Continuous Testing: The Key to Quality Assurance in the DevOps Era

    Continuous Testing: The Key to Quality Assurance in the DevOps Era

    Continuous testing has emerged as a critical aspect of quality assurance in the DevOps era. In recent years, there has been a rapid transformation in software development methodologies. With the advent of DevOps, there has been a significant shift toward automation and continuous integration and delivery (CI/CD). The traditional approaches to quality assurance are no longer adequate to meet the needs of modern software development practices. Continuous testing is the key to ensuring that the software is delivered on time, with quality and reliability.

    Definition of Continuous Testing

    Continuous testing is a process of executing automated tests continuously throughout the software development life cycle to provide rapid feedback on the quality of the code. It is an essential component of DevOps that ensures that the software is always ready for release. Continuous testing allows for the detection of defects and errors at an early stage, which reduces the risk of production issues and enhances the overall quality of the software.

    Importance of Continuous Testing in DevOps

    To understand the importance of continuous testing in DevOps, it is essential to understand the evolution of quality assurance in software development.

    Traditional Waterfall Method

    The traditional waterfall model of software development had a sequential approach to quality assurance. Testing was only performed after the development phase was completed. This approach often led to delays and increased costs due to detecting defects later.

    Agile Methodology

    The Agile methodology introduced an innovative approach to quality assurance. Testing became an integral part of the software development lifecycle, and the focus was on continuous feedback and improvement. However, even with Agile, testing was still done in batches, and there was a significant amount of manual testing involved, which could be time-consuming and prone to errors.

    DevOps Model

    The DevOps model took the concept of continuous feedback and improvement to a new level. With DevOps, testing became automated, and continuous integration and delivery became the norm. This approach significantly reduced the time to market, increased collaboration between development and operations teams, and enhanced the overall quality of the software.

    The Role of Continuous Testing in DevOps

    Definition of DevOps

    DevOps is a software development methodology that emphasizes collaboration and communication between development and operations teams to deliver software products rapidly and reliably. It involves the integration of development, testing and operations into a continuous process, with automation as a key enabler.

    Importance of Continuous Testing in DevOps

    Continuous testing is a critical component of DevOps. It enables the testing of software continuously throughout the development lifecycle, which helps to identify defects and issues early on.
    This early detection of issues is essential in reducing the risk of production issues, and it allows for timely feedback, which facilitates faster decision-making.

    Benefits of Continuous Testing in DevOps

    There are several benefits of continuous testing in DevOps, including:

    · Faster time to market: Continuous testing enables the rapid release of software, reducing the time to market significantly.
    · Improved collaboration: DevOps emphasizes collaboration between development and operations teams, and continuous testing facilitates this collaboration by providing continuous feedback on the quality of the code.
    · Enhanced quality: Continuous testing enables the early detection of defects and issues, which reduces the risk of production issues and enhances the overall quality of the software.
    · Reduced costs: Continuous testing can help to reduce costs by identifying defects and issues early on, which reduces the cost of fixing issues later in the development cycle.

    Implementing Continuous Testing in DevOps

    Choosing the Right Test Automation Tools

    The selection of the right test automation tools is critical to the success of continuous testing in DevOps. Some of the popular test automation tools for DevOps include Selenium, Appium, Cucumber and JUnit.

    It is essential to choose a tool that is easy to use, integrates well with other DevOps tools, and has strong community support.

    Building an Effective Test Automation Framework

    An effective test automation framework is essential to implementing continuous testing in DevOps. A test automation framework is a set of guidelines and standards that help in the creation and execution of automated tests.

    A good framework should be modular, flexible, and scalable. It should also be easy to maintain and extend as the project grows.

    Integrating Continuous Testing Into the DevOps Pipeline

    To implement continuous testing in DevOps, testing should be integrated into the DevOps pipeline. The DevOps pipeline is a series of steps that automate the software development process, from code commit to production release.

    Continuous testing should be integrated into every stage of the pipeline, from unit testing to acceptance testing.

    Best Practices for Continuous Testing in DevOps

    To achieve the full benefits of continuous testing in DevOps, it is important to follow best practices. Some of the best practices for continuous testing in DevOps include:
    · Test early and often: Testing should begin early in the development cycle and continue throughout the development process.
    · Automate everything: Automation is essential for continuous testing in DevOps. All tests should be automated, including unit tests, integration tests and acceptance tests.
    · Integrate testing into the DevOps pipeline: Testing should be integrated into every stage of the DevOps pipeline, from code commit to production release.
    · Use the right test data: Test data should be relevant and representative of real-world scenarios.
    · Collaborate across teams: Collaboration between development, testing and operations teams is essential for the success of continuous testing in DevOps.

    Challenges and Solutions for Continuous Testing in DevOps

    There are several challenges to implementing continuous testing in DevOps, including:
    · Test data management: It can be challenging to manage and maintain relevant test data that accurately represent real-world scenarios.
    · Test environment management: Ensuring that the test environment is consistent and reliable can be a challenge, especially in complex applications.
    · Test automation maintenance: Test automation scripts can become complex and challenging to maintain, especially as the application evolves.

    Strategies for Overcoming Continuous Testing Challenges

    There are several strategies for overcoming the challenges of continuous testing in DevOps, including:
    · Test data management: Creating synthetic test data can help ensure that the data is relevant and representative of real-world scenarios.
    · Test environment management: Using containerization technology such as Docker can help ensure a consistent and reliable test environment.
    · Test automation maintenance: Regular maintenance and refactoring of test automation scripts can help keep them up-to-date and relevant.

    Conclusion

    Continuous testing is the key to ensuring quality in the DevOps era. It enables the rapid release of software, reduces the risk of production issues and enhances the overall quality of the software. Implementing continuous testing in DevOps requires choosing the right test automation tools, building an effective test automation framework, integrating testing into the DevOps pipeline and following DevOps best practices. Although there are challenges to implementing continuous testing in DevOps, these challenges can be overcome with the right strategies and practices. By implementing continuous testing in DevOps, organizations can achieve faster time to market, improved collaboration, enhanced quality and reduced costs.

  • Decidability: SLOs to Measure Quality Attributes

    Decidability: SLOs to Measure Quality Attributes

    You may be familiar with the “-ilities”–the quality attributes that define a system’s so-called “non-functional” parts. One that isn’t on the list is decidability, which is the ultimate quality attribute because it focuses on what truly matters to your team and your customers.

    You can’t do it all. Fast, cheap and good? Here in the real world, we have tradeoffs. Software is the mouth that keeps on eating, but it isn’t a digital free lunch. When we decide what not to do, we bring greater clarity and productivity to the team.

    Of course, the world is full of “shoulds.” We should make our product accessible, we know. It should be secure; it should be reliable. Of course. But how do you decide the limit of your shoulds? To enable decidability, you need context. To gain a contextual understanding of your most critical quality attributes, you must talk to real people and reason about your situation. There’s no other way.

    New Design, Wrong Decision

    I had an eye-opening experience that demonstrated firsthand how quality attributes don’t necessarily deliver business results. Six years ago, I was working on e-learning software for public schools. One of the main problems was user management. We were selling to massive institutions that often had only one administrator responsible for onboarding all the users across hundreds of schools. While school was out, they had to enter data for the schools, create classes and assign teachers.

    Once we had a design for improving the workflow (luckily, before implementing it), we took the mockups to a customer to show the fancy ideas we had built. They surprised us by showing us “what it looks like for them”–a spreadsheet! They were copying/pasting everything by hand.

    So we asked them, “What if we gave you a way to upload the spreadsheet? Would that work?” And, of course, the answer was yes! So we scrapped our plans to build a fancy form and made a drag-and-drop input field to validate and upload the sheet. The decision was clear.

    Measuring Decidability

    How do we measure the critical business drivers and turn them into decidability? The closest answer I’ve found is service level objectives (SLOs). These take the fuzzy -ilities and turn them into metrics and goals that can quickly inform decisions.

    SLOs are a universal tool for measuring quality attributes from an indicator expressed as a proportion of “good” events for a given quality like reliability or scalability. Decidability comes from aggregating the SLO data across your services, geographies, user groups and quality attributes over time.

    Comparing an indicator to a particular goal (tuned over time as the business and engineering context changes), we can derive an allotment of allowable “bad” time or events–an error budget. Setting an error budget for reliability, performance, scalability, etc., allows you to decide how poorly your service can operate and still keep customers happy. Further, you can find the breaking point of user behavior and defend your service proactively from violating the quality attributes you expect.

    Technical debt inevitably stems from all the -ilities you should focus on but couldn’t quite get to, given your situation. Some technical debt is deliberate and even prudent. To tackle technical debt, you must decide which new features to put on hold to make space in the roadmap. SLOs provide a data-driven baseline to make this decision quickly and accurately by telling you when your -ilities are within error budget or out of whack.

    Scaling Decidedly

    You might start on a small, single-purpose project that’s rarely used. But if that changes, you must decide how to invest, redesign and maintain it. Suddenly, you might care about performance, scalability, security and the rest. First, you need decidability so you can prioritize your work. So you gather the people together who care about the service, and you start to think and talk and stack rank. You use your instrumentation to build metrics, set clear goals and do what it takes to keep the system running within expectations.

    Automating action based on error budgets is the magic of setting SLOs. They aren’t just for sophisticated, highly available services. Error budgets are extremely valuable in systems when you aren’t sure what to do. SLOs create decidability in all the trade-offs of all the quality attributes and the functional needs of the app or service you’ve carefully built.

    If you put decidability first, the rest will fall into place.

  • Software Quality is the Heartbeat of the Best Organizations

    Software Quality is the Heartbeat of the Best Organizations

    JPMorgan recently announced it was hiring 2,000 engineers, despite the gloom in global economic markets. Is this not an odd risk for an organization to take, given the demand for (and cost of) software developers today? What’s happened?
    JPMorgan’s hiring drive is no mystery. Virtually every company in the world is leveraging software, with many transforming themselves into software organizations to drive new efficiencies, widen profit margins and create new markets. Software has been disruptive, so much so that the current era has been dubbed the “third industrial revolution.” Consumers are benefiting from switching providers at the click of a few buttons and most consume services through software. Bad software experiences today mean rapid customer churn and competitive disadvantage.

    Quality Should be the Heartbeat of any Organization

    In spite of quality’s importance, testing is still perceived as a secondary discipline and a check-the-box exercise. This reflects practices developed for assembly lines during the original industrial revolution. A product gets assembled and testers verify its quality as it leaves the production line. Testing’s goal in this context was to identify problems before they reach end-users. This same approach has been applied widely to software development and is still used by “waterfall” organizations.

    Yet, software development has been revolutionized by new methodologies and practices. Software today is constructed at incredible speed. Notice I’m using the word “constructed” and not “built”—the best developers leverage libraries or APIs to assemble software using existing components. They then add a few pieces of custom business logic to define the intellectual property of an application. Many organizations don’t even code software, instead customizing off-the-shelf software with vast configurations to modify functionality.

    The assembly-line approach to software development is no longer appropriate. When testing is left late, defects are found before a release or even in production. Release cycles are longer and products poorer quality. Yet, many organizations still stick religiously to this approach, with testing teams operating in distinct silos.

    The Role of the Tester is Evolving

    The best organizations in the world are changing how software is built. Testing is no longer a check-the-box exercise at the end of the assembly line. It is transforming into a discipline that revolves around evangelizing and driving quality throughout an organization.

    Quality should be baked in as early as possible, touching every artifact produced. Ideally, this should occur from the start, as a requirement is formulated, all the way through to the software being shipped. The idea of siloed teams working on different pieces is outdated. For quality to thrive, teams must collaborate.

    Modeling offers one approach to driving quality and collaboration throughout an organization. Its journey starts with a requirement. These are typically formulated by business analysts or product owners. Having been a product owner, I found that this usually involves lots of scribbles on paper before communicating to stakeholders on a whiteboard. The preliminary requirement then gets reviewed and refined.

    At some point, the requirement will be converted into walls of text in a project management tool. Modeling intervenes at this stage, adding visualizations that make requirements more consumable, less ambiguous and easier to understand.

    The word “modeling” may seem a scary concept, but it need be no more than a flowchart that encapsulates a requirement. The benefit of modeling is not only that it provides a digital collaboration asset; models can also generate coverage-focused tests before a line of code is written. Modeling creates requirements that are quality-driven and quality-driving.

    The Journey of Quality-Driven Requirements

    • Models Provide Data Upfront

    Developers today require rich data to develop, while testing is only as good as the available test data. Yet, many organizations still feed slices of production data into developers and test cases.
    This approach is problematic for several reasons. First, it often risks legislative non-compliance. Second, production data features large volumes of low-variant data. Data may not then be available when developing unusual-but-important scenarios. Imagine an overdrawn account with several beneficiaries: What should happen when a transfer is attempted?

    Modeling defines data explicitly in requirements. It allows engineers to understand a requirement explicitly, including the relevant data. From the modeled definitions, correct data can then be masked and subset, or generated synthetically. Data can further be delivered on-demand and at scale using database virtualization.

    • Models Provide Understanding

    Once the requirement and necessary data are available, code can be developed. Using text-based requirements, misinterpretations often lead to incorrect functionality. Visual models instead align closely with business logic, and we often see developers enriching models with additional context so that models align with the actual software implementation.

    • Models Generate In-Sprint Tests

    Once the code is developed, the same tests which were created earlier from the requirements can be executed against new functionality. This facilitates reuse and means the test cases are ready to be executed immediately.

    Some tests might further be selected for automation. In this instance, automation can be overlaid onto the requirements model, reusing code to generate scripts. These scripts then become part of the standard regression pack as new features are added to the product.

    A Change Request Comes In

    With iterative development, change requests are common. This typically creates havoc for quality, since it is difficult to understand the impact of a change, and time-consuming to update artifacts like tests and data.

    Traceability is key to overcoming this challenge. Models can connect to external DevOps tools to provide end-to-end traceability, from a requirement, all the way to code and tests. The impact of a change can then be identified directly. Models can be updated, automatically synchronizing test data, test cases, and automation to bring everything up to date.

    Testing for the Fourth Industrial Revolution

    Software is playing a vital role in virtually every organization, as already recognized by organizations thriving today. Baking quality in early is the only way to ensure quality software. The role of testing must change on a large scale. Models offer a way to achieve a “shift left” and collaborative approach to quality while testing earlier and more rigorously by automating and optimizing test and data creation.