This is a guest post I wrote for Knowledge Tester blog – an excellent repository of insights into today’s knowledge tester world. The author, Majd is a close friend and ex-colleague. We both had the privilege to work together for a great group of knowledge workers. The article appeared here and I am reproducing it for Thinking Spirits audience.

In early days, life was simple. If you got sick, you would simply go to the ‘doctor’ who could treat your eyes, fix your stomach, amputate your leg and give you a diet plan. Specialization was unheard of. The patients, their diseases and expectations were simple. The medical knowledge was limited.

With time and progress, as man and his endeavors became complex, so did the medical profession. Specialists sprouted and the knowledge base expanded. The poor old doctor was replaced with hordes of specialists.

Software evolved in a similar way, albeit in a shorter span. Early software would be written by the engineer who could do everything from designing, coding, testing and deploying. There was neither need nor capacity for specialization. Time and progress, however, demanded specialization – the architect, programmer, usability designer, tester, deployment engineer and so forth. The process is recursive. In a tester’s world, automation, performance testing, penetration testing, usability testing and many others are becoming specializations of their own.

This progressive specializations has flourished – and complicated – the “Knowledge Testing” world.

With this background of evolution of testing specialization, here are my two cents (well, 8 to be exact) that I think every Knowledge Tester needs to know and do to survive and thrive in this knowledge-intensive world:

You are sometimes your own worst enemy The industry hasn’t yet completely caught up with the true role of a “Knowledge Tester” and stuck with the ‘Gatekeeper’ model – keeping testing as an end of line activity. What’s worse, the tester himself endorses that by vigorously defending his ‘boundaries’ and treating others (read developers) as outsiders “who don’t know how we work”. “Specialization of Labor” is  deliberately created in organizations to support its objectives. Everyone knowing their job better than other is how it is supposed to be. Key is for the specialists to work together – not against each other.

Focus Narrow, Think Broadly  It is essential to have specialization in your field. Equally important is to have the 20,000 feet picture. Understand how the different ‘specialists’ contribute together to achieve success. You need to know your piece and also how it fits in with others to solve the puzzle.

You are not the Gatekeeper  You may be the certifier but you are not the Gatekeeper of quality. Quality is everyone’s responsibility. The Gatekeeper mindset forces you – and others – to think narrowly, act passively and perform inadequately. You are part of the knowledge organization’s ‘core’ – not its periphery.

Stay Involved Your role demands you to be involved in the development lifecycle from the start. The involvement models may vary in various phases – from merely learning, observing, advising, demanding, harassing, screaming and executing – but you need to be always there. Contribute in project plans, observe the design discussion, evaluate the prototypes, start developing test cases early, review the user interface changes, raise the scalability concerns to the architect.

Communication skills matter  Your need to communicate effectively with multiple groups across various phases makes your communication skills critical for project’s success. It may be filing a defect report, creating a test plan, explaining the bug to a developer or raising a red flag at design time. This also requires talking in the language of the receiver – not your testing jargon. Communication is what the listener does.

Automation is your friend Automating what can be automated should be your mantra. You already have enough to do and there is no room for spending time on stuff that can be delegated to automation. Whether its an installation procedure, test plan execution, performance testing or report generation, you should always be hungry for removing less brainy and repetitive work from your bucket and focus on other stuff. Automation facilitates and helps you – its not for replacing you.

Dip in the other Ponds An effective way to learn the bigger picture is to occasionally dip in other specialist’s ponds – and let them dip in yours. Share developing and estimating a project plan with developer or let them work with you on brainstorming test cases. Everyone gets smarter for doing that. A knowledge organization is essentially a learning organization.

Read your way to the next level This is an area where I particularly find testing world lagging. Being a “Knowledge Tester” demands continually working with – and enhancing – your knowledge. Somehow this is not the norm for testers (the relatively low number of books published solely for testers is case in point). You need to be aggressively reading about your work – that’s the only way to get to the next level. Books are what add new dimensions to your learning.