The Quest Calendar

I have successfully launched and delivered to the world, the very first RPG (role playing game) built into a desktop page-a-day style calendar. The 2021 Quest Calendar: The Dragon Staff of Maladoria.

My full-time career is a Software Developer focused on Testing Engineering, but everyone has other passions and I have always loved games. Board, card, and video games are a deep passion of mine. In 2018, an idea sparked in my head for this game and I let it stew for a couple years. In 2020, I decided to go for it and launched on Kickstarter under the company of Sundial Games LLC. Today, thousands of people are playing my game. It is scary, stressful, exciting, and very fulfilling.

 

I am launching another Quest Calendar for the 2022 year and hope to take this further. It is a dream to be able to do this full time. It was very difficult to do both. I don't know why I chose 2020 of all years to make that endeavor. It was difficult enough.

I remember that someone once told me it take 7 years to master anything in life, why spend your entire life in one field? You can have about 11 different periods of doing something different and wonderful in your life. I feel it is time for me to move on to the next thing.

Can This Be Automated?

I hear this question often while working on or supporting a test project. You may even be the one asking it. I have some helpful thoughts on this based on the different perspectives. You might find it worth reading both.

Asking "Can This Be Automated?"
If you focus on manual testing or you are a test lead you might ask this question a lot. I understand your goals are to achieve maximum coverage and speed up testing. Isn't that exactly what automation is for? So can't it be used here, and there, oh and for this problem too... what about future regression tests?

