DevOps Personal Success Plan in action

by | Jun 10, 2017 | Build Quality In, People are the Lever, Service Virtualization

People are the Lever

A personal story of success in delivering value with Service Virtualization.

Shifting my career to Quality Engineering

Jerome Solomons at DevQA

Setting the Scene

This my story as Senior Test Analyst transforming to a Quality Engineer using Service Virtualization in accordance with the principles of Lean, Agile and DevOps

The company has transformed from a Testing House providing testing services to a Quality Assurance house using Lean, Agile and DevOps (see www.www.devqa.dev.cc).
We have replaced Annual Performance Appraisals with Personal Success Plans http://www.www.devqa.dev.cc/performance-appraisals-to-personal-success-plans-why-change-for-devops/
man shifting left with value delivery

Actor 1 Value Based Delivery

Agile has a focus on value-based delivery, so it is important to understand how to deliver value. However, value, like quality, is in the eye of the beholder. This actor looks at a way of measuring the seemingly unmeasurable.
man running left representing shift left

Actor 2 Common Ground

PSP’s provide a platform by which we create a shared understanding of the Why, How and What. The Why comprises 2 parts—what is in it for me, what is my passion. The How are the recipes, what actions you take, the ingredients and tools; and the What is the result you deliver. Our goal is your future potential. In the work context, your future potential is the value you provide to your team and organisation; and the value you provide to yourself
blue man running left representing shift left

Actor 3 Creating Value

This Actor draws from the Value Proposition Canvas - The Value Proposition Canvas

The Lean Principle of eliminating waste.

Agile’s principle of delivering incrementally

Small win theory - Power of Small Wins

The System and Business Purpose

 

I work at a Merchant Bank in the IT department servicing a key trading system. Business processes are typically spread over a 3-tier architecture of Front Office Systems that interface directly with customers, Middle Office Systems that gather data, process and transform and Back Office Systems that deal with the ecosystem (other Banks, Regulatory bodies and Financial Networks) in which Merchant Banks live. The specific Financial Network we use is is SWIFT™.
The BLUE system captures trades, the RED system validates the trades and carries out further processing before sending it onto the GREEN, which sends and receives SWIFT messages. SWIFT™  is the international network for transactions between financial institutions. I make use of SWIFT™  confirmation messages for trades booked.

The messaging backbone (ESB) is TIBCO™. Applications communicate with one another via TIBCO™.

My sigh about the work

It takes 30 minutes per scenario. It is boring and has no repeatability. The amount of repetitive boring work adds up.

There is a long feedback chain, meaning there are many different systems to work with to find the results of your test scenario.

All this gets repeated for recreation and confirmation of bugs for the developer. The developer then has to update his code and unit tests.

My testing got into a rut. Since it was time boxed there was no time to reflect or improve. I was using the same basic approach over and over again.

This is part of everyday software delivery life and it is the killer of effectiveness and efficiency.

Climbing the career ladder to success in value creation using Service Virtualization

My success is the Why I am doing this – to have a great day at work by having less sighs. The rungs represent the steps I need to take to achieve the success. The unknown—things I had to discover

What is Service Virtualization and why use it? Although I had seen presentations and heard about it I had no idea why or how Service Virtualization applied to me. I started investing the time, in between the other things I had to do.

I started with XML as the MT messages are wrapped in XML. I had to be willing to work through it and understand the mappings and my spreadsheet of test data. I started understanding SWIFT™  at a technical level and, as a Tester, understanding SWIFT™  at a business level (the trade) and the connection between the two.

The technical learning is the message structure and the conversations between applications: -

  • How messages flow in the SWIFT™ Network
  • How applications interact to complete a business process.

The service virtualization tool is a company developed tool for testing SWIFT™  Messages and XML (www.nppdevtesthub.com.au). It is pretty straight forward in that you set up a spreadsheet with the data and fire it off at the application under test. The learning curve is around TIBCO and the fundamentals of an Enterprise Service Bus (ESB). A whole new world of queues and views.

Improving my SQL skills helped with querying the TIBCO™ database for validation of fields and to check the workflow status.Some fields had to be validated in the SWIFT™  application. This was a daunting area. I do not have a technical background and now I am writing my own SQL queries.

Buddy up

A key component of the Personal Success Plan is the relationships with people that can help you achieve one’s goal – the question asked is “who will you buddy up with”. Here are my buddies –

The TIBCO™ developer for providing the important information needed to interact with TIBCO™, after I was refused by his team mate.

Anthony Mpofu, company guru on Service Virtualization, EMV and all round great mentor and coach. He would end up “camping” at my desk to make sure I found the time to push forward with test scenario creation. He also made sure we could showcase the delivery of the project to the correct audience.

Sometimes we just need a nudge to get things done.

Buddies are a great way to keep us on track to meet our objective and deliverables.

 

For a detailed video with service virtualization of SWIFT Financial Messages and the application of Lean, Agile and DevOps principles,  have a look at http://www.nppdevtesthub.com.au/npp-devtest-gateway/.

The result-the value created

Better quality coverage: - I have time to review, think and improve my test scenarios with new and different tests.

I still have time consuming work, I am just doing it in a better way. My company calls this type of automation mechanisation and uses the analogy of driving to work:

  • You still go to work everyday
  • You still sit in traffic.

You just do it in a much nicer, luxury car.

Making the journey more enjoyable.

The repeatability and the execution trail of test scenarios enable better root cause analysis.

Execution of test packs on demand ensures bug fixes do not impact other functional areas.

Quantify the value

Measuring the unmeasurable?

To quantify the value, we look at the difference in effort between doing things the old way and the new way. Applying the lean principle of removing waste and constraints. The quality improvement of new tests is still subjective but we can apply a gut feel number and the actual cost of any bugs picked up. There is compelling evidence of the value of exploratory testing in finding obscure / hidden bugs that are costly to business.

The value of a short feedback loop is immense; you are not going to a developer to fix code he worked on weeks ago. There is also test environment savings, data management savings and test setup that all add up in the effort of preparing to test.

We put all these numbers into a spreadsheet and came up with a value of R 1 112 240 for the year. If that number seems low, just imagine getting half of that as a bonus? Then think of the number of other test cycles to which I apply this new competency. Think of the how many of these types of situations exist in a project. It quickly grows to a significant number.

Finally, how do you quantify “I love my new job”.

You can’t, just like the feelings of:

  • Satisfaction
  • Accomplishment
  • Learning new skills.