Broaden the scope of the SUT

When testers talk about SUT (System Under Test) there seem to be an implied context of it being software, developed, bespoke software to be specific. Let me broaden the notion of a SUT using Wardley Maps and with that illustrate how testing can add value across the board.

Bespoke software (aka Custom built) is where the solution (SUT) is built and maintained tailormade to a specific company by a specific team that answers to order giver. When you build and maintain an app or web site for a company and is embedded in the team delivering the code base – it’s usually in a bespoke context.

Experiment/emerging example: Built an internal web site to do some simple public service case management. Write it based on MicroSoft .Net and IIS technology. The solution is new and novel, so interaction with the user is important.

All the commotion on buiding MVP experiments and interaction with the Product Owner are usual symptoms of a genesis situation. As the processes mature and products emerge, the solution development becomes more an customization activity.

Customization example: Implement Dynamics 365, SiteCore, SalesForce etc – but taylor and code them to your specific purpose. I have worked in a project taking Dynamics 365O and creating custom forms to handle public sector health events.

The last class of software “development” is the pureplay configurations of standard solutions. This is the context of SaaS – pay the license and get started. Think SAP or Office Applications, anything that is so accepted that it’s almost free (OpenOffice) and kills the IT department.

Let me draw this on the axis of Wardley Maps Evolutions:

Similarly we can add the underlying infrastructure to the drawing. As solutions move to the cloud and infrastructure becomes code, the system under test could very well be code around infrastructure. Initially bespoke infrastructure experiments (in perl?), and as time moves – even infrastructure becomes a commodity in the form of Amazon S3.

So where is your SUT? – what is the path down the stack? Because there is a huge difference between testing custom code for cloud services, as compared to product customization on actual physical owned hardware.

Let’s think testing outside the bespoke areas on the map too. Some current examples I am working on are:

• Infrastructure transition of 700 serves from being owned to being hosted
• Application transition of 50+ applications from being owned to being outsourced
• Transformation of a standard form management solution
• Implementing a standard system for ITIL case management

These projects have no code, the SUT is either a server, an environment (collection of servers), a form, a process or something else. While we do know a lot about testing in bespoke software contexts, the practices for testing in transition and transformation are emerging practices! This gives us and extra layer. And this is where it gets interesting.

There are plenty of standard practices (SAFe, agile..) but the practices for testing in the context of transition is yet to materialize.

The same model can be applied to IT as a whole. IT support and end user computing (devices, desktop operation) are to the very far right as commodity services. While on the far left is the constant experimentation and tinkering (of AI, ML and RPA) to become actual products.

If we only see testing as part of building bespoke software we fail – we fail to see the horizontal and vertical contexts, where the testing disciplines can add similar value and impact.

Black or white – it is the same box

• Exploration, Finding, Testing, Setting up hypothesis, Manual, Bespoke, Check lists, What if
• Steps, Confirmation, Checks, Proofs, Automated, Routine, Test cases, Does it matter

Does it indeed matter …

The “box” is a solution – if the box doesn’t fit the problem, it doesn’t work. (period) 

See also: Testing and checking, What if – and Does it Matter, The small changes in the big scripts Routinized and bespoke activities  left and right side of the brain

Establish yourself as an expert or thought leader

Being a thought leader is not about being a “boss” – neither is it about being a “manager”. Leadership is not only at monthly or weekly meetings. It is leadership to talk openly and often to those you lead, and go “visit their desk” – also just for a chat. Good leaders create a room for dialog, trust, mentoring and practice.

Leadership is about behavior – not attributes – nor properties. Management in itself is a structured process – perhaps very complex, but yet structured around planning, measuring and decisions. You can manage by Excel, but you can never lead by Excel.

Come to think of it, management can be somewhat automated, setup as routines, macros that verify and tricked by events. Management by bean-counting spreadsheets can be executed anywhere and can be setup as a commodity. True story – you can buy “Outsourcing management – as a service”

Outsourcing management as a service would require strong blend of skills in areas of program management, service management and relationship management. PMOs must own “outsourcing management as a service” and evolve these skills to implement and mature the competencies, and to derive maximum value from outsourcing initiatives

Leadership in comparison is more bespoke, and require a range of tools, tips and tricks – based on context and on the people in the team. Similar to testing and checking, we need to consider both activities – but also learn the difference between them.

So stand up, apply a little courage and be a thought leader in your own right. Stand on my shoulders if you like – it would be my privilege to support you: Establish yourself as an expert or thought leader!

—

#BigSelfishPun – the title of this blogpost and the below screenshot is from an internal presentation by Henry Singer, http://henrysinger.blogspot.com/ from September 29, 2011 called “Blogging for business“, where my internal blog was used among others and an example of  good use of a global collaboration tool. 

Innovation is about the unknown – deal with it

Innovation and software testing is about the unknown – deal with it!

[ The Biggest Obstacle to Innovation? You. | May 11, 2012 | HBR blogs by Leonard A. Schlesinger, Charles F. Kiefer, and Paul B. Brown ]

when you are leading innovation, the world is anything but predictable. You are creating something that has never existed before and so you simply don’t know how the world is going to react. By definition, innovation deals with the unknown.

And that’s why you are the biggest problem when it comes to innovation. If you keep using prediction reasoning in situations that are simply not predictable, you’re bound to be disappointed and frustrated.

You need a different way of thinking. 

See also More standards are not the solution, What you have learned becomes irrelevant, todays innovation becomes tomorrows commodity

Routinized and bespoke activities

[ It’s not just for knowledge workers anymore | December 9, 2011 }

Every business runs on a combination of routinized and bespoke activities. Running the trains in and out of London may routinized, but when a train breaks down the work becomes very bespoke. Tier 1 customer support is routinized; Tier 2-3 customer support is bespoke.

Routinized and bespoke activities require different types of supporting tools. Routinized activities require process tools to run the activity at scale as efficiently as possible, with as little variation as possible. Bespoke activities require a toolkit, a basket of techniques, tools, tips, tricks, and experts upon which a practitioner can draw to meet the needs of the moment.

Which type of activity should your business try to optimize? My answer: Both.

It’s not just for knowledge workers anymore – neither is it only for Social Media Software. It’s key for your job and your competencies – that you uses both parts. … of the brain