“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.
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.
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.
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.
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.
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?
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?