Tag Info

Hot answers tagged

31

Testing aptitude Willingness to ask questions Ability to negotiate Technical ability (reading and writing code) Strong communication skills Curiosity Tenaciousness


30

Should QA push for programmers running QA's automated tests? Yes, but I'd also suggest that if the programmers don't seem to, it's probably more productive to find out why before pushing harder. What's preventing them? Access to proprietary test tools? Difficult to setup easily on dev environment? Results not meaningful or easy to read? Too slow to ...


21

Disclaimer: I am approaching this as a programmer (who is here mostly to learn how to better interact with our testers.) It's important to remember that the developer has not always been told how to test the code. Although we wish it wasn't true, the developer was given a set of requirements from someone who really didn't care about every aspect of the ...


18

Although unit tests are normally good enough, it's nice to see a developer ensure that they've run a process from start to finish, not just the unit tests. Because the types of tests that should be run vary greatly with the type of application, I would discuss with a testing point of contact for the product. With new developers to me, I usually ask them ...


18

No - there is no "right" ratio. The answer depends on the product (is it a web service providing junior hockey scores, or a space ship?), and the roles that programmers and testers play on the team. I've seen highly successful teams with a 15 or 20 to 1 programmer to tester ratio, and teams with a 1 to 1 ratio that made crap software. In the high ratio ...


17

The tl;dr: Technical Acumen Communication Diplomacy Curiosity Drive I've always felt that technical skill was one of the more vastly overrated attributes of test engineers. Certainly having technical acumen is critical to executing tasks, working with product managers and software engineers but it's only a portion of the actual job. Again, I'm not saying ...


15

What has worked well for me is the following steps. The developer makes their best effort at writing good code. The developer gets a code-peer review from another developer The developer runs their unit tests, and checks that they all pass. The developer and the tester sit down for a review: The developer walks through with the tester to let them know ...


14

I definitely feel your pain. As noted in a question I had (I'll link in a minute) I too work for a 10-digit revenue company, and our primary software has 0 automated tests for over a million lines of production code. It boils down to the same philosophy that a lot of developers have about using external libraries rather than rolling their own: we fear what ...


13

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, ...


12

In my experience ... Execute, YES. Maintain NO. Context for my comment. I am assuming Programmers in your question = developers of application, not testers with programming skills I think that there is an inherent motivation that testers, (even dedicated software engineers in test) have that developers don't, and that is that writing, running and ...


12

Dedicated Testers I think that it is important to highlight that the role of being a tester, is different to the job of being a tester. There are many situations where you need testing, but you simply can't afford or are unable to have dedicated testers, i.e people who have that job 100% of the time. You simply don't have enough testing, or resources to ...


12

A good test manager has a number of key attributes. I tend to think that the best managers are like good, professional sports coaches. They have played "the game", at the highest levels, they know what is required to be successful and achieve the results you are after. Translated, they should be a great tester themselves and be able to test hands on if ...


11

If you are the sole tester, and might continue to be for a while, it probably doesn't matter much if you choose whatever tool you personally prefer. But if there is an expectation that other programmers will contribute to test automation, you should take their needs and preferences into consideration as well. Then again, when your company grows enough, you ...


11

I found Jerry Weinberg's comments about pinpointing in "Perfect Software: And other illusions about testing" really helpful. (My copy's at work, so this is from memory). Jerry comments that responsibility for pinpointing a bug's exact location sometimes lies with the programmers, and sometimes with the testers. In my experience, the most trouble occurs when ...


10

Excellent posts! Apart from what's already been listed, I can add another (somewhat context-specific)... a willingness to represent user / business interests Coming into software testing from a UAT / business-side of things (I'm still working on developing the technical skills), a willingness to be able to talk to the business (be it managers, users, ...


10

Adding on to the above answers: Does not get bored easily. I've found that some of the better testers were ones that didn't get bored clicking the same buttons over and over again in The Great Bug Hunt.


10

I always want an independent, dedicated, competent tester to test my code. However, I also always want a personal chef to cook for me. I usually can't afford that, either. Most developers have not worked with a truly competent tester, and so they don't know what that is like. For me, the few times I've had that, it was great. Having an ...


9

If the QA team is not embedded in the development team I don't think the whole process will run smoothly. Development should always write unit tests, not the QA team. This is because development has more insight in the code. I would let the QA team write more functional test scripts.


9

Great communication Analytical thinking Asks "why not" questions No fear (confident) Team player, no "long ranger" mentality Knows when to push the envelope & when to let go Grasps concepts easily Loves to learn Belief in themselves & the product (ie not a quitter)


9

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 ...


9

I think you'll need to understand why they are being nay-sayers. It may be that you've landed in the snake pit of office politics and you're wondering why because herpetology isn't written in your job description. Some of the complaints you may have heard from the Knights Who Say NIH (Not Invented Here)! may include: Why Change? We've always done it ...


8

I think it depends on two primary elements: Are your testers embedded on your software engineering teams. Is the output of your tests intelligible and useful to engineers. Obviously it's folly to think that engineers could run tests from some other shadowy team that they have no rapport with. However, if you do have engineers and testers embedded on ...


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

Eduard, welcome to SQA. I will assume you are that developer. I think there are a lot of ways a developer can help a QA team. The most obvious way to help would be to write automated tests or to write tools that make testing easier, e.g. creating test data or automating a deployment. You may have skills outside of coding that would also benefit your ...


8

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 ...


7

This depends on the organization. Where I have worked, QA teams tended to prioritize breadth over runtime or simplicity of setup. The "QA environment" may require some special settings and configuration for mock objects, fake data, and so on. Developers, on the other hand, prefer tests that run quickly so that they can be integrated into their ...


6

I would make it automatic post-commit (via a trigger, or preferably a build system) that some kind of test is run. If the test is too extensive, then scale the post-commit test back to run in a reasonable amount of time (so the dev gets feedback quickly.) If the longform test (because longform makes it better, right?) takes X hours to run, I would ...


6

Should QA insist that all of their automated tests pass before checking in? At my last employer, the QA test suite involved multiple operating systems (and several different service packs of each), so it would not have been possible for devs to run those tests as part of the smoke/tdd tests. Some of the other tests could not be automated as they ...


6

If possible, sit down with them, explain the bugs. Explain how you found it and ask what kinds of tests they run before they say that it's ready. Start giving some suggestions. I've always found that starting the code quality discussion with some polite, constructive feedback has yielded the greatest results, letting them decide what what they think is ...


6

In the past I have approached this by firstly defining the "quality bar" as to what is expected and had this agreed by the whole team. This includes setting a defect threshold for the whole team (usually 0 Sev 1's and 10 bugs per developer). When a developer or the team gets above this threshold they must stop adding features and fix their bugs. With this ...



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