Richard Bach’s “Illusions: The Adventures of a Reluctant Messiah” is a most treasured book from all the books I have read so far. It is a short book, something that can definitely be digested for an hour or a few, but it doesn’t fall short of inspiring and thought-provoking passages, and questions. I have always kept a copy close because it’s what I often choose to rummage through whenever I feel totally sluggish or disheartened, never failing to provide a good pick-me-up or occasionally giving a disapproving eye when needed.
Here are some favorite lessons from the book, which I remind myself every now and again:
- Learning is finding out what you already know. Doing is demonstrating that you know it. Teaching is reminding others that they know just as well as you. You are all learners, doers, teachers.
- The simplest questions are the most profound. Where were you born? Where is your home? Where are you going? What are you doing? Think about these once in a while, and watch your answers change.
- You are led through your lifetime by the inner learning creature, the playful spiritual being that is your real self. Don’t turn away from possible futures before you’re certain you don’t have anything to learn from them. You’re always free to change your mind and choose a different future, or a different past.
- There is no such thing as a problem without a gift for you in its hands. You seek problems because you need their gifts.
- The bond that links your true family is not one of blood, but of respect and joy in each other’s life. Rarely do members of one family grow up under the same roof.
- If you learn what this world is, how it works, you automatically start getting miracles, what will be called miracles. But of course nothing is miraculous. Learn what the magician knows and it’s not magic anymore.
- Isn’t it strange how much we know if only we ask ourselves instead of somebody else?
- If you will practice being fictional for a while, you will understand that fictional characters are sometimes more real than people with bodies and heartbeats.
- Like attracts like. Just be who you are, calm and clear and bright. Automatically, as we shine who we are, asking ourselves every minute is this what I really want to do, doing it only when we answer yes, automatically that turns away those who have nothing to learn from who we are and attracts those who do, and from whom we have to learn, as well.
- The world is your exercise-book, the pages on which you do your sums. It is not reality, although you can express reality there if you wish. You are also free to write nonsense, or lies, or to tear the pages.
- Within each of us lies the power of our consent to health and to sickness, to riches and to poverty, to freedom and to slavery. It is we who control these, and not another.
- There is no good and there is no evil, outside of what makes as happy and what makes us unhappy.
- If you want freedom and joy so much, can’t you see it’s not anywhere outside of you? Say you have it, and you have it! Act as if it’s yours, and it is!
- We are game-playing, fun-having creatures, we are the otters of the universe. We cannot die, we cannot hurt ourselves any more than illusions on the screen can be hurt. But we can believe we’re hurt, in whatever agonizing detail we want. We can believe we’re victims, killed and killing, shuddered around by good luck and bad luck.
- Why are we here? For fun and learning. It’s the same reason why people see films, for fun or for learning or for both together.
Fun fact: One of Richard Bach’s sons is James Marcus Bach, a software tester.
One big motivation for learning programming and testing applications technically is understanding what feelings and experiences do programmers face in their day-to-day work. Why do many of them have a strong dislike towards bug fixing and other distractions? What sort of things go through their heads when they talk about databases and algorithms? Why do they say that a task is difficult when the changes needed from a user’s point of view are only minimal? Is working with legacy code really that terrible? How do programmers test their code? These are some of the questions that’s tough to answer, so I sought to learn how to write code myself. I wanted to put myself in their shoes and discover how I would feel in situations they often go through in building and maintaining applications, sort of. I thought that if I knew how they generally feel during such circumstances and knew how to code, it would greatly help improve my communication with them in the long run.
Based on my experience so far, it does.
To me, part of the appeal of working in the software testing field is due to the nature of software systems. Apps change. Multiple times a year, some of their requirements are likely to get overhauled. Other programs are being built from scratch. Needs change. Technologies change. Business processes and flow change. As such, digital apps keep changing too and are evolving alongside people’s wishes. That’ what makes software testing work rarely boring and often challenging: because we get to have multiple chances at exploring systems, seeing what they’re made of and thinking about how they help us do the things we need to do. We are trained to be curious. We always look for patterns or their lack of. We keep a good eye out for details and we’re usually asking ourselves why a particular feature needs to perform a certain way. We have a hand in making things better.
And it gets better over time, when we start to realize that testing doesn’t have to be limited to client work. It extends to testing our own life systems, our beliefs, and the places where we want to go.
People learn the most when they themselves are the ones looking for the answers to their questions, when such problems can’t wait to be solved, when they’re excited to see how the solutions work, right now. That’s because it is when we are most curious where we wholeheartedly give whatever it is our all, our time and attention fully spent, excited in our hearts and with sparkles in our eyes, and which, in turn, where the universe rewards us with something equivalent in exchange – the finding of knowledge and the satisfaction of seeing miracles first-hand.
Yesterday, I received a bug report about certain details not being displayed in an application. The report said that this data should be there because it was configured properly in another application but wasn’t, hence the problem. I checked the user’s configuration and found out that the report was accurate. I replicated the user’s steps, looking for clues, and personally verified that we have an issue to fix. Why isn’t it showing? The question nagged me into performing more tests, trying out several steps that may be able to correct the problem but to no avail.
Eventually, I thought about logging on to the database to see what’s happening. Remembering what tables the particular feature is using, I looked for data that’s out of place or different from the usual behavior. I discovered missing values in one specific field and considered adding something to it and see if that changes anything. It did. Display of the reported details returned and I was ecstatic to have found the culprit, now ready for a quick fix, with less investigation time.
For software testers, it helps to know how to create and use database queries to find useful hints. They help us understand why some features behave as they do, especially when these applications transform dynamic information from one source to another.
Every time an issue is found in an application means it’s time for the software tester to play detective. She may not be wearing a detective hat but she has her thinking cap on. In the crime scene, she looks for clues about why and how these things occurred. She knows her work is not limited to just reporting bugs to programmers but rather encompasses so much more: process flow, data, business rules, and user interface limitations are always included in her investigations. She moves with focus on testing tasks at hand in order to find the correct solutions, which eventually helps the developer change code properly. She learns every detail of every software she’s been able to test and remembers them by heart.
She enjoys the pursuit of knowledge about the things she doesn’t yet understand. In her mind, the curiosity involved in work equals fun.
What if I select a date range that is broader than before? Will processing speed still be the same or will the system hang?
What if I type in a string instead of a numeric value? Is it allowed?
What if I disable the cookies in my browser and run through the whole process again? What would I see?
What if I place a SQL query into this input box then press Submit? What happens?
Testing becomes more enjoyable when the tester allows her curiosity to run free, when she asks questions that demands answers by doing the scenario herself. Engaging, but not easy.