current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 0 down vote favorite

This question already has an answer here:

We've got a bit of a problem in the company and not really sure the best way to handle it. We have a small programming team putting out incremental releases in a legacy system that is somewhat unstable. The code must be thoroughly tested.

The problem is that our testing department is a small team with absolutely no testing experience or programming experience. They know the company and the expected outcome of the release, but have no programming skills.

My question is how can I best lead them down the path to becoming an effective test team.

Where should a non-programmer with no experience start to be a decent tester? Is there a book to read, website to go to to get them up to speed? I'm not even talking about something like unit-testing quite yet, but their job is testing. They've got the whole day to simply test code. How can I get them up to speed?

share|improve this question

marked as duplicate by MichaelT, FrustratedWithFormsDesigner, GlenH7, Jim G., Robert Harvey Sep 25 '13 at 19:14

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
5  
Depends entirely on the application and testing needs. "Black box" testers are important for any user facing application. A good black box tester needs to be analytical, meticulous and have good communications skills, but doesn't necessarily need any technical skills beyond those required to use the application like a user. –  Steven Burnap Sep 25 '13 at 17:21
2  
I've had end users with no programming testing experience at all, just using the product being the best testers I've encountered. Also non-native english speaker happened to have found the most typos and grammatical mistakes in some of the screens I wrote. What type of testing are you expecting them to do? –  MichaelT Sep 25 '13 at 17:24
1  
The best tester I've ever had had no testing or programming knowledge. She found more problems than 4 other people combined, all of whom had testing experience - no programming experience, but I don't see that as a requirement; it may even be a handicap. The users have no programming experience either, so why should the testers? –  MetalMikester Sep 25 '13 at 17:30
    
I want them to do more check if the intended feature works. Of course it works, no programmer would release something if the intended functionality didn't work for the base case. I want real-world testing. As if they were the user itself. Coming up with some sort of list of every possible factor in our system and checking that works every time. If test X doesn't work, and I release an update and they test that X works, they're not done. They need to recheck Y and Z, etc. I suppose I'm answering my own question a bit, I was just hoping there was a resource I could point them to. –  user1767270 Sep 25 '13 at 17:30
1  
There are primarily 2 common test positions: Tester/STE and SDET. You seem to have the former, but want the latter. Your expectations should be very different between the two positions. –  Steve Evers Sep 25 '13 at 17:34

1 Answer 1

up vote 2 down vote

Yes, there are resources you can provide to help testers get up to speed. Start with a book like Cem Kaner's Testing Computer Software, which covers test techniques as well as how to deliver good bug reports. Testers may also find the lectures and reference materials on the BBST site valuable.

The value a motivated, effective test team can provide is simple: They'll think differently than developers, and they'll have more opportunity to explore different combinations of actions than developers will budget time for. They'll also spot things that developers will miss because we tend to focus on "happy path" outcomes and only the obvious-to-us side effects and interactions. They'll be able to advocate product quality with a more customer-focused perspective than most developers have focus or bandwidth for.

You should be providing testers with information and guidance about your concerns in the system based on what you know about the implementation and design. You will likely have some areas of concern because of technical debt, areas with poor unit or integration test coverage, or service boundaries and external dependencies.

Programming skills are far from essential for a good tester. In fact, when I was a tester, the more aware of implementation and design details I was, and the more focused on automation I was, the fewer bugs I discovered, as I was increasingly thinking more about the technical boundaries and less about the user's interaction with the software. Automation gave us confidence that we were not regressing functionality that was previously built, but it didn't necessarily catch new problems as effectively as an exploratory black box test team, and developers were often better equipped to provide the necessary hooks for test automation than even people with an SDET type background who were less involved in the implementation of the current project.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.