What Does a Software Tester's Job Constitute? 228
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?"
it means (Score:2, Flamebait)
telling the developer he's right about everything and the product is never broken, or the tester will get a tongue lashing.
Re: (Score:2)
Sounds like someone's got a case of wanting to be a product manager instead of a tester.
Some developers appreciate their QA people (Score:5, Insightful)
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.
Re: (Score:2)
Re:Some developers appreciate their QA people (Score:5, Insightful)
I am a developer and I tell my testers to consider me to be evil, lazy, and malicious. They must assume I am actively trying to fool them into thinking the application is working even if it is not with the minimum amount of work possible. That generally gets them to find the defects.
Re:Some developers appreciate their QA people (Score:5, Insightful)
Re: (Score:2)
I tell them I'm full of laziness, impatience, and hubris [c2.com]. And it's all true.
Re: (Score:2)
My QA tester was a contractor, and very good indeed. Among other things, he was totally invested in the process of delivering a great product. Contractor or not.
And he was let go, as we are making QA and UAT the developer's in-house responsibility. Don't bother to tell me how lousy an idea this is, management has their reasons, without consultation. We would normally predict failure, but it turns our they are releasing a beta of an entirely new product to replace this failed product within 2 months of t
Re: (Score:2)
As a developer my OP was more of a joke about my dislike of the arrogance of developers in general. and what seems to be all to often the talking down to the testers.
Re: (Score:3, Funny)
Sounds like someone is butthurt because he got chewed out for filing shitty bug reports that were vague and useless.
What Does a Software Tester's Job Constitute? (Score:5, Funny)
A: Suffering
scripts (Score:2)
To paraphrase an AC [slashdot.org], 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.
Re: (Score:3, Insightful)
Which as a developer I hate. What I really want testers to do is write automated tests. The only hand test a tester should do is one to see what the automated test should do. Yes, reality ends up being a mix, but reality should be informed by the ideal. It irritates the hell out of me that testers are doing the same thing over and over, that is what computers are for.
Re: (Score:2)
I say this as an automated tester who absolutely hates manual testing. I can't deny its importance, though.
Re:scripts (Score:5, Informative)
I have to disagree. I've never worked somewhere like this, and I've been in SQA for many years at many jobs.
If you want to be a low-paid button pusher, yes. Do the same thing over and over, all day long with no deviation. If you want to enjoy your job testing, test the software. Try to break it. Troubleshoot. Do things the developers wouldn't expect. (After all, who expects an apostrophe in a name field? "We only expect regular text, right Mr. O'Hanlon?")
The job of a software tester (tester, not button pusher) is to try to find all the defects in the software and report them to development so they can be fixed.
BREAK IT (Score:5, Insightful)
Go down a list of features.
make sure they work one at a time.
then try to break them anyway.
Automation or manual testing? (Score:5, Informative)
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.
Re: (Score:3)
Re: (Score:2)
If you're very lucky, the software will already have a list of requirements [amazon.com]. And if you're almost as lucky, your first job will be to create it.
If you're not even that lucky, then you're pretty much screwed.
Re: (Score:2)
How about usability testing?
And maybe accessibility? (this one is particularly of concern for web sites)
All I see in this discussion is how to find sofware bugs and issues that crash the software - important sure, but that doesn't mean the software is easy to work with. Having a design team that designs the UI beforehand also doesn't mean there are no bottlenecks there.
Good software for me means that the software not only does what you expect it to do, but that it's also easy to use.
Testing scripts. Lots o' em. (Score:3)
Re: (Score:3)
The job is probably somewhere between these extremes:
Just say no (Score:2, Insightful)
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.
Re: (Score:2, Interesting)
It depends. Often if you are moving to a better or bigger company they will start you in test. A lot of people move on, but test can be great.
You typically work less hours.
Test Automation can often be more difficult that the Engineering positions.
The pay can be just the same.
Re: (Score:3)
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.
That depends entirely on the company. Some of the big software companies, like Microsoft as an example, pay equivalent salaries to people who are SDE or SDET at any given level, and its fairly common for people to move back and forth over the course of their career. (Microsoft, to use the example again, has both SDET -- software development engineer/test -- and a very small number of STEs -- software test engineers. The latter are basically click testers, the former are software engineers.)
A lot of it comes
You are going to be the one who knows the software (Score:4, Insightful)
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.
Re: (Score:2)
...
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 includin
Re: (Score:2)
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
Re: (Score:2)
Very interesting what synapses got switched on in your system. Please have all the breaks you need.
Re: (Score:2)
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 [blogspot.com]
makes COBOL look like a paradise (Score:2)
Re: (Score:2)
That's why the good lord invented GUI scripting systems.
Re: (Score:2)
If you plan on testing something more than once you're probably wasting your time if you're not automating it. It's wasteful, unreliable, and makes it very expensive in time and money to release new versions, or even patches for old ones.
Re: (Score:2)
If you plan on testing something more than once you're probably wasting your time if you're not automating it. It's wasteful, unreliable, and makes it very expensive in time and money to release new versions, or even patches for old ones.
We automate what we can, but there's quite a few things that aren't well suited to automation. A big problem for us is the various display issues with different browsers, or bugs in our stylesheets. That's not something you can automate easily.
Re: (Score:2)
I'm sure there are also testers that think development is like this, a big inevitable slog. You are both wrong.
Are you Sure you are a Software Engineer? (Score:3, Informative)
Re: (Score:2)
Your right, you cannot become a SE in any worthwhile college without a course or two mentioning testing and specifically the job of Software Test Engineer.
That is stuff they start teaching in SE 101.
Pretty wide berth of possibilities here. (Score:5, Informative)
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.
Re: (Score:2)
Best answer so far!
I once did a contract job for Conexant, devloping software to acquire and stuff test results into a database, format reports, etc. (for Docsis cable model qualification). Now I wish I'd never put that on my resume, because I get calls for "software test" all the time.
At Sony I got to see game testing. Now THAT was a three-ring circus! Signs posted about no sleeping in the halls, and no hats or sunglasses... Some of that testing actually is just playing unreleased games and recording your
QA (Score:2)
Most of the job is fairly mindless, just reporting errors to the main developers as bugs so the devs can work on fixing them.
a lot recruiters talk out of there ass / have no i (Score:3, Insightful)
a lot recruiters talk out of there ass / have no idea about job some times there is not even a real job there.
Testing is applied epistemology. (Score:2)
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.
I am a software tester. (Score:5, Informative)
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.
Need more input (Score:2)
"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.)
Variety Pack! (Score:5, Informative)
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.
Re: (Score:2)
There's a "horizontal" distinction in testing, by colour: Black Box, grey box, and white box.
Black box is what the post above is doing - everything "under the hood" is not to be looked at, only the results. This is the easiest form of testing. It can be automated using scripts, if the UI's field order is stable. I like Black Box - you just get to "fuck shit up". My fave was to copy and paste the Unabomber manifesto into everything and watch the
Re: (Score:2)
require or have option for clearance? full/part time?
Re: (Score:2)
- 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)
Don't forget in this case to try Unicode text and make sure it comes out or errors out appropriately.
This is especially important if one of the tasks is to adapt the information for another system which may be Unicode-unaware - how does the output come out on the other end, and does it still work? Or does
Suicide (Score:2)
hth
It could be something good ... (Score:2)
Depends on the company and the software package. (Score:2)
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
Being dumb (Score:2)
Golden Rule of Testing. (Score:2)
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
Test Engineer (Score:3)
from Project Management perspective... (Score:2)
comic (Score:2)
Everything I know about testing, I learned from The Trenches [trenchescomic.com].
Oh, and doing it myself, of course. Of course I test my code. Why? Who's asking?
BEWARE! (Score:2)
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.
It's just what it says it is.... (Score:3)
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
A QA Engineers testing tools and skills (Score:2)
Run! (Score:4, Insightful)
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#...)
Re: (Score:2)
Responsibilities may include fixing mistakes from outsourced testing, and going to India to handhold them through the testing process.
...If there's anyone left from the original team with the knowledge.
Testing is one of those "costs" that PHBs and Bean-Counters love to cut continually since, to them, it is only cost that could be diverted to profit. They don't understand the importance of testing. After all, if the engineers (who are now a commodity) are doing their jobs properly, everything should be per
Make sure the position is crystal clear (Score:2)
Good Test Engineer == Dev/QA Toolsmith Automator (Score:2)
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, networ
What my friends have told me ... (Score:2)
... 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.
As Far As I've Been Able To Tell... (Score:3)
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?
Constitute? (Score:2)
Among other things, a software tester's job CONSTITUTES the software development process. I think you mean "consist of"?
TPS (Score:2)
You don't want software testers... (Score:2)
Seriously, this... (Score:2)
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 m
It's like a belt sander in the toilet (Score:2)
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.
Avoid it. (Score:4, Informative)
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.
Re:Avoid it. (Score:4, Interesting)
I'm a software tester in an organisation which has clear delineation between manual testers, software test engineers who build automated tests and developers (I gotta say that I speak for me and not them here - that's the policy out of the way). The first two of that list need to have a 'question everything' testers' mentality; the last two need to have a technical grasp of how the whole thing works, from the core OS, servers and transports to the libraries used and the UI.
A manual tester is concerned with the human experience of your software. Typically there will be a script of the exact actions or the class of actions the manual tester is expected to cover. Some firms roll regression testing and new feature testing into the manual tester's role, others have a separate user-acceptance testing team who stand between released software and deployment.
The automation tester's role is to make the computer test the software, by building a framework around the program and its installed environment to check the system as-a-whole does the intended job. Some automation testers also write unit tests in the core program code; mostly this is left to the developers, who are increasingly being asked to show that their code works - and doesn't break the existing code - before check-in. Some places operate a Behavior-Driven Development (BDD) process where client needs are expressed in testable ways - so that the evidence that your software does what a client wants is written down clearly for the client to see, the tester to test and the developer to build. Some BDD systems even build tests which show that these goals are met, and are known as Test-Driven because the proof of rightness is shown by the tests.
Preparing for an telephone screening or interview about software test engineer, you will need to show that you're technically-minded, that you've worked engineered a test system before, that you understand the benefits and shortcomings of building such a system (such as knowing when to build tests and when to leave low-hanging test fruit to manual testers), and that you're concerned for the quality of the product more than for building a new toy test rig.
I disagree with nearly every point made above, but I know this as a tester: there are a lot of people who shuffle into testing because it's the gateway to working in software. That's no bad thing. But mix it with the lack of confidence to apply for and get developer roles, and you will probably harm your sanity and your career. In every job, you need to be competent and confident. On top of that, you need to be personable so, for example, you don't make bug reports critical of the developers who made them (and know how to calm down a dev who's got that idea).
To be a good tester is genuine hard work requiring the best of your technical insight, pedantry and commitment to high standards, but to be a great tester will call for charisma, kindness, honesty, good working relationships, and the skills to help make a dysfunctional team work right.
If you're only a tester for a short while and move on to a developer role, you can either blame the economy for not having enough dev jobs (so you compromised in order to fulfill your passion for making software), or you can say that you wanted to improve your developer skills by learning what it's like to be on the other side of the fence as a tester. It's not a black mark if working as a tester makes it a benefit to you and a prospective employer.
QA is NOT a subset of development (Score:2)
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.
Testing (Score:2)
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 varia
You can not cram for this particular test (Score:2)
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
I would not hire you... (Score:2)
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 tr
bugs in code (Score:2)
Re: (Score:2)
Can mean anything (Score:3)
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.
Re: (Score:3, Informative)
Taking builk testing responsibilities off developers so they can work on more important stuff.
The epitome of a tester (Score:4, Funny)
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.
Re: (Score:3, Funny)
Any tips?
Yes. Review the Anonymous Coward posts in this thread. Many of them were written by software test professionals who don't want to speak frankly where their employers or others can associate it with their name. Many AC comments here are very good.
Developers often make poor testers (Score:5, Informative)
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.
Re:Developers often make poor testers (Score:5, Informative)
Indeed. Some stuff happens from weird ways that users try to do things that developers simply wouldn't think to test. Case in point, bug I found today: someone bought a six-month subscription by entering 0.5 as the quantity on a 1-year subscription. Our code wasn't expecting non-integer quantities, but happily did the math to get the line-item subtotal. When the data was stored, the 0.5 quantity went into an integer column, which the database cast to an integer by rounding down and suddenly qty * price != subtotal. It was caught and quickly fixed by a data integrity check, but a QA/dedicated testing person that thinks of weird user interactions like that could have prevented it from going out to production in the first place.
Now we have one more thing added into unit tests so it won't happen in the future, but there you go. The code was not untested, it was just used in an unpredictable way.
Re: (Score:2, Funny)
Input testing. I imagine most testers have a love/hate relationship with it. It can be one of the most boring forms of testing as you throw in endless permutations of seemingly random data. But it also where you're most likely to discover the most satisfying kinds of bugs; ones that don't crash the software, but instead trick it into following the most absurd scenarios. Discovering that you can enter scientific notation in a field limited to 10 characters and create loans that cost more than the entire net
Re: (Score:3)
Testers must have cackled with glee (and C++ developers cried) when fuzz testing [wikipedia.org] was invented.
Re: (Score:3)
Developers shouldn't test their own code, but some of them are viciously effective at testing other people's code. For example, I knew a fellow who would regularly do perverse things during testing like pasting GIFs and JPEGs into text fields, trying to open binaries instead of XML files, and other such perverse things that regular users do by accident all the time. Very, very few people produced application code that this man couldn't break.
But he had a bit of history in testing. When he was working
Re:Developers often make poor testers (Score:5, Informative)
Yup.
I write test software, specifically software that acts on firmware. The majority of our devs do unit tests, but once the whole thing is assembled together and used as a system interactions show up that are not ideal.
You need some form of QA department between Devs and Customers.
As someone who is already familiar with software engineering you likely would be an ideal candidate for test engineering, because you know how software generally works, and can write meaningful bug reports.
For an interview, if they ask you for strengths, I would focus on your development background and ability to write meaningful bug reports.
-nB
Re: (Score:3)
A1 comment. networkBoy knows what he's talking about. I transitioned from software developer to test developer, and it's a different animal, but highly rewarding. Knowing how software works is a boon. You know how to write better bug/issue reports.
Test planning and devising scripts is big where I'm at. I do far more documentation and planning WHAT we need to do than looking at code. I do participate in informal and formal software reviews though to keep my mind fresh with code.
Re:Developers often make poor testers (Score:5, Informative)
I maintain the test infrastructure kernel. It's a constant battle to keep up with dev changes, they change a struct, I change the struct, for the most part they are well linked (we import their headers), but there are some things that simply cascade downstream bad enough to prevent us from even compiling, it's a niche job, half maintenance coder, half lone cowboy. I really like it, but most people don't last on my team. We have three devs that have been at this one job for more than 3 years. Everyone else either goes to just test development (our customers, and sounds like where you are), the rest go to the dev side of house (you can always tell which ones are going to leave outright because they bitch about the maintenance coding).
One word of advice to new test devs out there: Parent post is right, most test development is spent on documentation, a full 3/4 of your coding time is likely to be some form of maintenance coding, deal with it well and you will not hurt for money or employment. Bitch about it and your co-workers will not like you all that much, which makes for very long working days.
-nB
Re:Developers often make poor testers (Score:5, Informative)
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.
Actually, that is not necessarily true. I get what you are trying to say, but you seem to gloss over the differences between QA, manual tester, and what the OP was referring to: Software Test Engineer.
To highlight some of the differences:
QA is responsible for "assuring quality". This is different from QC which is "checking quality". More often than not, a good QA is a process expert, with the assumption being that good processes ensure good quality. Their goal is to avoid the problem, not to detect the problem or fix the problem. Where the line gets blurred is the fact that a QA often performs the role of a manual tester. This usually depends on the size of the team.
Manual testing is usually QC - understanding what to test, how to test, and going ahead and testing it. They start off by translating the requirement specification (or user stories if you are agile) into a suite of test cases, add other test cases that might be non-functional or regression related, and finally test the system manually every time before it is released to customers.
Generally (although not always true), a "test engineer" is more of a developer than a tester. They are usually tasked to develop test frameworks using third party tools or even creating their own framework. The former usually involves scripting and lightweight coding and the latter can involve full blown coding. They can be developing a test framework for executing and managing unit tests and functional tests (often white box), and integration tests, regression tests, and performance tests (often black box). While many project teams skimp on devoting this much engineering to testing, it can give huge returns, perhaps even better returns than development can after a certain point.
To be fair, the OP has not mentioned anything else beyond "software test engineer" so the role might very well be manual testing. However, the word "engineer" leads me to believe it is more of a automation role. Having said this, companies often embellish their titles with "engineer" to make it sounds weighty.
Re:Developers often make poor testers (Score:5, Interesting)
Sometimes professional testers make poor testers. I worked on a project with a professional tester who did her job conscientiously, wrote test procedures and methodically exercised the software. We also hired some college kids during the summer and assigned them to test the software. They just tried things. The kids found a lot more bugs than the tester.
How is that a criticism? (Score:4, Insightful)
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.
Re: (Score:3)
One of your mistakes is rating by bug count. Another is thinking that a tester's job is to find bugs. What you ignore is the quality of the bugs your professional found. I'm willing to bet she found bugs the college kids would have never found. She also verified that the software does what it says on the tin. If she's spending her days filing bugs on BS defects like typos and "this button doesn't do anything", you're wasting money and boring her to death with crappy code.
Finally, if some random college kids
Re: (Score:2)
But if your job is to test then you are not going to just fiddle with the program for a while and then give it a pass.
As a professional tester you come up with boundary cases and test rigorously.
And it is not necessarily on a gui level.
Re: (Score:2)
We can spend months developing a new feature on one our embedded systems. Once we are done, one of our company owners will have it broken in under 5 minutes. We call it the "Kevin Bug", aptly named after said owner.
Sometimes we toss an early and intentionally broken feature at him, just to get the Kevin Bug out of the way since that tends to be most stressful stage of the feature cycle.
Re:Developers often make poor testers (Score:4, Insightful)
Similar, but there's a big difference here. The proofreader can catch every actual error so a sloppy writer can be saved by a proofreader. A tester can't test every case (assuming that they are not going through the code line by line, but that's really a development job) so a tester can't save a sloppy programmer, just mitigate the damage they do. Yes, testing is VERY important, but you can't test quality into a software product - you have to develop it in.
Stress testing and edge case testing are exactly the sort of testing I expect software developers to do some of and be good at. They should know what the tricky bits are and know how to bend the system to make things fail in minutes and hours instead of months of testing. Without that intimate knowledge of the internals (again, testers could have that, but it's very rare), a lot of stress testing just keeps testing the same thing over and over - not very useful.
Re:Ummmm (Score:5, Insightful)
Re:Boring test cases (Score:5, Informative)
Posting as AC but I've been a tester for over 10 years at different companies, many of them contract work. I very much enjoy the work.
Let me clarify many of the things about being a software tester (which can also include embedded software/firmware). From my perspective:
Following the test script as written is only a small amount of the big picture.
Issue characterization. It's not good enough just to report the issue. How often is it reproducible? Device specific? Configuration specific? Timing specific? Line by line steps to reproduce, what was the observed behavior, what was the expected behavior. Is it only on first time launch? Does it reproduce on a variant? Localization form and fit--even if the language is not fully understood, when checking localized builds for form and fit, is there any trucation or overlap, does text go outside the button areas? Does it always reproduce, or how many times out of how many attempts?
Severity determination--not everything is going to be a showstopper but properly rate the ones that are showstoppers. Also, a low severity defect can still have a higher priority if more than 50% or so of users will see the issue.
Exploratory testing skills are equally essential. Even after running the script line by line in order, what else wasn't covered? What if a different file is used, a purposely corrupted file--is the software still robust?
Quick turnaround on resolved issues. Verify the issue is fixed and close the issue, or reopen the issue with additional information as to why the issue still occurred. However--if the issue was fixed and a new issue is a side effect of the fix, then the issue resolved gets closed and a new issue gets submitted with many testing teams. They do not usually add the new issue to the existing issue except as a comment, so that closing one issue does not lose the other issue.
Teamwork--collaborating with other testers, developers, managers, maybe even conference calls with outsource vendors.
Test case authoring. Even in a pure manual testing environment, existing test cases need to be updated (or removed if a function no longer exists), new test cases need to be added for new functionality, best coverage in the least amount of test cases is the goal.
Automated testing--developing test scripts in the automated testing environment. This is programming for testing purposes in many cases.
It all varies from company to company, project to project--but in a lot of cases being a software tester is not about just go to the next test case and mark it pass, fail, or blocked/not possible for each working day, every day.
I hope this helps.
Re:Boring test cases (Score:4, Informative)