News Watch

NEWSNEWS WATCHWATCH

Microsoft’s new lab for inclusive tech

The Inclusive Tech Lab is a successor to a lab that was created by the Xbox team. The purpose of the lab will be to “to learn and develop specifically for people with various types of disabilities. ” Compared with the original lab, this one is larger and will be more equipped to bring in visitors who can participate in the product-making process.

Though the lab will showcase Microsoft’s accessible hardware, software, and services, it will mostly serve as a design incubator for inclusive products.

The company also revealed new adaptive accessories that will be released this fall for people who might have difficulty using a mouse and keyboard.

The adaptive accessories consist of three main components, an Adaptive Mouse, Adaptive Hub, and Adaptive Buttons.

The Adaptive Mouse can be customized with the Microsoft Adaptive Mouse Tail and Thumb Support to make a unique mouse. The Thumb Support accessory also includes the ability to customize it to switch sides for left or right-handed users.

The Adaptive Hub and Buttons can be used together to replace traditional keyboards. Options for button toppers include a d-pad, joystick, or dual button, or users can 3D print their own button topper to suit their specific need.

Hasura launches GraphQL Joins

This new service lets developers join data from different GraphQL services. This new GraphQL Joins feature can be used to create a unified GraphQL API.

According to the company, this feature builds on Hasura’s existing data federation capabilities. It also gives them the ability to mix and match data sources, which will reduce development time, security risks, and ongoing maintenance costs.

Hasura explained that it’s important that developers have the ability to compose data from different sources. Even though data is coming from different places, usually it is semantically related.

Previously, building relationships between this related data has required custom code where multiple APIs call each of the sources. GraphQL Joins provides a single schema that lets developers query, mutate, or federate data without having to write custom code.

GraphQL Joins is best suited for developers who have more than one GraphQL API, existing investment in GraphQL servers, and databases for which they haven’t already created APIs.

People on the move

n Talend has announced two new major executive appointments: Sam Pierson as chief technology officer and Jason Penkethman as chief product officer. Chief product officer is a newly created role within Talend, reflecting the company’s focus on developing new solutions for its customers. Pierson previously served as senior vice president of engineering at Illuminate Education, and Penkethman was Spireon’s chief product and strategy officer for the past five years.

n Jamf has appointed Michelle Bucaria as its new chief people officer. She will oversee the company’s people operations, including attracting and retaining talent to meet the company’s needs. She was previously chief people officer at PointClickCare, chief human resources officer at Teladoc Health, and held executive human resources and recruiting roles at J.P. Morgan Chase.

n Adi Sharabani is joining Snyk as its new chief technology officer, where he will drive the short- and longterm vision of the company’s developer security platform, as well as overseeing Snyk Labs. Prior to this role, he was SVP & GM of endpoint solutions at Symantec, as well as worked at IBM in security strategy and architecture after IBM acquired Watchfire where he was a security and research manager.

Docker unveils platform updates

This year at DockerCon 2022, Docker made two major updates to its platform to increase developer productivity.

First, it announced the release of Docker Extensions, enabling developers to add development tools to Docker Desktop. This will allow developers to extend Docker Desktop’s existing capabilities to better suit their needs.

As part of this announcement, the company also revealed the first 14 launch partners that are providing Docker Extensions: Ambassador, Anchore, Aqua Security, GOSH, JFrog, Layer5.io, Okteto, Portainer, Red Hat, Snyk, SUSE/Rancher, Tailscale, Uffizzi, and VMware.

The second announcement made at the event is the availability of Docker Desktop for Linux. This new offering will give Linux users the same Docker Desktop experience those on macOS and Windows receive.

Docker Desktop for Linux also includes access to the new Docker Extensions feature, along with all of the newest features being added to Docker Desktop.

The current main focus of the Docker team when it comes to Docker Desktop for Linux is ensuring that installation and getting updates is as easy as possible, according to the company.

Flutter 3 brings multiplatform capabilities

With Flutter 3, users are empowered to build experiences for six platforms from a single codebase, offering developers heightened productivity and enabling startups to bring new ideas to the full addressable market from the start.

