The Assimilated Tester...

What are the risks with being assimilated versus not? I would like to offer a different plane of thinking that is very much related to what you have both (Antony & James) stated and may in fact be different spins on the same concerns.

Assumption: “tester” = tester in the role of black box functional and/or regression testing.

I think the greatest risk of being assimilated is taking on the character, attitudes, and perspectives of the absorbing entity, in this case development. I am not certain that you intended my “assimilated” interpretation of your statement, Antony?? At any rate permit me to chase this thread of thinking with a list of additional risks.

Assimilated risks to non-developer tester, taken on by the absorbing entity:

1. The tester will feast upon the same source documents as the developers and lose specification accuracy-challenge vision that might not otherwise occur if independent. Example: The tester may accept as gospel the same documents the developers will design and develop to. I think the outcomes of this scenario are obvious.
2. The tester’s inputs to project estimates may be overlooked, either unintentionally or otherwise. While the head of the development organization may ask the tester for estimates, those estimates are likely to suffer more skew than if independent, since the development estimates tend to take on an aggressive skew to begin with, all in the name of being release-date driven – usually.
3. The tester is more susceptible to the negative aspects of fraternizing.
4. While many do not like to admit the following exists, I doubt that one can deny the following. There is a real competition between the camps – developers versus testers. The former attempt to not introduce them or discover them before the testers discover them. Healthy competition is proven to bear real fruit in terms of professional development. Being assimilated would tend to dampen if not eliminate that competition - silent or otherwise.
5. The tester’s voice loses strength when project post-mortems are conducted. The tester is less likely to be vocal or even recognized when it comes to sorting out issues and assigning process corrections to the responsible entity - testing or development.

I believe heterogeneity should be viewed both as ideal and as a privilege. As a privilege, I am less likely to develop any of the biases already discussed within this topic. I feel that testers owe self to be the best they can be today, better than yesterday and even better tomorrow. I believe testers personal processes should have checks and balances to detect and correct any biases or complacency.

I subscribe to Mr. Bach's philosophy:

My greater goal is always to help the company. And my specific mission can be different things.

[textile]I checked out "assimilation bias"... interesting, however, I couldn't see a direct connection to what I am talking about (other than the word). I'm suggesting the opposite... that we seek to be open to adjusting our schemas to fit the context, not the context to fit our schemas... i.e. "accommodation" not "assimilation". This results in assimilation of the people, not the context into the people's existing schemas. For assimilation of the people to occur, accommodation of a new context (increased collaboration) is required. Somewhat paradoxical, I know. That aside, here is what I mean by 'assimilation' in regards to an "Assimilated Tester"... This definition captures it quite nicely... "the state of being assimilated; people of different backgrounds come to see themselves as part of a larger national family" ("see search results":http://www.google.co.uk/search?hl=en&client=firefox-a&rls=org.mozilla:en-GB:official&hs=1O4&defl=en&q=define:assimilation&sa=X&oi=glossary_definition&ct=title) That 'national family' is the project community/team. In my experience, both confirmation and disconfirmation biases are rife...

...confirmation bias is a type of cognitive bias toward confirmation of the hypothesis under study. en.wikipedia.org/wiki/Confirmation_bias

Disconfirmation bias refers to the tendency for people to extend critical scrutiny to information which contradicts their prior beliefs and accept uncritically information that is congruent with their prior beliefs. en.wikipedia.org/wiki/Disconfirmation_bias

