Handing over the project to maintenance

Finally the project is nearing the end and handovers are being planned, kick-out dinner is booked and the next project is being staffed up. But there are still some open defects, how can this be?

Shouldn't we deliver a complete software, there should not be any defects, or ?

As stated over and over testing can continue until the fingers bleed, and yet there will be new issues found or some issues might not have been solved. So how do you handle this ?

A good handover is the key, and as usual good communication. The receiving organization must be aware of the current status and if they can accept a delivery with open issues. Also there should be a plan for handling these open issues.

Usually some tool is used for tracking issues during development, QC, Jira or similar. But when it's handed over to maintenance, they might not use the same tool, or the issue handling process is completely different as the product is now in production.

Make sure the open defects are clearly described with steps to recreate.

Ensure that when handover is done that the receiving organization understands the issue and the possible impacts. Also make sure that they understand the issue, what seems obvious to you might not be for another person.

Good practice is also to do a follow up later to see how these issues have been handled. As it is easy to forget and if not fixed they will come back in one way or the other.

Emergency room

After spending an afternoon and evening in the hands of healthcare due to bike crash and resulting fracture in the arm, i started thinking on how this is similar to development and test.

The scenario.

I am biking home from work and colliding with a pedestrian resulting i a short flight and a stiff and throbbing arm.

Defect report was raised to “first line support” and providing scenario and symptoms. The initial investigation showed that it most likely was nothing serious and rest was prescribed.

So a minor defect and nothing that needed to be re-written or was a show stopper.

A few days later the arm still was not better so a new call to First-line was made and as the symptoms had changed slightly it was decided that a doctor should look at it.

The minor defect now re-appeared, and was re-opened, but in a slightly different way and a little different outcome.

Finally arrived at the doctors office and was meet by the nurses who made an initial investigation and decided that x-ray was needed. This was done and the images show to the doctor.

Investigating the defect to find the seriousness of it.

Quick meeting with the doctor confirms the fracture and a cast is needed

Product owner checks the defect and decides it needs to be fixed.

Once again meeting the nurses and getting a cast. Information on what to think about and how to handle the cast.

Defect fix information and a workaround provided by the developers. Final fix to be delivered in one to two weeks.

Conclusion

It is important to verify the defect, can it be recreated, and if so will it affect more than one area. A minor defect in one system might affect another part and then become a major.

So remember to test around the defect, as they tend to live in groups

Stop29119 - A Tempest in a Teapot ?

It has been a few months now since CAST 2014 which seems to have been the starting point for the “great ISO29119 debate”. But what has actually happened since then ?

• The Stop29119 petition was started and got over 1000 signatures and this was then presented to the ISO-group.
• Numerous blog posts have been written
• Mostly posts against the standard, but a few pro-ISO have appeared
• Debate on Twitter and other media
• Ranging from personal beef to factual discussions
• Local discussions appears to have happened
• Probably quite a few people have bought the standard (me included)
• No information if any company has actually started to implement this

But what now ?

• The debate seems to have abated and things have gone a bit silent.
• No response to the petition, at least to my knowledge
• We are still waiting for the two final chapters of the standard.
• Awaiting to see if any organization will pick this up or not

So was the whole debate a storm in a water glass?

Well in a way it was. Probably because only a small number of people did the open discussions.

In another way it was not. It brought the attention to the general community on what is going on and even if most stayed silent, many local discussions seem to have happened. And the information has been spreading.

Some discussions might have gotten a bit out of hand and might have lost focus, but thats normal when you really stand for something. Then again we are testers and discussing is what we do, and question how things are.

Looking forward to read the last chapters and also to see what will happen both within the community as well as within organizations in regards to the standard

Hiking Analogy

After doing a hike up a mountain in near white-out conditions it got me thinking that this is a good analogy for approaching a new system-under-test.

You know what it is supposed to look like, what the system should do.

Up ahead is the goal, the end product.

Right now you can only see 100 meters ahead, you see the current function.