I get it. Automation sounds like a great answer to many problems. But I want you to fully understand what you are asking. You are essentially requesting a software project for a tool that will help you and your team. You likely provide fewer clear requirements for this tool than you are ever given. Think of how you feel when you are given a requirement that says "Make this work like this other feature/application." (If you don't ever get an empty requirement like this... can I come work for you?)

At the very least, don't forward on the requirements documents and ask, "Can this be automated?" You may not want to hear the truth, but when you do this, it will annoy people. You will come off as lazy and trying to pass off your job of critical thinking to someone else. You will effectively destroy the credibility you work so hard to build. And the automation team may start to resent you and avoid working with you.

Without your input, the automation team will assume your needs. Your tool will be full of bugs, costly, and require maintenance. You likely don't fully understand your automation architecture, capabilities, team dynamics, and workload. But knowing this will greatly help you work with the automation team to get exactly what you need. I suggest a quick meeting so you are all on the same page.

Read the "Discussion Points" section of this post. It contains information that will help you and you automation developer make the right decision.

Answering "Can This Be Automated?"
If you work in test automation, you get this question a lot. I often give my smart ass answer before even looking at the problem:

Anything can be automated. But "Should this be automated?", is the real question.

If you are too far removed from the actual testing goals, you might get hung up on the challenge that the original question poses. I like to program and love a good challenge. But if this is your mindset and you don't take anything else into account, you could deliver a solution that reduces the value of the project and/or your services.

Yes, I can take these records and use them to generate test data that can then be inputted into the API and build an oracle that verifies the transactions against the database. We can build you an easy to use interface that can do all of this across all products in the future which will ensure speed to market.

Even this made up problem sounds like a fun task to work on. And both parties may even agree of the future benefit. But we need to be up front with our customers and even ourselves. It is never this simple and the outcome isn't always the result we desired.

Customers of your test automation solutions don't always fully understand the outcome that can occur from what they are asking. It isn't that they are short sighted. They are focused on the immediate problem. Dealing with maintenance is going to fall on you. So try to take a step back and understand their needs before diving right in. This isn't a simple yes or no question. Like most businesses, other factors need to be considered.

I find it best to sit with the customer and get a better understanding of their project context before building a solution for them. I am not saying you should use my default answer, but at least repeat it to yourself.

Discussion Points

Complexity

• Remember a computer program can only follow detailed instructions. Do you need intelligent eyes to do critical thinking here?
• Is the oracle for identifying pass/fail results clear?
• Do you really need the automation tool to test everything in the requirement?
• Break down all the individual pieces/activities you wish the automation tool to handle. Separate them out into smaller chunks of work.
• Estimate the time it takes to manually do this then to build the automation tool to do this? You might find that manual testing can be quicker. We will visit repeatability below.
• Will manual testers be able to use it easily?
• How extensive will the training needs be for this tool?

Opportunity Cost

• The automation team is a finite resource. So is manual testing.
• What other tools could the automation team be working on?
• If this gets automated, what are you stuck with testing manually?
• Consider a bigger meeting where you review several requirements you want automated tests for.

Risk

• How likely will this functionality break?
• What is the outcome if it does break?
• Higher risk doesn't always mean it is a better candidate to automate. It often does, but not always.

Repeatability

• Automation is great for repetition.
• Value diminishes when less repetition is needed.
• Regression is repetition, but there is so much more to it. 
• Doing small menial task hundreds or thousands of times is not optimal for a human. Let computers do what they are good at.

Scalability

• Do you need a simple throw away script?
• Do you need a full architecture that will live for a long time on the project?
• What is the life of the project? 
• How will this tool need to evolve as the project moves along?
• Will this tool need to be generalized to handle more possible scenarios in the future?
• Will this be used by a lot of testers or just one?

Maintainability

• Will this tool be used in the future?
• Is this a throw away tool?
• Does the automation team have the resources to maintain this?
• What are the future changes you can foresee?
• What changes don't you predict that could cause increased maintenance?

The Buggy Bash (poem)

The Buggy Bash

By Thomas Bedran

I was working in my cube late one night
When my eyes beheld an eerie sight
For a bug from the code, began to rise
And suddenly to my surprise

He did the bash, he did the buggy bash
The buggy bash, made the computer crash
He did the bash, a requirement clash
He did the bash, costing customers cash
He did the bash, he did the buggy bash

From where my computer sat in Colorado Springs
To the servers it connects out in Bunker East
Defects came from their hidden code
For me to find with my testing probes

He did the bash, he did the buggy bash
The buggy bash, made the computer crash
He did the bash, a requirement clash
He did the bash, costing customers cash
He did the bash, he did the buggy bash

If you’ve ever seen a bug before
That’s what testing a program is for
Don’t be afraid, don’t run and shout
Test them all and get the defects out

Get down with the buggy bash
Get down with the buggy bash

Getting My Start in Testing

I would like to imagine that the God of Testing visited me in my dream when I was younger and told me I was chosen at birth to save humanity from the impending doom of buggy software. I may even one day recall it like this but since the internet is only for truths, this is how it really happened. And sadly, every bit of this is true.

I became interested in computers once I saw the movie Hackers. Internet was still in its infancy. I didn't get my own computer until I was in middle school. I wonder what would have happened if I had gotten one when I was younger. I was lucky to be able to take a programming course in 9th grade. It was BASIC. I did some programming at home and coded up little games. Trivia and such. Then I learned C as I progressed. My first full game was a text based RPG on a TI-83+ calculator that I did on the bus to and from school.

Early on I decided I wanted to be a video game developer. I loved video games and computers and programming cam naturally to me. It made sense.

I went to school for a degree in computer science at Florida Tech. I got a work/study job with Dr. Cem Kaner in his lab: the Center for Software Testing Education and Research (CSTER). I did various research projects and took classes in software testing. I didn't know at the time that FL Tech was well known for studies in testing.

In the summer of 2006, I went to a job fair and looked for an internship in development. I spoke with a representative for Progressive, handed him my resume, then went home to pray... and study. Ok, I played video games.

I got a call back and the phone interview went well. I was invited to visit Cleveland for an interview in a QA role. Wait! QA? I don't want to be a tester. I want to be a developer. I want to program. I am sure they were mistaken. I figured I would correct them once I arrived.

When I showed up and walked into the dining area for a large gathering of future interns, I learned that there were 5 students interviewing for 3 tester positions and about 100 students interviewing for about 10 developer positions. I am sure my numbers are off, but I knew math well enough to know that I needed this job and my odds were better as a QA.

Well, I got the job. I had a great summer and learned a lot. I got to program anyway (QTP automation scripts) and was a part of a small subset of people that could do both testing and programming well.

And here I am.

Testing at Progressive Insurance

This is not an opinion article nor is it explaining how Progressive does testing in general. It is just to give you more insight into some of the work I have done there.

I realized partway through that I can't create a readable story about every project in a meaningful way. How boring would that be? And by writing this, I think this post gives the impression that what is listed below encompasses everything I have done. There is so much more that I can't include in a single post.

I began as an intern in their Claims organization. Many of the people I worked with were new to the world of the Agile development lifecycle. My manager had me begin as a manual tester writing and executing test scripts before I joined the automation team and converted manual tests to automated scripts in QTP. My first projects were on client-server applications.

At one point I got approval to do both the manual and automated testing on a story card. This allowed me to perform better testing all around. I got to do manual testing where it made sense and automate where it would offer better advantages.

Before I left to finish my last year in college, I began work on a very large scale payment project on a thick client application that was going to replace the manual method of issuing paper check payments to electronic payments. After I graduated, I returned to finish working on this project. Batch jobs were a big part of this project and I helped to implement automation methods for generating data and testing these batch jobs.

Since then, I have done testing in in many project contexts such as converting DTS (data transformation services) to SSIS (SQL server integration services), implementing a Microsoft based Rules Engine, java based applications, several client server applications, thick client applications, migrating to newer technologies (e.g. SQL Server and Visual Studios upgrades), and heavy back end web service and data applications.

My favorite project was working on Progressive's Snapshot or UBI (usage based insurance) technologies. It was my first experience with dynamic design for web pages and social networking, and my first work with creating FitNesse solutions for testing. I got to work alongside a developer to help design, build, and test a batch service that was problematic. That was my first experience with bridging the tester/developer boundary for a project.

I have taken on the role of Test Lead and Automation Lead on several projects. I have acted as a Test Consultant on a few projects as well.

In a couple organizations within Progressive, I have worked to introduce, train, and lead others in Exploratory Testing practices. I relied heavily on James Bach's teachings on Session Based Test Management and Rapid Software Testing with excellent results.

I have acted as developer on a few "Code Jams" at Progressive  - where teams compete to build prototype technologies to help prove and experiment with business ideas. These were always a ton of fun. They are usually 1 or 2 days of straight coding and development marathons.

I have implemented, influenced, and created testing processes in many areas.

I have trained and mentored a lot of testers over the years. I really enjoy testing education.

I have been apart of recruitment and the hiring process.

A Tester's Blog

This site was spawned from my desire to update my resume and provide a place for others to view it online. And since this site allows me to post, I might as well do so.

I don't intend to rant about personal matters or blob about media frenzied affairs. Instead, this will be a platform for expression from a professional's personal experience in anything related to testing.

I am not promising that you will be able to come here and see some amazing new content each time or even valuable content for that matter - unless you came for my resume and desire to hire a skilled tester. If that is the case, take a look at my Resume and About Me tab .

Welcome to the wonderful world of testing.