According to Split, this aligns with the needs of today’s product developers because feature experimentation is considered crucial for successful digital experiences, but many developers believe they are not successful at it. With this integration, Azure App Configuration users can effectively run experiments in Azure, using Split’s capabilities to test features in production environments and gather valuable experimentation data.

“With this new capability jointly delivered by Azure and Split in Azure App Configuration, teams can use experimentation and insights to reduce risk, fuel innovation, and create delightful digital experiences by adopting modern approaches for progressive delivery in app development,” says Amanda Silver, CVP of the Developer Division at Microsoft. “Experimentation from Split within Azure will further our customers’ ability to build intelligent apps and release them to market quickly and safely – driving maximum value for end users and fuel business growth.” 

Since 2020, Split has been collaborating with Microsoft and is currently available on Azure Marketplace and integrated with Azure DevOps, including a Visual Studio Code extension. 

The new offering within Azure App Configuration will be accessible in early 2024 through a Private Preview on Azure. Customers interested in early access can sign up for the Private Preview through the provided link and will be notified by Split when it becomes available.

The post Split brings feature experimentation to Microsoft Azure appeared first on SD Times.

UserTesting has introduced a Niche Audience Recruitment feature that enables users to gain valuable insights from unique and traditionally difficult-to-reach groups. This feature allows developers to easily identify important audiences using advanced tools, access perspectives from contributors who were previously hard to engage, and ensure quality by relying on insights from carefully vetted and trusted contributors. 

These advancements simplify the process of managing specific audience needs, helping businesses create solutions that align with their goals more effectively.

UserTesting is introducing new integrations with the third-party platforms FullStory and Canva. The FullStory Integration enables users to connect UserTesting’s user feedback with FullStory’s detailed user session information, aiding in the prioritization of digital optimizations that have the most significant impact on the customer journey. 

“FullStory’s platform combines rich analytics, robust visitor session detail, and collaboration tools to help answer critical questions, understand issues, and uncover new conversion opportunities,” said Will Schnabel, SVP of Alliances and Partnerships at FullStory. “By integrating with UserTesting’s Human Insight Platform, teams can delve deeper into customer journeys, gain a holistic understanding of their audiences, and make data-driven decisions that significantly impact the business.”

The Canva Integration allows users to seamlessly incorporate video-based insights from UserTesting into Canva assets, promoting and sharing key insights throughout the organization to enhance understanding of the customer.

In addition, UserTesting’s Insights Services are a part of the company’s professional offerings, providing a cost-effective way for organizations to outsource research to their in-house experts. These customized research solutions aim to facilitate business growth and informed decision-making while increasing research capacity and expediting insights delivery. Furthermore, Insights Services ensure data security, risk mitigation, and efficient research management.

The post UserTesting adds feature that makes it easier to find users in niche audiences for user experience testing appeared first on SD Times.

By 2027, 80% of enterprises will have integrated AI-augmented testing tools into their software engineering toolchain, which is a significant increase from 10% in 2022, according to Gartner. AI-augmented software-testing tools assist humans in their testing efforts and reduce the need for human intervention. Overall, these tools streamline, accelerate and improve the test workflow. 

The future of the AI-augmented testing market

Many organizations continue to rely heavily on manual testing and aging technology, but market conditions demand a shift to automation, as well as more intelligent testing that is context-aware. AI-augmented software-testing tools will amplify testing capacity and help to eliminate steps that can be performed more efficiently by intelligent technologies. 

Over the next few years, there will be several trends that drive the adoption of AI-augmented software-testing tools, including increasing complexity of applications, increased adoption of agile and DevOps, shortage of skilled automation engineers and the need for maintainability. All of these factors will continue to drive an increasing need for AI and machine learning (ML) to increase the effectiveness of test creation, reduce the cost of maintenance and drive efficient test loops. Additionally, investment in AI-augmented testing will help software engineering leaders to delight their customers beyond their expectations and ensure production incidents are resolved quickly. 

AI augmentation is the next step in the evolution of software testing and is a crucial element for a strategy to reduce significant business continuity risks when critical applications and services are severely compromised or stop working. 

