Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

My team is bringing on two new people - an intern and a full time. The intern has one semester to go, and the full time is fresh out of uni. After a two week training period, the plan management has for them is to have them write tests to learn the code base. (Which, if you follow my other questions you know we need tests desperately.)

But then it got me thinking... how can you write a test if you don't know what the code is supposed to actually do? I fear this would cause us to have fragile and non-thorough tests.

Regardless of how common it is, is it a good idea to have new developers write unit tests for a while to learn the code base?

share|improve this question
add comment

5 Answers

IMHO just writing tests is a Bad idea.

If you want people to learn how to be unit testers then fine getting them to write tests for the codebase will get them experience writing tests for the codebase. The will learn how to consume the code base, and not necessarily work on the code iself.

If you want them to be actual developers, I would, instead have them fix actual bugs in the codebase and write unit tests before and after as well.

share|improve this answer
add comment

I had been through this when I was 4 months old in my company. To write test cases we need to read the requirements specification. I read the description of what the application is required to do along with mockup screens in the spec document which helped me to understand what the application does.

The test cases were reviewed by the Team Lead and peers to help ensure the communication is clear and the logic has been understood in the right way.

This approach would be worthwhile if expert guidance from a Subject Matter Expert (SME) is provided to the new team and all their clarifications\questions regarding what the application really does is clarified.

share|improve this answer
    
+1 because it sounds just like my experience & it worked out great for both myself & my employer. I began writing test cases after a few months with 1) user manuals; 2) common sense; 3) supervision from my manager. (I had written hundreds of test cases at my prior job.) The fresh set of eyes really helped, I think mainly because the design was so old. I found a lot of bugs (some critical & some not so much) & suggested a few major design improvements that were well received. We don't have a "Team Lead" nor do we have Requirements docs, but what glowcoder and Aruna describes worked great for us –  Laura Hensley Jun 17 '11 at 20:13
    
<puts on mod hat> Sorry, there's no way to un-CW a post. I noticed that when you posted the question, but apparently there isn't a way. :-( Which is too bad, this is a good answer and I think you deserve the rep for it. –  corsiKa Jun 17 '11 at 20:36
1  
<puts on user hat> Our SME's are highly unlikely to spend time with a developer who isn't directly working on one of their projects. And they might be experts in manufacturing, but they know only enough to get by about the system. A lot has been lost to tribal knowledge when people left. Same with req's and specs. We do have user manuals and sample screens they can use, as well as development systems where they can't screw up any data (we just refresh the database every so often anyway.) That would allow them to explore (which is important for learning) while writing tests. –  corsiKa Jun 17 '11 at 20:38
    
Quite true, in some companies interns are not projected as resources to the client and they will not have the priviledge to seek response/clarifications from the clients/SMEs –  Aruna Jun 17 '11 at 20:45
add comment

I'm kind of surprised by the approach. I have had (or seen) new employees test the code, code review, write unit tests or go through the Test Cases to understand the application and the code. I do share your concern that without good enough knowledge of the application, the tests written might be fragile. One of the issue can be that the tests might be written with too much of details, which won't be useful for the people who use the application on daily basis. Another important factor they would lack is prioritizing the tests as they might tend to follow the theoretical path.

That said, if it is an UI, and the new employees are writing automation tests, it might be a good idea to, let's say, have them create the Page Objects.

share|improve this answer
    
The system is almost as old as they are, actually. (One of them was 6 years old when we purchased it, and of course it existed before that.) The "ui" is a telnet session. So the last paragraph is not applicable in -this- scenario, although for something more modern (and by modern i mean within the last 10 years) it might make more sense. :) –  corsiKa Jun 17 '11 at 18:08
add comment

how can you write a test if you don't know what the code is supposed to actually do?

You probably can't. You can write tests to prove that it still does what it did when the test is written, but that has somewhat less value, I suspect.

share|improve this answer
    
What I anticipate happening is either they go through ignoring things they don't know and falling into "getting it to compile" syndrome, or asking one of the more senior developers every time they run into something they don't know (which I'm not entirely opposed to, as long as they 'spread the damage' around :) ) I see what you're saying about having less value, but I guess the question is... is the value of the test they write, added to the value of them learning the code, greater than the value of other alternatives? –  corsiKa Jun 17 '11 at 18:10
    
If they are skilled employees, their effort will help your project have some good tests. Also depends on other alternatives. You would rather have build Tests under proper guidance than have them write the development code with no experience of the system at all! –  Suchit Parikh Jun 17 '11 at 18:40
    
"is the value of the test they write, added to the value of them learning the code, greater than the value of other alternatives?" That's a good way to look at it, but really hard to evaluate. I see some goodness here, but I don't know the alternatives for your shop. It's always good to have new developers read, and begin to understand the code, and this is one way to get there. You could end up with some bad tests, if their work isn't reviewed well, and this might lead to a false sense of security. Hopefully not. –  Joe Strazzere Jun 17 '11 at 19:08
    
I suppose their work does have to be reviewed. I don't know if they're skilled employees or not. When I graduated uni, I already had over 5000 hours writing production code (most of my peers said their internships were getting senior devs coffee and web-surfing. At the time I thought they were lucky; turns out I was the lucky one!) I don't know what kind of previous experience these guys have, their GPA, or anything. I'm just a dev here. But, I take my manager's words seriously when he says "try to find ways to improve the team." If he didn't actually mean it, he shouldn't've said it! :-) –  corsiKa Jun 17 '11 at 19:19
add comment

It is a nice idea, as long as the new employees are willing to do it. Someone fresh out of a university, having spent their time studying compilers, language theory, operating system design, complex data structures, and complicated optimization algorithms may pale at the thought of writing something as lowly as unit tests. You and I know this stuff is important, but someone right out of school may not appreciate it.

But let's assume your new hires are open-minded and excited to be getting paid to write unit tests. You are wise to think about they should begin. Here are some things you can do to mitigate the risk you described:

  1. Pick a feature for them to test.
  2. Spend as much time as they need talking about the feature, describing its purpose, its trade-offs, its inputs, outputs, and configuration settings. Draw architectural diagrams. Even better, ask them describe the feature to you.
  3. Ask them to draw up a test plan, then review it thoroughly.
  4. Ask them to code a few tests from the test plan, then review those.

Once you've done that, you can hopefully trust them to implement the rest of the test plan.

share|improve this answer
    
With a little luck, a jumping off point will show up in their "training" (which is the first time we've ever had formalized training for developers, it's too bad they didn't have it 8 months ago when I joined the team. :-) ) –  corsiKa Jun 17 '11 at 23:04
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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