What to Blog about?

I have been little confused for last few weeks. I seriously wanted to write something but was too much occupied with work and at the same time, I could not think as what I should write about? I am not sure if any of the bloggers whom I follow, face the same problem.

I wanted to participate in BlogSTAR competition of EuroSTAR conference this year but I could not make genuine progress on that front. And when the list of finalists was disclosed, my name did not figure out there. I understood that I didn't have enough credits, reputation or number of blog posts to prove myself a suitable contender for the coveted competition. No regrets as I got to know few more people in the software testing field. I do make a point to read all the posts on a daily basis and comment as and when I feel the need or something that intrigues me.   

I am running short of topics. So I asked my friends and colleagues who are somehow related to Software Industry as "What they would like to read about testing in next few weeks?". The answers I received were really encouraging. People don't want to know much about definitions, they want to know as how testing is adding value to the organization? (seems like a typical management question.). They want me to share, day to day challenges that I or my team faces in testing, products of different nature. So after getting some inputs, I prepared a list of things that I would like to talk about in coming weeks.

There was one interesting input that I received from a guy who just started his career in Software Testing field.  

He said, "Rahul, you asked me to read blog posts from Michael Bolton, Dr. Cem Kaner, James Bach etc, but I find it very difficult to understand as what they exactly meant." I was kind of confused as that guy has very good communication skills both written and verbal. I asked myself, "Did I ask too much from that guy to do that too when he is just 3 months into Software Testing?" I didn't know that answer. I went back to that little chap and asked, "What's there that you find difficult to understand?". He replied, "I found few terminologies and ideas difficult to understand, like Heuristics". I understood where he was coming from. I faced almost similar difficulties when I started reading these blogs 2 years back. He asked for my help on understanding the things  that are not directly about testing but the knowledge gained can be applied to testing "the passion we share".  

Lets see what I can do to help him. 

C Ya !!!

Rahul

Test Environment to Production Environment

Many a time, I faced a situation when application under test; was working fine in Test Environment but when it is released to Prod Environment (to real users), it goes down.  There have been many reasons as why it happened; functional as well as non-functional.  Following some frequent prod incidents in one of the areas of work that I am aware of, I posted a comment on my LinkedIn Profile. The responses to this comment lead me to write this post.

My comment was “To Save Production Environment......We need a better Test Environment, ideally a mirror image of Production Environment.” I think one of the ideas of having a Testing team; is to Save the Production Environment from any failure whether it is functional or non-functional. There may be many points to counter the above statement but let’s agree that organizations spend a huge sum of money to be rest assured that the application will not cause any trouble once it is tested and deployed to end users.

What are the probable causes of Prod incidents?

No application works on its own. There are always some downstream and upstream apps as well. The incidents that I had experienced were a result of one or more points as mentioned below.

1)      Two interdependent applications are being tested separately in different environments (for e.g. QA and UAT), both works fine but when deployed to prod, all hell break loose.

2)      QA environment may not have the similar data size as in prod environment leading to performance issues specially when there are jobs running & supplying data to another job.

3)      An Urgent requirement change is deployed to prod assuming it would not affect anything else and there is no need to test. The change was urgent because business was getting impacted. Now, after deployment the business is severely getting impacted because of an untested minor code change.

There can be many more reasons for failure of application in the prod environment. The last one is the most frequent one for me.

What I meant by asking for a better test environment?

Environment where all interdependent applications work the same way (in terms of data flow, data size) as they supposed to work in prod.

I have faced situations where an application was tested in test environment, no issues found in UAT environment but when the application was released in Prod, there were some serious issues. When the Root Cause Analysis was done; it was found that when application was tested in QA or UAT; it wasn't receiving data from one of the applications, so integration was never tested. But in prod; the application started receiving data and BOOM. The problem as I see it was the communication gap between teams involved. 

An environment where the dataset and user base are similar to that is supposed be there in Prod.

An application broke in Prod because the data files it used to receive in Test environment were of size few KBs but once in Prod it had to receive files of size of MBs and it couldn’t handle the load. Kedar Kulkarni, a friend whose expertise is in Performance Testing, would agree to this.

In general, a test environment is shared by many applications so timely availability to different teams becomes an issue. In such cases, environment management becomes an issue. And it’s an irony that people, who want their prod environment healthy, don’t pay enough attention to their test environment which can be disastrous.  

Can a better Test Environment Save the Prod Environment?

My friend Parthiban disagreed with my comment as mentioned in the beginning of the post.  His idea is to have a stable test environment and then mirror the same to prod. Initially I didn’t like or probably understood this thought. Let’s evaluate;