How generative AI can improve software quality and testing 

AI is transforming software testing by enabling improved test efficacy and faster delivery cycle times. AI-augmented software-testing tools use algorithmic approaches to enhance the productivity of testers and offer a wide range of capabilities across different areas of the test workflow.

There are currently several ways in which generative AI tools can assist software engineering leaders and their teams when it comes to software quality and testing:

• Authoring test automation code is possible across unit, application programming interface (API) and user interface (UI) for both functional and nonfunctional checks and evaluation. 
• Generative AI can help with general-impact analysts, such as comparing different versions of use stories, code files and test results for potential risks and causes, as well as to triage flaky tests and defects. 
• Test data can be generated for populating a database or driving test cases. This could be common sales data, customer relationship management (CRM) and customer contact information, inventory information, or location data with realistic addresses. 
• Generative AI offers testers a pairing opportunity for training, evaluating and experimenting in new methods and technologies. This will be of less value than that of human peers who actively suggest improved alternatives during pairing exercises. 
• Converting existing automated test cases from one framework to another is possible, but will require more human engineering effort, and is currently best used as a pairing and learning activity rather than an autonomous one. 

While testers can leverage generative AI technology to assist in their roles, they should also expect a wave of mobile testing applications that are using generative capabilities. 

Software engineering leaders and their teams can exploit the positive impact of AI implications that use LLMs as long as human touch is still involved and integration with the broad landscape of development and testing tools is still improving. However, avoid creating prompts to feed into systems based on large language models (LLMs) if they have the potential to contravene intellectual property laws, or expose a system’s design or its vulnerabilities. 

Software engineering leaders can maximize the value of AI by identifying areas of software testing in their organizations where AI will be most applicable and impactful. Modernize teams’ testing capabilities by establishing a community of practice to share information and lessons and budgeting for training. 

The post Take advantage of AI-augmented software testing appeared first on SD Times.

Accessibility is all about the user experience, and is especially important for users with disabilities. Automated end-to-end testing helps answer the question of how easy or difficult it is for users to engage with the software.

“If the software is crummy, if it’s not responding, you’re going to have a bad experience,” noted Arthur Hicken, technical evangelist at Parasoft.  “But let’s say the software has passed the steps of being well-designed and well-constructed. Hicken said, after that, come those accessibility tests, which are, is this really usable and well-suited for humans? And which tasks do humans use most?”

There is nothing innate about test automation that can raise a flag to any issues, unless the model is trained to identify and report, for instance, if any tasks take more than four steps to complete, it should be looked at.

According to Jonathan Wright of Keysight, it’s equally important to be sure the application is usable and accessible in various regional deployments involving different language sets and cultural variations. “I had a call with a large-scale organization and they wanted to know how we could support their multiple different localization deployments, which includes help and documentation. So it’s really the ability to support global rollouts that follow the sun.”

Wright said in large organizations, centers of enablement are being marginalized as self-service takes hold. “I’m in a large organization, what tools and technology do I need? And you know, it’s usually a people problem, not a technology problem. It’s kind of giving them the right tools to be able to help them do the job.”

For accessibility testing, mabl’s Fernando Mattos said companies often will have a different team to do that type of testing. “Many times, it’s a third-party company performing that, along with legal advice. What we’re trying to do is to shift that left and allow the reusability of you having already tested the whole UI. Why recreate all those tests in a separate tool, and why have a different team do it much later after deployment?”

The impact of a poor user experience on digital businesses can involve loss of customers and revenue as users today expect a seamless experience. “In e-commerce, in B-to-C commerce, they’re seeing hypercompetitiveness in the market and customer switching because the page takes a little too long to load,” he said. “And that talks a little bit more about what end-to-end testing is.”

Mattos added that making sure things are working properly has been seen as functional quality, but it’s important for organizations to make sure the performance of the application is fast, that it responds quickly, and the UI shows up quickly. He added that organizations can reuse their functional test cases to check for accessibility, so if a development team is pushing new features, and one introduces a critical accessibility issue that gets caught right at the commit or pull request phase, it can get fixed right away. Mabl, and the industry as a whole, is moving to shift this testing left, rather than performing it just prior to release.

