Having received a handful of calls these past few weeks, I’ve realized that I’m thinking more about learning opportunities now than only looking at an offer’s compensation package. Salary still matters of course but there’s more to a day job than just allocating money for expenses and savings. Work wouldn’t be fun when there’s only menial work to do. What would I learn if I took an offer in exchange for my services? Will I be doing something I’ve never done or tried before? Is this work meaningful, both for our customers and for me as an individual?
And some more questions to recruiting employers on the top of my head:
- How does the existing software development and testing process work in the organization?
- Are testers embedded into software teams? Or do they work in silos, away from the developers?
- What does a software team look like and compose of?
- What does the day-to-day work look like for the software tester?
- How many testers are there currently in the organization? And what’s the existing ratio of developers to testers?
- What technologies do the organization currently use for testing? Are there automated checks? Is there an existing CI system?
- Does the organization use containers? Visual testing? Machine learning?
- Who are the organization’s actual clients? Which lives are we trying to improve on a daily basis?
- How do the software teams get feedback from the people who use their applications?
I have always thought of myself as a good listener. That’s what I believe to be particularly the reason why I have thrived working with both programmers and product owners, a software tester in the midst of all sorts of people. It’s a fundamental skill I have learned to be proficient in.
What’s not my strong suit at though is asking people for what I want or need. Of course asking for little things or asking probing/clarifying questions isn’t that difficult; what’s tough is inviting people to join you on a quest, asking friends to do something interesting together, or asking a fascinating lady out to lunch. It’s a fear which doesn’t get any easier even if I actually know the problem. And the solution is the same as with all skills: practice. It has been and always will be a struggle, so I need to continuously remind myself to be brave.
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?
2016 has been a surprising year. There’s been some considerable changes at work – people came and went, several small process changes for the good, and more transparency in automation which includes a dedicated testing server – many of which are for the better. There’s still some work to do though and those will spill over to the coming year, and most likely I’ll keep on adding valuable tests to the team’s daily running suite on the cloud.
Aside from that I hope to share what I’ve learned this year to the testing team, especially that bit about REST calls because that’s something they can actually use for testing any web application.
And I plan to read more next year. Or at least the following books: Specification by Example, Pride and Paradev, The Cartoon Tester, The Psychology of Software Testing, There’s Always a Duck, Rails 4 Test Prescriptions, Creating Great Teams, Explore It!, Willful Blindness, Tools of Titans, and The 4-Hour Workweek. Maybe I’ll slip in some fiction too in the reading list.
There’s some coding experiments I’d like to try as well:
- building a Ruby on Rails application
- Geb + Groovy + Spock automation framework
- Java + Serenity automation framework
Overall I don’t think there would be many changes from the things that I currently do, only continuous learning and refinement of existing workflow. But I can be wrong. We’ll see. 🙂
If I am to be asked to name female software testers who I look up to, I’ll probably say I can only name two so far: Lisa Crispin and Janet Gregory. Why them? Because of the many software testing lessons they’ve shared to the testing community through the books they’ve written, especially ‘More Agile Testing‘, which is a treasure trove. Some favorite excerpts:
About software testing:
- Testing expertise is a lot more valuable at the beginning of any project.
- Testers need T-shaped skills. To be effective on any given team, we need both deep and broad skill sets. Deep knowledge and extensive practice in a single field make sure that we bring something essential to the team. On the other hand, broad knowledge in areas other than our own specialty helps us collaborate with experts in other roles.
- Abilities such as communication, collaboration, facilitation, problem solving, and prioritization can be the most difficult to master, yet they are the most crucial for success in agile testing.
- The most useful thinking skill is to know how to help your team address its problems, rather than going in and fixing the symptoms. And you don’t have to be in a management position to provide leadership for your team and help them improve their problem-solving effectiveness.
- It’s possible to automate lots of tests and still fail to deliver what the customer really wants.
- Testing does not produce quality; it produces information about quality. At a high level, the outcome we want from testing is confidence in our decisions to release software changes. Better testing produces greater confidence in those decisions. Therefore, the valuable product of effective testing is confidence.
- Testing is more than just testing software. It is about testing ideas, helping business experts identify the most valuable features to develop next, finding a common understanding for each feature, preventing defects, and testing for business value.
About being a test manager:
- The role of a test manager extends beyond the scope of the day-to-day work of the agile team. Much of his work involves looking outside of the iteration activities and more at the cultural and strategic needs of the testing operation. A test manager can also be a type of coach for the communities of practice within an organization. The test manager is not there to prescribe but can facilitate learning sessions where interested parties can discuss new ideas. Management and Leadership is the ability to hire and inspire great people, to remove or overcome organizational constraints and impediments that hinder them from doing their best work, to see and exploit the opportunities for people to excel, and to motivate individuals to achieve what is best for the team.
About learning, and agile:
- Our real goal isn’t implementing agile; it’s delivering products our customers want. And when we start asking why the customers want the feature (the problem they are trying to solve), we’re more likely to build the right thing.
- In the software profession (as in many others), people seem to forget that it takes time to learn and practice a new skill.
- Learning is itself an agile process. Learning is not a big bang process: you know nothing, read a book, and two days later you’re an expert. Learning, like features, is something you do in iterations, adding a bit more knowledge at a time, and then building on it the next iteration. It’s not a race to the finish, and there is always something more to learn.
- Empathy is essential for providing good feedback.
- Changing an established culture is difficult.
The weeks of December are always great for looking back at the things that we did during the year. It’s also a good time for thinking ahead, about existing challenges we’re facing and about new roads we would like to try moving towards on.
For software testing, here’s a general list of what I hope to focus on in the coming year:
- Take one step back from test automation. Except for test maintenance, further refactoring sessions, and increasing test coverage of the regression test suite, I don’t think there’s much left to do. I like where the existing framework stands right now; it serves its purpose of providing testing feedback as quickly as it possibly can.
- Learn more about performance testing, security testing, and visual testing, branches of testing which I don’t have enough background of.
- Find other ways of helping the team besides test results, maybe keeping a reference library of testing mind maps and heuristics or more testing team skill sharing and mentoring sessions.
Lately I’ve been thinking about the software development process we have at work, the stuff that has been keeping us in shape for the past few years. It’s a system of smaller systems, which in turn makes up a flow – requirements gathering, sprint planning, sprint iteration and monitoring, demo and retrospectives, testing, project release. Good flow helps deliver quality service, bad flow makes it difficult to produce value.
I actually think we’re actually doing good so far on the flow. 🙂
Still, there are some areas in our current process where I believe we could be many times better in the near future, such as tasks estimation, business rules presentation and documentation, sprint data analysis, testing (especially unit testing), and continuous integration. It’ll take a while, of course. The challenge is for everyone in the team to keep seeking the possible small improvements we can easily implement, baby steps that makes our good flow better than ever. Delivering quality has always been a team effort, not a task reserved to testers (nor to any one person) alone.