My perception is that developers tend to test with a confirmation bias and testers with more of a disconfirmation bias. Disconfirmation, in this regard, is a problem when the prior belief is incorrect. I find when testing independently, I am more exposed to the risk that my prior belief is incorrect. I recently heard of one independent test-team that was raising bugs against behaviour that was correct and not raising bugs in areas that were incorrect. Their oracles (in this instance use-cases) were wrong. Developers and the client had communicated via other means and the requirements had moved on from the use-cases. These evolutions in requirements were reflected in the system faster than in the use cases. Testers had been unintentionally left out of these alternative communications. I've been in this situation as an independent tester before. Having learned the hard way, when I see this pattern, I always speak to the developers to find out why there is such a discrepancy between my oracles and their code. I then attempt to verify this with the client. This is an awful lot of unnecessary work that can be avoided by co-location and more so by mutual assimilation. Yes, the developers and the client should involve the testers but my experience as an independent tester is that they don't. So, co-location or even assimilation seems to solve a human failing - "out of sight, out of mind". The trick in an assimilated team is to make sure that you and the developers don't walk away with the same misunderstanding. I've found by increased involvement, I help to make sure that everyone has a common understanding of what's required by questioning the client and the developer during this process. This works especially well in a team using Acceptance Tests as their specification (as in extreme programming). James wrote:

But there is something important in your counterpoint. What you might call the "chicken little" or "cry wolf" effect is an important consideration. Too many alarms going off can desensitize us to all alarms. I don't think the better solution is to assimilate (in fact, there is something called assimilation bias you might want to check out) so much as it is to become more refined and skilled in our critiques.

Firstly, I'm not suggesting that we assimilate rather than become better skilled in our critiques. The two aren't mutually exclusive. I am saying that I have found that I can be more effective if I am part of a heterogeneous development team than if I am completely/mostly independent. I should still aim to be more refined and skilled in my critique (and one such solution I apply is to use tests to communicate variance of the system from my expectation). I am not sure I understand the point behind what you have described as the "cry wolf" effect. I think your observation of a good independent tester is the same as mine for an assimilated tester... it's just that we're trying two different approaches to living up to the same expectation. Regarding your experiences... I know you are talking from experience... I wouldn't suggest otherwise since one of the reasons I respect you is because that's what you tend to do... i.e. talk from experience. My point is that we have had different experiences. I know all about the Yahoo groups and a little about Brian's exit from the Context Driven School... I've had bad experiences on the mailing lists too, although mine was more on the testing oriented lists rather than 'agile'. On any of these lists, I find if you float an idea that doesn't conform to the collective mental-models (or schemas) of the group, one gets flamed... That's one reason I stay off them a lot of the time... although I do monitor them. Some people are on the groups to learn from each other. Some people are there to promote themselves. When someone comes along and challenges their ideas (or the ideas they subscribe to) things can get heated and passionate. Why? Is it fear? Is it self-preservation? Or is it just people with strong beliefs? I don't know. So, when I say we have had different experiences, I am referring to my experiences of the culture that grows within the teams I work in... Not in terms of debates on mailing lists among people who aren't all necessarily trying to achieve the same goals. I am talking about my very positive experiences of testers and developers working in harmony towards the same goal on Agile projects. Perhaps it's just me that has this effect ;-) however, I have a more humble belief. I believe that when good testers and good developers work closely as a tight knit team, conscious of their biases, there are many more opportunities gained than lost by no longer being so independent. -Antony

Antony said: "Indeed, how also do we tell the difference between the independent tester focussed purely on bug-hunting and just another negative thinker, in the thrall of disconfirmation bias?"

Antony, I'm not sure what your point is. Are you not aware that confirmation bias, unlike disconfirmation bias, is a pandemic in our craft, and far more dangerous? The Columbia and Challenger disasters, for instance, were not traced to the problem of people being too critical in their thinking, but rather too uncritical.

But there is something important in your counterpoint. What you might call the "chicken little" or "cry wolf" effect is an important consideration. Too many alarms going off can desensitize us to all alarms. I don't think the better solution is to assimilate (in fact, there is something called assimilation bias you might want to check out) so much as it is to become more refined and skilled in our critiques.

The way I tell the difference between a good independent tester and just another negative thinker is that a good independent tester serves the interests of his clients, rather than his own vanity. I can watch a tester and tell this difference.

-- James

