This content is part of the Essential Guide: Guide: Important steps to improving your QA career
Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Brand new to software QA testing? Here's how to get started

It's true -- some companies still don't test their software. But of course they should. Here's what to do in a company that's brand new to software QA testing.

Every day in the software development world, there are companies that find they need to start testing their software. Customer complaints or demand for software QA testing has reached the crisis point, and they determine testing must be done. Yes, it's true there are software application companies that do not officially test their software prior to a release. I should be more specific -- they don't hire or retain the services of professional testers. Some of them may use automated unit tests executed by developers or the testing duties pass from one group to another each release.

Imagine you're in advertising and it's your turn to test the application. Test what exactly? If you're creating ads in various platforms for a company, do you know how the software functions? I supposed you'd learn, or would you?

Let's say you get hired into an up-and-coming software development company that has figured out they need a software QA testing plan. Where do you start? When there's been literally zero nondeveloper testing and only random user testing executed, there's so much ground to cover. Where can you start to gain the largest positive impact?

I'd suggest starting with a software QA testing plan. It doesn't have to be a formal plan -- a simple outline or free association drawing works. The important part is to plan it out first before deciding where to start. Once you've created a plan, spend time constructing tasks and then putting them in sequence. Continue adjusting priorities as necessary. Flexibility is often a key to success.

Get down to the nitty gritty fast. Conduct brief interviews with users who have participated in testing. Ask them what they did, in what order and for what purpose? Get hold of any recent design specifications or review user stories as far back as possible. Ask questions and find out how customers expect the software to work. The best source is often support or sales. If you can understand the basic business need that's fulfilled, you can develop software QA testing cases.

Develop a suite of manual tests cases and execute them. Meet with the development team and agree on a method or tool to track defects. Define how to report them to the team. Start software QA testing and good luck!

Next Steps

Software testing professionals, get ready to be flexible

How’s your time management?

QA folks, are you ready for these challenges?

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

How would you introduce a company to software QA testing?
In the article.
"Let's say you get hired into an up-and-coming software development
company that has figured out they need a software QA testing plan."
"I'd suggest starting with a software QA testing plan."

It's kind of obvious that if the clients needs a plan you give a plan.

I'd suggest the short and long term goal of building credibility of the new testing role. Documentation can wait.
I agree that there is a lot of ground to cover. One of the first thing a tester needs to do is start asking questions so that they understand what the problems are what their information objectives are. That will determine the mission, which will then determine the test plan. It’s kind of like Sun Tzu said - the natural formation of the country is the soldier’s best ally.
If you have a project where little if any Software QA Testing has occurred of the human governed kind, I feel that jumping right to planning is probably the worst thing you can do.

You see, before you plan, you need to have some idea of what direction you may want to go in at least initially.  If you're the first tester on a team, then you may not have a good map of the software landscape.

Mapping the software, or learning the structure, the way the software is bound together, will provide an initial idea of what might be fodder for testing.  From there, a talk with your product owner, or someone with knowledge of how customers use the product would provide a great number of ideas of where to start.

The sky though is the limit.