Additionally, this release offers added support for macOS and Linux apps, bringing users new input and interaction models, compilation and build support, accessibility and internalization, and platform-specific integration.

According to the company, the goal of this is to provide customers with the flexibility to take advantage of the underlying operating system while sharing as much UI and logic as they choose.

Flutter has invested in supporting both Intel and Apple Silicon on macOS, with Uni-

versal Binary support that allows apps to package executables that run natively on both architectures.

On Linux, Canonical and Google have worked in collaboration with each other to bring users a highly-integrated, best-of-breed option for development.

With improved performance, Material You support, and productivity updates, Flutter 3 also works to enhance many of the fundamentals.

This version is also fully native on Apple Silicon for development, allowing users to take full advantage of Dart’s support for Apple Silicon.

Flutter’s work for Material Design 3 is also mostly completed with this release. This enables developers to take advantage of an adaptable, cross-platform design system that offers dynamic color schemes as well as updates visual components.

Codefresh offers hosted version of GitOps platform

This new hosted offering works to provide Argo CD as a Service as well as introduces new DORA dashboards and integrations with multiple CI providers at no cost for small teams and community projects.

According to Codefresh, the hosted GitOps service is a simplistic way for users to get started with GitOps. Additionally, it is cost-effectively scalable for bigger teams that target multi-cluster, multi-application deployments.

Codefresh GitOps CD will also add new dashboards, including fully integrated DevOps Research and Assessment tracking that provides visibility across Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service easily filterable by project and team.

For the first time, Codefresh has added first-class integrated support for external CI providers beginning with Jenkins and GitHub actions.

This integration with existing CI pipelines allows teams onboarding to use Codefresh GitOps and immediately start gaining insights from the Universal Dashboard.

Climate change the focus of Call for Code 2022

Call for Code is an annual development challenge in which developers create solutions to help with a problem the world is facing. It is sponsored by David Clark Cause, IBM, United Nations Human Rights, and the Linux Foundation. This year, the challenge urges developers to create solutions that take on climate change.

The solutions that are submitted can address a diverse range of climate challenges and provide things such as new ways to improve sustainable production, consumption, and management of resources; reduce pollution creation; protect biodiversity; and much more.

The teams that register for the Global Challenge on the resource page on BeMyApp can attend Challenge Accelerator events to help fast-track their projects that include skills-building materials, exclusive toolkits, APIs, and data sets from The Weather Company and participating IBM Ecosystem partners.

The challenge opened this month and projects can be submitted before the deadline of October 31, 2022. The Grand Prize winner will receive $200,000 and solution implementation support from IBM Ecosystem partners.

Android 13 Beta 2 emphasizes user privacy

In pursuit of improving privacy, this release includes a new permission for sending notifications, a privacy- protecting photo picker, and improved permissions when pairing with nearby devices and accessing media files.

Additionally, it is now easier to support app-specific language settings, match your app’s icon to the user’s chosen theme colors, and build with modern standards such as HDR video, Bluetooth LE Audio, and MIDI 2.0 over USB.

Android 13 Beta 2 also continues to provide users with an even better OS on tablets and other large screen devices, offering better tools to improve the experience.

To get started using Beta 2 and provide any feedback on the new features, enroll any supported Pixel device here. If you have already installed an Android 13 preview or beta build, you’ll automatically receive beta updates.

Interested users can also access this beta on selected phones, tablets, and foldables from Android partners, including ASUS, HMD, Lenovo, OnePlus, Oppo, Realme, Sharp, Tecno, Vivo, Xiaomi, and ZTE. Click here for the full list of partners.

Latest version of Android Studio now available

Android Studio Chipmunk is the latest version of the official IDE for building Android apps.

One new feature is the Compose Animation Preview which enables developers to inspect and debug animations that were built with Compose. They can inspect the exact values of each animated value at any given time, pause the animation, loop it, fast-forward it, or slow it down.

The Compose Animation Preview currently supports AnimatedVisibility and updateTransition and it will have support for more animation types in the future, according to the Android team.

Another new feature is the CPU Profiler which shows updated jank information, including jank types, and expected and actual deadlines that can help developers spot the actual cause of the jank available on the Android Emulator or physical devices with Android 12 or higher.

