Internship: Started in Documentation???

[ecoba001]

Hi guys, I have a newbie question for you all and I think you guys can give me a better understanding and clear up some things. I'll be graduating with a BS in CE in May this year. I started working for this software company as an intern, and they put me in the documentation dept. Basically my tasks include running test scripts (which is like following a guided line, there's no skill involved), and technical writing......I'm not allowed to touch code whatsoever and my responsibilities have no relation with it.. i just test stuff from the end-user's perspective... I feel like I should be experiencing more.

To all people who are much more experienced than I am.... Is this common???? Am I missing out? I'm afraid that when I graduate, i'm just going to be doing the same thing..... what are your thoughts?? Any comments will help please.

 

[IRstuff]

Interns are short-timers. As such, would you want someone who's going to be gone PDQ to work on a long-term project?

Also, it appears that you fail to see that testing and documentation, boring and irritating that it might be, is still a critical part of the product development process. You bitch about testing software, yet will complain about the lack of testing performed on a commercial product. Likewise, how often have you cursed documentation that was poorly, or inaccurately, written?

TTFN

FAQ731-376

 

[ecoba001]

yeah i agree the documentation's definitely vital.... but, i was wondering, isnt that left to technical writers?? or is technical writing part of it?

 

[IRstuff]

It depends. Tech writers, at least the ones I've known, didn't write original material. They were usually the ones that gussied up the writing from the subject matter experts (SMEs).

TTFN

FAQ731-376

 

[MacGyverS2000]

At my last position, I spent over a month doing little else but revamping the operations manual for a specific line of our products... and this is when some serious work was needed on the firmware. Even so, I had a deeper understanding of the system's operation after spending so much time going over the details with a fine tooth comb.

As far as test scripts go, I do not believe a trained individual should be stuck running basic scripts. If it's as simple as pressing a button and waiting for an error, it should be more automated and let some untrained monkey press the 'go' button. If the testing is more an exercise in true out-of-the-box case-specific testing, then yes, I see real value in placing a trained individual on the task.

While I second IR's sentiment that no sane company wants a short-term person touching a long-term project, they do not appear to be utilizing your skills properly. If the testing is as basic as you say, someone with little training should be able to do that. The company is spending more money than they need to be (even at your reduced intern payrate) for the given task.

Dan - Owner

http://www.Hi-TecDesigns.com

 

[ecoba001]

yeah the testing that I was doing for the past 5 months has mostly been "follow these steps to see if they pass." Now they gave me a little more responsibility and they're now saying that I have to place more emphasis on the validation.....which basically means for me to try and fail the system by any means and protect the end-user from crashing it by doing something abnormal. Is this what you mean by out-of-box testing?

 

[MacGyverS2000]

Yes.

You may have been doing the "monkey job" for a while to get you used to what can go wrong with the system, as well as what it looks like when things work. Now that you have some experience in that matter, they're extending your testing to include anything the scripts may not directly test for. This is true fault finding (or at least one aspect of it), and it's a job you should take seriously. Knowing the complete ins and outs of the system from a user standpoint will help you to write more effective code when the time comes.

Dan - Owner

http://www.Hi-TecDesigns.com