P.S. YES, I am speaking from experience when I complain about agile projects that deny testing skills. Check the archives of the agile-testing forum on yahoogroups. Or talk to me about Brian Marick's noisy exit from the Context-Driven community based on his view of that testing should "only reluctantly" be about bug finding.

Our discussion opened my ayes. It really doesn’t matter that I’m writing unit tests and sometimes use source code to debug the real reason for a bug (supposed to be developer’s job). What matters that I’ve been team lead for more than 5 years and communicating primary with PM, architects, development leads - less with developers. So it appears I’m assimilated into a different IT social group :). I could now recall myself saying to a developer – this is out of MY (as a tester) scope – I don’t care (so I agree I’m not assimilated there). I also know that I sometimes hide info from developers (in order not to damage their morale or performance).
However I wanted to pint out by my examples (and it appears I succeeded): we have different stories, nevertheless we share to some degree the same feelings – at least I feel that my perception of my role is not what is typically described (It doesn’t even fit context-driven role). I’ve been practicing for years “to step outside of the boundaries of your remit as perceived by you “ and trying to see myself through ayes of PM and others and improve accordingly. I know other testers sometimes blame me for not being too much a QA person: giving up quality. More over I’m afraid we (me and those who are not assimilated as well as me and you, Antony-assimilated into different group) would even have hard time to agree on testing definition but It doesn’t mean we can’t learn from each other practices.

[textile]My previous comment reminded me of Brian Marick's paper "Methodoloy Work is Ontology Work [PDF]":http://www.testing.com/writings/methodology-and-ontology.pdf

People begin with an ontology-a theory of the world of software-and build tools, techniques, social relations, habits, arrangements of the physical world, and revised ontologies that all hang together.

Problems arise when we learn about the tools and techniques of a methodology but haven't adjusted our ontology. Until we adapt to the new concepts involved the social relations, habits and the like remain the same as how we may have worked before. This limits the effectiveness of the approach and can leave many thinking the methodology doesn't work. Although, in reality what may have happened is that the tools and techniques didn't work because their adoption wasn't accompanied by changes to how we perceive ourselves in the team adopting those new tools and techniques. Antony Marcano

[textile]I don't think you have quite understood what I mean Ainars, based on your comment.

I'm talking about more than just what you do. I'm talking about a "mode of being" (thanks to Antony Gorman for the inspiration for that, albeit in a conversation about something completely different). It's about your perception of your relationship to others involved in the delivery of software; your perception of your role; your perception of what others expect of you; and the actions you take and attitudes you adopt as a result. I am not a tester in a team of developers, I am a member of a heterogeneous development team and my specialisation is software testing... thus I am called a "Tester"... but it isn't just that...

It's hard to explain succinctly, especially since your examples don't relate to my ontology of a software development team, how the people relate to each other and thus how they work with each other.

Let's distinguish for a moment between roles and people, or at least roles. I am a person, who predominantly undertakes the role of 'tester' but that doesn't define who or what I am. That is a reflection of the area in which I specialise. When I am writing a test-framework, I undertake the role of 'developer'. That doesn't make me a developer, but I am at the least developing (or at least programming)... That doesn't mean I am doing a developers job, however. I am doing a job that needs to be done and in a given context it may be that I am the most appropriate one to do it... I am as much a part of that context and thus my individual combination of skills and competencies will affect the feasibility of me taking on any given task.

Roles and people are often confused with the person and their job title. A role is a persona that I can undertake as required. To me, a job-title is meaningless other than to communicate the role that my specialist skills allow me to most frequently undertake.

People often get assigned a job title associated with the role they predominantly fulfil, but that shouldn't constrain them to contribute in other ways that their skills and availability allow them to. I suppose, being independent as a practitioner and consultant, means I tend not to have a job description... thus, I am guided primarily by my goals and not by what a piece of paper says I should or should not be doing.
I don't think of it as doing a BA, MIS(What's a MIS?), PM's or developers duties. I think of it as me fulfilling a different role as the context deems necessary and my capabilities make feasible.

