One-on-Ones

The past few years I managed in-office software testing knowledge-sharing and tools-tutoring sessions for junior testers at work. It’s not something fancy, sessions are minimal but somewhat regular, and my goal was only to pass on some of the interesting lessons I’ve come to believe to be true based on studying and experience. I want them to become curious about the industry they’re in and I want them to take ownership of their own growth as testers.

I’ve always done the sessions in a group since there are only a few of them. It’s easier to manage that way. But this year I’ll try working with each tester one on one. And this year I’m having them select a skill they think is something they need to learn more of instead of me just providing some agenda in the group meetings. Each tester will have a weekly one-hour one-on-one schedule with me, we’ll review what the tester understands about the topic of their choosing, we’ll study together, and then I’ll provide challenges for them to go through until the next one-on-one. It’s an engaging setup I haven’t done before, something that’s likely to eat more of my time and attention but something that warrants testing since the organization recently changed work schedules to working remotely about half of the time.

Advertisements

Testing Goals for 2018

I think that I have more or less accomplished my testing goals for this year. As expected there weren’t many changes at work; workload remained pretty much the same and I had enough free time to try the tools that I thought were interesting. I read most of the books on my reading list. I was able to get the testing team curious on API testing. I re-wrote the existing UI test suite to API-based tests because they’re faster, more readable, and easier to extend and maintain that way. I learned new skills – web application pentesting basics and a nifty test-driven software development workflow – that will be put to the test in the coming years.

What about 2018?

Hmm. Besides continued knowledge-sharing sessions and the practice of test-driven software development I don’t really have that many goals next year in terms of testing and development of software. I’m sure I’ll continue to take interesting online courses and be updated on what’s happening in the testing community but other than that I don’t know.

What I do know and what I believe I want to focus on more next year is taking better care of myself, outside of work. I’d like to get better at both preparing good food and exercising. I’d like to put my drawing skills to work once again. I’d like to take better care of friends and family. The skills I want to get better at now are not those that I can practice in front of a computer but on the field, both when alone and with other people.

I’ll have to try changing some of my existing ineffective habits and stories. It’s going to be a difficult 2018.

The Lessons I Learned This Year In Software Testing

It was only several years ago when I started writing Selenium tests, first with Selenium IDE, then in Java with Webdriver, then in Ruby with Watir. Now I don’t write a lot of Selenium tests anymore, ever since I found out that it is often better (faster and more stable) to write automated checks for application features through the API. Or through unit tests. Selenium has its place in checking user flows or automating the UI, but only if I have to, if its value exceeds that of its costs. There lies an important lesson in automation: there is not a single tool that does it all. It is us who decides which tool to use for a particular test, and it helps to understand if a tool fits the specific use case.

And I think I’ve familiarized myself with a number of tools this year: Postman for API testing, Winium for automating Windows applications, BackstopJS for open-source visual testing, Cloud9 for cloud-based software development, Phonegap for HTML-based mobile app development, Docker for building shareable self-contained images of applications for development or testing, PHP testing tools (PHPUnit, Guzzle, Behat), and source code linting tools like Rubocop for Ruby. I’m not a master of these tools, but I know enough to be able to decide whether I need them (or not) for a particular thing I want to achieve. They’re in my tool belt.

Needless to say, I have outgrown the hype of automation. It is programming and tooling at its core. It helps us perform repeatable tasks without breaking a sweat, not limited to testing apps, if done with care. It is not easy. It can be rewarding. It all starts with a deep understanding of what definite task or problem actually needs solving.

And this year’s experiences has lead me to better grasp the nuances of software development, which is actually a problem of people, of teams and their habits and biases. Our team certainly has its defaults, some of which are not helping us get better at what we do. And as such from here on I’d like to contribute in key areas I believe our programmers have not had much time to think about because of project deadlines and resource constraints – dockerized application environments and shift-left testing – solutions for providing testing feedback earlier in the software development cycle, which in turn can help us build better apps and release faster.

Questions I Ask When I Want To Contribute On An Existing Software Development Project

What is this project all about?

Can I set up the project locally? How? What are the dependencies?

How do I know if I installed the project properly on my machine?

How do I contribute? What is the existing team process?

Did I break anything after making changes to the code? Are there any tests I can run to make sure that the project is still stable? What sort of tests do we have?

Testing Early

There are various levels of testing in software. The one most people are familiar with (including software testers) is testing done through the user interface, which is basically using the application at the end of a software development cycle and finding out whether it does what it is supposed to do. It’s a practice that is easy to understand and natural to do. Most of us have mobile devices or computers at home and in that sense we all understand how to test apps on the UI at some basic level. We explore the functionalities apps say they deliver and we decide for ourselves whether we think those promises are being kept or not. We feel good when everything works well or we feel bad when it is difficult to use the app (and maybe never use that app again). That said, software testing is not limited to the user interface.

The more experienced testers understand that testing is easier to perform and more valuable when it is done early in the software development process, making sure that we are doing the right things and are doing things right, even though we know we can’t test everything all at once. Bugs found before shipping are cheaper and easier to solve than bugs found later. Quick and early feedback is ideal. But to accomplish testing early in the software development process means that testers actually need to understand how software is built from code, not just the code itself and how various pieces of code integrate with one another but how programmers write code too. Like everyone else, programmers are people and human and are fallible. People make mistakes, and people can continue to make mistakes even if they work on projects carefully, because that’s how people and the things they build grow. That’s why testing needs to happen as early as possible. That means testers working alongside programmers in putting systems in place that tests the application simultaneously while it is still being written, even when there is no user interface to see yet. That means recognizing where and when mistakes happen, whether in code or habits or processes, and making it easy to spot them when they happen again. Testing in the user interface will never disappear but we can do better than restricting ourselves to just testing at the end.

Pacing Ourselves Well

For any software tester or any software professional it matters to be curious about the industry we choose to be a part in, to be knowledgeable about the people we work with and the tools we use to perform our best work. It helps to be aware of existing practices and be in the loop with the news, well, because that’s how we find solutions to problems, and sometimes more problems to solve. We use the software we test. We find answers on the web. We try applications that could maybe make us be more productive. We network with people like us on the internet, and we go online, study, and digest whatever we can. That’s part of how we improve our skills. That’s part of how we grow, and help others along the way.

But learning takes time and effort and energy. It’s not just about reading and watching everything, taking every online course and going to every conference there is. Our minds does not work like that. We have to pace ourselves well. We need to take breaks in between, we need time for details to sink in, we need contemplation and scrutiny to guide us where to move next and why exactly. Some reflection happens in discussions with colleagues, family, and friends, while other realizations occur only when we are truly alone with ourselves.

Extending The Avenues Of Performing Testing

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.