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?"
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?"
Taking builk testing responsibilities off developers so they can work on more important stuff.
Try again. Repeat.
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.
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 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.
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.
hth
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
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.
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. :)
Reading and understanding requirements....Writing testing strategies, test cases, and low level testing scripts that can be traced back to the individual requirements that they test....Understanding which test cases map to which functional blocks of a system....Identifying which test cases should be part of a regression pack and keeping that pack fresh through various versions of the software....running that regression pack when requested during future development cycles...performing change impact analysis to select subsets of the regression pack to test various changes...etc.
....and if it is a manager position then add in all the people stuff on top.
...and of course executing test cases and tracking the results.
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.
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.
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.
Definitely! You are checking a list of features,however you don't get the features list solely from the software - you get it from the Business Requirements Document - you are testing that developers have delivered what has actually been asked for by the people who are doomed, sorry, destined to use the software.
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.
... 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.
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."
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.
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.
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
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.
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
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.
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
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
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 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...
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
Taking builk testing responsibilities off developers so they can work on more important stuff.
More.. important.. stuff, than making sure their code works?
I mean, I guess "a developer" is someone who "writes code" regardless if it works well, or at all? By that reasoning, "a thousands monkeys on a thousand keyboards" is the gold standard for programming excellence?
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.
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).
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