Hot answers tagged

22

Good and Interesting question. Here are some to make the tester's job easier: Developers should perform basic testing before giving the product to the tester. Include QA from the beginning of the project, not when the product is ready to test. Work as a Team, not as two different departments [Developer & QA] As the developer, never ask the QA to ...


16

Java Bean, I think you may want to ask yourself a few questions first: do you want to be involved in testing or in programming? In my experience, colleges are usually less than stellar in the QA domain, and tend to assume that testing is "any warm body" and useful to familiarize someone with an application before they start coding with it. do you like ...


15

In my experience, the best developer/testers bring what I call the boredom herusitic to software testing. Inother words, they often automate rote tasks so they can focus on testing and analysis of the software. An example I use often is the "add contact" feature in an instant messaging or email client. To test the feature, I'd need to try long names, ...


13

Treat them as equals. I have seen a lot of developers thinking they are more or better then testers in their companies and also treat them that way. Developers and testers have a similar goal: Making high quality software.


12

You describe several skills that are advantageous in a tester: analytical skills, the ability to find flaws, and tolerance for repetition. You also seem to be interested in testing. A potential disadvantage from your own candid admissions: reluctance to take ultimate responsibility and, to a lesser degree, discomfort with starting something from scratch. ...


11

Like Sam points out experience with SQL and/or with MySQL will greatly depend on the project and/or the company with whom you hope to work. SQL skills are one aspect of Software Testing that focuses specially on technology. James Bach, an expert in the field of Software Testing with 20+ years experience, published a Tester's Syllabus for those who are ...


11

Personally I find that tester who codes in addition to great testing skills is much more effective than the non-technical equivalent. A techical tester can esentially bring more "weapons to bear" on testing problems than you could without those skill sets. Some examples: Need to generate some test data? Write a tool to do it. Need to check security access ...


11

Just a few quick ones off the top of my head: Run the code they've completed at least once on their machine before marking it as 'Done'. Consult with QA on their intended route to implement a feature or bug fix to help flush out potential issues or bugs before even one line of code is written Encourage QA to participate in sprint planning/grooming, design ...


11

I've worked in both roles for a while and my recommendation is: Pair (before coding when possible) on test plans See QA as an asset that is protecting you and customers from the mistakes we all make Have an open mind when a QA approaches and avoid the (common) mistake of explaining away an issue as their lack of understanding Don't assume that they can ...


9

I never see common agreement on any software-related titles. In some shops where I have worked "Architect" implies a thinker, not a doer. For QA Architect, it means someone who thinks about QA, researches and suggests improved methods and metrics. Sometimes it's someone who trains others. In other shops, "Architect" just means "very Senior". It's the ...


9

Professors make this suggestion. I suspect many of them don't actually know what a QA career entails since most of the professors I know are a bit divorced from the world of business. For more information, I'd suggest reading this very similar question (Fundamental Requirements For an Entry Level QA Engineer) and my response to it. Some specific skills ...


8

I've had success using tester/developers for code review of production code. I've found that developers review code thinking, "Will this work", while testers review code thinking "In what ways could this not work". I've also found that most testers discover new test ideas while reviewing production code. I wrote a paper on the experiences of our team in ...


8

I tend to prefer allowing anyone in any capacity to log defects on any team I am a part of. It helps build a sense of ownership of quality in the entire team, which is as it should be, every team member regardless of role should equally own and care about quality. It is a different story when people outside of the project team are entering defects, I would ...


8

Without being flippant, this sounds like you've got a serious communication problem in the team. Given the limited timeframe, here's a few things to consider: everyone in the team needs to know what a good bug report looks like everyone in the team needs to search for a bug report on the issue they're seeing before they write up a bug report. This means ...


7