If we can have all the interdependent applications stabilized in the test environment in terms of data dependency, data flow and data size than yes we can mirror it to Prod. If we can remove the problem of communication which is generally a result of ego clashes, yes we can.

I would request readers to share their views on the same and let's learn from each other’s experiences.

Job Satisfaction

I read a book Outliers from Malcolm Gladwell. It talks about why some people are so accomplished and so extraordinary and so outside of ordinary experience that they are as puzzling to the rest of us as a cold day in August. Malcolm mentioned 3 factors that define Job Satisfaction for an Individual irrespective of the field s/he is working.
Autonomy: You get a role in deciding what you do every day. Even if you might not always get decide exactly what you do, you can choose how to get it done.

Complexity: It must be an intellectually stimulating challenge. As the book states, it should “engage both your mind and imagination.”

Connection between Effort and Reward: The harder you work, the greater your income or recognition (at least eventually).

I found the explanation quite good. So if I were to map my understandings of aforementioned terms in my area of work i.e. Software Testing; what I should consider?

I started my career in testing in the year 2006 and now it is 2010 so thought of base lining this write up on the same.

Year 2006

Number of defects found: In the beginning of my career, the more defects I raised, the more satisfied I was but it’s no longer the case. The Quantity has been replaced by Quality.

Automation: I thought that I should know automation and should be aware of various tools available for the same in the market. But I realized that if you don’t keep a regular touch with these ever changing tools and methods, you tend to forget it and you fall behind.

Domain Knowledge: Initially I spent hours/weeks/months to understand the business function of the applications under test, not all applications require domain knowledge but it is always good to know the basics.

Certifications: Ohh that’s a pain point for many. I did few certifications and believe that it helped me immensely in knowing terminologies and communicate freely with colleagues / clients.

The above mentioned points now have broader meanings.

Year 2010

Where the gaps are: I realized that issues in software aren’t intentional. No one actually wants to make a faulty system. But we still find issues. For example; issues may be a result of lack of communication or information flow. Now, I try to understand the bigger picture, I like to question why something is being done in that way and why not this way if I know what is this.

Learning: It’s a continuous process. Initially I used to think, “If I clear this Certification, I’ll become that etc.” But it’s not the case, with time passing by one need to continuously upgrade his/her skills. This is the only way to stay in demand is to improve on your skills. This is a hard learnt lesson and till date, it’s the most important one.

A new tool, a new scripting language, it can be anything. But the issue that I face is, if I don’t use technical learning I’ll forget the simple menu options of the tool. But if I find a relation of learning with my current project that learning become long lasting.

How can I contribute? I am not a Know It All guy but there is nothing wrong if I try my hands on an issue (may be silently) so that I may learn something. My limited technical skills do not allow me to contribute directly in fixing all the issue but I get some idea for example, how to install something on my machine? What can I do to reduce the on boarding time for a new joiner, how to make them productive ASAP without overburdening them. Is the QA team beside me planning to automate a set of their tests for an application if yes than is there a way to learn something if time permits? Taking this approach help me in revisiting things that I haven't used in long time, like setting something in Quality Center or QTP. 

Now, let’s back to three points above…..is there a relation?

Autonomy

I started believing that no one gives you autonomy, it has to be taken. One can get it by building trusts with stake holders, developers and fellow testers. Trust coupled with hard/smart work with motive to timely deliver a quality product; will definitely give the freedom to do something the way you know, is right.

Complexity

We may not start with complex tasks in a new field but if we can prove our mettle in handling relatively simple tasks, we can do wonders. I hope to shine, if not tomorrow than probably day after.

Connection between Effort and Reward

Rewards can come in many forms. Rewards are a result of continuous improvement in the assigned task or it can come because of excellent work done over a period of time. I am not worried about rewards as of now; my biggest concern is not to lose my passion for testing, learning, writing and reading. 

Test Managers

A Test Manager is a person who monitors deliverables, who bridges the gap of client and test engineers, who works as a motivator and mentor and one who decides your ratings at the end of year.  

This is a very generic definition I could think of which may be incomplete and readers may have different versions. In last 5 years, my friends and I worked with many people at different levels and here for simplicity, I would (on behalf of my friends as well) call, all of them “Managers” who have more experience than us. Here, experience means, they started their software testing career before we started. We find this definition of work experience incomplete (or wrong) though it is widely accepted across the industry.

They all were different in their approaches, few were so much involved so that we felt like a bird caged in a small compartment, and they were all followers of micro-level management style while few others were completely aloof. Then there were some, who allowed their test engineers a complete freedom with periodic review of deliverables, say once in a week / fortnight as the case may be. I really liked to work with the managers of this last category.