Android Studio Chipmunk includes the IntelliJ 2012.2 platform major release, which has new features such as project-wide analysis, a new powerful Package Search UI, and IDE actions enhancements to speed up workflows. z

What Do You Mean by “Communicate?”

BY GEORGE TILLMANN

Project management tools are amazing. Not only can they tell you the status of your project, but they also produce numerous spiffy charts and colorful graphs that you can paste into the PowerPoint report you are preparing for that senior user management presentation you need to give. You are sure you will dazzle them with your RACI matrix (responsibility assignment matrix) and knock them off their feet with your Pareto Diagram (look it up).

Imagine your surprise when senior managers are not impressed. Hours spent color coding the work-breakdown structure wasted on an audience that does not appreciate the nuances of project management. To be fair, you might be bored at one of their presentations on RAROC (risk-adjusted return on capital), DSCR (debt service coverage ratio), or EBITDA (earnings before interest, taxes, depreciation, and amortization).

The reality is that each specialty has its own language, methods, and measurements that are often understandable only to the properly initiated. It makes sense, you would not trust your favorite Japanese chef to fly your plane or the pilot to prepare your fugu dinner.

Worse, you might think that hearing all of that unintelligible-to-senior-usermanagement-geeky-jargon would make them realize that true IT experts are running their project. Not the case. You would probably be more effective reporting project progress through interpretative dance. Many senior managers consider jargon (at least not their jargon) a smokescreen hiding something you do not want them to know.

To effectively communicate, project managers need to see IT and the systems development process from the perspective of the user. Many users, including corporate senior management, do not understand what IT staff do and why they do what they do. They have a decent understanding of hardware— you need to buy it, you need to maintain it, you need to replace it. However, software and networks are seemingly unfathomable mysteries. You can see a computer; you can touch it; it has a physical presence, it is real. Software? It is intangible—who has ever seen it or touched it? It is not physical, so why do you need to fix something that is not physical—how can the non-physical break? Why does IT have people who dress like hippies (honest, who wears sandals in the winter?), smell like the homeless, (this is them talking, not me!), keep bizarre hours, and talk in a language unknown to anyone on this side of the Shire? And the costs! Why does something not real cost so much and take so long to develop?

They have a good point (except for the smell thing). They are competent and accomplished senior managers who know how to run their business. They might be experts in their respective fields, quoted in the Wall Street Journal or interviewed on CNBC. For them, IT is a very costly wizard shop of very expensive staff doing…who knows what. This uncertainty leads to many unanswered questions. Are the company ’ s IT people “the good ones ” or are they the dregs of the profession? Are they working hard or treating the job like summer vacation? Are all those dollars spent on things the company really needs, and what is the deal with the pizza delivery bills? They simply don ’t know.

It must be very uncomfortable for people who pride themselves on knowing exactly what is going on in their

George Tillmann is a retired programmer, analyst, systems and programming manager. This article is excerpted from his book Project Management Scholia: Recognizing and Avoiding Project Management’ s Biggest Mistakes (Stockbridge Press, 2019). He can be reached at georgetillmann@gmx.com.

business to need IT to run critical parts of that business, to have it cost so much, to be overseen by such strange people, and to know so little about it.

Yet, the need is mutual and symbiotic. IT needs the business just as much, if not more, than the business needs IT. Organizations have survived without IT, but no IT shop can survive without an organization behind it and willing to write all those checks. Therefore, it is incumbent on IT staff to adequately explain to business executives exactly why they are doing what they are doing, why it takes so long, and why it costs so much. IT staff who fail to learn this lesson might find themselves facing the Big-O (outsourcing), replacing them with consulting staff trained in business speak.

If you, the project manager, can ’t present that RACI matrix and don ’t know what RAROC is, then you have to do something else. You have to ask yourself, what does senior management want to learn from a meeting with the development team? What is it that will make them come away feeling that those in charge of their project know what they are doing and are working in the best interests of the company?

Hundreds of projects, thousands of project status meetings, and more than enough experience doing the wrong things, has taught successful project managers that, when all the dust has settled, management wants to know three things.

1. Is the project on schedule?