Xenu Link Sleuth (http://home.snafu.de/tilman/xenulink.html) can do that and more. It's easy. It's fast. Best of all, it's free! (Free as in $0, but not Open Source)


6

It's always a challenge to change careers. And as a hiring manager, a red flag always go off when someone wants to change careers and get hired onto my team. I see a few here. You say that you are burned out as a developer. That's understandable. So are you considering QA as "easier"? Less likely to cause burnout? Be prepared to discuss this in depth ...


6

A tester can add value to the product and development team by making/influencing key software design choices even before coding starts. Testers with programming background can understand and explore possible software design choices for better code testability and they can determine "if the code is fit for use?" Design choices like "Dependency Injection" and ...


6

Welcome to SQA. I assumed you're a tester :-) In short, do devs like being bothered by testers? Well, that depends on many things. If you find a bug and won't bother a developer to fix it or answer area around it, she might bother you to explain it better later, when you're busy. So it is in interest of both of you to find the right time. Finding ...


6

I am working under the assumption that you would be familiar with the language the tools are being written in. If the team you are on already is writing unit tests a good place to start might be with them. Talk to the developers that are writing the unit tests and get an idea for how the underlying code is working. In the process of doing this start ...


6

A few thoughts based on my not-quite-ten years experience as a tester and automator: Learn the principles, not a tool - If you understand the principles of automation and how it works, you're going to be in a much better strategic position than if you simply learn an automation tool. You could do worse than to dig through Joe Strazzere's blog and Alan ...


6

To start off, have a positive attitude towards tester's activities & identified issues Provide unit + dev-smoke tested builds to QA Share release notes with info like included fixes, features and known bugs etc Provide support in technical & back-end understanding of system Provide support in analyzing hard-to-reproduce issues Be appreciative ...


6

This is a simple point, but very effective: Be a developer who says "thanks" or "good catch!" or something positive whenever a tester finds a defect. It's the daily currency of the respectful working relationship. All the formal processes are good, but they flow from the basic attitude of respect.


6

In addition to Michael Durrant's excellent answer : Take time to make accurate bug reports. My rules of a thumb(I've been on both sides of the equation, which helps) : Every hour spent in digging into the bug from the tester's point of view spares one day of work for the developer. Properly checking the exact conditions of the bug, the exact parameters, ...


5

Some general skills carry over very well. 99% of it comes down to the mindset. My testing career started in electronics manufacturing. For most of the assemblies, there were only a few pre-determined tests that were run on them that were always black and white in regards to pass/fail. The only time that we were given the chance to be creative was with ...


5

SQL is specific to the project you're working on. Knowledge of SQL may or may not be applicable to a SQA position. I would say there are probably more SQA positions than not that don't have that requirement. The most important thing for an SQA position is logical problem solving skills. Especially for entry level SQA positions most of the focus will be ...


5

I would start with what you have, the inputs and outputs, then start questioning. I like to go through a bunch of what if's, such as in your case "what if the database is unavailable?" or "what if the mail queue is full?" or something like that. If you can't come up with questions like that, then ask the developers "what didn't you test that you think I ...


5

There's no one true way to do this, but there are some common things you can do to get an overview of the system you're working with. My approach is to start with a series of questions (not in any particular order) Who - who is the application intended for? Knowing who the users are tells you a lot about how they're likely to want to use the software and ...


5

One of the options is as you have already tried - browserstack. Then you can install android SDK on your machine. It provides an emulator for various screen sizes and android os. For iOS you can try the xcode. I haven't used it personally but it is somewhat like the android sdk but for iOS. You will need Mac OS and iTunes store to install it. BUT No ...


5

All the answers so far are good. A few other comments: Remember that the testers aren't there to make your life miserable. They're there to provide business stakeholders with information about how well the software fits what its intended users need from it. Don't just throw code over the wall and figure the testers will catch any bugs. They might, but ...


4

First of all, it is understandable that a former developer might approach testing in terms of individually testable layers or sub-components. However, as a tester, if you do nothing else, you must verify that the finished product behaves correctly when exercised using whatever interfaces the end-user will use. Everything else is secondary to that -- ...



Only top voted, non community-wiki answers of a minimum length are eligible