Many years ago, I had been hired as a programmer for a small
firm. My first assignment was to take
the accounting package that the firm was already selling and modify the package
to work for manufactures. I literally
was given this assignment my first day on the job. There was a deadline on getting this done and
I was actually given a PC to take to my apartment and do the work – and no,
there was no such thing as an internet to connect back in to the office.
I worked round the clock – not being married at the time, and new in town, it really didn’t bother me. I would go in to the office a couple of afternoons each week to work with the test team and to show my manager the progress that was being made. At the time, I remember thinking – “why are these guys picking on me?” They would take issue with small things that I was sure wouldn’t make a difference – yes, they also found other items that were bigger and I knew I needed to address, but I couldn’t figure out why they were so bothered by little issues on the screens or reports. This went on for a couple of months until I finished the new package and was then asked to go out and install it for the customer. All the while I pushed back on all the small changes that the QA team was asking me to make. In my mind – they were just slowing me down. It was only when I was on-site with the customer that I finally realized that the QA team wasn’t picking on me. The customer was elated with the end product – in fact the owner of the company pulled me in at the end of the week to tell me how pleased he was with what had been delivered. His comments about how much this was going to simplify his people’s lives and how impressed he was with the accuracy of the information being displayed and reported on – what a change it was going to make for his business. That’s when I realized that the QA Team wasn’t picking on me, they were advocating for the client.
I work in an organization where thousands of transactions can be hitting our switch in any given second. These are all financial transactions – payments, transfers, deposits, etc. When you’re out on the road in the middle of the night and hit a gas station to fill up – you want your card to be recognized and the transaction approved. When you’re out with a group of friends and paying for dinner – you want your card to be recognized and the transaction approved. When you’re on vacation and paying to get your family in to a hotel – you want your card to be recognized and the transaction approved. You don’t want to hear the words – hey the network is down and we couldn’t process your payment.
Our systems must work 24 hours a day, 7 days a week, 365 days a year (24x7x365). Not only must we make sure that each and every transaction coming through our switch gets routed properly for the authorization decision, we must track every transaction on the network and then settle with thousands of financial institutions, merchants and the Fed every night. That means we must balance down to the penny across all of the cardholders, merchants, financial institutions and ultimately with the Fed every day to actually make the money move between the various accounts.
We can do this because we have great people that are passionate about what it is they do and because we have built processes that allow us to validate our systems before they move in to production. Quality is not an afterthought!
While we have done a good job with quality – I’m now looking at how we can do this more efficiently within our organization. To date, we’ve been successful because we are able to take advantage of the wealth of knowledge that we have within our teams. People who are very passionate about getting it right!
Doing this right means planning it right. Very early in our processes we must begin to identify how it is we are going to validate what it is we are building. This isn’t a matter of testing a web page – or as one of our Enterprise Architects would put it, “the fluff”. This is digging in and validating real-time interfaces between point of sale devices, automated teller machines, our switch, other networks and processors and ultimately our backend billing and reporting systems. Some of the systems we don’t control. The systems all pass data among each other through documented interfaces without human interaction. It all transpires in milliseconds, and must work every time – all the time!
When we are building a system – it can cross multiple silo’d application environments, yet the card holder views it as a transaction. Our tests must take in to account every part of the transaction – at the terminal are we displaying the correct screens to the cardholder, are we displaying and reacting to all of the buttons properly. Once the transaction is initiated, we must make sure that the various data elements are represented properly within the messages that move between the terminal and our switch. Once the transaction hits our switch we must ensure that the data elements are reformatted properly to send to the authorization agent – sometimes that’s us, sometimes that’s other processors off our network. Then we need to make sure that the data flows to our backend billing systems, reporting and maintenance systems.
This gets very complex, very fast! So how do we do it? Have I mentioned our people – they are very good at what they do! The first thing we do is we plan. Our QA Analysts, Tech Leads, Subject Matter Experts and Engineers all work together to develop not only the individual unit testing that will be needed on any given application being touched, but more importantly, they plan on how to test all of the integration points between the systems. This means this group of people breaks down the transaction flow across all of the systems – starting with when the card is swiped to the point where the cardholder sees that the transaction has been approved. We need to plan to ensure that the test card data is setup properly across all the systems – that means the underlying test data associated with the dummy financial institution that issued the dummy card. We have to setup test environments representing all of the pieces of the network and touching all of the sub-systems or silo’d applications that the transaction touches. The integration testing is key to ensuring that we can take those transactions from the point of initiation all the way back to the user seeing the transaction approved, the financial institution getting the proper transaction reporting and settlement, the Fed getting the proper settlement information and the user ultimately being able to see the transaction in their on-line/mobile banking applications and on their monthly statements.
But you can’t just stop at the planning – you have to monitor the execution of the integration test plan. Are all of the identified tests being executed? Are you getting the expected results? What happens if you insert an invalid value in to one of the data elements being passed around the various systems? Can you prove that the settlement reports are accurate – to the penny?
As a developer, I’ve made my fair share of mistakes. It always irritates me when I, or someone else, finds an error. But what irritates me even more is when one of those errors makes its way in to the production environment.
Computers are excellent tools – however, if we don’t take the time to validate the information that we are presenting to our end users, we can lead them to make huge mistakes. Just think if I made a small mistake on every transaction moving through our switch – that’s millions of transactions every day. Do you think the cardholders would be happy if I randomly, and without reason, declined their transactions? Do you think the financial institutions would be happy if I couldn’t tell them which cardholders to debit or credit and how much money needed to move between accounts? Do you think the Fed would let us stay in business if we couldn’t balance our transactions and give them invalid information on what money needed to move between financial institutions and merchants?
What are you doing to improve the QA processes on the programs you’re creating, the team you’re working on and the organization you represent?
Tags: #sdlc, #softwaredevelopment, #lifecycle, #process, #applicationdevelopment, #qa, #qualityassurance
If you'd like more information on my background: LinkedIn Profile
I worked round the clock – not being married at the time, and new in town, it really didn’t bother me. I would go in to the office a couple of afternoons each week to work with the test team and to show my manager the progress that was being made. At the time, I remember thinking – “why are these guys picking on me?” They would take issue with small things that I was sure wouldn’t make a difference – yes, they also found other items that were bigger and I knew I needed to address, but I couldn’t figure out why they were so bothered by little issues on the screens or reports. This went on for a couple of months until I finished the new package and was then asked to go out and install it for the customer. All the while I pushed back on all the small changes that the QA team was asking me to make. In my mind – they were just slowing me down. It was only when I was on-site with the customer that I finally realized that the QA team wasn’t picking on me. The customer was elated with the end product – in fact the owner of the company pulled me in at the end of the week to tell me how pleased he was with what had been delivered. His comments about how much this was going to simplify his people’s lives and how impressed he was with the accuracy of the information being displayed and reported on – what a change it was going to make for his business. That’s when I realized that the QA Team wasn’t picking on me, they were advocating for the client.
I work in an organization where thousands of transactions can be hitting our switch in any given second. These are all financial transactions – payments, transfers, deposits, etc. When you’re out on the road in the middle of the night and hit a gas station to fill up – you want your card to be recognized and the transaction approved. When you’re out with a group of friends and paying for dinner – you want your card to be recognized and the transaction approved. When you’re on vacation and paying to get your family in to a hotel – you want your card to be recognized and the transaction approved. You don’t want to hear the words – hey the network is down and we couldn’t process your payment.
Our systems must work 24 hours a day, 7 days a week, 365 days a year (24x7x365). Not only must we make sure that each and every transaction coming through our switch gets routed properly for the authorization decision, we must track every transaction on the network and then settle with thousands of financial institutions, merchants and the Fed every night. That means we must balance down to the penny across all of the cardholders, merchants, financial institutions and ultimately with the Fed every day to actually make the money move between the various accounts.
We can do this because we have great people that are passionate about what it is they do and because we have built processes that allow us to validate our systems before they move in to production. Quality is not an afterthought!
While we have done a good job with quality – I’m now looking at how we can do this more efficiently within our organization. To date, we’ve been successful because we are able to take advantage of the wealth of knowledge that we have within our teams. People who are very passionate about getting it right!
Doing this right means planning it right. Very early in our processes we must begin to identify how it is we are going to validate what it is we are building. This isn’t a matter of testing a web page – or as one of our Enterprise Architects would put it, “the fluff”. This is digging in and validating real-time interfaces between point of sale devices, automated teller machines, our switch, other networks and processors and ultimately our backend billing and reporting systems. Some of the systems we don’t control. The systems all pass data among each other through documented interfaces without human interaction. It all transpires in milliseconds, and must work every time – all the time!
When we are building a system – it can cross multiple silo’d application environments, yet the card holder views it as a transaction. Our tests must take in to account every part of the transaction – at the terminal are we displaying the correct screens to the cardholder, are we displaying and reacting to all of the buttons properly. Once the transaction is initiated, we must make sure that the various data elements are represented properly within the messages that move between the terminal and our switch. Once the transaction hits our switch we must ensure that the data elements are reformatted properly to send to the authorization agent – sometimes that’s us, sometimes that’s other processors off our network. Then we need to make sure that the data flows to our backend billing systems, reporting and maintenance systems.
This gets very complex, very fast! So how do we do it? Have I mentioned our people – they are very good at what they do! The first thing we do is we plan. Our QA Analysts, Tech Leads, Subject Matter Experts and Engineers all work together to develop not only the individual unit testing that will be needed on any given application being touched, but more importantly, they plan on how to test all of the integration points between the systems. This means this group of people breaks down the transaction flow across all of the systems – starting with when the card is swiped to the point where the cardholder sees that the transaction has been approved. We need to plan to ensure that the test card data is setup properly across all the systems – that means the underlying test data associated with the dummy financial institution that issued the dummy card. We have to setup test environments representing all of the pieces of the network and touching all of the sub-systems or silo’d applications that the transaction touches. The integration testing is key to ensuring that we can take those transactions from the point of initiation all the way back to the user seeing the transaction approved, the financial institution getting the proper transaction reporting and settlement, the Fed getting the proper settlement information and the user ultimately being able to see the transaction in their on-line/mobile banking applications and on their monthly statements.
But you can’t just stop at the planning – you have to monitor the execution of the integration test plan. Are all of the identified tests being executed? Are you getting the expected results? What happens if you insert an invalid value in to one of the data elements being passed around the various systems? Can you prove that the settlement reports are accurate – to the penny?
As a developer, I’ve made my fair share of mistakes. It always irritates me when I, or someone else, finds an error. But what irritates me even more is when one of those errors makes its way in to the production environment.
Computers are excellent tools – however, if we don’t take the time to validate the information that we are presenting to our end users, we can lead them to make huge mistakes. Just think if I made a small mistake on every transaction moving through our switch – that’s millions of transactions every day. Do you think the cardholders would be happy if I randomly, and without reason, declined their transactions? Do you think the financial institutions would be happy if I couldn’t tell them which cardholders to debit or credit and how much money needed to move between accounts? Do you think the Fed would let us stay in business if we couldn’t balance our transactions and give them invalid information on what money needed to move between financial institutions and merchants?
What are you doing to improve the QA processes on the programs you’re creating, the team you’re working on and the organization you represent?
Tags: #sdlc, #softwaredevelopment, #lifecycle, #process, #applicationdevelopment, #qa, #qualityassurance
If you'd like more information on my background: LinkedIn Profile
No comments:
Post a Comment