Will the project end when is supposed to end? 2. Is the project on budget? Will the project cost what it was projected to cost? 3. Will it work? Will the system do what it was promised to do—features and quality?

Anything else is either gilding the lily or obfuscation.

The challenge for the project manager is to adequately answer these three questions.

Less is More. Have you ever been to a really good PowerPoint presentation? Have you ever been to a really bad one? Content aside, one of the big differences between the good and the bad is the slide-to-minute ratio.

Bad presentations contain a large number of slides in a short period of time. If your 30-minute presentation contains thirty slides (slide-to-minute ratio of 1:1) then the odds are high that few people will come away with a good picture of the project and/or a good impression of the presenter. The truly good presenters have a higher than 1:5 slide-to-minute ratio. Why? Because bad presenters get it backwards. They think that the presentation is the slides while their comments are the background. The truth is just the opposite. The primary means of communication at the meeting is the presenter speaking. The slides just underscore some of what is said. The successful presenter, and the successful project manager, must hobble together, not a series of charts and graphs, but a story—a story of how the project is doing. People remember stories—nobody remembers graphs. There is no greater take-away from this section than…

With this is mind, let’ s look at the three senior management questions.

PROJECT MANAGEMENT REVIEW RULE ONE:

A good presentation contains a good story that the audience can take with them when they leave.

Is the Project on Schedule?

Schedules are tricky. For senior management, some projects schedules are very important, while for others they are the least important answer to the three senior management questions (cost, time, and functionality). The difference is when the system is needed and the impact it has on the organization. For example, The Hershey Company, the chocolate manufacturer, required that IT have its new businesscritical systems installed before the busy Halloween and Christmas seasons (when most orders are placed). Project

How Not to Do It

The Hershey Company undertook a major IT upgrade (installing packaged software for new ERP, supply chain management, and customer relationship management systems) in 1996. The original schedule called for a 48-month rollout but senior management demanded a 30-month rollout to avoid Y2K problems and be live before their most important business seasons (Halloween and Christmas) when they receive the majority of their orders.

Both schedule and feature problems made the implementation a disaster, costing the company a reported $100,000,000 in lost revenue.

< continued from page 7 schedule slippage (read the sidebar) caused mountains of unfilled orders and put the very existence of the company is jeopardy.

The best advice for any meeting with senior management is to know before you go. If schedules are non-critical to the user, then the project manager of a late project will probably get a pass. If, on the other hand, they are critical to the business, then considerable prepresentation preparation, including possibly replanning, is needed. If the project manager doesn ’t already know the importance of schedules to the user, the project champion (See “Projects, Politics, and Champions, ” SD Times, March 2022) probably does.

If the project manager is unsure of the business users ’ tolerance for project lateness, then some pre-presentation homework is needed. The project manager should schedule interviews with a senior business manager or two to learn their allowance for lateness. Work on one or more possible solutions to the scheduling problem before the meeting— don ’t show up without some options for remediating the problem. However, don ’t postpone a meeting to avoid giving bad news. If there is bad news, it needs to come from the project manager and the sooner the better. Having management learn about it elsewhere can turn a bad situation into a disaster.

This is a good place to learn a lesson from lawyers—no really. Every lawyer will tell you that they never ask a question of a witness in court when they do not already know the answer. They want no courtroom surprises. Likewise, a project manager should strive to have no surprises at a senior management presentation. Vet everything possible before the big event.

PROJECT MANAGEMENT REVIEW RULE TWO:

Do not present a problem without an accompanying well thought out solution.

Is the Project on Budget?

Budgets can generate the most noise but are often the least critical of the three management questions. Budgets are what senior managers understand the best; after all, they have spent careers crafting them, enforcing them, and learning how to get around them. They can manipulate a budget faster than a politician can change positions. Their adherence to a budget can be fanatical while, at the same time, they can be eminently practical. If the project is needed for the business, e.g., if it will “kill more than it eats ” (business speak for “ generate more revenue than it costs ”), then spending more than anticipated will be approved. Oh, there might be some public castigation of the project manager, but most of that will be for show. If the project is needed, then it will be funded. The project manager just has to utter some public mea culpas, and all will be right.

