Your Mileage Will Vary

Looking at all the podcast, conference and community chatter you could get the impression that everyone else’s projects always follows the latest trends and hottest principles. That everything is perfect, and everything is a success – and that all new ideas are working right off the bat.

First Try… ish

It almost sounds as if testing has to be in a specific way, and that what you experience is wrong or less worthy. That there are no failures, no scrum-fall projects or old legacy systems. It sounds like everything runs smoothly on an up-to-date CI/CD K8 technology stack with all the bells and whistles.

Hmm.. no.

Don’t worry, listen to the “Guilty tester podcast”

Every single project/company/context is both it’s own mess and it’s own best. There is a huge difference between all the worlds companies and all the countries traditions around IT. Sure, it may happen – let me tell you the world of IT projects is a weird place, and that’s OK. So take all the stories of successes with the added American car commercial catch phrase goes “your mileage may vary” [YMMV] or as we tend to say coming from a Context Driven point of view “It depends“.

It depends on your context if modern testing is a thing for you, it might work in an enterprise setting of commercial standard systems. Using Robot Desktop automation in testing might work better in that setting, but then again it will probably not be a good fit in your average software development project. In a context of developing software business-to-consumer the web features is more importation than in an enterprise setting. And round and round the practices and approaches goes and goes…

If you look a little beyond the borders of your own project you will see similarities to others doing the same, but also the diversity in approaches, successes and failures. You are not doing all of it wrong.

You are not doing it wrong

– you’r mileage is just different.

Advertisements

When testing web features doesn’t matter

(aka not every testing problem can be solved by a webdriver)

Web features doesn’t matter as much in the contexts I usually work in. While some may be delivered over the web, the focus for testing is on the whole system’s fit for the business. Adding automation in testing to the mix gives additional challenges as there is no source code in the solution to interact with, and we have to find other solutions to solve the tedious tasks in testing with.

One area where this is the case, is when implementing standard commercial software packages (COTS) for the enterprise or public sector. Solutions like SAP for retail CRM and ERP, Microsoft Dynamics 365 for Finance and Operations, EPIC for hospitals, Service Now for IT Service management etc. These are standard solutions that can be configured and customized, but the general source code is not available.

Thus the “test automation pyramid” falls short to help us automate things as only the GUI is available for interacting with the solution. Test engineers might want to setup CI/CD but the success of that depends on the system architecture and the provided as-is methods of releasing updates. Some of the solutions above are provided as SaaS but quite often they still run “on premise” and the business still wants releases tested before launching things on a corporate scale.

Screenshot of an RPA test on SAP

Another example is the many bespoke software solutions that are still in operation. My local electronics store has two interfaces for the sales persons: web to look things up (specs and availability) and a mainframe system to set up the actual purchase (Point of sales, POC). Many public organisations and enterprises are only now transitioning from the desktop applications of the 1990’es to more up to date solutions. Unfortunately systems that are 10+ years old have very little of live and relevant specifications and neither CI/CD suites.

While some COTS and POC solutions are being delivered over the web, testing web particularities the very least of our focus areas. The web particularities seems to matter more if the solutions are business-to-consumer but not so much when it’s business-to-employer or business-to-business.

In a business-to-employer and business-to-business context, usually only one browser is in scope. And that’s it. There is little interest for HTTP status codes, broken links, browser compatibility or login forms.

The primary testing challenges of these projects cannot be solved by Selenium, Cypress or neat tweaks in the latest JavaScript library.

Focusing only on testing the web in contexts like these we fail in

  • covering the whole system landscape across applications of different technologies
  • addressing the real questions of the business subject matter experts and the business

It’s in this context that RPA probably has some benefits in providing automation of tedious testing tasks to the tester with a business background. That is, they are business people first – and then they do the testing that matters to the context.

Who is the tester?

In my current and primary projects the testing is not done by software testing professionals – and it’s probably for the better too! It is in contexts like these:

  1. A Microsoft Dynamics “D365O” implementation of health registration forms. Tested by public service clerks partly comparing to the previous solution, partly testing the new system platform.
  2. Moving 700+ servers running 50+ applications from one data center to another while keeping everything from mainframe to SaaS integrations live. Tested by the application staff that have maintained the system since for ever (10+ years).
  3. Implement at standard commercial off-the-shelf tool for 2000+ IT savvy users. To most users this tool is their primary work tracking system, so they get to test it too.

In contexts like these the act of testing done by subject matter experts of the field – infrastructure specialists, public service clerks, support staff, application developers and the like. These persons qualify as the “customer” in the Modern Testing Principle that “the customer is the only one capable to judge and evaluate the quality of our product“. They might have a testing /role/ during the project, but that is because of their high domain knowledge, but at the end of the project they continue with their “real business job” of using the system to produce stuff for the business.

It’s not their job to know ISTQB from “MT Principles” and “RST methodology“. That is up to me, as the manager of the testing. My role is more and more about the guidelines for the testing and the facilitation of the people doing the testing. My reach goes so far as to ask them to think about how the product fails and succeeds. But I cannot expect them to know checking from testing.

Long gone are the days of managing testers that put all their skill into the niches of the testing craft. There are less software testing professionals doing the testing in projects like the above. Part of it is, that the describing the whole system explicitly is simply to expensive in time and money. This makes the requirements inherently fuzzy and undefined. And part of it is that learning the skills simply takes to long. Some technical tests require skills of a certified VMware specialist, others having an eye for every unwritten tacit business rule.

