Welcome to the world of software testing. SOFTWARE TESTING is something that tests knowledge or skill or a check for expected operation or behavior.
Before doing anything concrete, let me investigate the career prospects on SOFTWARE TESTING.This article shall help you judge for yourself if software testing is a career for you.
What is Software Testing?
After the programmers or engineers create a piece of software, testers are responsible for making sure that it works and also trying to break it before the product is shipped or released to customers. How do testers do that? Well, sometimes it's easy and there is a written specification for how the new product is supposed to work and how it responds if there is an error. Unfortunately, that is not always the case and testers must rely on their knowledge of how computers work, how software works and their intuition.
What's a regular day like for a software tester?
I 've put together a short scenario for you called, A Day In The Life Of A Tester, that walks you through a typical day and includes one typical test case for you to try
Is Software Testing for you?
Software testing is a career that is well suited to bright, organized, inquisitive people. If you are a quick learner, self-motivated, interested in how software works and how people use software, and you have excellent verbal and written communication skills then software testing may be a field for you
What are a tester's most important skills?
Knowing how and where to look for bugs (errors)
Knowing how to report the bug effectively so that an engineer can reproduce it quickly without being insulted by the way that the failure was communicated.
MY VIEWS ON TESTING DURING DIFFERENT STAGES OF MY SOFTWARE TESTING CAREER
(1)When I was a brand new tester I wrote after one month of my experience in software TESTING:
"I have learned two very important things in my one month here, which I think will see me far in the business world
The first is that very, very few people know what they're talking about. So I don't feel bad -- and in this business, saying "I don't know that -- will you explain it to me?" doesn't seem to be a bad thing. The people who don't know feel like they're safe around me, and the people who do see me as honest.
The other big thing I've learned is that speaking confidently when I don't know what's going on can cover up for my lack of skills, when I'm talking to people who don't know either."
(2)After six months experience but still new , i wrote
"One of the things I like most about software testing is that I am constantly challenged and continually learning in this ever-evolving world of technology."
TIPS FROM VETERAN TESTER
A veteran tester of over 10 years writes:
"The most important things you need to know to be a successful tester...
You can never find all the bugs, you can only make the product as good as you can in the time you have available.
Know when to pick your battles. Some bugs may drive you nuts, but they aren't worth a fight, others will drive users nuts and must be fought for.
It's very important to have a good relationship with the developers/programmers/engineers. They are the ones who will help you and answer questions for you.
Try not to say 'I told you so' when the pet peeve you had about a product comes back as a fire-drill fix."
A veteran tester and test manager of 5 years writes:
"Sweat the small stuff but remember that you have the same goals that the developers do -- ship a product that works. It's not us against them (QA vs. Development). Sure, everyone would like to have more time to test their products, but remember what's important: if you never ship product your company dies."
A veteran tester and test manager (who manages remote testers) of 4 years writes:
"The best testers are the ones that can change assignments quickly, can work with minimal supervision and have a working knowledge of the concepts that I shall present you later"
A veteran tester and test manager of over 15 years writes:
"When Gurmit Singh tells you that the two most important skills that a tester has is knowing where to find the bugs and knowing how to write them up, he is so right on. You will have good relationships with engineers and managers if you can master these two things and you will not be effective in this business if you do not have good relationships.
As a manager, my biggest frustration is when a tester has made a commitment to do something by a certain date and then they don't do it, don't inform me or don't inform me early enough that I can either juggle their assignments or assign someone else to it. In many cases I've made promises to the team that the assignment will be done. Being honest and letting me know you can't get it done is a good thing. If you don't get it done and don't give me a chance to get it done you really make me look bad and that... really pushes my buttons."
A veteran engineer and project manager of over 20 years writes
"The best testers are the ones that can write a bug specifically enough and clean enough so that it can be quickly reproduced and fixed. My favorite testers to work with give me serious bugs with clear steps to reproduce, and clearly identified what was wrong and what they expected to happen."
A veteran engineer of over 17 years writes:
"The one liner: Testing is hard. If it was easy, programmers would do it".
Now I shall highlight the roles, tasks,
responsibilities and interpersonal interactions of five testing roles:The role of Automation Engineer shall be explained in detail
as I have a first hand experience in the same field.
Black Box Tester,
. Automation Engineer,
. White Box Engineer,
. Tools Engineer and finally,
. Test Lead and Manager.
This article will introduce you to four roles on the technical path of your career and explain some of their
major tasks and responsibilities.Please note, this article is not designed to instruct you how to do these
roles, but rather to get a broad overview of what is involved in each role to help you make an informed
decision about your career choices.
(1) Black Box Tester:
Black Box Testers (also called Analysts and sometimes Engineers) find bugs in software by using the
product or feature just like a user would. We call it Black Box because the tester doesn't see the
actual "code". They just use the product and don't care what is going on inside the "black box" of
the software. They just care about what the user sees and what the user can or can't do.
If you enjoy this type of testing, you can continue your career as a Black Box Tester, instead of veering
into more technical testing or test management.As a Black Box Tester, become familiar with the different
types of testing (like functionality or stress). Remember that it is important for Black Box testers to
stay current with technology. It's not a requirement to know how applications are built and how they work.
However, knowing how applications are built can give you clues about where bugs hide and dramatically
improve your bug hunting skills.
It's not uncommon for testers to begin to specialize in certain types of software, such as databases,
accounting, project management, etc. Here are some of the tasks that are required of a Black Box tester
Technical Tasks
Write the test plan for a product or feature.
Design and write test cases.
Research any technical issues that may arise.
People Interaction
Attend meetings and present status updates or issues. You may also present options and recommendations
about how you suggest the issues be resolved.
Meet with engineers to discuss the software and technology.
Train and mentor new hires.
Lead projects. The longer your tester career, the harder it is to stay out of management in some form.
You have so much knowledge and have been involved in so many projects that the team wants your experience in a leadership role.
Good Black Box, ad-hoc and/or methodical testers are difficult to find.
(2) Automation Engineer
Many companies now have expanded their testing strategy to include automated testing. This means that someone "automates" a test case so that it can run automatically. For example, If you are testing an online store, you could automate the test cases that put items in shopping carts, remove items and buy items. Then you could run the tests on an IE, Netscape and AOL browser at the same time...midnight. The next morning, you could review the results.
Some automation tools do "capture/replay". The tester captures the test as they run the test manually. Then they can automatically run it later. Any tester can do this, you don't need to know how to code to automate this way.
That sounds so easy, why doesn't everyone do it? Well, it also presents some problems. Let's say you've captured 100 test cases this way. Now marketing decides to rename the "Buy" button to "Purchase". All your test cases now Fail. So, if you choose to edit your 100 scripts, that means no one is testing your area.
So, we need automators that know how to code. They can help us around these situations by creating a framework. For example, they create a piece of code that does the "buy" function. When we automate our test cases, we use this function. When marketing changes the name or location of the feature, the automator makes 1 change to the buy function in the framework and voila...all our tests run.
Here's what a coding Automation Engineer does
Technical Tasks
Write the framework code.
Discover the hidden areas of the application that are hidden to the automation product. Think of creative ways to code solutions so we can still automate these areas.
Design tests that strategically leverage automation; such as Menu walk, Smoke test, Acceptance, Regression, Stress, Load, Repetition, and Number crunching tests.
Write test cases and automated test scripts.
Fix bugs in the automation code and update the automation code based on changed in the product.
People Interaction
Meet with engineers to discuss hidden areas of the code and ways to open it to automation along with discussing automation strategy.
Train other testers to run automated test scripts, write automation scripts using the framework, or help write the automation framework code.
Evangelize automation and describe why it's cost effective in the long run to write a framework or why it's not cost effective for everyone to write scripts.
General Information: Thinking About Test Automation?
This section contains general insights on automated testing that are applicable regardless of your test environment. If you are just starting to think about automation, or if you are in the process of selecting a tool, this section is for you
Choosing a Tool
There are a number of test automation tools on the market�some more expensive than others, some more full-featured than others. Certainly, somewhere out there, someone makes the tool(s) you need for your environment. For a comprehensive list of available tools,see Cigital's Testing Tool Supplier List
As with any other software package, you want to pick a package that will meet your needs now and in the future. Figuring out which package will work best for your development and test environment can be daunting to say the least.
Here are some general recommendations. First, the do's:
Do find a package that allows you to create scripts both by record and playback and by writing code.
Do take advantage of demo or evaluation copies of the software.
And now the don't's:
Don't be afraid to try a tool in a limited pilot project. You'll lose a lot less if you buy one license and decide the product doesn't meet your needs than if you buy fifteen.
Don't be swayed by vendor hype. All automation vendors promise amazing results in virtually no time. The vendors must be referring to how long it takes to automate testing of applications with one form and five lines of code. Real applications take real time to automate.
Get Management Buy In
Make sure that you communicate clearly with your management about the goals of automation. You want management to buy in to both the idea of automation and your specific objectives. If you ensure their support up front, you are likely to get the software and machine resources you need to use automation effectively.
Over the last several years, it seems that few development organizations question the need for test automation. Management is more likely to question a given automation strategy than the need for test automation in general
Understand the Limitations
Test tool vendors would like you to think that you can automate all testing of your software in six weeks or less. This is possible, but only if your product is less complicated than the calculator desktop accessory and you have very experienced automators working on the project. More likely, it will take a few months before automation begins to really pay off.
The good news is that once automation begins to pay off, it builds momentum. The organization sees the benefits of automation and may be willing to commit more resources to it. Often, having time saving tools in place means there is more time to create time saving tools. Test automation becomes a self-supporting cycle.
The bad news is that the first few months are rough. It is difficult to justify commiting talented individuals with strong product knowledge to a long term project when there are short term crises going on now. This dilemma is nothing new; it is a problem that is endemic to the software industry.
The best way to handle this is:
Don't commit more resources than you can afford.
Clearly communicate the initial goals and milestones of the automation effort to both upper management and the testers.
Measure your success against your goals and advertise the results to both upper management and the other testers.
Get Help
No matter how many talented testers you have on staff now, you will probably need help. Be prepared to:
Ask the programmers to add hooks or change UI elements to better support test automation.
Hire dedicated test automation engineers.
Bring in one or more consultants to help you establish your automation architecture and build the infrastructure
Plan To Do It Right
It's a lot easier to do test automation wrong than it is to do it right. Scripts that exercise the product without verifying anything are very easy to create. They may be good for automating setup, but they don't actually verify that your application works correctly. You cannot rely on scripts like these to test the product without seriously jeopardizing quality. The bottom line is that no matter what tool you choose, it is possible for automation to actually contribute to longer release cycles and lower quality.
So even before you choose a tool, make sure your organization is prepared to make the necessary investment of time and money to ensure that people are trained and the automation effort is focused.
Doing automation right means:
Target the automation effort to those areas of your product that lend themselves to automation. 100% automation is not necessarily the best goal to shoot for.
Plan to create reusable, robust, maintainable, data driven scripts. Use record and playback only as a learning aid.
Make sure you have someone on staff who can take a lead role in automating. Ideally, this person is a good tester who happens to have programming skills or prior automation experience, and who also has excellent people skills.
Plan to provide formal training to everyone who will be creating scripts.
(3)White Box Test Engineer
So, you've heard about and tried Black Box testing. Now, let's take a look at White Box Testing (sometimes called Grey Box or Clear Box). In White Box testing, testers that know how to code, get to look at the software and write code to test the software.
Managers may add White Box testing to their quality strategy in order to find bugs sooner. It's not cost effective to put a White Box tester on every function that the development engineer codes. Code that is the "engine" or does number crunching or is used a lot are good candidates for White Box Testing.
White Box Engineering tasks may include any or all of the following
Technical Tasks
Analyze and assess which modules are candidates for White Box testing.
Read and review code.
Write code (called test harness and stubs) to test the application code.
People Interaction
Attend team code review meetings.
Meet with engineers to discuss White Box testing strategy; the software modules' functionality and calls to other functions; or results of code review.
Meet with manager to describe, in ordinary terms, what you are doing, why you choose those code modules, how long it will take, how far you are, and when you'll be done.
Evangelize White Box testing by describing why it's cost effective to find bugs before the application is built or why it's useful to continue white box testing during the Alpha/Beta/integration phases
If you want to become a White Box tester, learn the coding language that your company uses
(4)Tools Engineer
There are other tools, besides automation, that a QA/test team can use to help test the product. Here are a few examples:
Link Checkers - Verify web page links
Stress, Load, Performance tools - verify the app and the server under high usage
Code Coverage - see what part of the code your test cases covered
Tools Engineering involves analyzing and recommending useful, value-added tools, implementing and running the tools, and writing small custom test tools or utilities for the application under test. So, testers should know how to code in order to do this job effectively.
Here are some of the responsibilities of the Tools Engineer:
Technical Tasks
Researching tools
Implementing and running the tools
Writing custom tools and utilities
People Interaction
Meet with engineers to discuss tool usage and recommendations, linking tools with source code, or discussing results of tools (like code coverage).
Meet with your manager and describe, in ordinary terms what you are doing, why, how long it will take, how far along you are in your schedule and when you'll be done.
Evangelize tool usage as to why it's cost effective to find bugs before the application is built and why it's useful to have a dedicated tools engineer.
In many companies the tasks of automation engineer, White Box engineer and tools engineer are all rolled into one job description
REMEMBER
Testing is a fun, rewarding and challenging career.
The testers career path could lead them into more technical test engineering, requiring coding skills or into test management
