Whenever there’s an issue in production that I can’t seem to replicate quickly in our development environment, the problem reminds me that I have not tested everything in our software, that there are gaps in the model I’m currently using to test our application. The mistakes I make in diagnosing a problem helps me improve but also tells me that I have not explored our systems enough, or that maybe I have forgotten something that should help me test, or that perhaps there are modules that have changed since I last visited them.
More importantly, such scenarios prompt me to remember that I literally can’t know or test everything, that I need help in these cases, and that is precisely why it takes a whole team always extending continuous effort to bring quality up to a point where customers love our app. That means everyone’s testing skills need to stack up, salespeople, testers, programmers, product owners, everyone.
What: Create executable specifications for an ongoing project sprint. Executable specifications are written examples of a business need that can be run anytime and acts as a source of truth for how applications behave. It is a living documentation of what our software does, and it helps us focus more on solving the unusual and noteworthy problems instead of wasting time with the ones that we know we shouldn’t have been worrying about.
- Join a software development team for one sprint duration.
- Discuss project tasks for that sprint with everyone.
- Ask about requirements examples and create executable specifications for those tasks as the application is being written.
- Refine the specifications when necessary.
- Continuously update the specifications until they pass.
- Keep the specifications running on a preferred schedule.
Why: To see if writing executable specifications alongside development is feasible during the duration of a sprint.
Limitations: Tester writes the executable specifications, programmers work as is.
- Writing executable specifications can be done during actual app development, provided that tester is experienced with the tools for implementing it and understands well why the need for such specifications.
- It is of course more beneficial if everyone in the team learn how executable specifications work and write/run the specifications, and why the need to implement it.
- It will take quite a long while before executable specifications becomes a norm in the existing software development process, if ever. This is a function of whether everyone believes that such specifications are actually useful in practice, and then building the skills and habit of including these specifications in the team’s definition of done.
It’s easy to learn something when you’re genuinely curious about it, no need to look for any other external motivation. On the other hand, it’s terribly difficult (often a waste of time) to teach something to someone who is not interested in the subject at that given point in time.
Software tester and programmer pairing in bug fixing or feature-writing situations is supposed to be a fun experience for both parties. Either of them getting frustrated at what they’re doing means something is blocking them from being able to perform well as a duo. Maybe they don’t know enough about the needs of the other person or how to fulfill those needs, maybe they don’t understand enough about the thing they’re building or how to build it in the first place.
If the people using the software have qualms regarding a feature update, maybe there happened to be a miscommunication between clients and developers about what feature the customers really want built. Solving that communication problem matters, maybe more than writing feature code quickly, definitely more than pointing fingers and blaming other people after the update’s been released.
Testing with deep understanding of why the application exists the way it is and how features actually work in both user interface and code helps us perform our testing more effectively, especially in situations with time constraints.
Pair testing happens more often than I initially thought it does, only not as explicit as how I imagine it happening.
For whatever you wish to be master of, it pays to have mentors, people you follow and respect and trust and provide feedback. If there aren’t any in your place of work, find them online.
The agile community at NewVoiceMedia recently wrote a book for Scrum Masters and for everyone who is looking to improve their knowledge about what scrum masters do. Their output during a hackathon, within 48 hours, the “So You Want To Be A Scrum Master?” ebook available at LeanPub, contains great ideas, stuff that I’ve learned through experience since I had the opportunity to become a scrum master myself, alongside being a software tester.
Some takeaways from the book:
- Maximise the time a team member spends doing what they love, and less thinking about how they should be doing it.
- Being a Scrum Master can sometimes come with the misconception that you are there to tell people what to do. That is definitely not the case. We’re not in the business of telling people what to do and when to do it and we’re not in charge of anyone.
- Make problems more visible before trying to point them out, and before offering a solution.
- Your job is to help team members stick to their commitment – we all find building new habits a difficult thing to do. You are protecting the team from themselves, from the tendency of human nature to pull each of us off the path we actually want to be on.
- To turn around a team, work with individuals in the team and listen to them.
- Always help. But only when your help is requested or when your offer of help is accepted.
- Not everyone who truly believes they are agile knows what it really means. They need battle scars of having tried lots of different things and lived through the consequences.
- Just because your label is Scrum Master you do not have to only follow the Scrum methodology to the letter. In fact, your job demands that you do not.
- Let the team fail.
- The end goal of a Scrum Master is to effectively make themselves redundant for their team.
Is there ever a specific software development process that works everytime, for all kinds of teams, on all sorts of development projects? If there is, how is it done? If we don’t know, do we need to create one or do we let each team decide and use what works for them?
Does it matter that teams are very productive as described by numbers and documentation, or should we focus on building team interaction and collaboration?
Do we write and test software for the sake of a manager’s approval?
Is it worthwhile that a team continues to use the latest trending process, or a comfortable legacy one, even when they know that the process has already failed them many times over?
Is it difficult to trust a team when you don’t know exactly what they’re doing but you understand that they deliver their best work every time?
Isn’t it a manager or a leader’s responsibility to believe that their team is capable of doing something great, to find and understand the needs of the team, and to help them in gaining those things? Isn’t it our job to guide them in becoming self-sufficient? Should they serve us, or should we serve them?
How does one appropriately evaluate team performance?
Does diligently performing estimation and daily stand-ups and writing user stories and going to meetings that take all day means we’re agile? Should we only continue to follow structured procedures that other people tell us to do or should we think about them deeply and see for ourselves whether they have merit on our team, experiment and decide on our own if they work?
Working (well-thought) software feels like magic when we use them, even when they do not magically build themselves out of nowhere.
To be a software tester means to see first-hand how software development actually happens, in real-time. They discover how programmers code what they can from concepts and (almost always) incomplete ideas, they catch themselves and their co-testers trying to cover all possible valuable test cases, they find user experience designers hampered down by client whims, and they learn how hard it is for product owners to figure out customer needs. Requests become examples that turn into a collection of links, copies, and buttons, which then grow into prototypes, then features, eventually complex products. The apps that we love in both mobile and desktop or in cars and toys gets built by people who enjoy creating digital stuff that help people do their work or have fun. Here, the software tester finds herself in the middle of an exciting adventure – on journeys to finding solutions to worthwhile problems. There are travels along the way – some smooth, some rough and bordering burnout, some really easy, others enormously difficult and sometimes doesn’t make much sense – and there are lots of stories that can be told. And always, the team tries to go forward on a sustainable pace even when there may be unforgiving deadlines, crappy customers, incorrect examples, heavy rains, failing servers, health problems, even personal irrational worries that’s just around the corner. There are ups and downs, and the software tester sees and knows that everyone in the team that’s actually building the feature from imagined descriptions is doing what’s possible in the moment, everything in their power to solve one problem at a time, day in day out, given the situation. There are successes and failures, and then working software goes live and becomes magic.
All because the people who made it together shared their magic.
The programmers are the usual suspects in a daily stand-up ritual. Each of them take turns talking about what they did yesterday, what they will be taking on today, and what problems or successes they’ve encountered. It is a must that their voices are heard clearly by the scrum master and the product owner, who are there to monitor the project’s progress, and their co-developers, who most need to be in sync with code changes.
I hope the team scrum master and tester are sharing the things they’ve been busy doing too; as far as I know, they work towards the same goal as the people who write the code. Maybe tasks are not yet ready to be tested, maybe the team is cruising well on the development iteration, still their thoughts and opinions are valued – about ongoing tasks, about current processes, about possible ways of moving the team forward as awesome as possible. Share tests scripts and important use cases, honestly tell the group where they’re at, ask clarifying questions whenever needed, show test results, suggest process changes that could deliver more fun and creativity, say thanks to everyone who’s been working hard.