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

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

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.