Working Smart in Test - a simple approach to personal workflow
Working Smart in Test
A situation came up this week with two different testers in my team. They both asked about the approach they were taking to a problem. Both of them were doing a lot of testing and they were trying to decide on a depth-first or breadth first approach.
In the end they ended up taking different approaches to similar problems. However, both approaches minimized randomization.
Minimize context switches
A typical test cycle on a feature involves a lot of thing. At some point you generate test cases, run them and report results. In most cases you need to figure out the approach that will make you most productive. Designing one test case, running it, dissecting the results and then reporting that one result before moving on to the next one isn’t an ideal way to tackle testing. You will be switching applications and thought processes very frequently. These context switches are very expensive in terms of easy things like mouse miles and clicks. They are also very disruptive to your brains natural process. You are preventing yourself from developing a rhythm or identifying the big picture.
Group similar tasks
Henry Ford figured out that an assembly line boosts productivity for cars. A lot of the tasks we do in test can be assembly lined. For example, you need to create test cases in the test case repository.
You could take a depth first approach, where you complete an entire test case before you move on to the next. In most cases you can do better. For example, you might use a tool to input all the test cases titles in one shot. I have even used some hacked together scripts to generate test case titles for predicable parts of a project. Being able to upload hundreds of test case titles in a few seconds is really rewarding.
The important thing is to identify task groupings and try to get all the tasks at a certain level done as a group.
Do the easy stuff first
Once you start running the tests you might find out that some of the test cases aren’t easy to run or verify. You can easily get hung up trying to debug, diagnose or improve these trouble children. Don’t do it. You will be paying a time tax to context switch. If something breaks the pattern, kick it on to another pile and keep moving.
It’s much better to finish 80% of your test cases on Monday and then spend the rest of the week diving deep into the 20% that gave you trouble. Your boss has a much better idea of the health of the software. Your developers have bugs you already found to work on. Best of all, if you run out of time, you did a significant fraction of the work.
Bug investigations fall in the same bucket. It might be best to log a lot of bugs that don’t have all the information you ultimately want in the bug. It’s much better to log 20 bugs a day that are missing details than log one bug a day with all the possible details. Be sure to note in the bug that you plan to come back later and provide details, if that’s your plan. During a test pass you want to put emphasis on finding bugs. When the test pass is over you can shift to fixing bugs.
Whenever you run into problems, ask if you can safely postpone a deep dive in order to knock out the easy stuff. Many times you can do just that and it will save you a ton of time.
Another example of this is when you have people helping you out. Say you just hired a tester to help out in the area you are an expert. You could make them do everything you do and let them call or talk to you anytime they have issues. It’s a lot more productive to have them do everything they can do by themselves and make a list of all the questions or problems they have and deal with them all at once. This same trick works with your boss when he or she “pitches in” in your area.
Circle back for the hard stuff at the end.
Of course you don’t want to neglect the tricky problems. You do need to address them. Just don’t let them distract you and cause a lot of context switching through the entire endeavor. In fact, you will probably benefit from having a rhythm with the deep dives at the end as well.
Do it better
Everyone in test gets distracted by trivia at one time or another. If you pay attention to what you are doing, you can catch yourself “rat-holing” and get back on track. Things get hard. We get behind schedule. Sometimes “pulling it in” is just a matter of re-arranging the order of our work.