You will encounter cliff face - defects or issues

Once at the top you’ll see the big picture can say you have a good view of the system

In order to really know the trail/system you need to do the hike several times in different conditions, it might be hard going but once done it is a rewarding feeling

(Hiking trail: Cairn Gorm and the northern corries)

Titles and definitions

In an earlier post i talked a little about my thoughts on test manager and test team lead.

There is a underlying discussion here that I would like bring up.

Why is it that the career path for testers is usually to move on to become TM or similar?

And how come a TM or TTL usually gets better pay?

As I stated in the last post: to me a TM or TTL is a tester with some additional responsibilities and tasks. This usually mean that less time is left to actual testing, ie the value to the company/organisation might be less than for the regular testers within the team.

To me the most valuable person is the tester and the TTL is there to enable them to do their job.

So why is it that TM seems to be the way forward rather than becoming THE expert tester ?

Development have had a similar issue a few years ago when the path was: developer to dev team lead to project manager. Not sure if this still applies today. One can become a brilliant developer and get the recognition for it.

So why is it not the same in test?

Test as a profession might be a bit younger and has really come into its own in the last couple of years, while dev has a few decades to do the same.

It also might have something to do with the title, put manager there and the paygrade jumps.

But as said above a great tester will provide more value to the organization.

Maybe there is a need to better define Tester in order to better see the difference between A tester and THE tester.

De-focus and Re-focus

We have probably all been there one time or another where the meeting or discussion takes a turn away from the agenda and end up somewhere else and everyone loses interest.

This is what seems to have happened with the current ISO29119 debate. It started with a petition to stop the standard but is currently a yelling battle between a few persons about the personal agendas and personal reason for either creating or stopping the standard. What happened to the discussions on the facts in the standard and how this will affect the testing trade?

Its time to get back on track and focus on the fact at hand:

• Is there any validity for the standard?
• Can the standard be adopted to a non-waterfall project?
• Is it really that document heavy?
• ….and so on.

Bring these types of questions to light and help people understand what the standard will do or not do, and take the discussion for there. hopefully this will be a discussion that the “quiet masses” will have an interest in.

Sure there is no denying that there is a monetary aspect to this as well, but show me something today that do not have this. And there is a personal aspect as well, but the main focus should still be on the standard itself.

Don't let this discussion end up being another example of Godwin’s law  

What's in a Title

I have had a few assignments where my role has been Test Manager or Test Team Lead. 

Common titles, but what has the actual job description been behind these titles ?

A common description is usually: Manage a team to ensure that quality is delivered.

But what does this really mean ?

My take is that as a TM or TTL you are responsible for the team and the testing you do. Yes I mean you, not them, as to me the TM or TTL should also be involved in the testing as much as the team. If you end up just attending meetings and setting policies or work processes your title should probably be Test Strategist or even Project manager. If you are to lead a team one must know what is being tested and how, and this means getting your hands dirty and run tests alongside the team. Doing this will get you the information needed to lead the team, make good decisions and hopefully feel confident when reporting the status to the project.

For me one of the most important roles as TM/TTL is to shield the team from unnecessary discussions, especially politics, and allow them to do the work that is needed and what they excel at. This might mean that it is on you to explain why the team is working in a certain way. Or act as a mediator between the team and the project management when questions arise.

One important factor to remember when changing from different teams and/or assignments is that no two teams are the same. What worked last time might not work here. Different project methodology, different system, different people and skills etc.

This is where communication comes in. Listen to the team, discuss the expectations, talk about the way forward and so on. But DO NOT forget to have a similar discussion with the organization as well. What you and the team decides must be communicated so that managements expectations are also met.  

So what should the job description be, or contain?

Simple: Mediator - consolidate the requests from management with the needs and wishes of the team

Simpler: Gatekeeper - protect the team and let them work in peace.

Simplest:Team Member

Final comment:

Titles should not define you, it's the work you do that defines you.