I had been working on a project for a few months, and it was still in the early stages. Installation was more difficult than it should have been. I had to download a zip package, unzip it, run a batch file, then stop services, edit a configuration file, copy a few other customized files into place, and then finally start up the service and start testing. I could have written another batch file to do all this for me. But, I wanted to make sure I fully understood every step involved in the installation process. Development would later create an MSI for the installation process, and I wanted to know everything that needed to happen from the ground up so I could test it later.
Get TestRail FREE for 30 days!
The biggest result of installing ‘the hard way’ was that I made LOTS of mistakes, and found a few oversights in the current installation process. For the first few weeks, I was constantly troubleshooting with the developers. From database connection errors in the log files to 404 errors in the browser, I saw them all. It was annoying, but I had good reason for learning the hard way, so I kept with it.
As the project continued, the lead developer started performing his own installations on some virtual machines so he could demonstrate progress to our stakeholders. One day I overheard him mumbling in annoyance, and thought, “That is the sound of someone having trouble installing.” I walked over to check on him, and sure enough, he was seeing an error I had seen many times before. I explained, “We have one database system for our website data, and one database for the messaging system. If you refresh one, but not the other, you get an obscure error when you try to start the service. Just refresh the messaging database, restart the service, and you’ll be fine.” Problem solved!
I went back to my desk and started working on something else. After a while, I heard the muttering again, so I went back over to the lead developer’s desk. This time, the service had started, but the browser was returning an error message. I knew just what the problem was. “When you deleted the database earlier, you also deleted the locally stored login information. We’ll need to take a few more steps to bootstrap your user into the system, since they haven’t created a formal story for creating the first user yet.” I walked him through the steps, and he was able to get logged in. Crisis averted!
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
At this point, I knew to keep my ears open, because there were one or two more places where he might discover that some part of the installation process had gone astray. Sure enough, after lunch I heard an unmistakable grunt of annoyance. This time, the lead developer called me over to ask if I’d seen this problem before. I let him know that I knew just what the situation was. “We have a story about being able to connect to multiple data sources, but I had to return it because it’s not working. You have two data sources listed in your configuration file. For now, you’ll have to comment out one at a time. Stop the service, edit the configuration file, and restart the service each time you want to use the other data source.” All done!
After a half day of interruption, the lead developer finally had the program installed and ready to use. I was happy to help him whenever I could.
This is a guest posting by Carol Brands. Carol is a Software Tester at DNV GL Software. Originally from New Orleans, she is now based in Oregon and has lived there for about 13 years. Carol is also a volunteer at the Association for Software Testing.
