Software testing is actually fun Where to go from here?

[dkotschessaa]

One of my longer posts. Please stay with me!

Background:
So as some of you know, for personal and financial reasons I had to leave school a bit early to get work and support my family. I was *almost* done anyway. I need only the qualifier for my master's (in pure math) and I was only taking another semester of classes because my TAship was covering them, and hey, free classes.

I started out as a contractor in the first place that would hire me. I wasn't excited about the job at first, but I ended up really loving the work, the people etc. The feeling is mutual - they love me back and have offered permanency.

What I was *starting* to look into was going into more data science. They don't have that here exactly - or at least, not yet. The company is growing and I believe the industry may go more in that direction.

Here's what I can tell you about the company and the kind of work: They are a payments processing company. So I am learning about bank networks, credit card processing, settlement, all that sort of thing. The testing right now is manual, but eventually I will be learning about automated testing. They have trusted me to write manual test scripts and even entire test plans for a new project (unprecedented for a contractor!) so they are really trying to see what I can do.

I am quite certain java and SQL will come into play somewhere down the line. We use splunk to get to some of our transactions and I believe this is a tool being used by data scientists. (In fact I'm not sure we are using it to it's full potential, so I think I can help out a lot here). I could potentially move into roles that involve more programming, and I am excited by that possibility as well.

There is a whole science to QA as well that is a lot more interesting than I thought it would be. The things nobody tells you!

So I am wondering if anybody here with a math/physics background has done work in either payments processing or software testing and can tell me how someone like me can leverage my background. At bare minimum it's a great place to pick up a lot of great skills, but I'd really like to stay and carve out a role here. It is hard to explain how my math background comes into play - basically software testing is a huge science experiment with lots of permutations and variables and requires very good reasoning to do well.

Thanks,

-Dave K

 

[Dr. Courtney]

One of my longer posts. Please stay with me!

Background:
So as some of you know, for personal and financial reasons I had to leave school a bit early to get work and support my family. I was *almost* done anyway. I need only the qualifier for my master's (in pure math) and I was only taking another semester of classes because my TAship was covering them, and hey, free classes.

I started out as a contractor in the first place that would hire me. I wasn't excited about the job at first, but I ended up really loving the work, the people etc. The feeling is mutual - they love me back and have offered permanency.

What I was *starting* to look into was going into more data science. They don't have that here exactly - or at least, not yet. The company is growing and I believe the industry may go more in that direction.

Here's what I can tell you about the company and the kind of work: They are a payments processing company. So I am learning about bank networks, credit card processing, settlement, all that sort of thing. The testing right now is manual, but eventually I will be learning about automated testing. They have trusted me to write manual test scripts and even entire test plans for a new project (unprecedented for a contractor!) so they are really trying to see what I can do.

I am quite certain java and SQL will come into play somewhere down the line. We use splunk to get to some of our transactions and I believe this is a tool being used by data scientists. (In fact I'm not sure we are using it to it's full potential, so I think I can help out a lot here). I could potentially move into roles that involve more programming, and I am excited by that possibility as well.

There is a whole science to QA as well that is a lot more interesting than I thought it would be. The things nobody tells you!

So I am wondering if anybody here with a math/physics background has done work in either payments processing or software testing and can tell me how someone like me can leverage my background. At bare minimum it's a great place to pick up a lot of great skills, but I'd really like to stay and carve out a role here. It is hard to explain how my math background comes into play - basically software testing is a huge science experiment with lots of permutations and variables and requires very good reasoning to do well.

Thanks,

-Dave K

I did a lot of software testing in my years at Cisco Systems, but most of it was software I had written for factory floor and design verification testing of wireless communication devices. In the process I was also wringing out product firmware, but the main focus was using my software to test the hardware. My main claim to fame in the company was that my software always worked well without allowing bad product to ship or wrongly failing good product. I achieved that result with very thorough testing.

Testing software YOU wrote tends to be easier than testing software written by others. Covering all of parameter space is very hard in terms of user input and system responses, but if you wrote the software yourself, you are more likely to know where the weakness are. Most weaknesses are introduced when software is retrofitted for a new task that may not have been in mind when it was originally written. The first version of software is usually narrower in scope solving or addressing some specific case that will need to be generalized to broader cases in the future.

One way I kept my software robust was to avoid feature creep. Users often request features that are really gee whiz wants rather than company needs. Ballooning features is an invitation for bugs. Even if there is a real company need, providing a separate program for a given need is easier to test and maintain than adding feature after feature to one big program. Another important tip is to cut off support for your code once incompetent programmers begin creating custom versions of it adding features and ignoring your advice on good architecture and design. You can't fix all their mistakes, and you cannot catch them all. People in the company will eventually realize that your version can be trusted and the other versions cannot. Yes, I got some negative feedback for my "my way or the highway" attitude, but folks knew whose code could be trusted.

 

[dkotschessaa]

There is a pretty hard line between the developers and the testers in our case. Actually there are 4 different systems (two pieces of connected hardware, a bank network, and our payment processing system). We are testing the functionality of the hardware (well, the software within the hardware but you get my meaning) and then we triage to determine who owns the bug.

My talents seem to be in this triage portion because I am great (thanks to math training) at deduction. I can usually figure out quickly all the permutations of all the scenarios required to narrow down the issue. I am also very good at breaking stuff, apparently. I asked early on whether this was a useful skill and was immediately told "Yes" and then later told to write the "negative test scripts" in which I found several major bugs.