Perhaps you are moving in that direction, however, I sense that you are still working as a tester external to a development team, if not in terms of location, certainly in terms of how you perceive yourself and how others perceive you. With this comes a set of constraints in your own mind and the minds of others. That makes it hard for you to step outside of the boundaries of your remit as perceived by you and perceived by those you work with. Of course, I could be wrong. Just saying it how I see it.

Antony Marcano

I know what are you talking about but never blogged about it because I don't believe anyone who never felt this way would ever understand me unless I become the master-story-teller. This is I believe the same issue that James point out or at lest related.

The phenomena you described I include into definition of guru tester "doing much more than his position formally describes. For tester it may be doing part of BA, MIS, or even PM job duties (defect prioritization, even triaging ; risk management; development progress monitoring; etc.). "
In my case the phenomena manifests as me saying to my testers - "do not report this type of bugs" or "postpone reporting it to the next iteration (sprint, if or want SCRUM terminology). Also sometimes asking developer to do a new feature implementation before bug-fixing (even if it means postponing fix to next iteration).

[textile]Hi James, As always you provide a brief reply that generates so many more thoughts... Unfortunately, I can't respond quite as briefly. Perhaps because I want to share with you the detail of my thought process, or perhaps because I'm just not good at being brief :-) I really like the way you challenge me. It shows an alternative view to the readers and helps to keep the messages balanced. I have to say, however, my experiences seem to be so much more positive than yours... or are you playing devil's advocate to keep me (and the readers) honest, as the saying goes :-) Indeed, I am silent about many of the potential downfalls of this approach, however, I'm equally silent about the downfalls of centralised independent teams. Every approach has it's pros and cons of course and it is about selecting the approach that is most likely to deliver the most value in a given context. Hopefully, my post has helped give some people an alternative. The intent of my post was primarily to convey the concept. Not the pros and the cons but to try to communicate the fundamental difference between co-location and assimilation... I'm happy to elaborate on the pros and cons over time. I do think that each of the points you've made are well worth replying to in detail.

Is an assimilated tester still a tester?

