Endorsement

One on one

A couple of days ago I was in one of those meetings with my manager where we discuss one on one how things are going and we if we have questions or problems in which we can help each other. Since things are going well enough we mostly spent time talking about work in general, project progress and personal interests. At the end of this particular meeting my manager asked me a surprising question:

“Why do you call yourself a senior test analyst?”

I fell silent for a moment. Officially my job title states Test Analyst C so he had a point there. My response held several aspects. First of all my official job title doesn’t have any meaning outside of the office and I am often meeting or interviewing people from outside of work. So I feel more comfortable calling my self senior test analyst then.

“Okay, I understand the test analyst part, but why senior” he responded

Well, I stated, because I believe that I am senior based both on my amount of experience,  skill and the effort I put in to my work. And using this title makes it easy to recognize what I do and at which level I am.

“I see” he said “But don’t you think that others can see that you are senior based on what you say and what you do and mean to our community and to the test community in general?” “Nobody calls themselves junior or medior. I only see people using senior. So why don’t you think about why you use it and if you really need it.”

Does it matter?

Well he got me thinking. Last year I published a series of three posts, https://arborosa.org/2011/08/17/whats-in-a-name-part-3/, on using names and titles. Part of the message in these posts is that the title you carry influences how others perceive your work, but also that it influences how you perceive and execute your work yourself. I ended the last post with the following remark:

“Currently I like to think of myself as a, context driven, software testing craftsman. At what level of craftsmanship I am I leave for others to judge.” 

Even my personal business card states me to be “Software Tester”. So why did I start using Senior Test Analyst when I talk about myself?

Having thought about it has me come to the following. It is not that I feel under-appreciated at work (although I wouldn’t mind a pay rise;) nor that I feel the need to emphasize my level of ability or knowledge. It is more my perception of how non testers value the profession. And for some reason adding the senior in front of test analyst seems to add some level of authority and importance.

How about you?

It is my opinion that I am not the only one who feels that (good) testers, by what ever name they go, do not get the appreciation they deserve. So my question to you is:

What do you do to convince non testers of the importance, skill and effort that go into your job? Or do you think that it’s all their problem?

 

250 hours of testing practice

The promise

On January 3, 2011 Phil Kirkham posted a question on the Software testing club:

“so if you were to set a target of doing 2 hours practice a week every week this year, how would you spend your 100 hours ?”

Having missed the post initially I read the post as early as the week before Christmas. So I really had not enough time left to get to 100 hours in 2011. After reading the post and comments I felt however that Phil was making a valid point. One should spent time and effort on practicing and in my comment on his post I made the following promise:

“As 2012 is on the brink of starting I will try to put this into practice. As two hours seems a bit low I will spent 5 hours per week on practicing and some extra time on logging and writing short (monthly) posts about it.”

2012

So today is January 1st and I am starting to live up to my promise. Every week of this year, except for the summer holidays, I will try to practice for at least 5 hours and log the things I do. At the end of every month I will write a post sharing my activities, providing short reviews and formulate my insights.

I have started practicing earlier today by reading “Essential Software Test Design” by Torbjörn Ryber. A book that I had downloaded as a PDF before and of which I found after a number of pages and comments from fellow DEWT’s that I wanted to have the hard copy. Later today I will make time to listen to TWiST # 76. I am not yet sure what I will do for the rest of the month, but as said before I will keep you posted.

For now I wish all of you a wonderful, succesful and entertaining 2012 and I hope to meet lots of you in person this year!

What’s in a name – Part 2, I am a quality assurer

This second post on the use of titles for software testing focusses on software quality assurance. Quality assurance, or QA, as such is not exclusive to software development. QA is practised in almost every other industry like e.g. car manufacturing or medicine.

Quality Assurance

Quality Assurance in essence involves monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with according to those same standards and procedures. Quality assurance is often seen as an activity to be executed independent of its subject.

Principles

The following two principles are included in the aim of Quality Assurance:

  • Fit for purpose; the product should be suitable for its intended purpose
  • Right the first time; faults in the product should be eliminated

The guiding principle behind Quality Assurance is that quality is malleable. This is achieved by working hierarchically according to detailed plans, use accurate planning and control, rationalise processes, standardise and uniform. In this sense quality assurance is continuation of Frederick W. Taylor’s ideas of Scientific Management. In line with this all skill and knowledge is transferred into standard processes, procedures, rules and templates and thus removed from individual workers.

Software quality assurance

By and in large software quality assurance follows the same lines of thought as quality assurance.

This part of the model then represents the assurance paradigm.

Like in quality assurance a tester in software quality assurance seeks the use of rationalized processes, standards and uniformity. She prefers the use of specific standards and methodologies. IEEE, ISTQB and TMap are well know examples of this. These methods provide the tester with (seemingly) clear guidelines to follow and artifacts to use so that if used properly software testing itself should provide adequate information about the state of the product and its readiness for use.

There is however a distinct difference between software quality assurance and quality assurance . In contrast with quality assurance in the traditional sence software does not have something tangible to measure. This is partly overcome with the use of software related quality attributes. Quality attributes are used to help guide the focus of testing and consist of characteristics that are considered typical to software development.

SQA – testing

Software quality assurance has the advantage that it is an understandable and recognizable proposition. To testers the appeal is that it provides a uniform solution for “all” situations and the handbook approach can be followed from the get go. To managers the appeal is that the procedures are recognizable in relation to mainstream management ideas and in combination with a phased interpretation of software development and testing, e.g. the V-Model, it is highly useful for project planning.

Following the process and filling templates alone (even) software quality assurance admits does not produce tests. So software quality assurance has teamed up with software engineering in that it uses test design techniques to identify and describe tests. In turn software quality assurance has developed means to limit the scope of testing with using a combination of quality attributes and risk assessment to order and if necessary limit the amount of tests to be designed and/or executed.

Improvement

In practise the use of software quality assurance, together with test engineering, has admittedly helped to establish software testing as a craft of its own. It has put software testing on the map and in general software testing is seen as part of the development process. But the use of software quality assurance as such has been no guarantee in stopping the development of ‘bad’ software. With bad software I mean software that did not provide a solution for the problem it was intended for.

In response to this limit to success several lines of improvement have evolved. One of them is to quality assess the software quality assurance itself with the use of models like TMMi or Test Process Improvement. These might help to forge a smoother adherence to the standards, procedures and templates, but the emergence of better software seems to be more of a side effect then that is the result of these new models themselves.

A second response is to more stress that quality assurance of software is an independent activity performed in separate (QA) departments that kind of police software development. Although this helps to adhere to external regulations and audit rules it has little effect in the pursuit of building good software that solves the or is fit to be used for problem it is intended for.

These models, and others like them, have widened the gap between quality assurance through process and the act of testing software through skill. So much so that increasingly quality assurance and testing are considered as different activities that oppose each other. In my opinion we need both aspects of software development to do a good job. How we mix them however should depend on the context in which you apply them. But in whichever context the testing of software should have the purpose of delivering useful information about the product. To do this, in my opinion testing skills come first and then knowledge and use of standards or procedures follows to aid or enhance the act of delivering useful information.