Tag: assessment

  • Why Software Usability Testing Is Essential

    Why Software Usability Testing Is Essential

    Keeping an eye on the bigger picture is important when doing just about anything. This adage holds true when testing software, too. There’s no doubt that the QA testing process for software is essential. It makes sure everything is running smoothly and as it should. But generally speaking, it doesn’t always fully take into account the user perspective. Even though developers, designers and testers all try to keep the end user in mind when building and testing, there is no true way to anticipate and test for the variability of actual user experience in the wild.

    This is why it is essential to consult actual users. That’s where the process of usability testing comes in. Every organization should consider implementing the practice before a software product launch.

    Usability Testing Defined

    Unlike functional testing, usability testing hones in on the user’s experience of a product. It focuses on how an application works in the real world with real users. In-house, it’s easy to test a feature and check a box to say it works. But that’s not necessarily the way an application will be used by every user in every situation.

    Usability testing involves having participants complete a few tasks with an application. Then, depending on how easy or difficult those tasks were, testers and developers can decide which, if any, improvements and changes need to be made. Usability testing helps organizations accomplish three key goals:

    1. Uncover opportunities to improve
    2. Identify issues in design
    3. Learn about intended user behaviors

    Differences Between Testing Types

    Software usability testing is sometimes confused with other similar approaches to quality assurance and control. Let’s look at and clarify similarities and differences between these methods.

    • User research versus usability testing: User research comes earlier in the software development life cycle and actually involves usability testing, but it also includes other components like interviews, surveys and focus groups to identify the behaviors of users.
    • User testing versus usability testing: User testing is put into place to validate a product idea. It’s used to understand how a user approaches a given situation and how a product might help address that situation. Usability comes later in the process of testing that specific product.
    • User acceptance testing versus usability testing: User acceptance testing confirms that a product works as intended; it’s about functionality. But usability testing will get into the specifics of user opinions, expectations and actual experience.

    Types of Usability Testing

    There isn’t just one way to conduct usability testing. There are a few options organizations can choose from based on differing objectives.

    • Moderated versus unmoderated: Moderated usability testing involves a moderator facilitating the progress of a tester through a series of tasks. This gives an organization the opportunity to ask questions during specific parts of the process. An unmoderated approach allows a user to complete tasks entirely at their own pace. This method can be conducted at any time, anywhere.
    • Remote versus in-person: In-person testing gives UX researchers the ability to provide specific devices to avoid technical issues, although it might mean missing issues with a user’s actual device that occur in the wild. It also allows for observing non-verbal reactions. Remote testing, on the other hand, allows users to complete tasks as they might in the real world from anywhere and with their actual device.

    Some specific usability testing methods and techniques that can be used include:

    • Screen/video recording: Gives insight into how long it takes to navigate and click through a website, application, system, etc. as well as tracking non-verbal cues.
    • Usability lab: A dedicated testing location. All variables can be controlled so the focus remains on the testing.
    • Guerilla testing: This is done in the wild, recruiting a few people to do a quick software test. While this can be quick and cheap, you can’t ensure you’re testing your specific target audience.
    • Contextual inquiry: Testing in a participant’s own environment with an interview and/or third-party observation of their use of the product. This allows researchers to know things like what device is used and where and how the application is used.
    • Usability testing partners: These are third-party organizations with testing expertise and access to a broad pool of participants that can be recruited and cultivated based on client needs.

    Benefits

    Usability testing can deliver a variety of benefits to an organization, including:

    • Direct feedback from the target audience
    • Cost savings through addressing concerns earlier in software development
    • Detection of usability issues before launch
    • Real-world testing
    • Unbiased assessment

    Costs and Challenges

    The most obvious concerns at the beginning of the software development life cycle are are development costs and time-to-market. While usability testing can take time and involve costs of its own, ultimately, the practice aims to address those concerns; in the long run, it is more expensive to launch a flawed product with poor user experience. A few factors that must be considered when it comes to the time and cost involved in performing usability testing include:

    • Sample size
    • Gathering the right participant profiles
    • Breadth and depth of testing practices
    • Amount of time allocated to the test

    All things considered, when done right usability testing delivers ROI that more than makes up for the cost and time involved.

    Consider the implications when an application is launched and certain users are frustrated with the experience and are left with a negative feeling toward the brand. Usability testing addresses this concern and allows for issues to be discovered and fixed earlier in the development life cycle. Investing in developing and testing for a positive user experience is always worthwhile and effective.

  • Using CALMS to Assess an Organization’s DevOps

    Using CALMS to Assess an Organization’s DevOps

    Of the tried-and-tested frameworks that allow enterprises to assess DevOps in their organization and how it can be improved, the CALMS model remains particularly useful.

    CALMS, which stands for Collaboration, Automation, Lean, Measurement and Sharing, is particularly helpful for analyzing an organization’s DevOps structure, and ultimately, its utility in any organization. The CALMS framework covers all stakeholders within DevOps, including business, IT operations, QA, InfoSec and development teams, and how they collectively deliver, deploy and integrate automated processes that make business sense.

    “DevOps as a technique is slowly but steadily maturing, so it’s good to see general assessment methods like the CALMS model,” Holger Mueller, an analyst for Constellation Research, said. “The CALMS model gives a good frame of reference to compare the maturity of a DevOps team, and as such,  is invaluable for assessing the state of teams for the transformational change that goes with it.”

    Applying CALMS

    Here are a few ways CALMS can be applied to DevOps for enterprises either thinking about shifting to a DevOps structure or seek to make improvements to an existing deployment.

    Culture

    It is long-established that technology adoption must be to serve a business need rather than investing in technology for its own sake. This shift in mindset applies to how the “culture” component of CALMS supports how the forecasted ROI associated with automating a process must be championed across the DevOps team. This mindset is especially important for getting the non-technical business teams onboard, Mueller said.

    “DevOps must have the backing from the business executives. That’s a crucial factor in the culture part,” he said. “One thing software teams can do is use successful software deployments to help convince the business executives in DevOps to make the investments. Those are the kinds of tribal events that every DevOps organization needs.“

    Automation

    Netflix is well-known as an exemplary case study for DevOps automation. Among other things, it can deploy code and software updates in a matter of minutes across its entire massive infrastructure, many times throughout the day. But Netflix’s example of automation does not take into account what can go wrong at firms that want to follow Netflix’s example when automating their software deployments and updates, Mueller said.

    “The risk is always deploying too fast and you end up deploying bad code,” Mueller said. “Automation, of course, needs to take this into account and compensate. But not everybody can do that.”

    Lean

    Once completed, it is relatively easy to document cost savings by eliminating resources. Within the CALMS framework, the corresponding “lean” component in DevOps is thus relatively easy to assess, Mueller said.

    The good thing about DevOps, Mueller said, is companies can come to a consensus ahead of time regarding what they consider to be a lean operation.

    However, he added, “There is always the risk of being so lean you begin to err on the QA side.”

    Measurement

    The success of software deployments is relatively easy to measure once completed. However, attempting to measure future deployments as part of a forecast model is, of course, much more challenging.

    “It can be surprisingly tricky to measure how good DevOps is ahead of time,” Mueller said. “Measurements should thus allow errors to be pinpointed  quickly during the post-deployment stage to fix the code if needed very quickly.”

    Sharing

    Sharing, in many ways, overlaps with culture. This is where assessing whether all of the different teams within DevOps are working together and communicating comes into play.

    “Thanks to  DevOps, the days of the lone developer are long gone. But sharing is not always easy,” Mueller said. “Even within separate teams, it is easy to fall into the trap of wanting to get your own work done without necessarily thinking about the team as much as you should.”

    The End Result

    While applying CALMS to assess DevOps never hurts, the framework is still not as important as one of the main objectives of DevOps—namely, using technology to make organizations’ operations more agile and reactive to customer needs, Mueller said.

    “At the end of the day, assessment methods such as CALMS are great, but they are never as important as focusing on implementing next-generation applications,” he said.

    — B. Cameron Gain