Mattos noted that there are libraries for automated accessibility testing that can be used to catch 55% to 60% of the issues, while the remaining 40-45% of issues have to be done by people with the disability or experts that know how to test for it. But for the 55-60%, mabl pushes those into development and introduces accessibility testing there, instead of waiting for a third-party company or team to duplicate the test and catch an error a week later.

The post Accessibility testing appeared first on SD Times.

What is a Developer Advocate? 

I recently looked up the word “advocate” online. It is defined as “a person who publicly supports or recommends a particular cause or policy.” At face value, this is someone who is actively engaged in supporting developers and their interests at companies. I assume that means enabling them and helping them do their best, be their best, make their work easier or more efficient, and hopefully more enjoyable. Is that correct? I can see the need to have someone in place for the developers. I am definitely not saying they aren’t needed. They are.

DevRel was started by developers, but it has expanded to include other roles, but the title still remains. 

Rejected as a DevRel

I recently found out about a popular Slack channel made up of DevRel professionals recommended to me by several of my peers. My parody videos were shared on the channel and got a very positive response. I decided to apply to the channel myself to get connected with the group. After several weeks of waiting and wondering, I got a rejection email:

“Based on the description you left, it doesn’t seem like you’re actively working as a Developer Advocate or Technical Community Professional.”

My description was based on the actual things I do online around software engineering topics and performance engineering and observability. I figured if load testing companies have DevRel people in the group, I would fit in. Perhaps my description was not what they were looking for. Perhaps they are right. Maybe I am not a Developer Advocate. Or maybe that title is just not helpful because a lot more roles need advocacy. That got me wondering – what am I?

The Performance Advocate

Perhaps I’m just being a fish swimming upstream, but I think developers have enough advocates supporting them today. I have experienced developers who push causes and policies that I cannot support – those that result in poor performing applications, grossly inefficient systems, or a horrible end user experience – all for the sake of “good enough being good enough”. I’ll continue to be an advocate for the Performance Engineers to support the causes and policies that result in better software and less technical debt. I know, I know – we all say that everyone (including developers) want that. However, I have not experienced that discipline en masse from the developer community like I have from the performance community. I want a relationship with the developer, but I advocate for the performance engineer. 

I was recently told by someone, “We are ALL developers”. I have to respectfully disagree. I may write code here and there, but that does not make me a developer any more than calling me a car because I am in a garage. I love the developer, but I will never be one of them. I want the developer to be successful, but not at the expense of losing the ideals and disciplines I advocate for, which may be different from theirs. It doesn’t have to be an “us versus them” situation, but there must be a balance in the ecosystem. Therefore, I remain the Performance Advocate, to bring that balance. Maybe I’m foolish, misdirected, uninformed, crazy, or all of the above. 

The Need For Specialization

What about areas where specialization is required – like performance engineering? I see Developer Advocate titles in load testing vendor companies. Does this assume that mainly developers are doing the majority of load testing? In my opinion, that is not only wrong, but if it is right, it is not a good thing. Developers shifting load testing left is a good thing, but it is not the only thing and certainly not a replacement for all performance testing that needs to occur. What about other parts of the software lifecycle outside of developing code? Doesn’t there need to be at least a few advocates for the Performance Engineers, System Engineers, etc? Should everybody be lumped into the Developer category? 

The same people who have been telling me for the last five years that developers CAN make good testers, and SRE’s CAN code and test and handle performance and security, and, and and…. these are the same people now talking about burn out rates and the need for platform engineering to relieve cognitive overload. 

An even worse consequence I’m seeing in the market is the loss of fundamental skill sets and the missing context of things that should be known before ever attempting to optimize a system. Add to this the lack of BUSINESS context, and you just have a group of loosely coupled people putting together loosely coupled systems based on fuzzy requirements – and then we wonder why the end result doesn’t make end users happy. By making specialized skills sets a commodity, it lowers the competency and ultimately the product suffers in several ways: technical debt, poor end user experience, higher support costs. Overall, this leads to a bad reputation – which you can’t put a price on.

