If you're first getting into software testing, or if you've started a new job testing in a different industry, you probably have a lot of questions—about terms and jargon, expectations, requirements, and more. Hopefully your new team will answer some of them, but if you feel like you keep bugging them, there are ways you can learn and discover on your own.

Three years ago, I convinced my husband to resign from his job as a police officer, we packed our bags, and we moved from Romania to London for a brand-new challenge: I was going to work as a tester at an investment management firm.

I had never done testing in the financial world before. “Testing is testing,” I thought. But there was so much more to learn than I had expected. All around me, people were speaking in a strange, coded financial lingo: “short sells,” “futures,” “funds,” “SEC and FCA regulations.”

The software and the team had been around for more than ten years, but they only now decided to hire a tester. Not only was I the new kid, but I soon discovered that they didn’t really know what a tester was supposed to do. There were no established testing practices, written oracles, or structures of any kind. I was not the only one with a lot to learn.

I bet you are wondering why they would hire me if I didn’t know anything about the financial software world. Well, they knew I wasn’t a financial expert, but they assumed I would learn it quickly. Looking at my previous experiences, they assumed I knew how to test.

In the past, when I had tested in other contexts, it had not been so complicated or different. In my new job, there were too many messages, labels, and concepts that the software was throwing at me, all of which were unfamiliar. I didn’t have enough background knowledge to enable me to learn as quickly as I wanted to.

I felt crippled by this challenge. I would be forced to ask questions, and this was frightening.

Time is a valuable, limited resource, yet asking questions is first and foremost asking for time: Do you have a minute? Do you have a second? When you have time, could you help me with this? These questions have a tacit, unspoken dimension. What we are really asking is, Do you have a minute, and are you willing to invest it in answering my question? Do you have a second, and are you willing to invest it in teaching me? When you have time, will you be willing to invest it in helping me? On the other hand, the person answering my questions might think, Is it a good investment of my time to help you? How much will it cost me to answer your questions, and what is the benefit for me?

The less I knew, the higher the cost for everyone who worked with me.

I had to find the people who would tolerate my interruptions and be willing to engage in the complex process of conveying information. People are more willing to answer questions and share knowledge when they see you trying hard on your own and can witness the progress you make. I had to show my team that I was able to put their help to good use. I had to prove they invested wisely in me.

My solution was to learn without asking a lot of questions. Here are some of the things I did.

I used my ignorance and my fresh perspective. Because I had no experience working with financial software, I had no established mental models of similar products. This ignorance is what helped me quickly become useful. It was the same ignorance that protected me from making dangerous assumptions.

Being temporarily ignorant turned out to be a test technique that led me to be able to perform shallow testing, and shallow testing is a way of learning. Reflecting on this experience, I realize that the very process of my learning exposed me to bugs. I didn’t need to wait until I learned everything to start the testing.

I explored the software in front of me.

It turned out that as I navigated through the structure of the product, I encountered quite a bit of useful documentation. Based on what I saw, I built a hypothesis of what the software might do. I looked for inconsistencies between what what going on and what was written, and while doing this, I encountered all sorts of interesting words and phrases. This was the language of financial software—it was speaking to me, but I could not yet understand what it was saying.

I looked for models outside testing to help me learn.

I didn’t realize it then, but learning to speak “finance” is no different from learning to speak any other foreign language. When you learn a new language, you don’t start with all the words at once, nor do you follow an exact sequence of steps. The process looks more like this: You master a few words, then you try constructing a sentence, then you learn a grammar rule, then you go back and add more words to your vocabulary, then you find out about another grammar rule, then you explore more challenging and diverse words, then you try spelling, then you improve pronunciation.

You learn the essentials first—words that can be useful fast—then learn more through exploration and experimentation. It’s all about discovery. I identified patterns of repetition and assigned different significance to different learning units based on their enabling capacity.

I read all wiki pages and generally every piece of documentation I could get my hands on.

Documentation doesn’t just happen—someone puts time and effort into producing this bank of information that might be useful for others. By going through these wiki pages, you are not only going to find out useful things; you are going to show the authors that you respect their work and the time they invested. Rather than asking them to convey all that again, you are respecting their time and making the effort of learning what you can by yourself.

The authors have already given you (and others) their time when they sat down and wrote those documents. Don’t make them spend their time twice, and don’t double your company’s costs.

I invited people to review my testing.

By reviewing my testing, others on the team would suggest things without my needing to ask questions. I used test reports as a means to identify and recruit a team of supportive testers. The process required the stakeholders to review my test ideas and point out any uncovered risks. In this way, I made sure that I was not missing critical testing paths and, at the same time, they were answering unasked questions. This was my way of getting them to talk without making them feel fatigued by my interrogations.

Three years later, I no longer fear asking questions. I feel more powerful and confident, I can tell stories about my testing, and I am a proud student of the testing craft. I know how to use the information I receive from other people, and I am also willing to forgive myself if I don’t find an immediate applicability for all the data that comes my way.

And it’s not just me. My husband became a tester, too. It has become the family business.

About the author

I am a passionate tester who managed to gather a few good experiences and stories throughout the years. I love my profession and I care deeply about the direction in which it is going. I am committed to doing good, meaningful work.

I belong to the Context Driven School of Testing and I purposefully study the Testing Craft.