Replies to This Discussion

Permalink Reply by Sasidhar Reddy on March 1, 2011 at 7:52am

What ever you are in interested do that only. Testing is not low priority.. developers should have knowledge on particular module only. but tester should have whole App.  It should not effect for salaries and promotions. may be your company doesn't giving preferences for test engineers. 

 

• ▶ Reply

Permalink Reply by Pramod Kr. Lumb on March 1, 2011 at 11:36am

RK,

 

A couple of observations from my end:

 

(1) Testing is NOT a non-technical activity. In order to test effectively, you need to have good knowledge of database structure and query languages (SQL, PL/SQL etc.) as well as at least one scripting language (PHP, Perl, Python, Java Script etc.). You may be able to perform some functional black box testing without learning and using these tools but any advanced testing effort will require you to be proficient in their use. Besides, white box testing and performance testing are very technical activities. Test automation is a better example. When you do descriptive programming in order to customize the test scripts generated by any test automation tool, you are actually doing more coding work than a developer at your level.

 

(2) Testing helps you gain a very good knowledge of the domain you are working on. A good domain knowledge is always an asset, and may, later on, even enable you to work as a domain expert.

 

(3) Your organization may not be paying comparable salary to testers but the scenario is vastly different in the industry at large. Qualified and talented testers not only get equal or better salary than developers with similar experience, they are also in more demand (it is specially hard to find competent automation and performance testers).

 

So, don't get disssuaded by what your manager is telling you. Learn as much as you can from your current assignment, and let your manager know the important role played by testing in ensuring the release of a quality product. But in the end, do what you are comfortable with, and like doing.

 

Regards,

Pramod  

• ▶ Reply

Permalink Reply by Jonathan Aibel on March 1, 2011 at 10:55pm

Software Quality is serious business.  Software errors have crashed rockets, caused blackouts, and killed people.  for instance, take a look at http://www.wired.com/software/coolapps/news/2005/11/69355.

So that's the principled argument.  A business argument is that the software affects your customers and their experiences.  I trace Sun Microsystems decline to a (hardware) memory error that they denied they had.  A popular database company went out of business in the 1980's -- sorry I can't think of the name right now -- because they had a bad release.  Once a company loses the trust of its customers, it can be nearly impossible to get it back.

Do your customers store vital information in your software?  Do they have a trust relationship with your company?

Even "minor" defects, like spelling errors in messages affect this trust relationship.

Do you have a support line?  Find out how much an average call costs.  Any defect you find in house will prevent calls.  You can probably do some sort of back of the envelope calculation to show how much money your work saves the company.  For example, if the basic cost of a call is $200, and you have 1 million customers, then catching a defect that would result in just 1% of your customers calling will at the start save the company $2 million.  Then, if you consider the value of preventing a bad customer experience, and the increased cost of fixing a defect once a product goes out the door, the amount goes up.

Ultimately I'd recommend finding a company where they understand the value of software testing.

• ▶ Reply

Permalink Reply by RK on March 2, 2011 at 8:11pm

Thanks for the valuable info Jonathan. Also can you please suggest me some emerging software testing areas where I need to focus on in order to excel in this field in long run. Currently am doing Manual Testing- Trade Finance domain. I didn't see any growth from almost past 3 years.  :(

• ▶ Reply

Permalink Reply by Jonathan Aibel on March 8, 2011 at 9:16pm

I'd start by reading up on software testing techniques.  I'm old enough that I started with Glenford Myers' "The Art of Software Testing,"  and I think back to the lessons I learned from it -- I think mostly from the preface and chapter 3.  Being able to talk about testing strategies like "Boundary Value Analysis" and "Equivalence Partitioning" can impress people with your know-how -- they're both basic testing approaches I use every day.  I've looked at some of Barry Boehm's writings; he seems very knowledgeable, but some of the techniques do not seem practical to me.  I've never read Brian Mereck's "The Craft of Software Testing," although I've met Brian and he's pretty sharp.  Someday I expect to read it.

I've followed James Bach and Michael Bolton and I've found them interesting.  Bach has a a presentation on "Testers Out of SQA" arguing that if you specialize in software testing, then you shouldn't try to present yourself as assuring quality.  I like his points although in practice, I've found the distinction between SQA and Testing to be artificial.

Definitely get a recent presentation or paper by Capers Jones: he has metrics on the effectiveness of different techniques to software quality.  I recently heard him talk and he also distinguished between the people who monitor software quality (SQA) and the people who develop and run tests.

This distinction may hold up in a large team, but in most of my experience I've had to do both.  For example, I've written tests and managed the bug tracking system and developed metrics.  I think a well-rounded tester needs to know the various strategies for managing existing defects and for preventing software defects. 

In addition, the market for test automation seems pretty good right now in the northeastern U.S.  If you don't have any coding experience, pick up one of the common scripting languages -- python, ruby, perl, even VBscript.  You can load these onto your PC (or Mac) for free and there's lots of tutorials, either printed or on-line.  I don't believe that a test automator needs to delve deeply into algorithms, but you need to have the basics of variables, logical selectiong, iterations, string manipulation, object-oriented programming.  it also helps to have these basics when you talk to developers about defects; you can get their respect if you show you understand the issues in coding.

Once you have basic programming, you can get Selenium (for example) for free and get an introduction to test automation.

If coding isn't your cup of tea, another way to go is to deepen your domain expertise.  I just talked to a travel website and one of their valued QA folks is a "Hotels Expert."  If anyone has a question on the result of a Hotels search, they go to her.  Reach out to support and get involved with customer issues.  This will teach you how to test more like a customer as well as providing value to the company.  With support/customer input you can try to figure out what sort of bugs the customers find that the tests don't.  It can also be useful to sit with the release engineers and pick up some of there skills -- you can't have a quality product if the build process is erratic.

I think I'm running on here, so let me try to summarize.  I would recommend growth in the following possibilities:

  + Software Testing strategies

  + Metrics

  + Coding

  + Test automation

  + Cross-team collaboration (work with developers, support, release engineers)

  + Domain expertise (I know, that's the area you wrote that you're not interested in)

 

By the way, I'm also currently working in a company in the Finance domain, and I really only know the basics about stocks and bonds.  My boss has also suggested that I learn more about complex investments... well, I figure that there will always be jobs where there is money.  Still, I think my primary value to the company is currently in the tests I am automating; the team I'm on reduced a set of testing by 90% (from 10 days to 1 day) last year.

 

Jonathan

• ▶ Reply

Permalink Reply by RK on March 11, 2011 at 3:01pm

Thanks very much for the detailed info Jonathan.

• ▶ Reply