If the project is considered anywhere between unneeded and frivolous, then the situation is entirely different. An overbudget report is often the catalyst to kill the unwanted or undervalued. This is not an entirely bad situation. Cancelling unneeded projects frees up scarce resources for more valuable work. It can, however, be a blot on the project manager ’ s career, though some perceptive and resourceful project managers have turned the tables to their advantage by being the one who recom“for the good of the company, ” the project should be cancelled.

An awkward budget meeting can point out one important reality of senior management thinking. Both project management tools and project managers themselves tend to focus on actuals (schedule actuals, actual spend, tasks completed), while senior managers are more interested in projections (what will happen when and what will it cost?). Spend more resources and time on when things will happen rather than when things did happen, what costs are ahead rather than what was spent, and what features are being developed rather than what was developed. For example, if you are a nickel overbudget then you need to be prepared to explain the impact it will have on projected costs.

Just ensure that focusing on the future is not perceived by senior managers as masking past failures.

PROJECT MANAGEMENT REVIEW RULE THREE: Traditionally, project management reviews focus on the past (work accomplished, milestones achieved, spend so far), but what management really wants to know is the future (when will it finish?, what will it cost?, what am I getting when all is done?).

Will it Work?

This is by far the most important of the three senior management questions but often the least discussed at project review meetings (where the focus tends to be on numerical issues such as schedules and budgets) and the most difficult to answer for two reasons. First, there are so many questions to answer. Functional failure can be caused by a lack of analysis, or programing that does not adequately do what is needed, or the architecture cannot support the production environment (platform, data volume, transaction volume, etc.). The list goes on and on. When reporting on budget and schedule progress, the project manager has many numerical and presumably objective measures; however, there are few mathematical crutches when reporting on feature progress. Progress on the functionality landscape

is highly subjective.

This is where iterative and incremental (I-I) development approaches, such as rapid application development, prototyping, extreme programming, and agile development, etc. come into play. By having user staff intimately involved in the project, providing insight and reviewing work accomplished, senior business management has the input of their own staff regarding the progress and quality of the system so far. There is an added benefit. If user staff assigned to the project are excluded from the preparation and presentation of the project review, then they might take on a more adversarial position, searching for project flaws rather than extolling its virtues. On the other hand, if user staff are charged with reviewing and presenting functional progress at the management meeting, then their inclinations will be more toward supporting the project rather than criticizing it. Many a project manager has suffered a self-inflicted wound by minimizing the role of user project staff. The wise project manager uses business staff assigned to the project as ambassadors to the user community.

Lastly, do not stand up at a senior management meeting and toss a project management hand grenade—giving senior managers bad news cold. Short of announcing at a senior management project review that you won the lottery and are quitting your job immediately, surprises are not a good idea. Moderate less than good news is OK, but senior executives hearing for the first time that the project will not deliver 50 percent of its promised functionality is not. Bad news, particularly about functionality, needs to be pre-sold, ideally with one-onone meetings with selected senior managers. This is also the time to use your project champion to pour oil on the troubled waters. But do not dawdle. Bad news is like dead fish—it does not get better with age. Too many project managers procrastinate about giving bad news, but as awkward as it is for senior managers to hear about problems from the project manager, it is far worse if they hear about them first from someone else. Any credibility you had will be lost.

Salty old project managers are awash with tales of presenting terrible news at a senior management meeting and getting no reaction, while getting skewered on something the project managers considered trivial. You never know what will pass without a sigh and what will cause a brouhaha. When in doubt, pre-sell.

Managing the Managers. Like it or not, a project manager needs to manage up as well as down. The project manager techniques that are so successful in managing subordinates are rarely the same techniques needed to manager superiors.

Techniques and styles that work so well with programmers might be the absolute wrong thing to apply to user supervisors.

The successful project manager has a separate tool kit for each constituency and the number one tool in the manageup kit is communication (See “5 tasks project managers must perform to ‘ sell’ their proposals, ” SD Times, November 2020).

A good project manager uses every opportunity in front of senior staff to sell the project, its benefits, its team, and its project manager. Anything else is shortchanging the project and the user. z

PROJECT MANAGEMENT REVIEW RULE FOUR: Never wait for a formal management meeting to present bad news. Always pre-sell bad news to the project champion or at least one or two senior managers before the meeting. No surprises.

