To find out that the programmers in the team are seeking out product owners, stakeholders, and teammates on their own to ask clarifications and start meaningful discussions is a positive thing for me, to notice them initiate communication to whomever they need to talk to is always a major confidence booster about their ability to work on problems on their own. They never need my authority or permission to do what they think is best, they manage their own tasks, they own the responsibility to do the right thing as they see fit. I’m just there to help them perform the best work they can, in the form of suggestions and testing.
That’s why it’s bewildering to see someone get disappointed over a behavior that I deem to be on the plus side. Why would letting developers talk directly to stakeholders make you feel overstepped, if they think it supports better work? It seems to be, at least for me, a shallow use of a leadership position, a certain level of being clingy to power that’s not serving the team mission. It’s an upsetting, controlling reaction that I feel does not do any good.
Focus on empowering the team.
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?
BPI (Bank of the Philippine Islands) suffered some account balance inconsistencies on their online channels for a few days last week. This stirred widespread panic and disappointment in their services during that time, forcing their customers to go manual. Everything’s back to normal now, but it is undeniable that the banking organization was hurt by what had transpired.
- Banking software, and any software which deals with money and investments, are very sensitive, because people care a lot about their hard-earned cash. Such software need to be precise, secure, on schedule, resilient, and performant, probably much more than what other categories of software are expected to be. People will complain loudly if the software is slow, customers will be scared out of their wits if they are unable to log in on their accounts, and panic will ensure if suspicious transactions are found even if they’re only bugs.
- Software that’s stable today might not be tomorrow. Systems can break, sometimes for trivial reasons, and what’s important is what an organization and it’s people do when bad things happen.
- It might be a good idea to open accounts in other banks, to diversify.
Last week I told our technical writer, a music expert, a video games enthusiast, a good father to his young daughter, and a loving husband to his wife, that I could build him a small tool that could quickly update a master file of local translations, so he could focus his precious time on more important matters other than the job of laboriously cross-referencing and manually updating such a document. That was a passing comment while some of us were suddenly randomly discussing the process of how he was currently maintaining the file. However, the passing comment also felt like a pitch to a software development project that had some sort of value to a very specific customer, and an easy one at that. It was a fascinating experience; it makes you think about how caring for the well-being of someone is very much a part of building software of value, and that good software connects people for the better.
Let’s see how that tool works out this week.
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.
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.
If it feels difficult, exhausting, and inconvenient to update an existing test (or system) code, it may be that you don’t completely understand what the code does or it may be that the code really is written badly. Either way both situations present a learning opportunity: the former to fully grasp the business rules for the particular code you want to change, the latter to review the purpose of the code and to rewrite it in a way that’s helpful to the team.
Complaining doesn’t help; it only prolongs the agony. Care instead, discuss with the team to check if the change is actually necessary, and, if you think that it is, leave the code better than when you found it.