Another angle is that the skills that the usual software testing specialist brings to the table is handled on a lower level. Testing is done by the organisation (like Microsoft) that builds the standard solutions and commercial off the self systems (SAP, D365O etc). Another is that the test techniques of the software testing field simply no longer applies. I mean how does boundary value analysis add value to enterprise data center transition executions, when the system under test it not even software?

The better tester is neither the software developer nor the software testing specialist. It’s the person who ponders:

  • How could this go wrong…
  • I wonder if…
  • For this to work, we need to do…

Come to think of it, everyone in the project does that! Some do it more explicitly, some do it more experimental. Everyone evaluates how their actions add value to the people that matter (at some time).

With A Little Help From New Friends

Do you ever feel guilty for not meeting the standards set by others in the Software Testing community? You’re in the right place then.

In this episode I talk to Dave (@theguiltytester). We discuss traditions, open questions and how to work within contracts which are specifically requesting traditional test practices based on large numbers of test cases. 

Listen and read all about it here: http://theguiltytester.libsyn.com/the-guilty-tester-episode-4-jesper-ottosen-with-a-little-help-from-new-friends 

Some of the blog posts mentioned are: 

New friends - the subject matter experts of all trades
New friends – the subject matter experts of all trades

You don’t have to be a boss to be a leader

It’s really that simple, yet awesomely profound. And a typical Gerald Weinberg quote, like my other favorites of his points:

  • No matter how it looks at first, it’s always a people problem (The second law of consulting)
  • You’ll never accomplish anything if you care who gets the credit
  • Things are the way they are because they got that way
  • Quality is value to some person

Regarding the last quote; which was later extended with “who matters, at some time” by Bach, Bolton. Once I had an argument about how to deliver quality. The other side held towards IEEE definition of delivering the expected. But even when he did, he failed to see that the unmeasured and irrational parts affected the value to the customer. I agree completely with The Cowboy Tester that knowing works of Weinberg is a measure of seriousness.

Weinberg worked not only with testing, but among other things also consulting and organisational change management. I did not know that when reading “Making Sense of Change Management” (Cameron & Green 2012). I literally jumped up and started laughing while reading the quite serious elaborations to the Satir Change model – the authors found that Quality Software Management: Anticipating Change (1997) is a “masterly book on change, but with a title that might not appeal to everyone“. It might not appeal to change scholars, but definitely appealed indirectly to a lot of people in testing.

Recently (August 2018) Jerry died aged 84. Not a boss – yet a leader.

Could Modern Testing work in the enterprise

So far I have mostly thought that “Modern Testing” of the A/B testing podcast would never work in an enterprise context. But it seems some tools and existing approaches in the enterprises already fits well with the ideas of the concept. 

The enterprise is all the privately owned companies that usually manufacture (non-IT) things –  for either the consumer or other businesses. The enterprise sell and produce tangible products like windmills, power tools, dairy consumer products etc. The interest with regards to IT for the enterprise is that it just works, and supports business processes around order setup, order tracking and invoicing – and many other moving parts.

While I have heard of some organisations that have successfully implemented some agile and SaFe methods (in banking), the enterprise have a hard time to change mode of operations, as it usually comes down to actual production of things, logistics and hierarchies of command-and-control … and culture, most of all culture.

 

@  via @HelenLisowski

 

Some enterprises change towards being learning organisations, but still treat their IT in general as low-value and an annoying cost. It seems the IT departments and IT contractors have a challenge in talking about what they do to achieve the right quality for the businesses….

 

 

Que: The Modern testing mission on “Accelerate the achievement of Shippable Quality”. While MT is mostly a concept around transition of testing activities, it seems the concept applies to IT delivery teams in general. MT has 7 principles and some of these are:

5. We believe that the customer is the only one capable to judge and evaluate the quality of our product

Most enterprise projects I know off around implementing SAP, MS dynamics 365, EPIC hospital solutions etc, have a large reliance on end-user testing and UAT. Often there is no professional testers involved, as the best tester is the business experts themselves. Interestingly the principle #5 fit’s well with existing practices from the UAT space.

Another interesting MT principle is #6 around data analysis of actual customer usage. This requires some totally different tooling for the tester, than previously generally available (…besides shifting-right perhaps…).

6. We use data extensively to deeply understand customer usage and then close the gaps between product hypotheses and business impact.

Yet recently I was investigating Panaya Autonomous Testing for SAP. One thing I realized is that what the tool collects real user usage of SAP and then provides the ability to balance the testing activities based on that analysis. It is interesting to see a commercial test management product for the enterprises following new trends like the “modern tester”.

While it’s interesting how some of the concepts of modern testing are reflected in testing in the enterprise – and vise versa –  the challenge remains for both the tools and concepts to be applied and accepted in more organisations. 

It might not fit everywhere, but it might be a good fit in more places than you think it would. 

 

On Medium regarding Testing, AI, ML etc

I’m writing on Medium regarding Testing, Artificial Intelligence, Machine Learning etc:

More to testing than AI and ML can solve

Artificial Intelligence (AI) and Machine Learning (ML) can perhaps solve some testing challenges, but not all testing. The testing vs. checking debateand all the shift-left of checking, have revealed that some of testing is about critical thinking and some…

 See also

Similar posts: Testing is wicked, Test all the things,

mad-brain