{"id":3015,"date":"2020-08-24T11:57:52","date_gmt":"2020-08-24T11:57:52","guid":{"rendered":"https:\/\/elementordzyns.com\/subject7\/?p=3015"},"modified":"2024-12-26T11:59:57","modified_gmt":"2024-12-26T11:59:57","slug":"platform-or-point-solution","status":"publish","type":"post","link":"https:\/\/elementordzyns.com\/subject7\/platform-or-point-solution\/","title":{"rendered":"Platform or Point Solution?"},"content":{"rendered":"

A few years ago, it was popular for companies to create \u201csuites\u201d that were really just a bunch of small tools, purchased, and bundled together. Often the technology did not interoperate. Many of those companies are no longer in business, or else they have been purchased by a MegaCorp. None of that is what I mean by platform.<\/p>\n

By platform I mean a single tool that the other tools integrate with. Programmers have something like this in Microsoft Visual Studio, or, to a lesser degree, something like Eclipse. These \u201cstudios\u201d have their main purpose as code editors, they also do debugging, compiling, visual front-end design work, and even include the installer and dependency mappers. They tend to have a\u00a0microkernel architecture<\/a>\u00a0that allows other people to write \u201cplugins\u201d to extend the product with new windows and new technologies. Unit testing tools like\u00a0nUnit<\/a>\u00a0may be the best examples of plugins for Visual Studio. These platforms aim to be \u201cthe one ring\u201d for software, as the one ring is in Tolkein\u2019s mythology: One Ring to rule them all,\u00a0One Ring to find them, One Ring to bring them all, and in the darkness bind them.<\/em><\/p>\n

Critics of the one ring say they are like standards. You have ten different standards and want one to control them all, so you write \u201cthe one standard.\u201d Congratulations, now you have eleven. That\u2019s certainly been true for testing, where my desktop has been so littered with tools for so long that no list I could produce would be complete. I have forgotten too many of them. At one point, I tried to put them on a USB drive. With the advent of Mobile, I got a new series of things like the network link conditioner, which intentionally slows down the bandwidth and corrupts packets to a cell phone to simulate poor-coverage conditions. I\u2019ve long given up on the USB stick, though a website with a list of tools might make sense. Having a single platform is appealing, but does it really make any sense given the depth and breadth of our testing work?<\/p>\n

Point Solutions<\/h3>\n

It\u2019s easy enough to understand the appeal of platforms. Point solutions force people into their own little, specialized role, a role that no one else understands. They often involve esoteric open source systems that take time and energy to master. This protects the specialist, but it completely denies\u00a0the power of collaboration\u00a0<\/a>and slows the pace of overall development. And when the specialist is on vacation, sick, or, heaven help us, quits, there is a huge amount of relearning that needs to happen. In some cases, especially test automation, the team simply throws away everything that went before and starts over.<\/p>\n

When things evolve naturally, you get a bunch of separate tools. The security people do their thing, the database people do theirs, there is a lot of confusion when the roles need to talk. Things work \u2026 sort of \u2026 until eventually they don\u2019t. Then there is the third approach, the \u201cSwiss Army Chainsaw\u201d that UNIX and Linux fans know so well.<\/p>\n

Interoperability<\/h3>\n

These are a large number of little tools, strung together to create some great outcome. Many a UNIX hacker has combined a half-dozen commands into something to direct to a file, then used awk, sed, perl, or ruby to process that file and put it into a database. More than a few have used those sorts of commands to capture traffic and create low-level performance or even functional tests.<\/p>\n

In my experience, when people build these sort-of \u201chacks in the best sense,\u201d it is possible that no one else on the team understands what they do \u2013 and it\u2019s\u00a0likely<\/em>\u00a0that no one understands how. Plus, those sorts of things are useful to combine tools that process information the same way to produce a result. Load, Accessibility, API, and Database testing are very different modes of testing. It may be possible to re-use functional tests as load tests, and they may have a similar reporting engine, but under the hood, these are all very different animals.<\/p>\n

That brings me back to the MicroKernel architecture, where we have a single \u201crunner\u201d that can run any combination of plugins. The plugins can have similar reporting and could push information to each other, yet be separate. That is the vision Subject7 has for the elements of testing that can be automated.<\/p>\n

But will it blend?<\/h3>\n

As a consultant, one of my deepest frustrations is when I go into an organization and the role of testing is limited to just one of those plugins. Security, accessibility, performance, and load are all the domain of some other \u201cexpert\u201d or contractor or just ignored completely. To borrow a phrase from Thomas More\u2019s Utopia: first we create a low-value-add role and then we disrespect and punish the people in it.<\/p>\n

The Subject7 approach is to take just those components that can be automated and put them together under one platform. In Subject7, a \u201csuite\u201d consists of Test Scenarios. Each scenario is a set of commands. Commands can come in any type, from GUI\/Functional tests, to database, API, or SSH to name a few. Consider this logical set of actions:<\/p>\n

1] Setup a new user with no orders that belongs to a shared account with no orders\r\n2] Login as user #1\r\n3] See no orders \r\n4] Create another new user in that account and add an order\r\n5] See an order appear on user #1's screen<\/code><\/pre>\n
 <\/p>\n