The Little Book of Big Mistakes and How to Avoid Them

Project Management Scholia focuses on the 17 most consequential reasons IT projects fail and presents ways the project manager can avoid these problems by reading the danger signs and taking timely corrective action. The book dives into the often painful lessons learned — not from the library or the classroom — but from the corporate trenches of real-world systems development.

Available on Amazon

By George Tillmann

George Tillmann is a retired programmer, analyst, management consultant, CIO, and author.

Microservices push the testing focus from UI to API

BY JAKUB LEWKOWICZ

API testing has become more important than ever because the world of three-tier architectures and monolithic applications is being replaced by something much more complex. That has driven up the number of APIs in applications.

According to Joachim Herschmann, senior director and analyst on the application design and development team at Gartner, the number of APIs in applications has grown tremendously over the past few years because APIs offer a great way to extend the functionality of an application without having to write code. However, the sheer number of API tests has created many challenges for developers; challenges that are similar to those in other types of testing.

It is often difficult to test API calls because they require a testing environment to be set up and maintained. This can be a difficult and time-consuming task for developers who already have a lot on their plate. There are also many different types of API testing, including functional testing, load testing, security testing, fuzz testing, and performance testing which testers have to handle often.

Organizations are having to move API testing up from their developers who may have written some initial API testing or frameworks or patterns and shift it to test engineers or quality engineers who may need to maintain those tests, build new versions of those tests, and frameworks to help them do that, explained Coty Rosenblath, CTO at Katalon.

However, many organizations still rely on collaboration between QA working in tandem with developers.

“Since we can ’t gain the knowledge and experience overnight, it’ s important that we ask for help and use the knowledge and experience of other people — like developers. They offer great support and they can teach QA a lot, ” said Adam Lochno, a quality assurance analyst at The Software House.

Certain platforms enable testers to do different types of tests in one place, making it easier. Often people look for a platform to shift into automated functional testing and once they have those tools they can then shift that over to the API world.

“This enables the combination of functional and API testing in a way that lets testers and engineers do things like setting up a context for testing using the API and then check its functionality. Or vice versa, they can do a functional test suite, and then check its performance and confirm that it did the things it was supposed to through an API so that you ’ re not having to deal with some of the vagaries of functional testing except when you really want to know the specifics, ” Rosenblath said.

Another challenge is being able to track the performance and behavior of those tests, which is a problem amplified especially in API testing.

It’ s especially critical in API testing to be able to track how quickly someone responds because it can scale up and cascade. Any given functional test may be dependent on a number of different API calls, and they may stack up.

Testers want to be able to understand the baseline performance and understand when it goes off the rails and tackle it because it can have wide-ranging implications.

“If your login API or your tracking API starts to spike in terms of maybe 1020% performance, it could have an impact across your application. So having a system to track not only the working capability of the API, but did it perform its function, and how does it perform, it is important, ” Rosenblath said.

API standards also vary often so testers need to keep up with the state of the art when it comes to API testing and its complexity. Whether it’ s SOAP or REST APIs or dealing with GraphQL, each has its own authentication protocols and network configurations that need to be tracked, Rosenblath explained.

The Software House ’ s Lochno found that documentation is sometimes lacking for REST APIs, leading to a lack of information about what fields endpoints take and what are frequent blockers during tests. In such situations, he said that it is necessary to find a person who can provide testers with this information.

“Any form of documentation is invaluable. When we have it, we can easily find the information we need, such as the required fields in the body request, or what response we can expect. Swagger deserves special attention. This automatically created documentation not only presents all the data on the tray but also allows you to ‘ shoot the API’ directly from the documentation, ” said Lochno.

With the absence of documentation, testers are forced to look at the developer console and they have to spend a lot of time sifting through all of the info to find the answer which is often obstructed by all of the unnecessary information.

API tests are ideal for automation

While APIs and how they behave can be very complex, API testing is very suitable for automated testing and even autonomous testing, which can generate tests.