The post Why I can never be a developer advocate appeared first on SD Times.

This capability integrates into mabl’s SaaS platform so that users can enhance the value of existing functional tests, move performance testing to an earlier phase of the development lifecycle, and cut down on infrastructure and operations costs.

“The primary goal is to help customers test application changes under production load before they release them so that they can detect any new bottlenecks or things that they would have experienced as the changes hit production before release,” said Dan Belcher, co-founder of mabl.

According to the company, these API load testing capabilities allow for the unification of functional and non-functional testing by utilizing functional API tests for performance and importing Postman Collections to cut down on the time it takes to create tests. 

Mabl also stated that this performance testing lowers the barrier to a sustainable and collaborative performance testing practice, even for teams that do not have dedicated performance testers or specific performance testing tools. 

“Anyone within the software team can use it, so it is not limited to just the software developers or just the performance experts,” Belcher said. “Because we’re low-code and already handling the functional testing, it makes it super easy for the teams to be able to define and execute performance tests on their own without required specialized skills.”

Furthermore, these tests can also be configured to run alongside functional tests on demand, on a schedule, or as a part of CI/CD pipelines. 

The post Mabl’s load testing offering provides increased insight into app performance appeared first on SD Times.

Functional tests, performance tests and UI tests, among others, can reveal if an application isn’t behaving or performing as expected. But on their own, they can’t tell you if your user is having a great experience. And as we know, a poor experience can lead to losing customers and revenue, as well as  damage your company’s reputation.

To ensure a good user experience, organizations need to understand their products, they need to know their markets and they need to have empathy for their users. Once that’s established, according to Gevorg Hovsepyan, head of product at test automation platform mabl, you need to make sure your testing strategy aligns with that.

“You need to have a good pulse on what your customers are experiencing, and the quality of that,” Hovsepyan said. “Because ultimately, your goal is to deliver a great customer experience. It’s not just to make sure your API endpoint provides the right JSON structure.” 

With changes in the markets and the need to have everything digital drive faster delivery and better experiences, you need to do UI testing to understand the performance, you need to understand the accessibility, and you need to appreciate the impact on the organization’s business and revenue if those things aren’t addressed, he said.

“For example,” Hovsepyan explained, “if you’re an airline and plan to offer discounted fares on a particular date, your website needs to be able to handle that surge in traffic.  If your website doesn’t perform to enable 10,000 people to buy those tickets, or 1,000 people to buy those tickets, then your bottom line takes a direct hit. Your CFOs and your executives will look at that and ask what happened, and those would-be customers are less likely to book another trip with you.” 

This has led to a shift in mindset to determine where – and how – you test the experience of your customer. It has become increasingly important for the entire organization to contribute to  quality.

Hovsepyan said mabl believes everyone in the organization should be able to participate in building high-quality software, and approaches testing  from a low-code perspective that enables product managers, business teams and engineers who wouldn’t always participate in quality to be able to quickly create tests or reports that are important to them.

Mabl sees quality engineering as a strategic practice that integrates testing into development pipelines to improve the customer experience and business outcomes. Similarly to DevOps, quality engineering seeks to bring teams from across the software development organization together to establish a shared understanding of quality and how everyone can contribute to it. 

Hovsepyan said that low-code test automation enables everyone to participate in testing and contribute to quality engineering, even if they don’t have a lot of coding experience.

“At mabl, we believe that quality is a combination of multiple things from functional to non-functional. So our solution is a modern SaaS cloud platform that unifies all testing capabilities.” Beyond functional testing, mabl has added visual testing, PDF testing, accessibility testing and performance reporting, bringing different testing capabilities into a single unified quality engineering platform that enables users to assess quality, he explained.

Taking steps toward quality engineering

