Slashdot Mirror
What Does a Software Tester's Job Constitute?
First time accepted submitter rolakyng writes "I got a call from a recruiter looking for software test engineer. I'm a software engineer and my job is development and testing. I know I mentioned testing but I'm pretty sure it's totally different from professional testing practices. Can anyone shed light on what a software test engineer's day to day responsibilities are? They said they'll call me back for a screening and I want to be ready for it. Any tips?"
Just a guess, but: Testing software?
telling the developer he's right about everything and the product is never broken, or the tester will get a tongue lashing.
It consists of repeatedly running slight variations on predefined use-cases. Basically following scripts and recording your experiences.
i.e. boooooring.
A: Suffering
To paraphrase an AC, you basically follow an established-by-development script over and over and over and over and over and over...
You do not think, you do not troubleshoot. You perform prescribed actions and check marks on your... checklist.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Go down a list of features.
make sure they work one at a time.
then try to break them anyway.
There are several different industry software testing platforms which allow for the creation of complex automated testing scripts. These scripts can be very complex and constitute a programming language in their own right. The idea is to be able to provide a script that the developer can run to recreate a set of error conditions so they can be fixed. Likewise you would end up with a series of scripts, that when run (often over the course of a day or more) will test all aspects of the software and check for new errors or confirm functionality. These scripts will have to be updated as the application changes, so if done right its a full time job.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
It means:
a) Planning software testing (Which is the hard bit)
b) Testing the software (Which is the boring bit)
If you are a software developer, do not take the job. Development is usually considered more skilled.
If you want to try just ask for your current salary and than you will have no problem since they will say no.
In short they are looking at you as a sucker who will accept less pay with more skills.
Of ... What Does a Software Tester's Job Constitute?
PULL UP !!
PULL UP !!
PULL UP !!
If you're a contractor, expect to be abused. You might not be just responsible for testing.
The truth is that if one wants to find out what software does under different conditions, he shouldn't go the designer or the developer, he should go straight to the tester.
The job of a tester is to put together a meaningful plan - understand how the software is going to correspond to the business needs and test the main logical paths as well as some optional and failure paths and find out what the software really does as opposed to what people think it should do.
If the difference between what the software does and what is required is such, that the business will suffer because of it, this should be fixed, so this goes back to the developers.
Testers prepare test plans and test the software.
Good testers prepare the data and seed it, so that it is the same at the start of similar tests in each iteration.
Intelligent testers use various tools so that they don't do this by hand.
Excellent testers figure out what the business needs and actually provide good user-like (but better) feedback to the development.
You can't handle the truth.
I tested OS/2 Warp (That was when they took OS/2 1.3 and recompiled it under Visual Age for 32 bit) and OS/2 Power PC (IBM Mach kernel).
FVT - Function Verifiction Test - basically an app programmer that would create apps that makes sure APIs do what they're supposed to do. SVT - System Verification Test: follow a script - day in and day out. Click on button, click on menus - down to every single one.
The FVT job was kind of fund. I learned things about app writing and OS internals that you'd never learn in school. I had to debug the OS many times.
SVT was boring as all Hell. Mindnumbingly monotonous.
For both deptartments, we had a script. FVT you'd write a program that did the script and SVT you did the script manually is what it comes down to.
I pity our poor testers.. I have to assume that they must develop some sort of mental detachment capabilities to be able to sit there and test the same thing over and over and over. Go back to your cube. Spending hours trying to get the damn login screen to work in every browser might seem painful, but it's nothing compared to the hell that is testing.
I've never heard of Software Engineer that did not now what a Software Test Engineer does. Perhaps User Acceptance Training? Your the middle man that takes requirements from client and makes sure that what the Developers produce works within the framework the client provided. Generally you create mock ups and run through the data until all the results and the interface are what the client expects.
Anything from glorified mouse-clicker and result recorder on up to programming test cases and developing an automation framework.
The line blurs depending on WHO you work for and WHAT you work on.
My best suggestion is to ask the person offering the job what they have in mind for someone of your skillset.
For every benefit you receive a tax is levied. - Ralph Waldo Emerson
telling the developer he's right about everything and the product is never broken, or the tester will get a tongue lashing.
As a developer who was fortunate enough to have an internal QA department I can say that your opinion is not universal. Hell, myself and fellow developers were annoyed when our QA people were moved to an adjacent building. We preferred having them one floor away in the same building so that we could more easily walk over to their cube to see what they see. Of course our QA people were trained, part of the company not contractors, etc.
We call them "Quality Assurance Engineers" (QA). Ours talk to the software engineers to build applicable test cases, and then continually run the tests on the platforms they've been assigned to work on.
Most of the job is fairly mindless, just reporting errors to the main developers as bugs so the devs can work on fixing them.
It is pitch black. You are likely to be eaten by a grue.
a lot recruiters talk out of there ass / have no idea about job some times there is not even a real job there.
The real tester should have some developers skills and:
...........
1.Run predefined scripts.
2.Follow predefined scenarios (in case it is not possible to use scripts)
3.Try to "crash" the program, and document it, i.e. prove it that it is repeatable.
4.Being able to read the source code and even correct it, if the changes are insignificant.
5.Actually, you could say that the tester is "juniour software developer" who for one or another reason cannot move to the next level.
The reality is that nowadays you have to do only "1" and "2" to be considered a tester. Good luck.
You have software with expected behaviors. First you verify that behaviors occur. If they don't, you have a fail. You formulate a theory as to what might cause the fail and you test to see if you can reproduce it. If you can consistently create the fail, you report it to development, who may fix it if it's severe enough. It's somewhat analogous to scientific method, albeit writ small.
That's the box top explanation. In practice, of course, it's *much* more complicated.
Please do not read this sig. Thank you.
Wow. Sounds like some test engineers out there with sucky jobs.
My last job was as a development engineer. We tested our own code while in development, then turned it over (along with any relevant and useful test cases) to the QA team.
I recently took a position as a Software Test Engineer at a different company. Our philosophy here is that we own the quality of the product. Granted, it takes a little more creativity to write tests to break an OS than an application, but my job here is quite challenging, with very little of the "run script, make checkmark" drudgery so many others seem to endure.
To the OP: ask lots of questions about what you'll be expected to test and how. Nobody likes drudgery, and being given a certain amount of leeway and ownership makes the job much better.
Gota blame someone.. easy to get a tester and just blame them for not catching something.
I'm a software tester for data moving products.
While a lot of testing is repetitive, the repetitive stuff can often be automated. For example, there's functionality that exists in every release ... so automating those testcases such that they are easy to run hands-off is good. This automation is often something the tester will be doing.
For new features, what typically happens in my group is that the developers will explain how they implemented a given feature and how it should work. We are responsible for testing this feature - with any tips that dev gives us - as well as trying to put it through various scenarios that cause it to break.
In my product's line, for example, we do clean reboot and power cycle/crash testing. What happens to our product when the power goes out? What happens to the data that was being moved? Does it recover? That sort of thing. This requires thought - and, contrary to some comments here, since we all want our business to SUCCEED and make money, which means customers need to be happy with the product, development is happy when we find errors or scenarios that they did not plan for in their coding. The earlier we find them, the better.
Day to day activities? Well, I'd break it into two major sections.
Planning
The test group, in my case, is responsible for reading through the planned product's features and changes and coming up with a test plan accordingly. This is then reviewed by developers, the test group, etc. Usually, during this time period is when a lot of work on automating previously-manual testcases can be done, in preparation for the next release. Also, planning for what testing environments will need to be setup and starting to set them up... it depends how big your group is I guess. Since mine is relatively small, all the testers help out with setting up various machines for testing, too.
Testing
During testing, the test plan is executed. Day to day activities include test environment setup, manual testing, automated testing, discussing potential issues with developers and opening work requests (WRs) if it's decided that it is really an issue and not a weird environmental problem etc.
"Can anyone shed light on what a software test engineer's day to day responsibilities are?"
Making yourself very unpopular among your fellow developers! :]
Seriously, that really depends on what exactly is being tested and how the testing is organized. I've seen people with the description of "tester" sitting in a single room doing totally different things. Have some more input data?
(But one virtually bulletproof hint is: If you don't know Python, learn it. It might save your life if you ever decide to test anything.)
Ezekiel 23:20
Any tips?
Study the techniques of Bob the Bastard in testing hardware. Apply analogous techniques to software. Software developers will fear and respect you, and tremble at the mention of your name.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
As a software tester at my job, my work includes:
- Building test scripts for each application (I use Google Docs spreadsheets) that we develop
- Perform feature-specific or fix-specific regular testing of applications during development cycle
- Argue with developers over severity of bugs
- Coordinate full-scale software testing before each release
- Update documentation when developers fail to do so
- Argue with developers over importance of different features in terms of development time
A big part of what makes or breaks you as a software developer is the willingness to go off the beaten path. For example, when I test, this is what I consider:
- Hmm, that's an interesting text field, and it's meant for an IP address. I wonder what happens if I type "abc::1234**!!whymeeee" into it (input validation)
- This is a resizeable dialog - if I resize it absurdly in vertical/horizontal, do elements in the dialog scale correctly?
- Here's a text area that's meant for a paragraph or two of text. If I put the Iliad into it, does the text run off the page? (bounds checking, text limit checking)
- Here's a dialog that has to validate text - what are all the possible errors it could encounter, and are the error dialogs properly implemented for each? (check all error condition handling possibilities)
- This dialog is localized into 15 languages - is the page sized/formatted correctly in all languages?
- This program is meant to be installed to C:\Program Files\Blahcompany\Product - what if I install it to a nonstandard location?
This will ultimately put you at odds with a lot of developers because your job, every day, is to make the assumption that they have made mistakes that you will find. I enjoy it, and find it to be a rewarding experience, but that's because I work at a company that highly values its software testers and takes QA as a serious priority. Try to get a feel for how this company treats QA, because if all they're doing is using you as the fall guy for bugs you made them aware of before a release, it'll be no good.
It can vary wildly. I work for a very large software org, and our test team is so varied in skill set and role that it would be hard to quantify it succinctly. Everything from scalability testers, who manage the scaling of our products to 1000s of instances and servers, and 100000s users... to interop testers who create realistic wide scale deployments based on customer feedback and test product interop... we have formalised functional testing to break/test/fix software, and we have automation engineers who create repeatable, structured tests which can run many times per day as changes are made to the codebase. Consequently, our test teams are some of the best paid engineers going - and can easily progress into senior management and director roles within the wider development team.
hth
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
Testing software can mean different things. It depends on the sponsor of the testing. If you are testing on behalf of a customer, it is more evaluation oriented: is it good enough for our needs. If you are testing on behalf of a development sponsor who's intent is to sell it, they may want a more rigorous process that can include automated testing (writing code to exercise the application and demonostrate fitness), bug hunting (including corner cases, user simulations, etc), stress and load testing (make a bunch of worker threads and pound on something, be it library (e.g. a .dll) or a service (like db or web site). You may also get involved in ways you can help improve the code's testability, which is to examine the source and find ways to structure, configure, and expose it in ways that let you do more specific testings.
You might be testing in a small office, doing whatever the program manager wants. That is often the case. You may write test plans and test cases. You almost certainly will discover, write, and resolve bug reports and report that to your sponsor.
Obvious statements are obvious...come on guys, sure a software tester can just simply follow a checklist. Can't say what a screener is looking for(i.e. scripted responses), but as an interviewer I would look for...
1) Passion to understand things and constantly digging deeper
2) Natural distrust of quality of code
3) Passion for security as well(it is another form of bugs)
4) Someone who is willing to stick to their guns(can believe 100% they are right) as much as willing to back down(not 100% ego).
Following scripts or going down features...anyone can do that, but if you don't have at least some of the drive as listed above, you will get burned out fast.
It could be something good. At a past employer we had software engineers who developed the product, six figure telecommunications boxes, and software engineers who were part of the QA team. Those who were part of the QA team wrote code to test sub assemblies during manufacturing, to test fully assembled boxes before delivery to customers, regression tests to exercise the development team's software in simulated environments (i.e. testing development versions of code before approving the code for release), etc.
There is a book called Agile Testing - read that. Also, read a free pdf called Scrum and XP From the Trenches. After that, learn about the paradigms of different testing: A/B Testing, Automation, and the standards around how test cases are come up with.
OP is correct - the job of a software tester is to try to break the software. I've enjoyed working in software quality assurance (SQA) for over a dozen years now. I get paid to break things all day, and when I do break it - I don't have to fix it.
SQA is very different depending on where you go and what you're testing.
Web Applications - you'll want programming experience so you can write flexible automated scripts. You can test manually for every supported browser/OS combination, but it's tedious.
Desktop Applications - Sometimes manual testing is enough. If the software is large, you'll likely want to automate.
Large companies that move fast will want automation. Small companies that move fast will want automation, but might not realize it. You can get away with manual testing at small slow companies.
You don't need automation skills to be a software tester. You do if you want to become a software tester with a high income.
If they have a good regression system setup, it will mean you will write a test case once and it will automatically run for you, and you are good, you will automate all of this is it is not already done. You will only go back to look at these if something breaks.
You will also likely get the specifications for a new component and a script and be expect to try all possibilities, the better once know how to program and thus do thing that they know we likely miss. Bad testers are a dime a dozen, good tester are golden.
Generally think about it like being the first customer and having to learn a new components all the time. A person who's job it is to figure out all the ways to use something within the rules given (not that much different then hacking, actually if you think about it hackers are just really good testers, they win when they find a bug).
Testers are also involved often in customer deployments and trials here where I work because they have the most experience using new software. Developers know how to write thing, testers know how to use it (Big difference).
In the end, you will make what you will of it. Go talk with them, all you have to lose is a bit of time.
Best of luck,
---
I'm a programmer not a English major, if you have a problem with my writing, write a better grammar and spell checker, then we can talk.
Seriously. The job of most software testers is try the software and then complain it's too hard to use so the UI guys can tweak it down to a 3rd grade level or so. I guess there's regression testing too.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Those who can, do. Those that can't, teach or QA.
While not always true, you have probably heard the above statement many times. Testers in many cases are responsible for bringing the whole project together. Other departments might make portions, a graphics/animation department, software programers, maybe math groups or database, however you are the one who has to test all the components together. For all this responsibility you get the least amount of pay, and are expected to know everything about all the parts and pieces. Blame QA is the common cry heard among companies, when something gets out buggy. The job itself could be ungodly script running repetition, or pretty cool new project stuff that has not been automated and the bleeding edge of the companies new products(with ungodly script repetition to follow later).
It tends to be a pretty thankless job, but in some cases it could be a good way to get into the company and use the job as a stepping stone for a better paid, less responsible, software developer (or otherwise) job at that company.
Taking builk testing responsibilities off developers so they can work on more important stuff.
Not quite. Developers often make poor testers. Software tends to get debugged and tuned for the way developers use the software, which is not necessarily how others (in particular customers) will use the software. How many developers have written a piece of code, tested it conscientiously themselves, presented it to others expecting no problems, and watched these other folks find serious bugs within minutes?
Having dedicated testers between developers and customers yields better products, even when the developers take testing seriously.
I think you ought to be very careful about going into QA. At many jobs that simply means pushing buttons and running the software. You certainly won't be adding any development/code writing skills on your resume at a job like that.
Also, they more you do something, the more companies will only want to hire you for that one thing. So, if you want to be a developer or remain a software engineer I'd think twice before filling your resume with QA positions. You'll likely only be considered for that position going forwards.
My $0.02, and good luck with whatever direction you end up going. :)
Going into QA is career suicide for a software engineer. Seriously this is a big step down.
Wait. You're a software engineer and you don't know what a software tester does??
A tester tests the code. A test engineer typically will write code to test the code. These aren't unit tests they are writing. But test scripts. Testers tend to test the finished product. They are the ones doing integration testing. If you are currently a programmer you probably will not want to be a tester.
What Does a Software Tester's Job Constitute? Well, from the perspective of Project Management for my off shore outsourced projects... NOT A DAMN THING!
Everything I know about testing, I learned from The Trenches.
Oh, and doing it myself, of course. Of course I test my code. Why? Who's asking?
The job of a tester is to put together a meaningful plan - understand how the software is going to correspond to the business needs and test the main logical paths as well as some optional and failure paths and find out what the software really does as opposed to what people think it should do.
Yeah. What he said. Sure, misconceptions abound, but when the role really is "software test engineer", the job is a lot more important than just running scripts and trying to make the software break. I think this may vary vastly between employers, and in some (or most?) situations the management themselves probably don't understand what they should be asking for from their testers. The reality is destructive testing only covers a portion of the job, while to do the job well a lot of knowledge and imagination can be needed to grasp the entire scope and complexity of the software, knowing what goes on in the back-end data, what the users see and believe is going on with the particular parts of the s/w that they use, how action in one person's role effects what is seen by a user in another role - the tester needs to see the entire view which individual users may never be involved in.
I have great respect for the testers I work with (not least because they can handle a grumpy developer without hitting me) and often prefer to go to the tester instead of the B/A for answers. Development environments may differ, but when I have a nasty bug to hunt down which requires data to be set up in multiple integrated software solutions to get just such an error to occur between them, I can't imagine what I would do without somebody there with the knowledge and patience to go thru the entire scenario to reach the point where he can say "now press that button and watch what happens".
Sure, its still annoying when the tester comes back and tells me that little Bobby Tables just broke my database, but yeah, they do need to do the simple basics first as well I guess.
If I had a DeLorean... I would probably only drive it from time to time.
I worked testing software for phones (many different Android phones mostly) for awhile and often the test instructions were "Play with it for 30 minutes and see if it breaks." And fairly often it did.
Once you have a "testing" job on your resume, its pretty dang hard to get anyone looking for a coder to consider your application seriously. I've run into at least a dozen hiring managers who discard resumes for dev positions solely because the last job someone held was as a tester.
Having dedicated testers doesn't relieve programmers of their own testing duties. A programmer writes tests for the data they expect, and programmes for that data. A tester writes tests involving all kinds of data. He's expected to be pretty well trained on security issues and will get to know how the program will react to different circumstances as well as or better than the programmers. He works closely with software architects and others in translating storyboardsinto automated tests too.
Software test engineer was my first technology job, so I was pretty junior. Your responsibilities might be more extensive if you have more experience. That said, my responsibilities included:
Overseeing the build process
Maintain build scripts/makefiles, manage software repositories
Grabbing the latest code from all modules and building from source
If the software didn't build properly, identify the source of the problem and (if I could) fix it, otherwise provide feedback to the responsible developer
Integration testing
Create and maintain test environments and scripts
Once the software was built, test major functionality to ensure that new code didn't break anything
Test whatever functions had been modified (new features, bug fixes, etc.)
Debug any issues and (if I could) fix them, otherwise provide feedback to the responsible developer(s).
Troubleshooting
Reproduce bugs that had been escalated to the dev team
Debug the issue and identify the source
Fix the bug (if I could), otherwise provide feedback to the responsible developer(s).
Software Releases
Build release versions (Beta and production) for distribution to customers and manufacturing
Regression test release versions
Other Stuff
Create test reports
manage bug tracking
Set up dev environments for the developers
Design and set up test beds for testing and troubleshooting
Developers were responsible for unit testing their code before releasing it to me for Integration. That may or may not be part of the job you're looking at.
HTHAL
No, no, you're not thinking; you're just being logical. --Niels Bohr
And of course we manually test, too. But, damn, is that boring... :)
I was looking for work recently, too, and got lots of calls from recruiters looking for Software Test Engineers.
I've worked very hard to get to being a developer, so I resisted and eventually got a better paying and infinitely more stimulating development job.
Software Test Engineers are sort-of developers, but the emphasis is on understanding requirement to be able to implement a "test matrix" that will (perhaps exhaustively) exercise a system (hardware and software as a whole) through all of the "use cases" that a user might be expected to do i.e. how J Random Luser will use the product.
Practically, this means implementing hundreds (or maybe thousands) of automated tests driven from something like Fitness. If you're lucky, you'll get to implement your test cases in something like Ruby. If you're unlucky, it might be C#...
It's quite a skilled job. You need to know a bit of statistics (statistical significance, confidence levels, variance and all that), about Combinatorial Testing (test coverage) and a bit about scripting and good software design. You would also need to understand the difference between white- grey- and black-box tests and when they are appropriate.
There are two ways in, from being a "tester" upwards or sideways from being a developer. (Note I didn't say "down." It's a skiled job, but I've done it for a few weeks for the experience and I got bored quickly).
In the spirit of cost-cutting, most Western companies are offshoring their testing. For example, Xerox just got rid of their manual and automated test to HCL in India. McAfee have done the same.
Stick to development unless you're starving/about to have your house repossessed or want a little extra experience on the side (which is a good thing for your CV as long as you don't make it your whole life).
One last thing: clueless recruiters see "Test-Driven Development" on your CV and think, "Aha! A software tester!" I had hundreds of phone calls under that misapprehension. (They also don't know what a kernel is (Windows and Linux both have one so they must be the same, right?) or the difference between C, C++ and C#...)
Stick Men
At Microsoft, for example, there are 2 test positions which sound the same but are VASTLY different. "Software Development Engineer in Test" and "Software Test Engineer" are the two positions, but SDET is given a lot more responsibility and gets to do a lot of development and works very closely with the developers and others on the team. STE generally gets little development and is all about making sure the test environment that actually execute tests is working and making sure the infrastructure is happy and the network is working. So my advice would be to make sure that you ask about other testing positions and discuss the differences and make sure you are getting the right thing. Testing is awesome and fun and very important and usually more difficult to do right than development but not all testing positions are created equally.
Our company uses Agile as our development methodology. A task for our testers, from start to end, usually looks like this:
1. A new bug fix or feature request gets created in Jira (task management system). If it's a bug, the tester tries to reproduce it on their system. If they can't, they discuss it with the submitter until it's reproducable, or determined to be user error.
2. In the backlog grooming (thinking about and estimating the time cost of new feature and bug fix requests), the tester asks questions about what the final system will look like and do when finished. In the sprint planning meeting (assigning tasks to developers) they try to get a list of requirements that are, well, testable.
3. When the tester leaves the meeting, they start writing some test cases. "User clicks here, this happens. User enters this value, this happens." This includes lots of corner cases, like opening files stored in locations where the directory has a space in the name (i.e. "C:\Program Files"), or inputting negative values for things that should only be positive, or clicking outside the dialog window. They then code up some test scripts that with Marathon, using Jython.
4. When the developer marks the feature as resolved, the tester gets the latest updates from subversion, runs it with Maven, and starts going through the test cases they wrote. "When I clicked here, did this happen? When I entered this value, did that happen?" They also run the Marathon test scripts.
5. If the feature or bug fix passed all tests, the issue gets marked as being closed in Jira. If it doesn't pass all tests, then it gets kicked back to the developer who is responsible for the changes. Sometimes the requirements need to be renegotiated with the product owner.
This involves a lot of collaboration with the developers, product owners, and product support personnel. Qualities possessed by successful testers are: an attention to detail, perfectionism, creatively thinking outside the box, imagining what a user might do, imagining what a stupid user might do, communicating observations, comprehending vague requirements, writing documentation, and being able to politely goad developers into finishing their tasks well before the deadline so you have enough time to test. Notice that coding is not part of this? Also note that unit tests are the developer's job.
In case you're wondering, I'm a developer. My team's tester has a background in writing technical documentation, and has nearly completed her Masters degree in Project Management, but has no background as a coder. She's extremely good at what she does.
Your development background will be very useful in a QA / Test Engineer role, assuming you are considering joining a technically competent organization.
I say this because many companies have an antiquated view of "testers" as low skilled keyboard jockeys able to bang keys and input fields like monkeys on ritalin. Avoid these places like the plague...
A premium QA/Test Engineer will apply development and other solid technical skills to:
- Provision test systems spanning wide varies of operating systems, network configuration, applications and settings, in short: be able to build everything you need to test the systems tasked of you.
- Obtain a deeper understanding of the system under test; able to dig into code to discern logical errors and oversights, triage down to root cause and even suggest a fix/patch.
- Integrate test automation technologies into the software process so regression and performance testing is part of a continuous integration & test lifecycle. Manual testing should only be a part of your efforts, as software systems continually expand in scope and a manual-only test process will eventually be overwhelmed by progress.
- Extend and apply third party tools, ranging from code performance analyzers to network traffic capture/replay, code coverage analysis and unit test frameworks, fuzzers and chaos monkeys, etc.
- Understand security risks and defensive coding techniques to identify deficiencies in a code base or implementation/design which introduce vulnerabilities. Catching these defects before a product goes live is very rewarding and can be exceptionally cost effective.
- Develop internal tools or customize existing software using Shell, PERL, Python, Ruby, Java, C/C++, and other languages as required or appropriate for the task at hand.
- Communicate effectively with multiple stake holders in an organization: development, product support, marketing, administration, operations. These will all be interfacing with you and the ability to tailor the technical depth and nomenclature of your written and oral communications to each of these groups is critical to being an effective QA/Test Engineer.
And many other skills and capabilities I've not listed, depending on the context of your role in the group and the domain of the organization you work for.
Many people still consider QA a less important or prestigious occupation compared to other technical professions, like software development. While the prestige may be lacking, the job satisfaction of a competent QA/Test Engineer who applies development, operations, and security analysis skills to improve a product is significant.
The many varied resources you should incorporate into your tester toolbox is too long to list here. Many sites exist devoted to QA toolsmith / test automation / security analysis roles, and you're going to want some skills and tools from all of these specialties at your disposal.
Good luck! I hope you consider the switch; the world needs more competent QA/Test Engineers.
This. It's incredibly variable.
I work for a company that produces an app that uses a MS SQL backend and a Visual FoxPro frontend (yes in 2012, we still use FoxPro). We have *no* automated testing. Testing is done by reading a bug report / feature request and making sure that the compiled version meets the specification. Of course, because we have no automated testing this means that we manually have to use the feature how we think a customer might use it.
Because our codebase is so old and filled with spaghetti (and because we have no formal test cases -- and sometimes some behavior is simply undefined due to oversights in the specification) the QA people have to constantly try to keep the program in working order via manual regression testing. Manual regression testing is mind-numbingly boring. You really want to kill yourself after running the same test over and over again, month in month out.
Being a QC tester or QA Engineer can be anywhere from monkey grunt work, clicking through menus and following test cases while writing up bug reports to establishing test cases, standing up testing environments and developing scripts and metrics to configure those environments and take benchmarks. To me QA Engineer leans more to the latter and a QC tester leans more towards the former.
The kind of qualifications the recruiter is asking for is probably a good indicator of where on that scale you'd be but a QA engineer will some times do some of the grunt work a QC tester will do if the department is small enough but a QC tester rarely does what a QA engineer does because they tend to not be qualified. A lot of software companies will hire in house from QA engineers to be new developers because they are a lot more familiar with the coding standards and practices of the dev team than more qualified people from outside the company.
Our department's QA engineer has basically been working two full time jobs right now fulfilling the roles of both a QA engineer, establishing test cases and testing processes and a QC tester, doing the grunt work of going through hundreds of tests multiple times across various environments. We're taking on a small team of QC testers in the coming quarter and he'll be able to take on the full time role of QA engineer. There is definitely a difference between the two and often recruiters and employers will muddle the terms.
... is that I should have been a software tester because it seems every program I touch I always find something wrong with it or manage to break it somehow.
now we need to go OSS in diesel cars
Day to day responsibilities for a Software Test Engineer or QA can involve several things:
Design test cases (think of ways to test the requirements of the software and document that knowledge),
Submit bug reports and feedback (find an exception, crash, incorrect data or calculation, usability, "it's ugly", performance),
Design/write automated scripts,
Design test harnesses (write utility programs and interfaces that hook into the software being tested to get to data or features that are otherwise unavailable or not Directly testable by a person),
Verify code changes for new feature implementations or bug fixes,
Manual scripted testing,
exploratory testing (manual, non-scripted testing).
These are still just generic descriptions. For instance, my day to day testing tasks can include packet sniffing, manipulating a UI, messing with a web page query strings, querying a database, crafting an overload scenario for a feature, cloning alot of client software to bombard a server, writing code, manipulating hardware configurations, testing network connectivity, using a stopwatch to track page load times, and managing an IIS server.
It will depend heavily on the maturity of the team doing the work and the software being developed, as well as skill of the person doing the work of course. You may find that it is more efficient to manually test certain features or functionality when first starting out, but as progress you are able to automate your tests. Or maybe what you are testing has no UI at all, in which case you'll have to write test harnesses or automated scripts from the start. Some features don't lend themselves to easy automation, and vice versa for manual testing.
A tester needs to be prepared to take home less pay and expect high turnover in his/her dept (if he/she doesn't leave first).
We have a QA dept and they don't stick around more than a year, tops. By the time they really get into the product, they're either fed up with the pay, the hours, or they get switched to another product. QA catches few important bugs because we (a) treat them as second-class citizens and (b) we don't involve them at the beginning of the design cycle.
I've also seen some pretty brutish egos among fellow devs wear out QA staff. Do you want to subject yourself to that?
-- Posted from my parent's basement
Among other things, a software tester's job CONSTITUTES the software development process. I think you mean "consist of"?
...
The job of a tester is to put together a meaningful plan - understand how the software is going to correspond to the business needs and test the main logical paths as well as some optional and failure paths and find out what the software really does as opposed to what people think it should do....
That's incorrect - a tester follows a test plan and performs the test steps. This can be a program and the tester will evaluate the program output if it conforms to specs.
A test plan is part of the design process and should run parallel to development.
What you describe is ad-hoc testing - finding additional defects by going outside a structured, predefined test plan.
There is no way that more complex systems - banking, Internet, manufacturing etc. would function without a highly structured approach including testing.
The term "Engineer" is undefined - can mean anything.
Having been in quality for over 20 years, both in manufacturing and software, I will tell you this--if you are a developer, and you actually have to ask what a tester does, don't bother trying it--you'll never get it, because you are either too immature, too stupid, or just haven't been paying attention.
In the real world, great developers and great testers don't play Kindergarten games, and call each other useless or unprofessional. They understand they each have unique skill sets, and work together to produce awesome stuff. I've worked with great developers and great testers. We did some great shit.
For the most part, good luck finding such developers and testers. Most are content with pissing on one another, I guess because their mothers didn't love them enough. Who knows.
Tester roles vary widely with the company. Here at MS, testers are supposed to do 30% development: either writing their own test tools, or researching (if not fixing) bugs for the regular developers. One I know said he went into testing rather than developing because he got to write more code with less process. Being a MS SDET requires pretty much the same skillset as a developer, and people switch between the two occasionally.
At another large Seattle company, the testers knew little to nothing about the internals of the product, they basically ran the software periodically and tried to break stuff. Automated test runs (a major secret weapon for MS, BTW) were pretty much unknown: BVT's were a manual script. (Of course, this was just one group, and the products were not all that complicated; still, a BVT run took hours, and therefore didn't happen every day.) Most of the testers were young and I suspect the company wanted (cheap) quantity instead of quality.
The main characteristic of testers is the desire to break stuff; I can't do it because I want stuff to work. There is also some admin stuff (like test plans) that you might not have seen much before (MS teams usually have elaborate templates that make it pretty easy, elsewhere it can be anything from a bullet list in an email to a formal document.)
The takeaway is that you need to find out exactly what your job will entail, from the team, before signing on. Don't assume anything.
Any takers?
I have a gmail account, doubleplusgoodalbert, to which you can send a resume.
Probably will involve TPS Cover sheets.
There is no way that more complex systems - banking, Internet, manufacturing etc. would function without a highly structured approach including testing.
For the last few years I've worked in SQA testing a very complex piece of banking software. We use a lot of automation, but without extensive exploratory (or ad-hoc) testing, our software would be in bad shape. Automation is used to verify things are working as you expect them to - it typically takes a while to set up. Exploratory testing is a way to quickly check, "I wonder if the developer thought about THIS THING," then trying that thing.
I don't code automated tests to make sure _every_ single field has a field text input limit. But I have checked them all at some point manually just to see what would happen. Non-critical functions of non-critical areas don't get extensive automated tests - it's not worth the time/money. But looking at them once, ad-hoc?
"A test plan is", or "The job of a tester is"... Both of these have very different answers depending on what company you work for, and who in that company you ask.
...you want quality assurance. Testing is a part of the whole. Good QA is involved throughout the process and involves more than just "pressing ctrl-a while in high-DPI mode with the program maximized caused the DVD tray to pop out instead of display an about box."
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
I too will be posting Anon.
This AC isn't in a rare circumstance - it happens far more than you think. It's happened at companies I've worked for, and partially at the one I'm at now.
It's horrible. It's legacy applications. It's "old guard" thinking that gets a company into this position and it's very hard to get out of.
I researched automation packages until i found something that would work for us, talked the company into spending $4,000, then spent six months getting some basic regression tests together. During the next six months I would mention when automation caught fatal bugs that wouldn't have been noticed with manual testing.
It's now over a year later, and the company is accepting and happy with automated testing. It's been a very challenging experience due to corporate culture.
That's incorrect - a tester follows a test plan and performs the test steps.
- aha. And a developer follows a design and performs necessary steps to build the software.
And a BA follows necessary steps to collect all of the necessary business requirements.
And a DBA follows necessary steps to ensure that the data model is correct and the database configuration makes sense for the project.
And a PM follows the best practices and whatever steps to ensure that the project is on time and within the budget and it delivers what it promises.
And the sales follow the necessary steps to ensure the customers are buying what they believe they need.
And the marketing follows the necessary steps to ensure that the offerings are of value to the customers, partners, clients and what not.
The top management follows the necessary steps to direct the company towards a successful vision, etc.
And no company fails to achieve its goals.
And no project fails.
And no design decision is amiss.
And no developer makes mistakes.
And QAs never find the unexpected.
And banks don't fail.
And governments don't fail.
And Challenger didn't blow up.
And countries don't fail.
Give me a break. Things don't work the way they are 'supposed' to, a good QA will catch problems even if nobody thought of them and whatever plan that everybody thinks is the shit today, is shit tomorrow, just not that kind of shit. Even in the banks and insurance companies and investment businesses and medical companies and utilities and manufacturers and telecommunications and who knows what else.
You can't handle the truth.
Those who can't code, test and those who can do either, supervise and say Mmmm-kay
There is no way that more complex systems - banking, Internet, manufacturing etc. would function without a highly structured approach including testing.
For the last few years I've worked in SQA testing a very complex piece of banking software. We use a lot of automation, but without extensive exploratory (or ad-hoc) testing, our software would be in bad shape. Automation is used to verify things are working as you expect them to - it typically takes a while to set up. Exploratory testing is a way to quickly check, "I wonder if the developer thought about THIS THING," then trying that thing.
I don't code automated tests to make sure _every_ single field has a field text input limit. But I have checked them all at some point manually just to see what would happen. Non-critical functions of non-critical areas don't get extensive automated tests - it's not worth the time/money. But looking at them once, ad-hoc?
"A test plan is", or "The job of a tester is"... Both of these have very different answers depending on what company you work for, and who in that company you ask.
Oh, and make sure you find ALL the ways to break them.
Dude. Have you never read QA Confidential? It starts out as the job of a lifetime, but it all ends very, very, horribly.
Create and propagate information that helps people to create and ship the software...
Everything else is details on this. I was the senior software tester for multiple projects. I got paid more than most everyone else, because I owned the above. I helped and did everything, and spent as little time as possible, NOT doing anything else.
However, most people spent tons and tons of time NOT doing the above. The created very little new and useful information, and propagated very little. The company would make up for this by hiring LOTS of people, to try and create more information. Lots of time, people were given my stuff, in an attempt to expand on it.
Personally, I spent a very small fraction of my time on regression testing. A little more on verification. But most of my time creating and propagating information.
I would spend time creating models and predictions, and watching carefully what would happen. I would look at errors, user expectations, standards, behaviors and functionality. And barf stuff out as quickly as possible. And some percentage of time was coming up with larger and better explanations.
I was never done, and I never could work enough to find them all, and I was never satisfied. There was always rich veins of information to be uncovered and passed on.
At some point it shipped anyways...
Sometimes I was there for the next version, sometimes I did other things.
My personal satisfaction, was knowing that I had a substantial impact on what shipped. And that it was better for me being there.
Criticizing someone by saying that they got less done than a group of other people is a pretty lousy criticism. All you've really done is establish that there's a benefit to two types of testing: methodical testing, and let's-just-mess-around-with-it stress testing.
Just messing around is way faster, and it will quickly catch a lot of bugs. But it's no substitute for methodical testing. How many bugs did she find that the entire group of other people would have never noticed?
I feel sorry for her. It seems like she did a pretty good job, and it sounds like she did exactly what the business hired her to do, yet it doesn't sound like she got any respect for it.
Much interesting stuff ahead of this, one or two more things
:-)
QA is basically the meeting place of business/customer requirements and the developer's interpretation of that. So - as a software test engineer you should be able to create a test environment that will sufficiently (and there's a critical value judgement right there) mimic the customer environment. That environment needs good enough controls that it can automatically run through enough of (another value judgement) the functionality to ensure that there are no regressions, it needs to report well enough (ooh look - another value judgement) so that you can write a useful bug report when things go wrong. This needs a historical context of actions so that a good developer can look for a generalized fault (the bad ones just generate point fixes that make that specific problem go away) and enough of a data variance to establish some boundaries for the known good performance envelope for the product.
Having done all that - you need to do enough of a business analysis and provide enough domain knowledge to craft a set of test cases which aim for optimal coverage with minimum effort.
For the new stuff - don't bother automating until it becomes relatively stable, use automation for the things that you think (value judgement - are we seeing a trend yet?) won't change much because people are not good at repetitive tasks so that manual key bashing testing is doomed to expensive failure. Save the warm brains for the new stuff where you are trying to make sure that what the customer ends up with will actually do what they want.
In essence, assuming you avoid the human monkey organisations, you can expect to do everything a developer is called on to do - and then more. Although you may not go to the same depth in any particular sub-field you will be expected to wield a much broader skill set on a day to day basis. If you get lucky and work with good developers then it makes a great team. Of course - there is a more than adequate supply of assholes on both sides of that fence to make that a crapshoot.
You can also expect to be 4th line support once the thing ships - because by that point you will probably have (or at least should have) more practical operating knowledge of the system than anyone else.
Oh - and one other thing - broken by design is still broken
Software testing is typically an entry-level position.
Very little coding is done, and most of the time is spend writing bug reports, generating test-cases, scripts, and lots of manual mouse-clicking.
If you are indeed a software "engineer" and a recruiter is offering you this position, you either:
a) have not been in your position very long
b) are still a student
c) blindly looking for a "programming" job
d) some combination of the above
It's entry level work, for entry level pay, with little chance of real upward mobility.
Throw a belt sander in the toilet, then turn it on and leave it.
You'll note that it does a lot of noisy grinding, though achieving very little of value, while being shat upon at random. It will continue doing this until it burns out.
This is the life of a software tester.
Pretend there is some witty statement here.
I have been working in the testing field for almost 20 years but after a 5 year stint at Microsoft I found it to be such a horrible experience that I will never work with testing ever again. There are numerous problems and here is a selection.
1. As a tester at Microsoft your main use is as a scape goat. If you find a big bug then it is all your fault. No matter when you found it, you should have found it earlier. It is a pretty wierd experience when you do your job properly and well and you still can be blamed for doing a bad job.
2. As a tester at Microsoft you really are a second class citizen. You are considered less competent and more stupid. You are also far less important than anyone else since what you do does not explicitly impact the product.
3. As a tester at Microsoft you do not have a career. It is pretty easy for a newbie to reach SDET2 but very few reach senior level. Where I used to work there was a 1:1 ratio between testers and devs but it was a 1:7 ratio between senior testers and senior devs.
4. When you point out the problem with testers not having careers it only results in you having to listen to the director of test lying to you for an hour or two regaring how they are aware of the problem and how more testers now are going to be promoted. The result that year was that 12 devs reached senior level but not a single tester reached senior level.
5. If you are good at your job people are going to hate you. Your job (among many other things) is to find bugs in the product and people really love having someone pointing out all the mistakes they make.
6. If you have bad luck (like me) then you might end up in an automation swamp where the devs repeatedly break your tests and you spend an enormous amount of time fixing all the breaks. This really murders your competence.
7. If you have really bad luck (like me) then you might find yourself with a test manager that has nothing but contempt for testers and their competence plus thinks it is really important for testers to do a lot of mundane manual testing.
8. Also, having tester in your CV is bad if you want to pursue a career in software development. It will make it harder for you to get a job as software developer.
In one of the companies I worked for, testing (we called it validation) was part of engineering (this is firmware testing).
Passing those guys basically meant that QA could not fail on functionalities, but perhaps user experience or much higher level testing.
These guys (in validation) knew the specs. and products at _least_ as well as us developers.
Mind you, they were not interesting in debugging our code and failing them was not a happy thing.
They loved looking for loop holes and corner cases to break us ... they were having fun too and developed their own systems in order to be one step ahead at all time.
I think of them as hackers in the positive sense ... man they were tough ;)
Right, black box testing and exploration testing are the most interesting, it can be like a game. Detective work where good analysis and diagnostics skills are required.
When you find a failure, you have to investigate further to pin point the defect, to have something tangible and accurate to report to the developers (so that they have no other choice than to believe you ;-).
You're not the guy who made the code, but as a developer yourself, you know how it works, and you know where developers sometimes neglet to shield their code or what is likely to fail. You don't see what's inside that "box", but you guess. You have a totally different point of view than the coders who made it, so you see things they don't see.
It can even happen that you end up explaining them how what they wrote works, that you gain a better understanding of what their software does in reality! Think networking for example: with modern high level OO languages, networking is completely burried into many software layers. Opening a remote connection at high level is easy-peasy nowadays, but many programmers (especially youngest ones) don't know (or are not interested to know) what's going on down there on the cable. Your tool will be Wireshark and with it you'll see the live connection, you'll see in details how it works or fails, not how the developer expected it would work.
Software testing can be much more than pressing buttons and ticking PASS/FAIL checkboxes. It's a domain where you can have plenty of freedom and can use all your imagination and skills. Some tasks such as preparing test cases or writing reports can be boring but it's not worse that documenting code for a developer. Some coders will see you as a fellow who helps them while some others with a large ego might not like you very much, especially when they cause many defects and see your name too often! But being a good tester is rewarding. If you can share this job with some programming, you'll be a happy guy.
A book I recommend is "Lessons Learned in Software Testing": http://tinyurl.com/86f9q48
I've been a system tester in the past, a developer and at present I run a large software group for a global company. I've had to set up test groups several times and I can tell you that they only work if the dev org treats them as partners in building their product.
If however the dev team's culture is to throw things over the wall and move on to better and shinier things, you'll still might get paid, but you won't enjoy your work. Worse is a dev group whose strategy is to blame all problems as test failures and schedule overhead.
Attrition and morale in test groups has always been a problem. Be aware of that and make a decision.
As for me, the last independent test group I set up will be my last. Just not worth the people issues.
I have worked both in the software and hardware industries for almost 20 years (accumulated). The job really depends on what exactly is being tested.
If it is hardware, than you will be designing software to test different functionality and will likely need knowledge on how to debug failures at the hardware level. Not necessarily microcode knowledge, but enough to reliably produce a reproducible failure in as little code as possible for the hardware engineers to be able to reproduce in their simulated environments at the microcode level.
If the testing is for a software development team, you will want to be involved with a product design as early as possible to help point out failure points early in the design phase. As the software development progresses, you will want to develop and maintain test that can hook into the software under development and inject test scenarios in an automated fashion.
Both software and hardware testing will benefit from test plans that include focused tests with fixed data designed to attack corner cases (90% of failures are hiding in the corners - where end users somehow always end up). Another type of testing involves randomization of instructions and tests. This can actually better simulate real world usage, but it can also be much harder to develop and maintain.
One test I came up with many years ago involved taking data from random queries to our company ldap database, converting the data to a compressed binary stream, and processing it as if it was graphics data using SSE2 instructions to shift a lof of bits at a time. This actually found a bus violation between processor and memory. (The test was later rewritten by someone with a lot more knowledge of the hardware, but it was a cool "outside the box" idea).
for instance at Microsoft it means filling out a piece of paper and playing XBOX all day, or at Electronic Arts oh wait they dont even need them cause all they do is add one to the year and update an xml file, and at apple they do whatever they are told to.
Testing is the infinite process of comparing the invisible to the ambiguous in order to avoid the unthinkable happening to the anonymous.
Software Test Engineer is NOT a subset of Software Engineer.
Just be honest in the interview. If they ASK you to guess, then guess. Otherwise, just tell them what you know. You might be a perfect fit but you might be missing the particular skills they're looking for.
You kind of left out the most important element - good testers use not only the requirements document, but user expectations. Yes, I know the "non-functional" requirements should cover that, but if you make that assumption, you will be wrong 100% of the time.
And you will fuck up the deployment.
Spoken as one who has developed, analyzed requirements, tested, and been the business owner.
I'm a software engineer. I work with our software testing department. They are great and have saved my butt a number of times. Here is what I would recommend if you want to be a GREAT software tester:
1) Be evil. I don't mean in real life, but at your job. I tell the software testers to put on their mean hats. Think like an attacker. They are the enemy. If you are nice and everything always passes, you are not doing your job. If software engineers are mean to you, tell them to STFU and make better products. If a manager tells you to let something slide so they can meet a ship date, tell them to STFU and pull their head out of their ass.
1.a) Do not try to re-engineer the product. Your job is to make sure it works as designed, not to redesign. If you say, "Well this new electronic toothbrush is great, but it needs to have 27 configurable patterns, play music, download updates from the web in real time, and run Linux.", then you are not doing your job.
2) COMMUNICATE EFFECTIVELY! I have a personal joke that bad testers are like chickens, they come into my office saying, "Its broke, broke, broke, broke. Its broke, broke, broke." (Say it a couple of times, it really sounds like a chicken). GOOD SOFTWARE TESTERS TELL ME HOW TO REPRODUCE THE ERROR. They include, what their system setup was. What versions of what they are using. What they did before and during the test, and (most importantly) why they think it doesn't meet the requirement. In turn, I try to provide a reasonable test plan as a starting point. Here's what I changed, here's the feature(s) you should test, here's the regression you should test. But I don't limit them to only those tests.
3) Automate if you can, but don't automate what you can't. Sometimes software testers (especially newbies) get caught up in the automation process. "Here look, I spent 12 hours writing a test script for this test that reduced its time from 6 to 5 minutes."
4) Know thy product. The software engineers will have specialized knowledge on their little piece of the puzzle. You on the other hand must KNOW EVERYTHING! (Maybe just not all there is to know about everything.) You are the last line of defense between the lazy devs and the honest, hardworking customer that is laying down their hard earned dollars for your product. The fate of the company is in your hands.
5) TEST THE FINAL PRODUCT, its your ass on the line. Be tenacious. Do not let a developer sweet talk you into "Oh yeah, I just made this one little change. It won't affect the user. You don't need to test it." Assume if you hear this, he put in a backdoor that immediately will send all confidential info to North Korea. (Remember, the devs are the enemy!)
As some who DOES do software testing, there are a few things good software testers do but it depends on exactly what type of testing they're looking for.
Generally, you will need to analyze the business requirements to create functional tests to ensure that you have code coverage and that the code does exactly what the requirements say. If there are variances, they need to be documented and someone has to determine if they are bugs, or omissions of the requirements (and then update the requirements).
UPS Sucks
http://a.mongers.org/clueful/20020402-peopleware-blackteam
and
http://www.penzba.co.uk/GreybeardStories/TheBlackTeam.html
A junior engineer in my previous company was a far better tester than a dev. But sw dev has an allure and prestige associated with it that testing doesn't. I sent him these links and convinced him he would make a kick ass tester or a mediocre dev, his pick. He chose testing and in just a couple of years he's become a tester at one of the best companies in networking, testing things that few in the world can even dream of.
So if you want to break things, have a passion for finding faults in others, can make software shudder when you are in the same room - then testing's for you :)
I think it really depends on your company size and the kind of products they churn out. The life of a software tester in a 20 man code house is probably very different from a software tester in a 200 man IT department.
I've been working as a "senior software engineer" / "test analyst" at a regional Telco (1.8 billion USD yearly revenue) for the past three years.
Your job scope in a large enterprise will probably start with the "button-pushing" aspect of testing. Your boss will have a schedule and a quota to meet during the testing phase. "Ok, we've got one month to finish these 400 test scenarios. Let's get it started." And then you will have to attempt to meet the quota by manually executing the test scenarios. Raising defects when the expected results do not happen. This will probably last for a year or two.
Once you are more acquainted with the business processes and the products, your boss will probably get you to write those test scenarios. You will be given a bunch of documents: User Requirements, High Level Design, Detailed Designs (which most likely will contradict each other). So now you have to assess and work with the various people to confirm what is really needed or wanted.
When you prove yourself useful to the project managers by identifying the potential design gaps, they might get you on-board for the over all project test planning. You will then be involved in setting up the test environments, identifying the necessary systems involved and some resource planning (What to test, how to test, who will test and when to finish).
That's pretty much what happened to me during the past 3 years. YMMV.
Very interesting what synapses got switched on in your system. Please have all the breaks you need.
Your question is too broad and too general to be meaningful, since the answer is going to be "it depends on the role they have in mind for you".
There is no such thing as a meaningful definition of a "certified software test engineer", and there is no such thing as "best common practices" or anything else that would give a common, formal definition of what someone has called "Software Test Engineer" in a job posting means by the title.
It means whatever it means to the person who told the job poster to write in the job posting. Usually, job postings have lists of relevant experience, certifications/degrees, and tools familiarities which will give you some clue.
Most software testing is Ad Hoc (read: "not reproducible without activity logging"), and most automated testing is reactive (read: "sure hope we don't see this bug again, let's write a test which will probably never fail again"), rather than a result of a formal specification to which actual software behaviour can be compared.
It's possible to get to the point where software testing is a formal discipline, but in general, no one seems very interested in doing so unless you are talking about life support systems (e.g. getting correct results from medical equipment, not sending a reactor hypercritical, or not crashing a Mars probe into the ground). Even then, desire is not frequently reduced to practice, and mistakes are made.
PS: attempting to cram for an interview almost always leads to bad things: claims on your resume to knowledge you do not have in depth, and can not answer deep questions on, or worse, getting a position for which you are not qualified and futzing everything up for everyone else involved.
-- Terry
Save companies money and have the PROGRAMMERS pragmatically code the application in the first place.
Basically, don't trust ANY input, validate input EXHAUSTIVELY, and catch EVERY POSSIBLE non-user-input I/O error (disk full, socket closed, etc.).
You are done!
This is likely what they did when they coded the software for the now-grounded Space Shuttle flight systems. They even went FURTHER than that by designing 3(?) different systems by 3 different groups that ran together. As long as 2 or 3 systems agreed with each other, everything was OK, otherwise the alarm would have been raised.
when they call you to schedule an interview, hang up on them.
.. software custodian -- ie: janitor.
there is no path from "software testing" to software engineering, in that paradigm.
freelance, intern, do anything but "testing". it's a euphemism for
The job of a tester is to put together a meaningful plan...
...and then not use it.
http://googletesting.blogspot.com/2011/09/10-minute-test-plan.html
A software QA professional reviews the specs before coding the determine potential failures, and has them addressed in the spec beforehand.
Then to validates that it works correctly, as per the spec.
THEN you break it. Document the nature of the breakage, and note the issue catagory for future spec reviews.
Software QA is not just it's own process, it's improving the whole development process.
A testers first responsability is to be a nitpick and a giant pain in the ass for developers. If you aren't you're doing something wrong. I _am_ speaking from experience, being a developer and the best testers were nice guys, but TERRIBLE nitpicks, naggers and know-it-alls, forcing me to improve the software continuously. So there...
is to assert the product quality ... so whenever your "developer-self" thinks: "this could never possibly break" -> be even more sure to test the hell out of it :D
I have been a test manager for years, that includes doing intakes with new testers. Whilst I highly value development skills, the worst testers are those that just do it because there is a need for testers right now. I always look for that the tester: really chose to be a tester, and did not make that choice just because they couldn't land a contract as a developer.
There will be exceptions, but most are either gone the moment they do get a better offer or worse, when they find flaws in the software, they try to fix it.
So my tip would be: either simply do not go for this contract, or come up with some real good explanation that you really want to test. The good explanation should not include anything that is based on money/bad market etc.
---
Tester to developer: "Your code as a bug". Developer to tester: "Your test code has a bug".
"Gentlemen, you can't fight in here! This is the War Room!" -- Dr. Strangelove
Tasks
1) Make sure you make nobody angry otherwise you'll be replaced by a h1b visa holder.
2) they want developers with qa or qa with development because they want the fox guarding the henhouse.
3) Regardless of how many bugs are found, the software will be released with bugs because companies don't care about software quality.
4) And remember: most likely your tester is an h1b visa holder because companies don't usually hire software testers who are US citizens.
I know a lot of people are going to say things like unit testing through to user acceptance test and everything in between or maybe taking testing off of developers so they can get on with more 'important' stuff (see first post).
But all of that is the technical skills and knowledge that you need to do the job. At the end of the day, you are meant to be an advocate for the end user, argue to get bugs fixed, don't accept "Thats how it's meant to work" just because the spec said that is how it will work if that doesn't help the user etc.
Also, grow thick skin and be prepared for cynism to creep into your view of the world (or maybe good testers are already cynical?)
It's a job which breeds a negative view of live, you spend your time not producing anything directly sellable and tearing other peoples work apart.
These comments are my personal opinions and do not necessarily reflect the opinions of the other voices in my head.
Software Testing is a very unique job, its not just sitting at a desk and following a series of steps to test a software product. I was a software tester for 8 months as a coop student and I would say the biggest surprise was that software testing had no good formal description. When I did my software testing I used more experimental methods then formal methods. I personally never saw the point to formal testing, formal software testing never made and sense because software never preforms in an exact formal way. if 99.99% of a software's running time is produces output x, y ad z that means 0.01% of the time it will produce x, y and t output. The goal of a good software tester is to find a way to produce the 0.01% case and document it. When you preform formal software testing your only following steps to make sure you produce 99.99% of cases which doesn't really tell you a lot.
Software testing should NEVER be outlined by the developer, a developer will ALWAYS be biased on how to test there software. It's also important that the developer listen to the software tester, I had more then a few cases were company's told me to screw off when I was able to exploit there software through testing. Software testing is literally like solving a mystery, you know something will happen and you need to find the steps of a bug to get from stable to issue.
A "Software test engineer" job can mean pretty much anything, and you should find out before accepting.
It can be focused on finding bugs, or on ticking off a list of tests to have passed before shipping.
It can be close to the code, or with the product as a black box.
It can be detailed functional tests, performance tests, or big statistical simulations running for days or weeks.
It can be work together with the developers, or completely isolated from them.
It can be manual GUI testing, automated, or with a complex mix of test tools
The tester can be (perceived as) a low-level grunt, or as the person who knows the product the best; the end users' only representative.
If it is, your job gets to be very complex. Agile User stories are usually incredibly loose in specification (Example: In order to do my job better I need the printing to be faster so that I can match my quotas as an Accountant). As a Software Engineer I have one concept of "faster". As a tester you need to have the customer's idea of "faster" in case it doesn't match mine. Worse yet, faster may really mean "ignore the fifty times I punched the print button because I'm under a lot of stress". Our testers also need to present the iteration results to the clients - so that the clients keep believing that they are worth the money they are being paid. You will also need to have the political savvy of a genius - you are telling an overworked Software Engineer that they are wrong, and you are trying to wring technical details out of the representative for a department that may only know their side of the story, and is so focused on the workflow that they are used to that they won't accept a new one, even if it is better... and you also will have to deal with previous test cases representing the prejudices of the previous test engineer. I respect my testers, and try to keep them from going postal as much as possible.
where the hell do you think the US defense budget goes? of course raytheon etc can do tests like this, because they literally have money to burn
i'm not saying it happened like that, but defense R&D can easily get this bizarre
Why use the expensive Tomahawk when Harpoons are cheaper?
if you've been paid to test the capabilities of a defense platform, that's what you do. the op only mentioned testing guns, but the test could easily have included functions of the tomohawk missiles.
you might as well ask why develop nuclear weapons when a slingshot is cheaper. a harpoon may be similar to a tomohawk, but obviously there are differences (a quick google search reveals that tomohawks have significantly higher range than harpoons, and can carry nukes).
Your primary job as a QA Analyst / Test Engineer is not to make sure the code is perfect. It's not to make sure the developers did everything right. It's not to catch the developers doing something wrong.
Your primary job, is to give the project team, including the business interests an accurate view of the state of the software. You tell them what's good, what's bad, what could potentially be flawed, etc.
A good developer could be an excellent tester, but it's a major paradigm shift for most developers.
Lots of advice already given, one point... There are many companies out there looking for testers that can code, often unsuccesfully. So if you can code are are happy to do test automation you could potentially have a strong advantage. Many testers are not coders, they don't always have to be, but as a result it puts uber techie/developers in a stronger position if they are looking for a testing type role.
Actually, it was 5 IBM AP-101s, four of which ran identical software, with the fifth running independently written backup flight software.
http://en.wikipedia.org/wiki/IBM_AP-101
-- Terry