On An Indeterminate Hiatus

I wrote my first post on this blog about six years ago. I was three years into software testing then. I’m around nine years into it now. Many things have changed over the years, in processes, in tooling, in people I work with, but some things remain the same. The core of my abilities in making a living as a tester is still rooted in a strong relationship with the software development team, and how strong that relationship is depends on everyone’s communication and technical skills. I’m fortunate enough, all these years, to have worked with wonderful people, enabling me to make a living in an industry I’ve come to love.

I’ll most likely going to be working as a tester for many more years to come.

Today, however, I am putting this blog on an indeterminate hiatus. I’m not sure when I’ll be back. There’s not much to say really, except that I would like to take the time and energy I’ve been putting here somewhere else that may or may not work.

For now, all that’s left to say is a huge thank you for following along. 🙂

 

 

Is There Really Nothing We Can Do?

“I’ll wait for the code to get pushed to the Staging server before I continue testing because the data there is a lot more stable.”

“It’d be a waste of time trying to teach people how to program when it feels like they don’t have the motivation for it.”

“There’s a high chance things will break after a code merge with the production branch. It’s been that way ever since. We’ll just have to fix those that we can until the release.”

“I wish there was an easy way to spin up a version of our apps in a local environment. That should help us test things faster.”

…

Some problems become the status quo. It’s worth revisiting them, asking ourselves whether there’s really nothing we can do about it or we’ve just become comfortable with complaining.

Remember to Focus on Helping People

It’s easy to get caught up on writing a lot of automation, adding more process steps, and implementing stricter policies, believing we need them, because we think we’ll be safe from risks that way. We might have had a history of being carelessly bitten in the past.

So it is good that we’ve chosen to do something. But we have to be aware of the potential to get lost in the details.

Why did we have to do this work in the first place?

We don’t just want to add one more test to the suite. We don’t just want another meeting. We don’t just want customers to pay a fee when they request something for the nth time. What we want is to remember the big picture, what we want is to focus on helping people.

Rookie Blog Post Mistake

I’ve made a rookie blog post mistake early in the new year:

Why am I posting a 2017 blog post when it’s already 2019? :O

That is, I forgot to remove a scheduled blog post I’ve made in the past and it got published recently. Some of you might have gotten the post through email and wondered why I’m talking about 2017 and maps. It’s a little embarrassing; that post should have been in the trash a long time ago but for some odd reason I didn’t delete it until now.

Maybe I thought there was an idea worth saving in there which I forgot to review. Or perhaps I just got lazy.

I’ll just think of this as a reminder that mistakes are always bound to happen. And what’s important is how we behave and what we do when they happen.

The post is gone now. And I am sorry about the weird blog post. I’ll make adjustments on my end so that it won’t happen again.

Testing Goals for 2019

All year round, I’ve spent some considerable time thinking about where I am and where I want go next. Where I am is where there’s some sort of stability, a status quo. Where I want to go next is some place where there are unknowns.

It would be interesting to experience a full-time remote gig, in a role that challenges my skills in either building automated scripts or mobile app development. But even though a full-time gig, it should still enable me to work on personal side hustles.

After increasing my overall strength to at least twice since the start of the year, I’d like to surpass that achievement in the coming year. That likely means making better food choices and improving cooking skills.

I want to build my portfolio site from the ground up and get more acquainted with web development.

And it would be great if I can finish the art project I started this year, to complement the portfolio site.

I believe I did well with my testing goals this year. My lifestyle got better, but I’m not where I want to be just yet.

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.

Questions on Releasing Daily

What if?

Do we think we can do that?

Is that a goal worth something for us to reach for, or are we satisfied with weekly, monthly, or yearly project releases?

If we do decide to release to live daily, is it going to take a lot of work?

For what reasons do we have to put in the effort for?

What changes should we have to make so we can push as early and as often as possible?

How does that affect our existing software development process?

Does our team have sufficient expertise to follow through?

Do sprints even matter in that case? What about daily stand ups and retrospectives?

Should we push to live our long-running projects? What happens to feature branches?

How much testing is enough for us to be comfortable with daily releases?

Do we still need as many test environments as we do before?

What happens to our testing when we don’t have plenty of time to manually check everything?

Are our customers supposed to be delighted if we release daily?

Will the team be more pleased with a presumably increased efficiency or are we happy where we are?

If we decide to forego a daily release schedule, where else do we want to focus our attention to?

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.

Our Scrum Masters

Recently, I was asked by the Human Capital Management team at work for a list of specific requirements for our scrum master role. I obliged, and at the top of my head wrote the following:

A scrum master is someone who –

• has great written and verbal communication skills
• understands the software development process, has experience working with product managers and programmers; preferably with customers too
• well-versed in the practice of software testing, enjoys exploring systems, thinking in various perspectives, and putting on different sorts of hats
• delights in shouldering a support role to the software development team
• is a self-starter, regularly updates himself/herself on what’s happening in the software development and testing industry
• someone who takes pleasure in a bit of scripting / programming is a plus (Webdriver, Watir, Cypress)

It’s not an extensive list, and I may have gotten some of the details wrong about what skills scrum masters are supposed to have based on the ideal definitions that’s out there in the web, but it’s alright. These are just the things I initially thought would suffice, in the context of what I and my team does and experience most days. Our testers are scrum masters too, and I’m proud that so far we’ve been able to make stuff work on our end.

Scrum masters in other places probably need a dissimilar set of requirements, because those are what allows their systems and processes to be effective, and that’s just fine.