Best practices

Do you believe in "best practices"? 

If you answered yes, here are a few questions for you. 

How do you know for sure that what you term as a "best practice" is indeed the best practice that has ever existed and will remain so for ever? Is there absolutely no scope for further improvement? - if there is, then how can the current practice be termed as a best practice? 

Just because some expert or standards body says so, does something become a best practice? Or, even if the majority follow a practice and call it the best, does it become the absolute best? How can you be so sure there isn't any possibility of improving on the so called best practice or even if there are alternate better practices? So, why do we have so called best practices when we know they really aren't? The point I am trying to make is not to stop following these "best practices", but rather to assimilate the finer points of so called best practices while remaining open to the possibilities of improving on these practices or even coming up with totally new practices which make the current "best practices" seem archaic in comparison ... a concept which is similar to a "permanent beta" ... always improving and seeking newer and better ways to do things ... not limited to testing or development or any particular function ... an all encompassing approach to being and doing. 

Advice from well-meaning relatives or friends ….

Quoting from a recent experience with a QA engineer in a different group, whose relative gave him some career advice based on her experience (or lack thereof).

The engineer is relatively new to the industry having left campus recently and still learning the ropes. He has been recruited to the QA team and is working on testing a significant area of a major product. There’s a lot to learn and the engineer is actually learning and enjoying working with this group. Now the relative, tries to offer this engineer some “good” career advice and suggests he consider a move to a Development role asap. She said that 1) it would be much harder to shift from QA to Dev after 2 – 3 years of experience in QA and 2) QA did not offer any future/career path. She also added a few more thoughts to reinforce these statements based on her "extensive" experience.

The novice engineer is now confused and begins to seriously consider following his relative’s suggestion. In any case she would know better since she has 6 years or so of work experience. That seems like a lot of experience in the eyes of a fresher.

I happened to meet this engineer and wasn't in the least bit surprised at the advice or the naiveté. This is a typical phenomenon  wherein well meaning relatives or friends provide advice that is factually incorrect. I personally know QA engineers with > 3 years experience who have moved to Developer roles with little extra effort. Of course, not every QA engineer can move to Development nor would the reverse be true too. There are skill and knowledge requirements that need to be met when moving across functions. And, in terms of career path I and several of my colleagues can attest to the fact that there is indeed some sort of career path in QA too. It isn't all bleak and hopeless as it is made out to be. The other point to note for the newer folks is that someone with 6 or 7 years of experience isn't really an epitome of knowledge. Believe me, I am now in my eighteenth year in the industry and I realize there’s so much more to learn and know. It is humbling and exciting at the same time. I know colleagues who have 30+ years of experience and realizing that there’s so much more to know. When I look back at my past when I was around 6 – 8 years of experience, I realize how little I actually knew then in comparison to where I am today. Of course, back then I thought I knew a lot more! I also realize that many years from now I would probably look at the current time frame and see how much I did not actually know now.  So, my dear fresh-to-the-industry colleagues, do listen to your relatives and friends and their well meaning advice. However, do some research of your own and be open to not following the herd. There is more than one way to succeed and you if are the philosophically inclined, more than one definition of success. 

Irrelevant testers

This is a tribute to the BBM (Black Box Manual) testers as they are called or rather a heads up to these soon to be extinct species ... get out of your (black) box, quick! Its no longer a world where exclusive specialization of the non-technical kind which the BBM tester represents is relevant. I have come across several of this kind who are happy to be executing their BBM tests. Well, some organizations do encourage them to continue their work ... well, all I can say is that none warned the dinosaurs or the many other species prior to their extinction.

If you do not know the tools and technologies used and are not comfortable with your product's operating (and preferably the development) environment, you are on the road to irrelevance. If you are happy in your cocoon creating and running BBM tests all day, congratulations! You have the dinosaurs and dodos for company. It does not take much to replace you. 

Exclusive full time BBM testers are generally worthless unless accompanied by adequate technical skills and a clear understanding of the technologies and tools plus a high degree of comfort with the development and operating environments. If they aren't already extinct, it is just a matter of time before this breed is declared useless. For example if you had to test a web application, how many organizations would prefer a pure BBM with little technical skills vs a tester who understands web technologies and can even do some basic debugging of issues. The more skill sets the better. The days of the exclusive black box tester are gone. The future needs folks who can comfortably cross the line between Development and Testing. We already see a good amount of convergence in skill sets and requirements across functions. Developers are required to do more and more tests. Many groups measure # of Dev found bugs vs QA found bugs and try to minimize the latter. Testing is moving upstream requiring very few "exclusive" testers. The specialist testers are expected to move beyond the obvious tests to more end-to-end tests, non-functional tests and areas that require a pretty good understanding of a wide range of technologies and tools.  

So, if you are a BBM and do not have sound technical skill sets, do yourself a favour and go acquire some. Else, wait to become irrelevant before you even realize it. The purists may argue that the BBMs come with a tester mind set that a Dev cannot have. Frankly, that is a load of BS. The reality is that the tester mindset isn't something that all testers are born with. When we hire from campuses we hire both Dev and QA from the same place and then put them into different roles. One group acquires a builder mindset and the other the tester mindset. In the convergence future, the builders are increasingly being asked to don the hat of the tester which is actually not an impossible task at all. Newer development models (think Agile/Scrum) require common teams where functional distinctions are blurred. Testers and Developers work together on building and testing work products and delivering them rapidly. The value of a non-technical BBM is usually less than what most folks think they have.

Agile Development & Testing

When adopting an agile approach to producing software, it is essential that folks from different functions come together to work as one team. Of prime importance is the coming together of the builders and breakers. Both developers and testers need to work closely together as one team to produce quality software. Development and testing go hand-in-hand rather than testing playing catch up with Development. This implies an incremental approach to testing work-in-progress artifacts as opposed to testing completed pieces. Build something-test it quickly-provide rapid feedback-incorporate feedback-build more-test some more ….

In such an approach too, it is easy to retain the functional distinctions in terms of assuming that testers do the testing and developers just code. To achieve greater quality, the emphasis must be on building in quality and prevention rather than just detection. Development is equally if not more responsible to build in quality and adopting quality practices that minimizes defects. Testers would partner with Development to quickly understand, test and provide feedback.

For Development to prioritize building in of quality, there needs to be shifts in the way customer reported issues are dealt with. When a customer reports an issue which wasn't found by internal testing, does the "blame" rest on the tester who did not find the issue or would you rather question the developer who built that piece of code with the defect? It isn't about blaming one or the other. Instead, the responsibility must lay with both. The developer whose code has the defect is as much responsible for the issue as the tester whose tests did not catch the issue. 

Also, there needs to be an organization wide emphasis on testing. When Development produces an artifact, there needs to be demonstrated evidence of tests having been run with "satisfactory" results. In fact, reporting of test results for any artifact being delivered by Development needs to be a requirement rather than something that is desirable or good to have. Effort/project estimates for producing software must include testing and time required to implement quality practices.