Half a day to do what’s right

 

This posts describes how half a day for me went and what lessons I have learned and used for them. These items are recurring and should not be taken as a silver bullet to become more effective, people work in different ways. The goal is to show a set of practices to certain circumstances at hand to achieve better testing.

9.00 - What can I do to make everything else easier for the day?

When I get into work, I have a habit of setting my goals and objectives after getting a cup of green of tea, and saying the usual morning pleasantries with my colleagues. I set my goals and objectives.

Mark Twain:

The secret of getting ahead is getting started. The secret to getting started is breaking your complex overwhelming tasks into small manageable tasks and then starting on the first one

How do you know what the first one should be?

Ask yourself - What is your goal? What do I have to do to achieve these goals?

Life is question. Answers come from questions, and how well you answer it is dependent on the quality of the question. Ask a good question, get a good answer. Ask the wrong question, you’re in for a bad day.

For this particular day, I have been given tickets to look at so I can aid the product manager in writing more effective user acceptance criteria and test plans. Now I ask myself - What am I doing? Why are we building this feature? Do we need this feature? Is there a workaround? - Once I have answered these questions I can now look at the specification at hand.

Implicit v Explicit Specifications

An explicit specification is a source of requirements information acknowledged by your stakeholders, it can come up in conversations such as “Yes, that’s the specification”, “That’s one of the requirements on the document”, “This is what we agreed upon”.

An implicit specification is a source of requirements information that is not acknowledged by your stakeholders, but it makes sense for that to be correct, it can come up in conversations with words along the lines of “That’s not in the spec, but it should work that way”, “That’s not part of the ticket but it should do it”, etc.

Looking for implicit specification is not difficult and can take many forms - email discussions, skype discussions, face-to-face discussions, company “house style”, browser compatibility, environment and many more. When the specification does not mention anything on this, add it to the document to make it clear for the developers what they need to do.

When it comes to testing this later on, if it violates an explicit specification, it is easy to report it by saying “It violates spec #1, this needs to be fixed”. When an implicit specification is violated, it becomes a challenge to get it fixed. Go to this post on how to get your bug report fixed.

9.30 - Standup

Imagine you have a goal, to achieve these goals what do you need to do? You set objectives. Although we try to account for multiple scenarios that might come our way, it is impossible to think that there will be no trouble ahead. The tester finds information along the journey from inception of an idea to the release of a project so that the team is able to make better decisions.

You are mid way through your project, you found a few bugs. As the tester, it is your responsibility to let the team know what is going on. It could be that what you have said will affect the decision of the management.

In the standup, you will confirm that what you are doing is the highest priority task. One constant blessing while working in a startup is having so much work to do. You will never have a moment when you tell yourself “What am I meant to do?” In this post, I talked about listing down the items that you have to do and base them with your current goal. In a startup, priorities shift left and right and now it is important that you are only doing the most important stuff. If you do unimportant things, a deadline for a project may have been missed. In a startup, it is vital to only do what is priority as a missed deadline can cause lost leads.

Understand, what you do is informing your stakeholders about anything that threatens the value of the product according to your definition(s) of value. If you can show that the product falls below this certain value, you report your concerns to them. Another important thing to note, is that as the tester, you light the way. Testing is done to find information and the information you find is useful to aid in business decision making. Yesterday, I found a major bug in one of the releases and it requires abit more work for the developer - testing is now halted and I have time to review the deferred bugs from the previous release and then create test scripts.

9.45 - 12.45 - Time Blocking your work

Productivity isn’t about being a workhorse, keeping busy or burning midnight oil… It;s more about priorities, planning and fiercely protecting your time

Productive action transforms lives.  If everyone has the same amount of time and yet some do more than others. Productive people get more done and achieve better results. They do so because they devote maximum time to being productive on their top goal - They time block their goal.

Most people think there's never enough time to be successful, but there is when you block it. Time blocking ensures you get shit done.

If you concentrate all your thoughts into doing one thing, you will achieve extraordinary results

Build a bunker - Before you build your bunker, tell the people most likely to contact you when you will be available and to only contact you if it is absolutely critical- people are accommodating. Find somewhere to work that takes you out of the path of disruption and interruption. Sometimes there are free rooms, I go inside it and close the door.

Don’t let deferred bugs disappear into the abyss

Deferred means that the bug that you reported is real, but it’s not going to be fixed in this release 🙁 and never really becomes an issue until someone from the wider business team or a client finds it. Products that pass through many releases pick up a collection of annoying bug reports that will never see the light of development time.  Schedule a review with management at the start of the sprint (less constraints, more happiness) , and advocate for the bug to be fixed using this post. My favourite is getting a wider business team stakeholder to fight for the bug to be fixed in the sprint.

It is important to know that despite trying so hard to become the most effective tester you can be. You won’t find all of the bugs. To find all of hem, you’d have to look everywhere  and have a standard as to what counts as a bug or not. The purpose of time blocking is that you spend your time, knowing and accepting that you can’t do everything.

12.45 - 12.50  Time Blocking your time off

Extraordinary people start their year by taking time out to plan their time off. They know they’ll need it and they know they’ll be able to afford it. The most successful see themselves as working between vacations. By planning your time off in advance, you are, in effect, managing your work time around your downtime instead of the other way around. You are also letting everyone else know well in advance when you’ll be out so they can plan accordingly. If you want to be successful, book your holidays now and take regular breaks.

Take time off. Block out long weekends and long vacations, then take them. Ever notice that after a few days off you get back to work refreshed? Everything needs rest to function better and you’re no different.

Resting is as important as working.

So you don’t currently have day off? Work in Bursts

When you are testing a complex product and a wild feature set, do it in bursts. The human mind has the ability to manage and adapt to complexity, but it can’t do it all at once.

What you can do is to do your work in bursts. What I do is get a timer, set the time to 40 minutes (you can do more, you can do less). In this allotted time, you will focus on work. Once the timer has finished, stand up, get water, and take a walk for around 5-10 minutes. Don’t worry about being unproductive for this time, you’ll thank yourself later.

When I started working in bursts, I began to see patterns and outlines. I thought about design patterns on how to make my testing more effective. Overtime, I managed to design a comprehensive test plan outline to account for certain types of releases.

Happy Testing!

 

One Comment

Leave a Reply

Your email address will not be published. Required fields are marked *