Sunday, 7 December 2014

On Being an "Impostor"...

I have always taken an interest in testing as an activity ever since I was given the testing role in my last job some years ago. I was the first dedicated tester the company had, and had to learn it from scratch without help for training. I managed to achieve good things in the role and set up some effective if crude processes although I did make some horrendous mistakes. l have spent time meeting other testers in industry meetups, read the blogs, followed the online discussions that interested me etc. However the more I read, the more I have realised how much I know about this area of IT- still very little. There is nothing like speaking to the highly skilled testers and studying more in the field to install a sense of humility and the idea that I have so much more to learn.

That isn't in itself a problem except that it does get me down that I haven't done or learnt more as a full-time tester, or that I still find it hard to think of myself as a "good" test analyst. I find every day something new to add to the pile of things to improve and learn. I like the challenge and stimulus but I seem to never catch up !. Is there a point in this industry when you can finally call yourself good or even adequate? Is it after X years of working or crossing off experience in enough strategies such as exploratory testing, static analysis, ATDD etc? After a good employment review, a good rep by a testing expert or an invitation to speak at a conference? After the nth ISTQB advanced/expert cert, maybe?

l recently came across the idea of the "Imposter" Syndrome, a common condition affecting high achievers where they cannot come to terms with and internalise their achievements and skills - thus believing themselves frauds and undeserving of their success. The term was coined for the first time back in 1978 and it is thought that up to 70% of all people will suffer from it at some point.

Left unchecked, this can have a damaging effect on one's career - Carol Pinchevsky in her article Impostor Syndrome in the Workplace—and a Few Ways to Overcome It describes them as follows -
"Charlie, who manages a team of developers, explained why he requested anonymity. “An implication that someone thinks of themself as incompetent or an impostor runs the risk causing other people to believe that as well. Needless to say, this can cause increased attention/lack of trust issues from bosses, increased friction with colleagues at the same level, and potentially morale issues from subordinates."
Noted Microsoft software engineer and blogger Scott Hanselman, in his blog post on the subject, describes his experiences affected by the Imposter Syndrome and states his mindset in overcoming it -
"The important thing is to recognize this: If you are reading this or any blog, writing a blog of your own, or working in IT, you are probably in the top 1% of the wealth in the world. It may not feel like it, but you are very fortunate and likely very skilled. There are a thousand reasons why you are where you are and your self-confidence and ability are just one factor. It's OK to feel like a phony sometimes. It's healthy if it's moves you forward."
While I don't imagine that a third party assessment of my skills and achievements would reveal me as a "high achieving" tester (whatever that means) I do find that I don't take as much pleasure in a job "well done", or a good review, or praise from a manager as I would like. Some months ago I went through a spell for a few months when I made sloppy errors and bad decisions in the workplace; where I felt that I could do nothing right. Instead of shrugging it off and thinking of ways of recovering quickly, I allowed myself to end up in a slump - for a short while under the impression that I had been "found out" as some awful tester and lead. For some weeks I went through the motions, fearful of making the next
 embarrassing error. Luckily, I was able to get out of the slump eventually with the help of one of my colleagues.

It is difficult, I find, to talk about issues of struggle or disappointment or failure (of confidence or otherwise) in the general company of other testers at conferences or testing events. Conversations at these events tend to be more about one's successes and advice than one's disappointments and concerns. It is equally hard discussing this with colleagues and managers, since being a test lead you are expected to be poised, confident and in control. There aren't many testing blog posts I come across where any sort of vulnerability is mentioned.

British journalist Oliver Burkeman mentions in his Guardian article on "imposterism" as he calls it that -

    "The only solution, many experts say, is for higher-ups to talk about their own insecurities much more. ("When people see those they respect struggling, or     admitting they didn't know everything when they started, it makes it easier to have realistic opinions of their own work," says the Ada Initiative, which     supports women in technology.)"

The inspiration for this blog came about a few years ago from a piece of advice from a notable testing expert who gave a talk in Sydney, and who out of respect shall remain nameless. After the talk I had a chat with him about his blog and expressed concern that if I wanted to write my own blog, I couldn't add much new to the body of testing knowledge. His advice, just writing about your thoughts and experience - the good and the bad - should be enough. Well here they are! Hopefully they may touch and relate with others who have felt the same in the past or feel the same now.

 Please let me know your thoughts...
I will be writing a follow up blog with my opinions and experiences about various approaches to combatting the Imposter Syndrome, bearing in mind that I do still have it to a degree. In the meantime, for further info on the Imposter Syndrome, the additional resources below could be useful -


Monday, 27 October 2014

