Where the Fun and Challenge Is

Ultimately what makes software testing fun and challenging is because it needs you to interact with people. You have to talk to both the software development team and the application users. You have to understand what they care for and why. You have to ask questions and the answers to those questions guide what you do when you test. You can test in a silo but that doesn’t help you learn anything deeper, you can’t thrive if you stick to the things you already know. You grow because you take in all these perspectives and beliefs that other people have and test them against your own, for the goal of making better judgments about how to test the thing your testing and why you’re testing them in the first place. It’s not easy, because you have to care. The challenge is that you have to learn a great deal of many things, you have to regularly check the landscape of where you are, and you often need to reflect about what you’ve done and what you want to do next. And on the journey of overcoming the challenges you set for yourself is where the fun is.

Being Reminded of All the Phases I’ve So Far Had in Writing Automated Checks

I’m currently in the midst of a test code overhaul, a re-writing project of sorts. It started about a week ago and so far I’ve made considerable progress on what I’ve wanted to achieve with the rewrite, which is basically cleaner and more maintainable code, mostly in the sense of test data management and test description language. The number of tests running everyday in our Jenkins system has grown noticeably and I’ve felt that it’s been difficult to add certain tests because of how I structured the test data in the past, which I have not upgraded since then. The two possible avenues for running tests – on the UI and HTTP layers – also adds a bit of complexity and it’d be nice if I can integrate the two smoothly. It’s an interesting development because I did not plan on any re-writing to be done anytime soon but I guess at the back of my mind I knew it’ll happen eventually. And so I decided to take a step back from writing more tests and do some cleanup before it gets tougher to change things. I plan to finish everything in about a month or so.

At the moment, I’m reminded of the phases I’ve gone through in learning to code and writing automated checks in the past few years:

  • Early 2014. It all begins with Selenium IDE, with giving the self some time to study the basic Selenese commands for writing automated checks and (more importantly) understand how to properly retrieve the page elements you want to manipulate.
  • Mid 2014. Test management in Selenium IDE becomes difficult as the number of tests grow, hence the decision to switch to Selenium WebDriver. The only programming language background I had back then was C++, which was limited to only functions and logical/conditional operators, so I chose Java to work with to lessen the learning curve.
  • Late 2014. Familiarized myself with Git, which hooked me on making daily commits and appreciating version control. Along the way I learned the concepts of classes and objects.
  • All of 2015 up to Early 2016. I was in a trance, writing code daily and pushing myself to create all the automated checks that I wanted to run for our apps before every release. Tests run on the Eclipse IDE using TestNG and I was happy with what I had, except that those end-to-end tests are really slow. Running everything took overnight to finish, which was okay for my employer but annoying for me personally.
  • Mid 2016. Re-writing existing tests in Ruby with Cucumber integration started off (when I found Jeff Morgan’s “Cucumber & Cheese” book online) as a side project for fun and testing my skill level in programming. And I did have buckets of fun! The experiment told me that there’s still a lot I need to practice on if I want to write better code, and it also told me that I can be more productive if I switch programming languages. There’s a bit less code to type in when writing code in Ruby than Java and I liked that, plus all the interesting libraries I can use. I switched to Sublime Text and used both Jenkins and the command-line interface more extensively too.
  • Late 2016. As I was looking for ways to speed up end-to-end tests total execution, which by then takes about 4 hours to complete, I ended up exploring testing apps in the HTTP layer instead of in the UI. That took a lot of studying of how our apps actually behave under the hood, what data are being passed around, how images are actually sent, how to view pages without a browser, how redirections work, among other things. After years of testing apps via the user interface, this was such a refreshing and valuable period, and I completely wondered why I never knew such a thing existed until then. It wasn’t being taught extensively to testers, perhaps because it all depends on how the app was structured to run through an API.

And these phases brings me to now, where there’s a healthy dose of API and UI layer tests all checking major app features. It’s all good, just several pieces needing a cleanup, a little parallelization, better test description language, and great documentation. It’s all good, because the lessons in both programming and testing keep piling. The two practices differ in mindset but I think they complement each other, and I think that there’s no reason anyone can’t do both.

Takeaways from Scott Berkun’s “The Dance of the Possible: The Mostly Honest Completely Irreverent Guide to Creativity”

How does one become a creative person? Are we only being creative when we’re delving into the realm of the arts? Why do we say that some people are more creative than others? Does creativity contribute to success? We admire accomplished illustrators, actors, programmers, singers, writers, painters, dancers, poets, and designers of all kinds because of their creativity in their chosen fields of endeavor, because we feel they have good taste in whatever it is that they do, and often we desire to be like them, wishing to churn out great pieces of work too in our lifetimes. But what does it really take to be creative? Scott Berkun gives his take on his latest book,  “The Dance of the Possible: The Mostly Honest Completely Irreverent Guide to Creativity“.