Obviously there is a lot of data transfer going on between all of these systems. So there's the QA itself, and then there is the idea of becoming a "bank network geek" in which I think query/data skills might be useful if not statistical skills. Not sure yet.

 

[Dr. Courtney]

There is a pretty hard line between the developers and the testers in our case. Actually there are 4 different systems (two pieces of connected hardware, a bank network, and our payment processing system). We are testing the functionality of the hardware (well, the software within the hardware but you get my meaning) and then we triage to determine who owns the bug.

My talents seem to be in this triage portion because I am great (thanks to math training) at deduction. I can usually figure out quickly all the permutations of all the scenarios required to narrow down the issue. I am also very good at breaking stuff, apparently. I asked early on whether this was a useful skill and was immediately told "Yes" and then later told to write the "negative test scripts" in which I found several major bugs.

Obviously there is a lot of data transfer going on between all of these systems. So there's the QA itself, and then there is the idea of becoming a "bank network geek" in which I think query/data skills might be useful if not statistical skills. Not sure yet.

I see. Finding other programmer's bugs can be fun, especially if the corporate culture takes pride in fixing them and doesn't resent the bearer of bad news.

"Breaking stuff" is a very useful skill indeed. Even if not your code, I'd always want a good look at the design and architecture of the underlying code. Try and understand how new features in one area can end up having unintended consequences and breaking things in other areas. Don't let the code be a black box to you, but be honest about when you are testing it that way and when you are not.

 

[dkotschessaa]

I see. Finding other programmer's bugs can be fun, especially if the corporate culture takes pride in fixing them and doesn't resent the bearer of bad news.

Well the bug is either with our company or with one of two other companies, and possibly there is an issue with the bank network. Most often it's one of the other two companies. The stuff gets escalated externally at that point.

"Breaking stuff" is a very useful skill indeed. Even if not your code, I'd always want a good look at the design and architecture of the underlying code. Try and understand how new features in one area can end up having unintended consequences and breaking things in other areas. Don't let the code be a black box to you, but be honest about when you are testing it that way and when you are not.

I don't have access to the code. For one piece of hardware (a POS system) I only have access to the front end and it's configurations. The other one (a terminal hooked up to the POS) I can telnet into its operating system and poke around as well as get logs of the transmission to the bank network etc. I can also capture information from the bank network itself and look at the raw data of a card transaction.

As part of QA we are doing some data validation of this raw data in a very tedious hands on way. So this is where I think I could either write some sort of script or program to automate this process. I could probably shorten it from a couple of hours to a couple of seconds. (Though it might TAKE dozens of hours to figure out how to do it!).

-Dave K

 

[dkotschessaa]

I wonder if @StatGuy2000 has encountered any of this - either QA in general or the bank network stuff.

 

[StatGuy2000]

I wonder if @StatGuy2000 has encountered any of this - either QA in general or the bank network stuff.

Well, since you did mention me, I suppose I should respond!

As it happens, I do not have much experience with either payments processing or QA work -- I have worked primarily in the health care, pharmeceutical, and biotechnology sectors as a biostatistician for the last 16 years. Some of my classmates in the graduate program in statistics have subsequently ended up working in credit risk modelling for banks, which is loosely tangentially related to the work you're involved in. I have another friend who is now working full time as a data scientist for a market research company, and who had previously worked in statistical consulting work for the technology, health sector, and banking sectors.

 

[dkotschessaa]

Well, since you did mention me, I suppose I should respond!

As it happens, I do not have much experience with either payments processing or QA work -- I have worked primarily in the health care, pharmeceutical, and biotechnology sectors as a biostatistician for the last 16 years. Some of my classmates in the graduate program in statistics have subsequently ended up working in credit risk modelling for banks, which is loosely tangentially related to the work you're involved in. I have another friend who is now working full time as a data scientist for a market research company, and who had previously worked in statistical consulting work for the technology, health sector, and banking sectors.

Thanks for replying! I know you had been looking into potential future jobs and such so I just wondered if you had come across that.

Incidentally, I am actually looking at taking a biostatistics graduate certification because a) I thought it would be great training in some applied statistics ("something practical") to complement my "pure" math background and b) it turns out the classes are online and enrolling in them helps me meet the enrolment requirements I need to take my qualifier. c) the cert is only 12 credit hours so I can do it two semesters part time.

There's this whole "unicorn of data science" which is the person who has quantitative+programming skills + domain knowledge + good communication skills etc. So I'm kind of chipping away at those different areas. At this job I can definitely work on the latter three but I'm not as sure about the first just yet.

 

[TMFKAN64]

Finding other programmer's bugs can be fun, especially if the corporate culture takes pride in fixing them and doesn't resent the bearer of bad news.

And if the corporate culture *does* resent bug finding, get out as quickly as possible, because such a company will *never* be capable of producing a quality product.

 

[dkotschessaa]

And if the corporate culture *does* resent bug finding, get out as quickly as possible, because such a company will *never* be capable of producing a quality product.

Word.

Our internal people are pretty good and pretty quick about fixing stuff. Most of the problems have been with the software written externally. Aside from a language/culture barrier and the occasional stall tactic they turn it around pretty quickly.