Last Wednesday afternoon I anxiously asked my boss for permission to make changes on our application code repository. I said I wanted to try fixing some of the reported bugs listed on our tracking system, if there are no other resources available to pass them to. I made a case about myself not posing any problems because of the code review process built into our repository management tool, that there’s no reason for me to merge any changes without getting feedback from a senior developer first.
He smiled at me and gleefully said “Go ahead. I’m not going to stop you.“, to which I beamed and heartily replied “Thanks, boss!”
This is a turning point in my software testing career, to be able to work on the application code directly as needed. It is actually one of my biggest frustrations – to not be able to find out for myself where the bug lives in the code and fix them if necessary. It’s always a pain to be able to do nothing but wait for a fix, and for a fix to be dependent on the resources available. In my head I think that I’m available and maybe I can do something, but I don’t explicitly have access to the application itself and the code that runs it so I can’t do anything until I have the rights to do so. That’s how it always been. Software testers are often not expected to fiddle with code, at least in my experience, especially in the past where automation was not yet known to be useful as a testing tool. Now that I have the skills and the permission to work on the application repository, I feel that my reach for making an impact on application quality has now expanded remarkably well.
Now bug-fixing is not software testing work in the traditional sense. But I figured there’s no harm in trying to fix bugs and learning the nitty-gritty details of how our legacy applications actually run deep in the code. I believe that learning technical stuff helps me communicate better with programmers. It helps me test applications in a more efficient manner too. Of course I have to consistently remind myself that I am a software-tester-first-programmer-second guy and have to be careful not to fill my days playing with code and forgetting to explore our applications themselves. That said, there are ideas I really want to experiment within our software development process, towards the goal of improving code quality and feedback, and I can only tinker with those ideas inside the application repository itself. Dockerized testing environments, code linting, and unit tests are three things I want to start building for our team, ideas that I consider to be very helpful in writing better code but has not been given enough priority through the years.
I think I’m still testing software, just extending the knowledge and practice of the various ways I perform testing.
One interesting topic I’ve come across this year in a few podcasts I listen to is Stoicism. William Irvine introduced the school of thought in an episode of the Art of Manliness podcast and Ryan Holiday wrote a practical guide about it for entrepreneurs on The Tim Ferriss Show. It has practical applications in daily life, and because of that I’d like to eventually learn more about what to practice and its how’s and why’s. For now though, I thought that reading up on Seneca’s essay ‘On the Shortness of Life‘ would be a good starting point.
Here are some notes from the essay:
- It’s not that we have a short time to live, but that we waste much of it. Life is long enough, and it’s been given to us in generous measure for accomplishing the greatest things, if the whole of it is well invested. But when life is squandered through soft and careless living, and when it’s spent on no worthwhile pursuit, death finally presses and we realize that the life which we didn’t notice passing has passed away. So it is: the life we are given isn’t short but we make it so; we’re not ill provided but we are wasteful of life.
- Look at those whose prosperity draws crowds: they are choked by their own goods. How many have found their wealth a burden! How many are drained of their blood by their eloquence and their daily preoccupation with showing off their abilities! How many are sickly pale from their incessant pleasures! How many are left with no freedom from the multitude of their besieging clients!
- What foolish obliviousness to our mortality to put off wise plans to our fiftieth and sixtieth year, and to want to begin life from a point that few have reached!
- The person who devotes every second of his time to his own needs and who organizes each day as if it were a complete life neither longs for nor is afraid of the next day. For what new kind of pleasure is there that any hour can now bring? Everything has been experienced, everything enjoyed to the full. For the rest, fortune may make arrangements as it wishes; his life has already reached safety. Addition can be made to this life, but nothing taken away from it – and addition made in the way that a man who is already satisfied and full takes a portion of food which he doesn’t crave and yet has room for.
- I am always astonished when I see people requesting the time of others and receiving a most accommodating response from those they approach. Both sides focus on the object of the request, and neither on time itself; it is requested as if it were nothing, granted as if it were nothing. People trifle with the most precious commodity of all; and it escapes their notice because it’s an immaterial thing that doesn’t appear to the eyes, and for that reason it’s valued very cheaply – or rather, it has practically no value at all.
- The greatest waste of life lies in postponement: it robs us of each day in turn, and snatches away the present by promising the future. The greatest impediment to living is expectancy, which relies in tomorrow and wastes today. You map out what is in fortune’s hand but let slip what’s in your own hand. What are you aiming at? What’s your goal? All that’s to come lies in uncertainty: live right now.
- There is a common saying that it was not in our power to choose the parents we were allotted, and that they were given to us by chance; yet we can be born to whomever we wish. There are households of the most distinguished intellects: choose the one into which you’d like to be adopted, and you’ll inherit not just the name but also the actual property, which is not to be hoarded in a miserly or mean spirit: the more people you share it with, the greater it will become.
- Honors, monuments, all that ostentatious ambition has ordered by decree or erected in stone, are soon destroyed: there’s nothing that the long lapse of time doesn’t demolish and transform. But it cannot harm the works consecrated by wisdom: no age will efface them, no age reduce them at all. The next age and each one after that will only enhance the respect in which they are held, since envy focuses on what is close at hand, but we more freely admire things from a distance.
- It is nevertheless better – believe me – to know the balance sheet of one’s own life than that of the public grain supply.
- In this mode of life much that is worth studying awaits you: the love and practice of the virtues, forgetfulness of the passions, knowledge of how to live and to die, and deep repose.
Everyday, prepare a very specific question (or a task) interesting enough to warrant research for an answer within several hours without distraction. Sometimes for learning, sometimes for fun, hopefully most days for both. Everyday there must be an adventure to immerse in, albeit small, something to be curious for.
Having received a handful of calls these past few weeks, I’ve realized that I’m thinking more about learning opportunities now than only looking at an offer’s compensation package. Salary still matters of course but there’s more to a day job than just allocating money for expenses and savings. Work wouldn’t be fun when there’s only menial work to do. What would I learn if I took an offer in exchange for my services? Will I be doing something I’ve never done or tried before? Is this work meaningful, both for our customers and for me as an individual?
And some more questions to recruiting employers on the top of my head:
- How does the existing software development and testing process work in the organization?
- Are testers embedded into software teams? Or do they work in silos, away from the developers?
- What does a software team look like and compose of?
- What does the day-to-day work look like for the software tester?
- How many testers are there currently in the organization? And what’s the existing ratio of developers to testers?
- What technologies do the organization currently use for testing? Are there automated checks? Is there an existing CI system?
- Does the organization use containers? Visual testing? Machine learning?
- Who are the organization’s actual clients? Which lives are we trying to improve on a daily basis?
- How do the software teams get feedback from the people who use their applications?
I have always thought of myself as a good listener. That’s what I believe to be particularly the reason why I have thrived working with both programmers and product owners, a software tester in the midst of all sorts of people. It’s a fundamental skill I have learned to be proficient in.
What’s not my strong suit at though is asking people for what I want or need. Of course asking for little things or asking probing/clarifying questions isn’t that difficult; what’s tough is inviting people to join you on a quest, asking friends to do something interesting together, or asking a fascinating lady out to lunch. It’s a fear which doesn’t get any easier even if I actually know the problem. And the solution is the same as with all skills: practice. It has been and always will be a struggle, so I need to continuously remind myself to be brave.
What does our team actually want to accomplish this particular sprint?
Do I know my teammates well enough?
Does everyone in the team feel safe working together with each other?
Can I rely on everybody in the team?
What does a user story mean to us?
Do we even need tickets in order to perform our best work?
Do we truly need this specific document to move forward?
How can I help a teammate feel good with the work he/she is doing?
What’s the minimum amount of input do we need in order to start?
What’s the 20% of activities that contribute to 80% of outputs we desire?
Do we believe in what we are building?
Which rules, in reality, help us become the best versions of ourselves? Which don’t?
2016 has been a surprising year. There’s been some considerable changes at work – people came and went, several small process changes for the good, and more transparency in automation which includes a dedicated testing server – many of which are for the better. There’s still some work to do though and those will spill over to the coming year, and most likely I’ll keep on adding valuable tests to the team’s daily running suite on the cloud.
Aside from that I hope to share what I’ve learned this year to the testing team, especially that bit about REST calls because that’s something they can actually use for testing any web application.
And I plan to read more next year. Or at least the following books: Specification by Example, Pride and Paradev, The Cartoon Tester, The Psychology of Software Testing, There’s Always a Duck, Rails 4 Test Prescriptions, Creating Great Teams, Explore It!, Willful Blindness, Tools of Titans, and The 4-Hour Workweek. Maybe I’ll slip in some fiction too in the reading list.
There’s some coding experiments I’d like to try as well:
- building a Ruby on Rails application
- Geb + Groovy + Spock automation framework
- Java + Serenity automation framework
Overall I don’t think there would be many changes from the things that I currently do, only continuous learning and refinement of existing workflow. But I can be wrong. We’ll see. 🙂