How do I maintain work discipline during testing cycles?

Question

We work in team sprints - and after a couple of development sprints we have a testing sprint before implementing our changes into the production system. This is in addition to unit-tests and expectations that people have tested their code when they wrote it to make sure it works.

I have noticed that my productivity drops immensely during the testing sprint. Testing is always the least fun part of developing (for myself), and I have problems focusing on my work during this time which I don't have when developing.

While I'm looking to improve my own discipline, I'm also wondering how this might be handled from a supervisor's perspective.

What can I do to help improve my focus and discipline? If I were a supervisor with an employee that had this issue, how could I help him gain better discipline?

Answer 1

Since is my first answer I want to expand a little bit my comment.

What I've tried since a few weeks ago is setting my self objectives, and use techniques for time management. If you can schedule that it works pretty well. I use that when, for instance, I have to prepare an exam and I need to stay focused, and the subject of the exam is something I don't like or I don't enjoy.

Techniques like Pomodoro allow you to schedule your time, and have pauses to "refresh" your mind.

At least in my case I've found that having an objective allows me to stay focused. There are plenty of apps, mobile and web, that you can use to arrange the time you mantain, and your objectives may vary between each pomodoros, i.e., complete a specific number of tests.

When I complete the objectives I even enjoy doing something that before it was hard to do.

Answer 2

Can't say I like your process, but sometimes, it is what it is. Apparently they don't think they can afford real testers, so you have to go with what is.

Sometimes changing how you think about something can help change your motivation. Right now you possibly see this a chore that you gain nothing from except boredom. If you change your perspective, you can change your motivation.

Since you are testing the work of others, you are doing them and yourself a disservice by doing it poorly. It will look bad when they have bugs you should have caught make it into production. If you looking bad isn't enough of a motivator, maybe letting down your teammates is.

You can also look at it as a chance to really figure out how to write better code. Testing, honestly testing not just going through the motions, teaches you how users actually use things and what edge cases you need to be able to handle in your own future projects. It also gives you some insight into how other people's stuff works which is helpful when you are called on to make changes after Joe goes to another project or job.

And testing can be fun. Think of it as a battle between you the tester and the person who wrote the code. Will you emerge victorious with a string of bugs or will he, wily opponent that he is, emerge with the coveted title of bug free?

You can even gamify by trying to see how many bugs you can find in every testing sprint and try to get better scores.

Or you could follow the very good advice from @Gonzalo and use the Pomodoro technique.

Answer 3

I don't see this as a supervisor caused issue. It's really up to an individual to stay focused. A supervisor already has a normal procedure for this sort of situation and would likely deal with this by giving a bad review rather than trying to make it more 'fun'. It's a performance issue which could impact badly on you.

The good thing is you realise there is a problem, the bad thing is your expecting others to solve it for you. We all have to do jobs that we don't enjoy at some point or other, one of the marks of a professional is that he/she handles them all without losing focus.

You need to develop strategies to help you cope, just the same as everyone else.

Answer 4

Testing isn't about productivity but rather repetition

As a developer you're very conditioned to look at things from an output perspective. Testing really doesn't satisfy this. It's mundane and boring work - but that doesn't mean that you're not doing good work when feeling unmotivated.

The unfortunate reality of testing is that it is very repetitive. The joy in it has to come from breaking something, or finding a flaw - which happens rarely with good code.

Focusing during testing?

Write test cases. This sounds like it's adding extra work onto an already boring task but I find as a developer that I'm very achievement focused. If I have a series of test cases to work through then I feel that sense of accomplishment each time another one lands on the completed pile. Additionally having a record of the testing performed is important, and doing this is highly recommended.

Find the joy in bug hunting! Finding a flaw in yours or another developers code is a raw learning experience. I find it quite enjoyable taking an interesting bug to another developer and hunting down the cause together. You shouldn't find them often but when you do it can be a great learning experience that you start to seek out when testing.

Answer 5

You are simply more productive doing things you like.

If you have the option to change the process

Make it smarter and include more of what you do best.

You don't specify the kind of software you are developing, but most testing can and should be automated (for multiple reasons, such as it being a repetitive task, prone to human error, the ability to run functional tests as part of continuous integration and so on).

With regression tests having been automated, the task at hand will be to write new tests for new functionality introduced. This blends testing and development together. If tests are maintained properly and created in a reusable/modular approach, they will become easier to write with new functionality being introduced. In the longer term your team will need to put less time and effort into testing and productivity will increase overall.

If changing the process is not an option

Change your attitude.

Try changing your perspective and understand why testing is a very important part of development. You can try to develop the inner QA in yourself - identify where and why software may break. Many developers simply don't anticipate all possible or likely scenarios. They think of the straight case, where the user is doing the correct thing. Trying to break software, you'll learn how to identify common pitfalls. Then, when writing new code, you'll have these things in mind and your output will be better.

If possible, test features developed by your colleagues and let them test your code. We all tend to be more careful when testing something we created ourselves. This has another positive side - you'll always be on track who wrote what and how it's used. I've been in teams where team members were unaware what their colleagues, within the same team, were doing. With this level of awareness, it'd be easier to switch tasks or pick up a task from where a peer has left it. Also, testing something you didn't write just the week before will make work feel less repetitive.

Whether or not you can implement automated testing make sure you keep track of the different scenarios you execute. You should do this before even starting to write code - with writing the tests you may discover issues with the requirements given. In many cases the product owner would have not anticipated a given scenario, and you'll be able to clear the requirements with them, so you can eradicate the problem before it even appears.

Nice test case organization will ensure sufficient coverage. You'll be able to track progress, spread work between the members of your team and easily verify something has been tested. Finally, when you need to identify why a bug has made it to production, you'll be able to see where the reason was - whether you made an error during coding or maybe you didn't have this scenario tested.

Note: This is my first answer ever. If you have feedback on how to improve it, please go ahead!