Hovsepyan said first and foremost, organizations should start with a strategic mindset and seek to understand the state of your business, what your business is trying to accomplish, and how quality-related issues might contribute to your business performance – positively or negatively. “If you don’t do that,” he said, “selling your ideas down the road is going to get increasingly harder.”

Once you understand the state of the business, he advised doing a self-assessment to determine the state of quality within your company. “This doesn’t necessarily include understanding the quality of your technology,” he pointed out. “It’s also understanding your org structure, and the skill sets you have in your team. How do you see your plans developing? How can you broaden quality contributions so that testing matches the needs of your customers in the long-term?” 

Finally, he said, assess the maturity of your testing capabilities. Is the team mostly doing manual testing, or is some automation involved? Do you have scripts and infrastructure in place? Then, he concluded, look for modern technologies that are coming to market to help accelerate the journey toward quality engineering.

Content provided by SD Times and mabl

The post Quality assurance assures great user experiences appeared first on SD Times.

Even if an app delivers the best, most innovative functionality, it won’t matter if loading or transactions take too long. Further, as users continue to grow increasingly impatient, the definition of “too long” continues to shrink.

As a result, it is critical to validate application performance, both before new services are launched and before periods of peak activity. For example, for a retailer, it is vital to do extensive performance testing in advance of Black Friday. 

Traditionally, teams have been doing what we’d refer to as “classic” performance testing. Through this approach, teams do end-to-end testing based on high volumes of virtual users or synthetic transactions. Quite often, this type of performance testing is likely to delay new releases by several weeks. Further, this type of testing is extremely costly, invariably consuming a lot of staff time and resources. These challenges are particularly problematic in modern continuous delivery lifecycles, where keeping cycle times to a minimum is critical. 

To combat these challenges, it is imperative that teams gain the ability to speed software releases, while consistently ensuring they’re not introducing performance issues into production environments. 

Introducing Continuous Performance Testing

While a lot has been written about continuous testing, much of the focus has tended to center on continuous functional testing. A subset of continuous testing, continuous performance testing (CPT) is based on the principle of “continuous everything” in DevOps. As opposed to having a single performance testing phase, CPT is employed in situations in which performance testing needs to happen across different phases of the continuous integration/continuous delivery (CI/CD) lifecycle. 

CPT is a key enabler of continuous delivery. With CPT, teams can ensure apps are peak-performance ready at all times, so they can release new code without lengthy performance testing delays. There are three keys to enabling the successful implementation of CPT: 

•     Teams must be able to specify performance requirements at the component level. These requirements must either be tied to functional requirements or product features, or they need to be tied to an application’s specific system components.
•     Teams must be able to test each component in isolation.
•     Teams have to be able to test frequently as application changes occur. 

Continuous Performance Testing: Three Best Practices

As organizations seek to employ CPT in their environments, there are a few key practices that will help ensure implementation success. Each of these practices is detailed in the following sections. 

Test at the Lowest Possible Level of Granularity

With CPT, most testing can be done at the unit, component, or API levels. By establishing testing at the component level, teams can test early and often. This component-level approach offers advantages in speed and operational efficiency.  

Another key advantage is that this approach reduces the number of tests that have to be completed: If component-level tests don’t pass, teams don’t need to run higher-level tests. This means teams can reduce the amount of resource-intensive, end-to-end tests that have to be executed. This also means more testing happens at the CI level, rather than at the CD level, where minimizing lead time for changes is most critical. 

Establish Frequent, Change-Driven Testing 

Once teams begin to do more granular, component-level testing, they can then employ another approach that helps reduce elapsed testing time: change-impact testing. Through this approach, teams can focus testing on specific parts of applications that have changed. At a high level, there are two ways to make this happen:

•     “Inside-out” approach. In this scenario, teams take an inside-out approach by analyzing the impact of changes made in the code of application components. 
•     “Outside-in” approach. In this case, taking an outside-in approach refers to focusing on analyzing the impact of changes made to application requirements or behavior. Through this outside-in approach, every time a requirement is changed, teams flag the set of tests that have been affected. In many organizations, this approach has reduced the amount of ongoing testing that is required by approximately 70%.

Scale Testing of Individual Components 

