Software Testing

Endorsement

/ Arborosa / 4 Comments

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?

 

A footnote on the future

/ Arborosa / 3 Comments

A while ago I wrote a post called ‘Is testing dead?‘ in which I reacted to Alberto Savoia’s and James Whittaker’s Test is dead paradigm. In short the paradigm stated that testing is changing and will move into two directions. Either it will move down to the developers or it will move up to the users. And at this time I still do not agree with the idea that the software testing craft will disappear. I do however agree that software testing is changing. And I see two characteristics, that are not often mentioned as such, driving the change.

Testing is not a goal in itself

and

Software development is a form of communication

This post will address the first characteristic. A following post will address the second characteristic.

Let me repeat the first characteristic “testing is not a goal in itself“. The reason I emphasize this is that to me it seems that a lot of discussion and activity surrounding software testing ignores the most obvious thing of all.

Testing software is one of many activities you do

while developing software

I imagine that reading this you may think “Yeah right, that’s indeed stating the obvious”.  But look again and note that there is something odd about this sentence if you consider the (still) dominant way to approach software testing. First of all I switched software testing to testing software. The reason I do this is because to me software testing refers to the craft, the skills, the ideas, the learning and the process of testing software. Whereas testing software refers to the actual act of bringing the craftsmanship, skills and ideas into action within a project and as part of a team. Secondly I believe that good software testing can only exist if executed in collaboration and alignment with the whole team and only if it is directed towards delivering a valuable solution to the stakeholder(s). With this I assign an equal value to all activities (architecture, coding, testing, managing, facilitating, etc.) during software development. I believe that all of these activities and their roles are needed to develop software and that they will only vary over time based on either contextual demands or limitations.

The above is in contrast with the still present ‘mainstream’ way of looking upon software testing. Software testing is often still seen as a separate activity performed independently by a (almost) isolated tester or test group. Even in agile software testers are often still seen as separate by the team. Or probably worse testers see themselves as having a separate responsibility to guarantee quality.

In addition most courses that involve software testing address software testing as if it were a stand alone activity. In this isolation they explain how to execute tests, how to make the testing process better or how to influence the other roles to follow testing principles.

In my opinion both testing education and testing practice should remove their blinkers and realize that testing software, even if it is an important activity, is only one of the activities in software development. Software testers have to learn to be team players. They have to learn to collaborate with all roles. The have to learn to integrate testing into the process of software development. They have to learn to do this while still advancing their craft and skills as a software tester. Because even if integrated software testing still is a specialism. It just is not a specialism for its own sake it is a specialism within a team and in service of delivering a valuable product.

The second post in this series will go into how I think testers should do this.

Being challenged by James M. Bach

/ Arborosa / 9 Comments

On March 31st I joined Huib Schoots and Pascal Dufour in picking up James Bach from Schiphol Airport and driving him to his hotel in Dordrecht. Having met Cem Kaner (briefly) and Michael Bolton (several times) I was looking forward to meeting James in person and I was not disappointed. Conversation en route was vivid and fruitfull  and continued during dinner at Villa Augustus and later on April 3rd after an Agile Meetup with presentation by James at Codecentric. During dinner James had offered Pascal a challenge and later that evening he offered me the following challenge on twitter:

Explain dendogram-based testing

My first thought was “What’s a dendogram?” So I googled it and saw something I had long forgotten from when I studied Social Sciences and certainly had never used in testing.

So for those of you who requested me to blog on testing and the social sciences this is my first post on the subject.

For all the others with this post I want to share my answer to the challenge with you and some of the reactions I got from James on it.

What is dendogram-based testing?

To answer this question I will start with a short description of what I understand a dendogram is. Followed with a description of how I think this could be used in testing.

Dendogram

A dendogram is a visual representation of data that shows hierarchical clusters of, potentially before unknown, groups of data in a cluster tree diagram. A picture of such a diagram is shown below.

Cluster analysis, for a dendogram, starts with a data matrix, where objects are rows and observations are columns. From this beginning, a table is constructed where objects are both rows and columns and the numbers in the table are measures of similarity or differences between the two observations.

  X1 X2 X3
O1      
O2      
O3      

 From measurements to relative observation results 

  O1 O2 O3
O1      
O2      
O3      

 You can then place the results in a cloud of n points or in a matrix and put each point in a class of its own (having n classes, each containing a single point). Then, look for the closest two classes (for a given distance, for instance the relative distance between measurement of a feature– but other distances will give other results, perhaps more appropriate for some data sets) and join them into a new class. You now have n-1 classes, all but one containing a single element. Then iterate this activity until you reach a single set containing al the classes. The result is presented as a dendogram: the leaves are the initial 1-element classes and the various “levels”) of the dendogram are various clustering’s of the data, into a decreasing number of classes.

It is also possible to calculate the distances and their relationships with the use of Euclidian algebra. This uses a number of formulas to calculate hierarchical distance between the data (clusters). But besides the relative complexity of the calculation I prefer to use the more visual and intuitive approach.

Dendogram-Based Testing

The concept of clustering  data in a hierarchical form and thus grouping it based on some measured characteristic opens a number of possibilities for testing. All of these possibilities have in common that both the activity of clustering of data and the end result, be it in numbers or a visual representation, form an additional source of information about the subject under test. The kind of information will largely differ based on the chosen measurement. With regard to testing I see the following, extendable list of areas for observation and measurement:

  • The relationship between functionality and code

Where code is differentiated into several elements such as (that are more or less commonly used):

  • Type of input
  • Used variables
  • Classes
  • Functions
  • Methods
  • Etc.
  • The relationship between test cases and code
  • The relationship between functionality and GUI elements
  • The relationship between defects and code
  • The relationship between defects and their cause of failure

The clusters of information that you get out of it provide the following information and activities for testing:

  • The different clusters of information can suggest different testing techniques
  • The different clusters of information can suggest different testing missions
  • The different clusters of information can suggest different elements of reporting

In essence the information derived from a dendogram is dependent from the kind of observation and measurement you choose, the skill you have in identifying the clusters and patterns and the skill to adapt your testing activities. In any case it forms a new oracle to be used in software testing.

The above description was made before I read the following document, that I had avoided on purpose:  http://melindaminch.com/docs/thesis.pdf

In my, opinion the thesis is a nice academic exercise that adds insight to testing, but lacks sufficient practicality for use in every day testing. But I will study it more carefully at sometime in the future and I will see if there is an opportunity to use HCE 3.0 that I have downloaded.

For now I prefer the more general intuitive approach as described above and instead of the more elaborate HCE program I would use a reverse mind map.

Giving me the below, originally not in my answer included, graphical steps:

Which translates into the following Dendogram

James response to my answer

Below I have pasted the, unedited, response James gave my to my answer.

Jean-Paul, I am impressed. This is an excellent answer. I concur with your reasoning. I’d like to try using dendograms in testing, when the opportunity arises.

The reason I gave you this challenge is that we who aspire to excellence must be comfortable describing test techniques that don’t yet exist– in other words, we must be confident in our ability to invent test techniques as needed. This is a challenge that cannot be solved well using Google, since almost nobody has applied dendograms to testing, and the one reference you cite does a poor job of it.

By researching this and replying as you did, you have marked yourself as a leader in the Context-Driven community. Thank you.

— James

Needless to say that I am proud to receive such a response. And I feel strengthened in my drive to grow and learn as tester and as a member of the context-driven community.