Yes, the "Assimilated Tester" is still a tester and must retain that focus in their reading, study and contribution to the team! As soon as they stop these things, they are then just "Assimilated" and at that point become something else altogether. In a heterogeneous team, there should be a respect for each of the specialisations within the team such that each can retain their identity. London, where I've lived all my life, is a very cosmopolitan place. There are many cultures, sub-cultures, merged cultures and the like. It's one of the most diverse places I've ever visited. I love it! I've watched the city transform from one that was mostly intolerant of other cultures, to one that was mostly tolerant of other cultures, to one that is now (in my experience) mostly accepting of other cultures (well, apart from a few bad apples making the press recently). Through exposure and transparency I believe there is (among most) a respect placed on diversity and the value that such diversity adds socially and economically. This has also been my experience of being a member of a heterogeneous team. Joining a development team (that sees itself more as a developers' team) I am tolerated. Over time, through gaining "street cred":http://www.testingreflections.com/node/view/4945 (yet retaining my identity) I am accepted. What was once a developers' team is now a heterogeneous development team. A team with mutual respect across the disciplines; where testers and developers recognise the symbiosis between them; with a joint commitment to delivering working software of value. The (perceived) value of software is dictated by it's quality, timely delivery and cost.

Have you ever seen a tester working without support or training pulled into a development team and becoming a junior programmer who kind of dabbles in testing?

I haven't seen this personally. This is one of the potential pitfalls. It's important that if a company does cause its tester community to be "disintegrated in favor of programmer-dominated project communities" then the testers need to maintain their own community. For example, regular social get-togethers; study groups; mailing lists and show-and-tells across project communities. This shouldn't need the testers to be independent and centralised. "Disintegration" isn't what I'm talking about, however. Line/discipline/practice managers and project managers need not be the same. Ideally my people manager and project manager should not be the same person. For example, several organisations I've worked with have a "Line Manager" or "Discipline Head" who is not a project manager. It is their role to ensure that the personal development of the people and consistency of capabilities is maintained across one or more disciplines. Thus, they are the champion of that discipline within the organisation. I find that it is a reality that many development organisations (companies and departments) are generally programmer-dominated anyway. I think that this may be further encouraged by independent test teams. One of the pitfalls of a centralised independent test-team is that fewer people understand the value testers add, with reduced visibility across disciplines, and may reflect that in the funding available to that team. And so we end up with the problem of never having enough testers. This is a common problem (in my experience)! A while back, I worked with a team that had two (almost) assimilated testers. The developer-to-tester ratio was typical in my experience of a company like this (approx 3 to 1). Due to the assimilation of the testers (full inclusion in team meetings, retrospectives and daily stand-ups) the developers could see how the testers were overloaded. The developers complained for a while but then the team pulled together. The developers agreed to take on some of the work the testers were doing so that the testers weren't the bottleneck anymore. The testers performed tasks that made the best use of their skills. The developers tracked what time they spent on programming and what time they spent on what they considered to be testers' tasks. Management soon recognised that they hadn't balanced the team right, once they saw how much time developers were spending on what they considered to be testers' tasks.

My greater goal is always to help the company. And my specific mission can be different things.

Yes, however, my experience is that many testers are driven by finding bugs or trying to encourage excessive levels of quality.

But if no one is focusing on finding important bugs quickly, some important bugs will probably not be found very quickly, or at all, that would otherwise have been caught.

Why would what I have said mean that there wasn't a focus on finding important bugs quickly? I am sure that I haven't suggested that this wouldn't happen. It is very important that we spend the right amount of time on the right things... Let's say we are in a row boat that is leaking. If we spend all our time bailing, we never have any time to row. If we strike an appropriate balance of our time between fixing and bailing then eventually we will not have to bail so much and have more time to row. (Adapted from an analogy once shared with me by "Jason Gorman":http://parlezuml.com/blog/index.php) Being inside the team helps me to see opportunities for improvements that can help to reduce the amount of time I have to spend bailing. I also have a greater influence to get the team to capitalise on those opportunities. When I have to log bugs, that takes time. If I have to log lots of bugs that could reasonably be avoided, then that is less of my time spent on finding those that may not be avoided so easily. By spending some of my time on things that aren't strictly testing to help my team avoid some of the bugs that prove to be a distraction, I get to spend more of my time on finding important bugs more quickly. Do testers do anything else or is finding bugs the extent of a tester's existence? I think that many testers have resigned themselves to the fact that they are unlikely to be empowered to do any more than that. My experience is that I am empowered to do more than that as an assimilated tester.

How do you tell the difference between an assimilated tester and just another positive thinker in the thrall confirmation bias? How do you keep from becoming such a person? I think I know the answer to that question, but it's an important issue that your post is silent about.

Indeed, how also do we tell the difference between the independent tester focussed purely on bug-hunting and just another negative thinker, in the thrall of "disconfirmation bias":http://en.wikipedia.org/wiki/Disconfirmation_bias? :-) The impact of an independent tester experiencing a disconfirmation bias also carries a cost. Perhaps because of the reduced transfer of knowledge that happens when not assimilated, the tester's understanding of what the application should do may have become less accurate (this has happened to me). This can happen through information passed to the developers by the customer without involving the tester. They then over-scrutinising that area of the application but logging all sorts of acceptable behaviours as bugs. This is time spent away from scrutinising an area of the system that really isn't working correctly. Triaging those bugs consumes the time of others too. Worse still, perhaps they may miss bugs simply because they match the expected behaviour of the tester's misunderstanding. I always try to be self-aware as much as possible. I try to recognise when a bias is at play. Pairing also helps to flush out biases through having someone else questioning things as you test. Regular customer feedback and interaction also helps. So, yes, I was silent about many things. The intent was to share how I differentiate between co-location and assimilation. So, you asked how can we avoid becoming a "positive thinker in the thrall of confirmation bias". I am a positive thinker with a healthy amount of scepticism and prefer that to being a negative thinker. I do want to avoid being consumed by a confirmation bias. How probable this is, I believe, depends on the team, the process they are using and the tester. I try to be mindful of my biases by at least trying to understand biases and their effects. We all need to do that, regardless of independence, co-location or assimilation. It's important to be aware of the impact. I also use trusted colleagues to help keep me honest (there's that phrase again :-)

Antony, it is not snobbery that makes testers want to have some distance between themselves and the programmers.

James, snobbery hadn't even crossed my mind. I have re-read my post and I can't find anything in there that implies this. Is there a prejudice caused by a past experience or debate with someone else that caused you to infer this from what I am saying? For the record, in no way do I believe that snobbery is at play here. Were I to propose an emotional cause of any resistance to assimilation or even co-location, it would more likely be fear... or a feeling of having being disenfranchised, thus congregating with an affinity group.

The more tightly I am integrated into a team, the more my behavior will be determined by direct communication and negotiation with my teammates.

Indeed, influenced... perhaps not determined... but hopefully their behaviour will be influenced by yours too.

That's great-- unless my teammates have little knowledge of what I do for the team, and have a great incentive for me to stop doing it (they will be able to ship it in the naive belief that it works). This is really the case in most projects, and especially the Agile projects...

...In your experience? :-) I have seen this on lots of projects, however, less so with Agile projects.

...the Agile projects, where not only do programmers not study testing, they often appear (at least in print and in the forums) to believe that NOBODY should study testing.

This is where we have had fundamentally different experiences. You and many other software testing experts are referenced by agile sites and developer blogs worldwide. The developers I know who are also respected in the community do study testing as well as programming (although the emphasis is on programming). Developer-centric sites like "TestDriven.com":http://www.testdriven.com/modules/xoopsheadline/ are an example. Let's not forget developers who have been learning from people like you through your blog and your book, like "Darrell Norton":http://codebetter.com/blogs/darrell.norton/articles/50337.aspx (although let's ignore Darrell's remarks about best-practice-rants for now). So many developers I know and experienced in Agile development who recognise and respect testing and knowledgeable testers. Many developers I've worked with recognise that testing is too big a subject and learn enough to do what they need to. They then call on my expertise to fill in the gaps. Sometimes that's through me doing some testing or by pairing with them but often through asking for my advice & guidance. This happens far more fluidly in a heterogeneous team assimilating developers and testers. Antony Marcano

Have you ever seen a tester working without support or training pulled into a development team and becoming a junior programmer who kind of dabbles in testing? I have. The first time I saw it was when Apple Computer destroyed its testing community in 1988. The group was disbanded, the sub-groups were disbanded, and by the time I left in '91 I had no sense of any coherent intellectual social life among the scattered remnants. The testers who could program simply became programmers. The others became doormats, as far as I could tell. That's a generalization, of course, there very well may have been great teams out there. I just didn't know about them, and that's my point: the tester community had been disintegrated in favor of programmer-dominated project communities.

My greater goal is always to help the company. And my specific mission can be different things. But if no one is focusing on finding important bugs quickly, some important bugs will probably not be found very quickly, or at all, that would otherwise have been caught.

How do you tell the difference between an assimilated tester and just another positive thinker in the thrall confirmation bias? How do you keep from becoming such a person? I think I know the answer to that question, but it's an important issue that your post is silent about.

Antony, it is not snobbery that makes testers want to have some distance between themselves and the programmers. The more tightly I am integrated into a team, the more my behavior will be determined by direct communication and negotiation with my teammates. That's great-- unless my teammates have little knowledge of what I do for the team, and have a great incentive for me to stop doing it (they will be able to ship it in the naive belief that it works). This is really the case in most projects, and especially the Agile projects, where not only do programmers not study testing, they often appear (at least in print and in the forums) to believe that NOBODY should study testing.

-- James