Personally, I don’t think much about what it means to be creative. I feel that thinking about its meaning doesn’t practically help me, because I’ve learned through experience that that only way to create good work is to do it, failing multiple times, learning along the way, and then succeeding. That’s what creativity has always meant for me – building things or solving problems that matter (to me or to other people I provide service to), whenever the itch is there or if the problems bug me enough. And reading Scott’s book felt like a confirmation of some sort of the beliefs I’ve had about creativity, plus a reminder to handle some of my habits better.

Here are some favorite lines from the book:

  • It’s far wiser to think about the effect you want an idea to have. If the goal is to make someone laugh, fix their car or increase the revenue of the widgets their company makes, that matters far more than how “creative” an idea is or is not.
  • We always have more freedom than we think, we just forget. We spend so much time trying to be efficient that doing anything interesting feels like a waste of time. And in this tendency is another misconception: creativity is rarely efficient. It always involves taking chances and trying things that might work but might not. The question then is: are we willing to spend time to be interesting, to think interesting thoughts and make interesting things? We all have the power, but perhaps not the willingness.
  • To create means to make something new, at least for you, and to do something new is like going off of the map, or more precisely, deliberately choosing to go to a part of the map that is unknown. In this case it rarely matters where or how you start.
  • You will, no matter how talented you are, have your finished works challenged and called not-so-good names. Good is surprisingly subjective, and the more creative the domain you work in, the more subjective it is.
  • The ability to see an idea, or a thing, from many different perspectives is among the greatest assets a thinking person can have. Of course you don’t have to agree with someone else’s perspective, but you owe it to yourself to try to see what they do. They may see something important you’ve never noticed before, however small, that can improve what you’re making or what you make in the future.
  • I don’t know a single productive creative person who doesn’t have a scrap pile of unfinished projects at different states of completion. This is not waste, but a precious archive of projects that might need to breathe, or of spare parts that may be perfect for other projects.
  • Some movies and books are poorly received when they’re released but become popular decades later. Others are big hits at first but fade over time. What is good? The answer depends on what your goals are and what problems you choose to solve.
  • No matter how great your idea is, there will be energy you have to spend, often on relatively ordinary work, to deliver it to the world.
  • Take pleasure in making things for the sake of making them: what a gift to have the time to make at all! If you were born 200 years ago, or to different parents in a different country, you wouldn’t have the time to feel bad about your work, because you wouldn’t have the wealth and time required to try. If you feel love for your craft, honor it by showing up, even when it’s hard. Especially when it’s hard. Working when it’s hardest often teaches rare lessons that will earn you easy rides now and then. Take pleasure in small progressions when you see them, and know those hard-won gains are the only way anyone in history has ever achieved anything noteworthy—for themselves or for the world.
  • If you truly love your craft, there is an infinite number of projects in your future. There will be other chapters. There will be other canvases and other songs. Perfection is a prison and a self- made one. Whatever you’re making, it doesn’t have to be perfect. Perfection is an illusion.
  • Expect to be rejected. You will be. It will happen no matter how successful you are.
  • Do one project for commerce and one for art. It’s an interesting approach: maybe the best work can only be made if it serves only one master at a time. It’s a healthy exercise to both make something entirely for yourself and entirely for other people. In each case you will stretch your boundaries for what you are capable of, as so often those conflicting desires of satisfying ourselves and satisfying other people bind us to conservative choices.
  • Too often we are distracted away from what we say is important by things that are more pleasurable or convenient. This means a central skill any creative person needs is a mastery of time, which means a mastery of habits. There will always be easier things in our lives than creative work. There will always be demands on our time that are more logical and lucrative than chasing an idea. If you are truly passionate about something you must be willing to make sacrifices to make it possible. What good is that passion if you can’t use it to help you do the work? Merely saying you are passionate, or feeling passionate, is not enough.
  • The simplest habit is to work on your project every day. If you don’t have a project, go to your private journal or drawing notebook daily until you do. It can be for ten minutes or an hour, but you must touch the work at least once a day. It can be in the morning, or late at night, or during your lunch break at work. At first when and where won’t matter. All that counts is that you commit to the discipline of honoring your ideas.
  • We all have the same time limit of 24 hours every day, which means the difference between a productive creative person and an unsatisfied dreamer is in how they choose to use it. Most of us forget how much of our time goes to entertainment, things we do purely for pleasure. We have plenty of time—it’s just we have to protect it for the things we claim are most important.
  • “Will anyone care about my work?” people often ask. Yes—you. It starts with you.

Whenever I Can’t Replicate A Scenario

Whenever there’s an issue in production that I can’t seem to replicate quickly in our development environment, the problem reminds me that I have not tested everything in our software, that there are gaps in the model I’m currently using to test our application. The mistakes I make in diagnosing a problem helps me improve but also tells me that I have not explored our systems enough, or that maybe I have forgotten something that should help me test, or that perhaps there are modules that have changed since I last visited them.