“It’ s comparatively straightforward these days to take API definitions like Swagger files, or similar definitions, read them, and create test cases right out of that. And most vendors have capabilities to do that, ” Herschmann said. “On the other hand, for UI tests, there is not necessarily such a thing as a definition of a user interface. There ’ s a lot of change going on, which makes UI tests a lot more brittle. So API tests are more stable in the sense that these interfaces or the contracts or definitions change less frequently than a user interface does. ”

Another common way to do API testing is to create test cases by recording the traffic against the API, similar to how UI tests are performed.

The developer or tester uses the recorder mechanism to record the raw blueprint of the test case. They can record a day ’ s worth of recorded traffic, then replay that same traffic on another system to see if this new system is capable of handling the same kind of traffic.

A useful way to perform API tests is by directly accessing the business logic that is accessible through the APIs rather than first going through whatever interface layer is there.

In order for developers or testers to do some of the testing, they can virtualize the service and instantiate it in another environment through service virtualization.

“Service virtualization is really intelligent in the sense that it implements the behavior of a more complex set of APIs that interact with one another, " Herschmann said. He used the example of wanting customer data, and a single request goes out, but on the back end, it triggers several subsequent requests — one for customer name, another for the customer address, and another for the financial details of that account. All of those might go to different databases. “It triggers a real simulated activity of that service. And so that allows me to do very complex testing in environments where the actual services may not be available, ” he said.

API tests are more accessible to computer processing than traditional

continued on page 12 >

One company’s journey into API testing

The job search site Jooble has a distributed monolith architecture but is trying to move to a microservice architecture. Andrii Rybalko, a developer at Jooble, said that in their case, the hardest thing is separating APIs from their dependencies. Here a dependency is any executable thing that is not a part of our app, like other APIs, databases, Rabbit, Redis, etc.

The team at Jooble divides dependencies into two groups: APIs and all the others. For APIs, they create stubs or mocks. But they use real databases, Rabbit, Redis, etc in a special testing environment, like in Docker or virtual machines, which is recreated from scratch on each test run.

“At first, we were creating static stubs of APIs, but this way we cannot check that some endpoint was called, and it’s unclear which setup of the stub corresponds to which test. So, we moved to another approach where we dynamically set up mocks of APIs inside the test itself, ” Rybalko said. “This solves the previous problems, but introduces new ones — setups can intersect each other, and when you run tests in parallel, this can cause some strange bugs. To deal with that, we generate pseudo-random data, which differentiates from one setup to another. ”

This approach with pseudo-random data is also used for databases and other dependencies, for the same reason — intersections of tests.

This gives the team the ability to deploy logical units independently and automate the regression, which leads to daily releases and a reduction of slow and at times unreliable manual testing. This decreases the testing time of business hypotheses and provides a reliable and stable development speed. z

< continued from page 11 functional testing, according to Katalon’s Rosenblath. With API tests you just have text, you can parse that, and you can understand what was asked for and what was returned.

An automated testing tool will be able to track the actual execution of APIs by watching API logs as they’re occurring in the live system to service test configurations and context. Then, for example, the tool can look at a stream of API calls and understand what the dependencies are between those API calls and then structure the test so that everything occurs in the right order, and then can look at the data that are being passed back.

Once the normal data is established from the tests, teams can infer what might be outliers and then push that in as potential edge case tests.

According to Herschmann, organizations are generally not doing enough testing at the API layer and are rather focusing on UI testing. But that might change as more organizations are focused on creating tools for API tests.

“Instinctively, the first way to think about testing is through the user interface, because we humans interact with an application through the user interface. But basically, humans only see the tip of the iceberg, literally, the front end. We don’t see that, potentially, the website makes hundreds of calls to the back end,” Herschmann said.

However, there are some organizations that go the other way around and instead start at the API testing level and those are the organizations such as highly interactive financial network types of solutions where it’s all about low latency and fast connections to all servers.

Now testing vendors who have long focused on UI testing tools are now shifting their focus toward APIs either through growing tool capabilities organically or through acquisitions, according to Gartner’s Herschmann.

While API testing needs to be in the spotlight, organizations want to make sure that they have a good balance of all types of testing, according to Rosenblath.

Some organizations have extensive API suites but have neglected their functional testing which can leave them blind to user experience issues.