Why I liked third type of Managers?

These managers were the ones who discussed the problems without imposing so many solutions on their resources. They allowed their resources to explore different approaches, allowed them to disagree with anything and listen to their inputs whenever they had one. These Managers were not so obsessed with test case preparation because they understood one fact very clearly that “Its not the test cases that will unearth a number of issues, it’s the tester who will do the job.” They were not too much worried about metrics in the beginning for a new AUT but they recognized importance of data that will be available after one round of testing. These were the managers who allowed their resources to learn new technologies and also emphasized on implementing these learning in day to day work wherever applicable. These managers were open enough to share the client expectations clearly and communicate them freely without wasting any time.

It’s not just positives with third type of managers, its negative as well. I personally experienced that when one is really good with his/her work, they tend to become perfectionist and that leads to aggression. Few of them were bit aggressive at times but that was ok because their aggression was just about deliverables.  

What was the problem with other type of Managers in our perception?

The Aloof ones were not involved with anything throughout the years but when it came to appraisals, they had all the time in this world to point 1000 things in their subordinate’s work. Fortunately, I never had to work with such managers but my friends were not so lucky.

The micro-managers were always too much involved. So involved that they never realized the problems their resources may have. This may sound a bit exaggeration but read on the following thing they never understood.

1)     Test case preparation is not as important as testing, during execution. We are not against documentation but stake holders should realize that not everything can be documented.

2)      Test engineers are the ones working on projects, trust their abilities to perform well, monitoring should be there but it should not turn into smothering at any point of time.

3)      Automation is good to have, but it does not make sense to completely rely on it.

4)      There are no Best Practices; one should understand a context rather than blindly following something for marketing at higher level. 

My friend's Story - Who should do the Automation & When?

My friend recently changed his job. He is a Software Tester in Telecom domain with good knowledge of things (Domain & Technology) and more importantly he is willing to learn, for him learning has no limits. And this is precisely the reason why I thought about sharing his story with you, as it concerns us all.

As we all know that whenever one switches his/her company, s/he has to first adjust to new working environment, new colleagues, new processes etc. Same happened with my friend as well. My friend was given a project / application to work on. The project didn’t have this QA function earlier and there were no documents available for my friend either. So question was where to start?

Well, a meeting was called with all the Stake holders and it was decided that the new joiner should undergo some Knowledge Sharing (KT-Knowledge Transfer) sessions to get some more knowledge about the product he will be working on. KT completed just after a single one hour session and my friend was asked to start writing test cases. The irony was, the person who gave this KT to my friend was also a new joiner and was a developer. For most of the questions asked by my friend, he didn’t have any answer and what can be the better excuse than saying “I am also new like you.”

Then somehow Test Case started coming in and there were hour of reviews by different stakeholders to get it correct. (Actually no one knew what is correct, as told by my friend.)Later my friend came to know that the test cases he prepared are to be used by some other team. That team will use these test cases for preparing Automated Scripts.

My friend wondered as he never did automation straightaway without executing at least one cycle manually just to make sure that application is stable enough to for automation. To worsen the matters, he had to conduct reverse KTs for that so called Automation Team to make them understand the functional flow of the Application Under Test.

My friend proactively offered a solution to his manager saying he can do a lot better job if given an opportunity to work on his own with a definite timeline. Manager partly agreed and party disagreed. Manager said, “You should focus on preparing test cases, leave automation to concerned team.” But at the same time, manager was also concerned with deliverables that were getting delayed because my friend (who was asked to just write test cases) was not just writing test cases, he was also executing, logging defects, attending calls, feeding automation team and exploring application under test all at the same time and these things remains unsaid but he has to do it.

This whole process required a lot of time and the result was neither test cases could be completed by my friend (who is still exploring the product to learn more about it) nor the automation team could completely prepare their scripts.

So, Who is responsible for all this delay? NO NO I should rather say What is responsible for this delay? My friend who was a Star Performer in his previous organization (because of his gifted skills in Testing and his hunger for knowledge) is a worried guy these days.

I could think of few reasons, I would request you to put few points from your experience as well.

1) Stakeholders should not have directly jumped onto automation to get more coverage; they should have first allowed my friend (a tester by destiny) to understand the application thoroughly.

2) If it was pre-planned that automation will be done by some other team, that team should also have participated in KT session. This would have reduced the Learning curve.

3) Taking parallel approach for automation and manual testing makes sense only when one knows what should be automated and what not that too when application is stable but not otherwise.

My take, stakeholders should think in long terms, consider the broader view. What do you think?

My friend is in need of your guidance, please share your thoughts.