More importantly, such scenarios prompt me to remember that I literally can’t know or test everything, that I need help in these cases, and that is precisely why it takes a whole team always extending continuous effort to bring quality up to a point where customers love our app. That means everyone’s​ testing skills need to stack up, salespeople, testers, programmers, product owners, everyone.

Lessons from Richard Bach’s “Illusions: The Adventures of a Reluctant Messiah”

Richard Bach’sIllusions: 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.

Takeaways from Timothy Ferriss’ “The 4-Hour Workweek”

Timothy Ferriss‘ “The 4-Hour Workweek” might be my favorite book this year. Tons of lessons about how to be productive, as well as how to enjoy life to the fullest, and reading the book has left me excited about the future while reconsidering many of my other choices.

Some favorite takeaways:

  • The perfect job is the one that takes the least time. The goal is to free time and automate income.
  • ‘If only I had more money’ is the easiest way to postpone the intense self-examination and decision-making necessary to create a life of enjoyment – now and not later. Busy yourself with the routine of the money wheel, pretend it’s the fix-all, and you artfully create a constant distraction that prevents you from seeing just how pointless it is. Deep down, you know it’s all an illusion, but with everyone participating in the same game of make-believe, it’s easy to forget.
  • What are you waiting for? If you cannot answer this without resorting to the previously rejected concept of good timing, the answer is simple: You’re afraid, just like the rest of the world. Measure the cost of inaction, realize the unlikelihood and repairability of most missteps, and develop the most important habit of those who excel, and enjoy doing so: action.
  • Retirement as a goal or final redemption is flawed for at least three solid reasons:
    1. It is predicated on the assumption that you dislike what you are doing during the most physically capable years of your life.
    2. Most people will never be able to retire and maintain even a hotdogs-for-dinner standard of living. Even one million is chump change in a world where traditional retirement could span 30 years and inflation lowers your purchasing power 2-4% per year. The math doesn’t work.
    3. If the math doesn’t work, it means that you are one ambitious hardworking machine. If that’s the case, guess what? One week into retirement, you’ll be so damn bored that you’ll want to stick bicycle spokes in your eyes.
  • If it isn’t going to devastate those around you, try it and then justify it. Get good at being a troublemaker and saying sorry when you really screw up. Ask for forgiveness, not permission.
  • Ninety-nine percent of people in the world are convinced they are incapable of achieving great things, so they aim for the mediocre. The level of competition is thus fiercest for ‘realistic’ goals, paradoxically making them the most time- and energy-consuming. So do not overestimate the competition and underestimate yourself. You are better than you think.
  • Doing something unimportant well does not make it important. Requiring a lot of time does not make a task important. What you do is infinitely more important than how you do it. Efficiency is still important, but is useless unless applied to the right things.
  • Remember that most things make no difference. Being busy is a form of laziness – lazy thinking and indiscriminate action. Being overwhelmed is often as unproductive as doing nothing and is far more unpleasant. Being selective – doing less – is the path of the productive. Focus on the important few and ignore the rest.
  • If you haven’t identified the mission-critical tasks and set aggressive start and end times for their completion, the unimportant becomes the important. Even if you know what’s critical, without deadlines that create focus, the minor tasks forced upon you (or invented) will swell to consume time until another bit of minutiae jumps in to replace it, leaving you at the end of the day with nothing accomplished.
  • The key to having more time is doing less, and there are two paths to getting there, both of which should be used together:
    1. Define a short to-do list
    2. Define a not-to-do list
  • Don’t ever arrive at the office or in front of your computer without a clear list of priorities. There should be no more than 2 mission-critical items to complete each day. Never. It just isn’t necessary if they’re actually high-impact.

An Experiment on Executable Specifications

What: Create executable specifications for an ongoing project sprint. Executable specifications are written examples of a business need that can be run anytime and acts as a source of truth for how applications behave. It is a living documentation of what our software does, and it helps us focus more on solving the unusual and noteworthy problems instead of wasting time with the ones that we know we shouldn’t have been worrying about.

How:

  1. Join a software development team for one sprint duration.
  2. Discuss project tasks for that sprint with everyone.
  3. Ask about requirements examples and create executable specifications for those tasks as the application is being written.
  4. Refine the specifications when necessary.
  5. Continuously update the specifications until they pass.
  6. Keep the specifications running on a preferred schedule.

Why: To see if writing executable specifications alongside development is feasible during the duration of a sprint.

Limitations: Tester writes the executable specifications, programmers work as is.

Experiment Realizations:

  • Writing executable specifications can be done during actual app development, provided that tester is experienced with the tools for implementing it and understands well why the need for such specifications.
  • It is of course more beneficial if everyone in the team learn how executable specifications work and write/run the specifications, and why the need to implement it.
  • It will take quite a long while before executable specifications becomes a norm in the existing software development process, if ever. This is a function of whether everyone believes that such specifications are actually useful in practice, and then building the skills and habit of including these specifications in the team’s definition of done.