I got this question in email this morning from a reader:

 “I am a test supervisor at — and was promoted to a QA management position yesterday. I’m excited and terrified, so I have been thinking about how to organize the thought in my mind. After attending StarWest and following your blog for a while now, I am very interested in your opinion.

If you were a brand new QA Manager, and you knew what you know now, what are the top 5-10 things you would focus on?”

I am flattered by the confidence but in the event it is misplaced I wanted to answer this question publicly and invite readers to chime in with their own experiences. Besides, I am curious as to other opinions because I live with this same excitement and terror every day and could use a little advice myself. Here’s my first couple and I’ll add some more in future posts (unless of course you guys beat me to it).

 

tart living with your product, get passionate about it

 

Drink your product’s kool-aid, memorize the sales pitch, understand it’s competitive advantages but retain your skepticism. Test/QA managers should be as passionate about the product as dev managers but we need to temper our passion with proof. Make sure the test team never stops testing the functionality represented by the sales pitch.
Furthermore, part of living with your product is being a user yourself. I now live without a laptop and exclusively use my Chrome OS Netbook for my day to day work. As people see me with it in the hallways, I get to recite its sales pitch many times every day. Great practice. I also get to live with its inadequacies and take note of the things it has yet to master. This is great discussion fodder with devs and other stakeholders and also forces me to consider competitive products. When I can’t do something important on my Chrome OS Netbook, I have to use a competing product and this spawns healthy discussions about how users will perceive our product’s downside and how we can truthfully communicate the pros and cons of our product to customers. Every day becomes a deep dive into my product as an actual user.
This is a great way to start off on a new product.

 

Really focus on the test plan, make it an early priority
If you are taking over an existing role as test manager for an existing product chances are that a test plan already exists and chances are that test plan is inadequate. I’m not being unkind to your predecessor here, I am just being truthful. Most test plans are transitory docs.
Now let me explain what I mean by that. Testers are quick to complain about inadequate design docs: that devs throw together a quick design doc or diagram but once they start coding, that design stagnates as the code takes on a life of its own. Soon the code does not match the design and the documentation is unreliable. If this is not your experience, congratulations but I find it far more the norm than design docs that are continually updated.
Testers love to complain about this. “How can I test a product without a full description of what the product does?” But don’t we often do the same thing with respect to our test plans? We throw together a quick test plan but as we start writing test cases (automated or manual) they take on a life of their own. Soon the test cases diverge from the test plan as we chase new development and our experience develops new testing insight. The test plan has just become like the design docs: a has-been document.
You’re a new test manager now, make fixing these documents one of your first priorities. You’ll get to know your product’s functionality and you’ll see holes in the current test infrastructure that will need plugging. Plus, you’ll have a basis to communicate with dev managers and show them you are taking quality seriously. Dev managers at Google love a good test plan, it gives them confidence you know what you are doing.

Software testing is an integral part of the software development life cycle (SDLC). Effectively and efficiently testing a piece of code is equally important, if not more, than writing it. So what is software testing? Well, for those of you who are new to software testing and quality assurance, here’s the answer to this question.

Software testing is nothing but subjecting a piece of code to both, controlled as well as uncontrolled operating conditions, in an attempt to observe the output and examine whether it is in accordance with certain pre-specified conditions. Different sets of test cases and testing strategies are prepared, all of which aim at achieving one common goal – removing all the bugs and errors from the code and making the software error-free and capable enough of providing accurate and optimum outputs. There are different types of software testing techniques and methodologies. A software testing methodology is different from a software testing technique. We will have a look at a few software testing methodologies in the later part of this article.

Software Testing Methods
There are different types of testing methods or techniques as part of the software testing process. I have enlisted a few of them below.

The above software testing methods can be implemented in two ways – manually or by automation. Manual software testing is done by human software testers who manually i.e. physically check, test and report errors or bugs in the product or piece of code. In case of automated software testing, the same process is performed by a computer by means of an automated testing software such as WinRunner, LoadRunner, Test Director, etc.

Software Testing Methodologies
These are some commonly used software testing methodologies:

Let us have a look at each one of these methodologies one by one.

Waterfall Model
The waterfall model adopts a ‘top down’ approach regardless of whether it is being used for software development or testing. The basic steps involved in this software testing methodology are:

In this methodology, you move on to the next step only after you have completed the present step. There is no scope for jumping backward or forward or performing two steps simultaneously. Also, this model follows a non-iterative approach. The main benefit of this methodology is its simplistic, systematic and orthodox approach. However, it has many shortcomings since bugs and errors in the code are not discovered until and unless the testing stage is reached. This can often lead to wastage of time, money and valuable resources.

V Model
The V model gets its name from the fact that the graphical representation of the different test process activities involved in this methodology resembles the letter ‘V’. The basic steps involved in this methodology are more or less the same as those in the waterfall model. However, this model follows both a ‘top-down’ as well as a ‘bottom-up’ approach (you can visualize them forming the letter ‘V’). The benefit of this methodology is that in this case, both the development and testing activities go hand-in-hand. For example, as the development team goes about its requirement analysis activities, the testing team simultaneously begins with its acceptance testing activities. By following this approach, time delays are minimized and optimum utilization of resources is assured.

Spiral Model
As the name implies, the spiral model follows an approach in which there are a number of cycles (or spirals) of all the sequential steps of the waterfall model. Once the initial cycle is completed, a thorough analysis and review of the achieved product or output is performed. If it is not as per the specified requirements or expected standards, a second cycle follows, and so on. This methodology follows an iterative approach and is generally suited for very large projects having complex and constantly changing requirements.

Rational Unified Process (RUP)
The RUP methodology is also similar to the spiral model in the sense that the entire testing procedure is broken up into multiple cycles or processes. Each cycle consists of four phases namely; inception, elaboration, construction and transition. At the end of each cycle, the product or the output is reviewed and a further cycle (made up of the same four phases) follows if necessary. Today, you will find certain organizations and companies adopting a slightly modified version of the RUP, which goes by the name of Enterprise Unified Process (EUP).

Agile Model
This methodology follows neither a purely sequential approach nor does it follow a purely iterative approach. It is a selective mix of both of these approaches in addition to quite a few new developmental methods. Fast and incremental development is one of the key principles of this methodology. The focus is on obtaining quick, practical and visible outputs and results, rather than merely following theoretical processes. Continuous customer interaction and participation is an integral part of the entire development process.

Rapid Application Development (RAD)
The name says it all. In this case, the methodology adopts a rapid development approach by using the principle of component-based construction. After understanding the various requirements, a rapid prototype is prepared and is then compared with the expected set of output conditions and standards. Necessary changes and modifications are made after joint discussions with the customer or the development team (in the context of software testing). Though this approach does have its share of advantages, it can be unsuitable if the project is large, complex and happens to be of an extremely dynamic nature, wherein the requirements are constantly changing. Here are some more advantages of rapid application development.

This was a short overview of some commonly used software testing methodologies. With the applications of information technology growing with every passing day, the importance of proper software testing has grown multifold.