Step #1 and #4 are not actually commands to the web browser. They are done on the back-end, adding rows to a database or calling a web service. What we are testing here is that the screen auto-refreshes. By creating database or API commands and adding them to a functional test, we\u2019ve got peanut butter in our chocolate \u2013 and speeding up testing by hours. Consider the alternative: driving all the instructions through the user interface in one browser, or worse, trying to coordinate two different browser objects. The first isn\u2019t really a test of the real-time-update feature at all, while the second is going to lead to a lot of debugging and heartache.<\/p>\n
There is power in the ability to have the tools work together. Another example might be security, load, or accessibility testing the page you touch by re-using functional tests created in Subject7 or tracking requirements to features to get some idea of coverage or traceability using a tool like Jira. All of this is possible in Subject7.<\/p>\n
Moving Forward<\/h3>\n
More than a few tries have been made at creating a platform for software testing. Most of these are frankly naive, over-promising, and under-delivering. Today, I\u2019ve laid out some of the problems with point solutions, and discussed how Subject7 has suggested a \u201cone ring\u201d \u2014 while being very specific and pointed with claims on what it is capable of doing.<\/p>\n
If you\u2019ve got a better idea, I\u2019m all ears. As James Bach once wrote, we are a young field. We should make the most of it. That means experimenting and trying. The folks at Subject7 have a MicroKernel architecture that enables different types of tests to interweave and different roles to communicate in a shared language.<\/p>\n
What have you got?<\/p>\n","protected":false},"excerpt":{"rendered":"
A few years ago, it was popular for companies to create \u201csuites\u201d that were really just a bunch of small tools, purchased, and bundled together. Often the technology did not interoperate. Many of those companies are no longer in business, or else they have been purchased by a MegaCorp. None of that is what I […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-3015","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"acf":[],"_links":{"self":[{"href":"https:\/\/elementordzyns.com\/subject7\/wp-json\/wp\/v2\/posts\/3015","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/elementordzyns.com\/subject7\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/elementordzyns.com\/subject7\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/elementordzyns.com\/subject7\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/elementordzyns.com\/subject7\/wp-json\/wp\/v2\/comments?post=3015"}],"version-history":[{"count":2,"href":"https:\/\/elementordzyns.com\/subject7\/wp-json\/wp\/v2\/posts\/3015\/revisions"}],"predecessor-version":[{"id":3018,"href":"https:\/\/elementordzyns.com\/subject7\/wp-json\/wp\/v2\/posts\/3015\/revisions\/3018"}],"wp:attachment":[{"href":"https:\/\/elementordzyns.com\/subject7\/wp-json\/wp\/v2\/media?parent=3015"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/elementordzyns.com\/subject7\/wp-json\/wp\/v2\/categories?post=3015"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/elementordzyns.com\/subject7\/wp-json\/wp\/v2\/tags?post=3015"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}