ISO 29119 - Mutton dressed as Lamb...

There is little that has not already been said regarding the outcry by the testing industry against the impending implementation of the ISO/IEC 29919 standards for software testing - at the time of writing, 1182 signatures have been added  to the petition against it (and more added every day), legends in the industry such as James Bach and Cem Kaner have criticised it vehemently in a much better fashion than I could do. Nevertheless, I wish to add my two cents in support of the outcry over a standard that in my opinion offers little to the industry and could cause great damage to the work of testers.
In formulating my originally ambivalent views on the subject, I had the great pleasure of meeting and discussing the new standard with Henrik Andersson from the International Society for Software Testing. This is a testing association closely linked to the Context-Driven School, noted for their open letter to the ISO in protest over the implementation of the ISO 29119 standards. The letter eloquently put the idea of standardisation, the expertise and bias of the ISO panel and the voluntary nature of its implementation into question. It is well worth a read as a summary of the key points of contention.

If there is one point of concern I have, it is that I have no real idea what problem the standards are meant to solve. In my time in the industry, I have found that companies and (good) testing teams generally apply a selection of testing techniques and methodologies to their work in a way that achieves results for them. The idea of an off-the-shelf standard being applied to projects and life-cycles of different types, lengths, resources and requirements is extremely unlikely. It is also unlikely that the testing community as a whole will accept this.

It could easily be said that the standard is purely voluntary and testing teams would be allowed to pick and choose aspects of each standard that appeal to them and discard the rest, but if that was the case then the need for an overarching standard at all is essentially moot and adds nothing of value to the industry.

The IT industry, due to its immense variability and the wide range of products, stacks, methodologies, projects and technologies that make it up, does not fit easily to the idea of standardisation. While some areas such as Project Management have been partly amenable to methodologies such as Prince 2, others such as software development and database administration have not. It would be impossible to impose, voluntarily or coercively, a standard all developers and tech leads would agree to.

In software testing, the divergence of ideas and methods is, if anything, even greater and less amenable to reconciliation. Cem Kaner in his comment to the ISO 29119 petition made the point that we as an industry cannot even agree on what software testing is, or what its basic practices are. We have little hope on unity on its more specific approaches - especially in the enormous detail described in the five parts of the standard. Efforts to enforce standardisation from the top down could be seen to turn testing into a set of rote processes to tick off instead of an intelligent multi-part study and learning experience regarding the state, performance and suitability (among lots of other properties) of a piece of software or web application or system in a specific context. The only way to implement adherence to the standard everywhere would almost certainly be through either coercion or the sidelining of those who speak out against it.

So who in the testing industry supports the new standard? Presumably the ISO will state that the Context Driven School is a vocal minority and that the majority of so-called "Factory" testers will adhere to the new standard. Interestingly there is little reaction from testers in support of the ISO changes I have read online - certainly not compared to its detractors. I don't have the evidence to support this but I would not be surprised if the majority of non-CDT testers see the ISTQB mostly as an accreditation hurdle to jump through for resume padding and the ISO/IEEE standards as guidelines that they rote learn during the exam. They will then naturally implement whatever processes and techniques they deem necessary for the project they are on instead of keenly box-ticking the standard. That is hardly a groundswell of support.

My personal view is that since the ISO does not have the support of the entire testing body and can do nothing to coerce testers into implementing it, there is a good chance that the standards will be largely ignored by most of us and the ISO will be seen as irrelevent. This is unless the large testing consultancies use adherence to the standard as a form of marketing and force their consultants to use it in its entirety, regardless of the context, which would be disastrous.

Other points I have in protest against the standard, themselves iterated in previous comments, I have outlined below -
  • I feel such an overarching standard detracts from testers and test managers’ choice to decide on the best practice necessary in the context of their environments and projects, especially if it is deemed compulsory over time.
  • The sheer amount of setup and documentation required to adhere to the standard could shift a sizeable amount of the workload of testers from actual testing to writing enormous documentation that may be superfluous. This was also a notable criticism of IEEE-829.
  • If anything it could be suited to large waterfall SDLC projects but seems to be at odds with more modern agile development approaches which emphasize smaller, iterative test cycles that emphasise teamwork and man-to-man communication over process and rigid documentation. In this way, it seems dated - as if the ISO haven’t kept up with wider developments in the industry.
  • The testing community in general is not behind it and the consultation process seems to have been limited to a handful of contributors. Since no single body can be said to speak for all testers, this is inherently likely to lead to division and failure.
Such are my thoughts on the developing ISO 29119 standard. I would like to know your thoughts and would welcome your comments...