A 7-Year Run

It’s been seven years since I got employed at the private company I currently work for. I didn’t set out to be employed for them this long but the pay was okay and there was a lot of freedom in the testing work so I stuck around. That freedom allowed for opportunities to learn and improve on the testing (and software development) craft consistently, even though there really wasn’t any in-house training available, as long as I managed myself well year in and year out. At that time, I thought that all I needed was time to train myself and so that’s what I did. I managed my tasks well, I asked people and the world wide web questions and tried their suggestions one at a time, and that pattern continues to this day.

Don’t know where to start testing? Look at what’s available, see which ones could be interesting, and then just dive right in to those. Too many things to test? Find which features are most important and start with those, not worrying too much about testing everything. Found something odd? Ask the customer whether it’s something worth exploring. Think a particular task isn’t worth doing over and over again? Automate it, if there’s really some value in automating it. Not technically savvy? There’s tons of materials out there you could study a little at a time. Something troubling the team? Ask and listen to what they have in mind. Is a certain process annoying? Find out why that is and think whether there’s something you can do about it. Bored? Do something else. Tired? Take a break. Want to get better at a particular skill? Read books and blog posts, watch webinars or take courses, and build projects with what you’ve learned. Day in and day out, the fun is in hunting for intriguing problems to solve and testing one possible solution after another. And the trick in having the most fun is in finding out what problems are worth solving for, both for your customer and for yourself.

Yes, it’s been an extraordinary seven years. I got the growth spurt that I wanted while performing valuable work on time. Now thinking about it, I’m actually not sure if there will be many years more to add to that record, but all is well because it’s been a great run.

Advertisements

One Month with Flutter: Some Notes

Wait, what, it’s already been a month? 😮

It apparently took me an exciting month to build a moderately intricate multi-page mobile app, powered by Flutter, with custom calendar and credit card views. The designs for the pages already existed, which was good because I did not want to worry about designing an app for my first try with Google’s SDK and the Dart language. I only wanted to test-drive writing the code for the user interface and find out what tools and structure I could use for managing state and data, given a relatively short span of time. A month isn’t enough to understand everything about the framework but I did learn a lot from the experience. A realization: I can totally write mobile apps now if I want to.

Some notes I’d like to remember from the exercise:

It’s Alright to Make Mistakes

Looking at the screenshot above, it’s ironic that there’s a mismatch between the commit message and the actual pipeline result from the tests after pushing the said commit. 😛 What happened was that after making the unit tests pass on my local machine, I fetched the latest changes from the remote repository, made a commit of my changes, and then pushed the commit. Standard procedure, right? After receiving the failure email I realized that I forgot to re-run the tests locally to double-check, which I should have done since there were changes from remote. Those pulled changes broke some of the tests. Honest mistake, lesson learned.

I frequently make errors like this on all sorts of things, not just code, and I welcome them. They bewilder me in a good way, and remind me of how fallible I can be. They show me that it’s alright to make mistakes, and tell me that it’s all part of the journey to becoming better.

And yes, testers can also test on the unit level! 🙂

 

Guard Up

Knowing how to automate things and building scheduled tests to monitor known application behavior does not guarantee bug free apps.

They do help boost confidence in what we’ve built, and that makes us more comfortable releasing changes into the wild, because it means we’ve explored a fair amount of feature breadth. It’s not the only strategy I’m sure to use given some software to test, but it’s something I’ll practice every after thoughtful exploration.

But, even with that tool to augment my testing, I have to keep my guard up. Every time, I should keep asking myself about the more valuable matter of the unknowns. What sort of things have I not considered yet? What scenarios might I still be missing? Have I really tested enough or am I merely being overconfident, just because I can automate?

Choosing Variables

We consider a lot of things when we build and test software.

Who are our customers? On which browsers or platforms do we target to deploy our application? Does our software load fast enough for a considerable number of users? Are we vulnerable for SQL injection and cross-site scripts? What happens when two or more people use a specific feature at the same time? Is our API stable and structured well enough for its purpose? How easy is it to set up our apps from scratch? Do we handle rollbacks? What metrics should we monitor on production? Do we feel happy about our happy paths and other not-so-happy paths? What actual problem is our app trying to solve?

There’s a fair amount of room for making mistakes. Bugs can creep in where there are gaps. Some errors are likely to occur while we are building and testing stuff because there’s just so many variables involved.

That’s how things are. There’s not one but several moving parts. It’s up to us to decide whether to be overwhelmed at the complexity or decide to get better at finding out which things to look out for and learn those.

The same is true in building and testing the life we choose to live.

The Harajuku Moment

On a chapter from Timothy Ferriss‘s book titled “The 4-Hour Body“, he talks about something significant called the Harajuku moment, described as:

.. an epiphany that turns a nice-to-have into a must-have.

The expression actually came from a realization Chad Fowler (programmer, writer, co-organizer of RubyConf and RailsConf) had in Harajuku with friends some time in the past, while window shopping and lamenting how unfashionable he was. He noticed the tone of helplessness in his own words as he talked about his obesity, and felt angry at himself for being an idiot who went with the flow, making excuses, for many years.

After that defining moment, he turned things around and lost nearly a 100 pounds.

Two years in a row of annual physical exams (2015-2016), I was told that I have hypertension. The previous years I also felt that I tire quickly, becoming more so as the days went by. I’m just over 30, skinny, and believed that I should still be in my prime but was not. I wondered why things turned out the way they did, and eventually recognized that existing habits did not help me become the healthy person I thought I was.

I’m now performing weight-lifts and body-weight exercises 4 times a week, and is in my best shape in the past 10 years or so. What’s interesting is that making the change was actually fun and somewhat easy, very unlike the grueling and exasperating experience I initially thought it would be. I plan to keep things up, gaining as much strength as I can and keeping body fat percentage minimal.

What the Harajuku moment tells us is that, often, on most days, we have insufficient reason to take action. We only have nice-to-haves. We tell ourselves it would be nice to get fit, go on a date with that someone we really like, have a well refactored code, travel internationally, or learn a new skill. But the nice-to-haves do not give us enough pain to move forward. That’s why we sometimes feel we’re stuck in a rut.

Our nice-to-haves must first turn to must-haves before we can take advice and act.

A Design Problem

This weekend, while in the middle of a deep dive into the practice of discovery testing on a personal project, I realised that there are different ways of building software from the ground up. That’s actually obvious because there are various programming languages and there are tons of frameworks for quickly constructing apps and sites. It’s literally never been easier to write software from scratch. But simple to start doesn’t mean that what we create turns out to be something that’s easy to maintain or extend, even if the team decides to write more tests or use more tools to monitor the sanity of the codebase. Even if user stories are clear and there’s enough capacity for testing, it can still be difficult to deliver changes without a hitch and on schedule, when the code makes it hard to do so.

For many testers and product owners who have never before looked at the code that runs the apps they test, it may be tough to see how simple feature requests take too long. It can be mind-boggling why bugs continue to creep in. We tend to just accept things as is. Finding out why is one reason I learned how to read and write code myself, besides the desire to have better communication with the devs I work with and having the ability to write my own tools to augment how I test. And after having been writing test code for a number of years now I can say that translating ideas into new code can be easy, but revising existing code to accommodate new business rules is often  troublesome. That means, at least for me, that I have a problem about the way I am writing code for the long haul, even if my app is working at present. I can imagine other programmers having the same predicament.

I now understand that writing long-term, maintainable, software is essentially a design problem. And it seems that a lot of us needs to up our skills in that area.