Is Agile software development good for a tester’s mental health? Depends, doesn’t it?
So, how can we keep software testing projects on track when the Developers are using Agile to create sprints?
What do we need to ask our developers?
Ask Dev to confirm THEIR understanding of UAT
It’s not enough to ask, ‘do you understand what’s expected of you as an Agile software developer and helping me with the user acceptance testing…’, instead ask them to explain back to you how they understand their task.
This highlights if there is a gap in their understanding, which you can clarify and avoid any future misunderstandings.
Agree the due date
Ensure that this is stated clearly and reminders are sent frequently.
Review progress frequently
Don’t wait until the end of the project to check progress reports. Instead, perform spot checks as frequently as possible. This ensures that minor deviations don’t become major ones.
So, what will make you miss your target date?
Watch out the following:
Shortcuts
New recruits who decide there is a simpler way to perform some task, or improve some process without understanding its impacts on other people, systems, and projects.
Alarm bells should go off when you hear someone new mention an ‘obvious shortcut.’ They probably have not thought it through.
Great ideas
New ideas to make something simpler, usually means that it makes things easier for one person but a nightmare for others.
Watch for powerful personalities who try to bully other team members into following their guidelines often using ‘must do this now or else…’ type tactics to frighten others into following their lead.
Innovation
Another variation on the great idea, innovation is when someone decides to change an existing process without telling others. ‘I didn’t think you needed to know,’ ‘Do I have to tell you everything’ and ‘I thought you wanted us to be innovative’ will all be thrown back at you.
Being innovative is often an excuse to avoid doing the work that needs to be done. It’s more interesting to do and, if positioned correctly by the innovator, can be hard to criticize.
Changing priorities
This can happen if other projects arise which have to be managed in parallel with the first project. Instead of completing the first project, they deviate and start on the second.
This often happens when boredom, fatigue, or burnout affect a team. Looks for these signs and find ways to balance their work load to avoid these issues undermining their productivity.
Over confidence
This often affects newer recruits who, due to lack of experience, may under-estimate the amount of work involved or be unaware of issues that lurk around the corner.
This colours their thinking as they assume the project will go forward smoothly without the interruptions, impediments, and conflicts you’ve seen in the past.
Gremlins
Obviously not a technical term, but allow for issues that may arise which significantly impact project delivery. For example, if you are working with a remote team, allow for bandwidth and access issues.
Your technical configuration may be very different than theirs. In addition, they may be facing technical impediments that you are unaware of, for example, access to software, releases, or testing tools.
Multiple Spreadsheets for Tracking
If you’re using a web-based system to track and record your progress, for example, in Excel on the intranet, there may be access issues.
For example, someone opens the Excel but doesn’t close it, so everyone else is locked out. In this case, people may start to make their own local copies with the intention of copying and pasting into the master copy.
In theory, this is fine. In reality, it will corrupt the data in the Excel.
What usually happens is that someone makes a change to the master Excel, say adding new rows. This changes the numbering in the Excel.
Another person comes in, turns some or all of the filters off, and paste into the Excel over-writing some of the data in the process. Of course, you may not notice this until you filter your own entries and see that the values have changed.
Known Unknowns in Software Testing
Expect the unexpected.
Give yourself some wiggle room so that if something occurs outside of the usual range of issues, for example, a severe storm closes down the office, that you have some lee-way in your project plan.