As mentioned above, doing end-to-end performance testing is expensive and time consuming. Through CPT, teams can effectively scale testing on specific components and reduce their reliance on these resource-intensive tests. To further scale component-level testing, teams can integrate CPT activities with CI/CD orchestration engines. In this way, teams can automate a range of efforts, including provisioning of environments, deployment of app components and test assets, execution of tests, capture and dissemination of test results, and post-testing cleanup. Teams can also leverage continuous service virtualization and continuous test data management, which can further boost scalability and test coverage. 

To learn more, view my earlier article entitled, “Optimize Continuous Delivery of Microservices Applications with Continuous Performance Testing.” This article features step-by-step guidance for implementing CPT across all the stages of the CI/CD pipeline.

The post Why performance testing is so vital and so difficult appeared first on SD Times.

“VHS started as a project that filled a need related to our performance testing and optimization portfolio, namely, accurate load generation,” Abrahams said. “Our mission as a company is to extend the concept of application performance from being a reactive mindset focused on operations teams, to a proactive, automatic and continuous process that includes and empowers the application developers themselves. Part of that mission is ensuring that developers in the community are not only aware that proactive solutions are available to them, but that they’re able to contribute and help build tomorrow’s application performance solutions.”

According to the company, current methods for recording and replaying app traffic did not provide clear enough or precise results. VHS aims to provide load generational aligned with actual live production to better guarantee performance testing and forecasted traffic. 

As part of the community-driven project initiative, StormForge is asking the open-source community to help rename the project in Q1 of 2021. “The name VHS wouldn’t be particularly easy to find in a Google search, anyway, and the acronym is already taken in most places that matter, so the rename will be happening sooner rather than later,” Abrahams wrote. 

The post SD Times Open-Source Project of the Week: VHS appeared first on SD Times.

The biggest mistake organizations make when preparing for holiday sales is decreasing the required amount of security testing of their web and mobile applications in favor of tight release deadlines, said global director of application security strategy at Checkmarx, Matt Rose.

“Proper security testing is a must and should not be overshadowed by the need for enhanced features or functionality that may not even be utilized if an application is hacked or down to a DDoS attack,” he said.

(Related: How DevOps security is lacking)

Organizations might look to cut testing processes because of their shorter release deadlines. Sometimes, security testing is cut because “cool” application features are seen as generating revenue, whereas security testing is not, said Rose. It’s a narrow-minded view, because if the application has security issues, the new revenue-generating feature may never be available to the user, he said.

Different organizations can assign different levels of responsibilities to developers during the holiday season, but all companies should review how developers would support operations during critical times like Black Friday and Cyber Monday, according to Michael Butt, senior product marketing manager at BigPanda. And, just like those in operations, developers need to understand how much stress peak shopping times will have on systems during the holiday season, he said.

Developers can also prepare for the holiday season by properly testing their applications for stability and security, because the “potential for unanticipated load or exposure to hackers is a real threat,” said Rose.

If developers fail to do this, retailers can expect worst-case scenarios like being blacklisted by users, he said, especially if they fear that a platform is unstable and their personal information is at risk.

“The holiday selling season is a very short time period, and any downtime or instability of their web or mobile applications could potentially have very damaging implications to a retailer’s bottom line,” said Rose. “If an application fails to meet the consumer’s expectations, they will simply take their business somewhere else.”

Mobile applications have changed the world of digital business and e-commerce, and now that organizations are going to a mobile-first world, all of that mobile traffic adds to the holiday load, said Butt.

Just the nature of these mobile applications and how they have developed opens a new category for risk, said Rose. Many organizations outsource mobile application development to third parties, and if these third parties do not know if proper security testing was done to applications, it increases the chances of hackers attacking, according to him.

“The third parties are paid to develop these mobile apps based on a set of functionality criteria,” said Rose. “If security requirements are not properly defined by the outsourced development teams, they will probably not be included in the application, which is a huge risk to organization contracting the third party.”

The post Security testing should be on every DevOps team’s Black Friday checklist appeared first on SD Times.