If testing is handled purely within the development organization, the engineers may build a lot of API tests, but they may not be building enough functional tests and vice versa for companies that focus their testing efforts in the testing ward.

All in all, API tests need constant maintenance and need a testing team around them to handle changes that the engineers are not fully aware about.

“You may have new tests that are needed, that aren’t the result of changes to the API code itself, but changes to the way the business is operating, maybe something upstream, or maybe something in the data infrastructure has changed. And that changes the way the API behaves. That’s something the engineering organization is probably not dealing with,” Rosenblath said. “But your test organization needs to take that into account and needs to be connected with their business organization and put those tests in place quickly so that they know and they can assure you as a business that you’ve got that new business requirement covered in your API.” z

Contract testing offers a more holistic approach to automated testing

An important aspect of API testing is contract testing which focuses on ensuring that spec files such as Swagger or OpenAPI and RAML properly fulfill contracts between API consumers and producers.

“Contract testing is important because it’s the type of technology that allows you to gain some level of confidence with the aspects that contract testing tests, while also increasing velocity. It’s a lower overhead method that’s actually piggybacking or leveraging something that’s already enumerated, in many of these cases: the API contract,” said Abel Matthew, CTO at Sauce Labs.

Contract testing can also validate spec files in an automated way by capturing how an API consumer and producer communicate with each other.

By creating this contract, developers have a mechanism by which they can specify the behavior of your APIs. But additionally, they can leverage code-generation techniques. By creating a spec file, developers can generate a bunch of the boilerplate often associated with an API, according to Matthew. “I can leverage that same file to take the same requirements, the request and response that I use, and then I can say, well, now that I know what this should look like from a black box testing perspective, I can effectively validate what the request and response should look like in terms of both form and content,” Matthew said. “Now, because it’s using a spec file that’s created at the beginning of the development cycle, the first benefit that we have here is that an introduces some form of testing early on in the development cycle.”

Without this type of testing, an error might occur in functional testing and then one has to drill it down further to identify what was the cause.

This method of test generation also allows for the testing of third-party APIs fairly easily as well, according to Matthew. For example, if an API calls in some sort of third-party, one can effectively enumerate what the expected contract from that API is such as a strike. Now, testers can get more holistic testing, which is a huge advantage as opposed to writing functional tests, Matthew said. z

“You like me… You really like me”

BY DAVID RUBINSTEIN

The great actor Sally Field, upon winning her Academy Award in 1984 for “Places in the Heart, ” understood that the trophy meant that a rising Hollywood star had gotten the recognition for her on-screen work that she had longed for. It came not just from industry insiders, but from the general public at large.

Fast forward to 2022, and — while the Oscars haven’t lost their sheen — technology companies have their “You like me” moments through the five-star rating system under which users rank how much they like an application. And it’s also seen through the action of their peers and competitors, who are all striving to outperform each other on the grand stage of technology.

This year’s SD Times looks at the best of the software development companies from how they performed in 2021 — a year like no other due to the lingering COVID19 pandemic, the fact of business shifting from central offices to remote locations, and the boon to our industry driven by the new types of tooling to enable this workfrom-home culture change.

There are many familiar faces on this year’s list. Some have been industry stalwarts since the SD Times 100 began; others fell off the list in previous years and have managed to return by shifting to the new realities of software. And, for the first time, we are highlighting those companies that are new to the list, who — through hard work and innovation — have shown they belong among the best.

In short, “We like them.. we really like them!” And we know you do too. z

We’ll Help You Keep It Clean

Dealing with bad data is a task no developer needs on their checklist. Inaccurate, outdated, and duplicate records can build up in your database, affecting business decisions, the customer experience, and your bottom line. As the Address Experts, Melissa helps our customers improve operational ef ciency with the best Address Veri cation, Identity Veri cation and Data Enrichment solutions available. We validated 30 billion records last year alone, which is why thousands of businesses worldwide have trusted us with their data quality needs for 37+ years.

BAD DATA BUILDUP

Returned Mail & Packages

Money Laundering & Fraud

Decreased Customer Insight DATA CLEANLINESS

Real-time Address Veri cation

Identity Resolution & Watchlist Screening

Geographic & Demographic Data Appends