Writing for the screen has many similarities with software development. It is a highly collaborative affair, and one that requires patience, skill, clear communication and quite possibly a penchant for the masochistic.
A screenwriter has only 120 pages in which to tell their story. It sounds like a lot, but when you can write only what can be seen or heard, it rapidly becomes very challenging. Every word must drive the story forward.
The story has to be one that works on film. If the story depends on internal states (what people are thinking and feeling), it may be something that is better suited to a novel. If it’s dialogue-heavy, you might have a stage play on your hands. Not every story lends itself to being on film.
A writer of spec scripts (scripts that are unsolicited) is, whether they know it or not, writing for at least four audiences. Firstly the production company’s readers.
Readers are paid a pittance to wade through massive piles of screenplays that (literally) tens of thousands of other writers submit to Hollywood every year. They’re the ones who sift the gold from the shit (and 99.9% is shit). They’re hoping that the next 120 pages that they pick up is going to be the nugget they can plonk on a producer’s desk and say ‘we have to make this’, and of course they’re generally disappointed. Poor bastards.
As a screenwriter, you have to grab their attention from the first sentence – the first word if you can, then hold it. Keep them wanting to turn the pages even if it’s the 30’th script they’ve read that day and their eyes are red raw. A spec script has to be that good.
After that, the script has to grab the imagination of a director. If you take a look at a novice screenplay, it’s generally full of camera direction and references to music and such. This is a no-no for writing on spec.
It is the director’s job to call the shots, not the writers. Okay, so a spec script with this sort of direction will be binned by a reader before it ever gets to the director, but the point is, screenplay writing is collaborative and you need to know what other people’s jobs are, and let them do it. That doesn’t mean you can’t capture their mind’s eye and suggest implicitly what the right shot might be.
Let’s say for instance you have an action movie where you have a hostage strapped to an operating table about to be operated on, and your next scene is your protagonist tending his wounds after a battle. If the last sentence of your operating theatre scene ends with the hostage being anesthetised, and the first sentence of your protagonist scene is him having a bullet wound stitched shut, you’re not explicitly telling the director to superimpose the needles for the scene transition, but the inference is reasonably clear.
You’re not telling the director how to do his job, but there’s a suggestion there if he wants to use it.
The screenwriter needs to write for the actors as well. If you don’t have characters that test the range of an actor, that challenges them, they’re less likely to want the part. You need to know how to build tension and create conflict and show them the opportunity to display their acting chops.
The novice writer probably starts out with the movie-going audience in mind and of course they’re important too. You need to have a story that works on screen, that grips the interest and imagination of the viewer, holds it for 2 hours and leaves them feeling that the time they spent was worthwhile.
As a software tester reporting bugs, your role is not so terribly different (although hopefully on a smaller scale in terms of length). You also have several audiences and several relationships to manage.
You need to report your findings clearly and concisely with enough detail to adequately convey the bug and the environment and context surrounding it. Make it easy for the person reading your report. If there is some heavy lifting you can do for them, do it.
Is your bug worthy of reporting? Relate the problem to risk. Why is the bug worth fixing? What happens if we ship without it being fixed? Who benefits from it being fixed (or who is it detrimental to if not). Create a compelling case for the resolution of your bug.
Don’t tell a programmer how to do their job. If you have theories about the cause, or suspicions about a more serious underlying issue, then note it down, but preceding it with ‘you need to fix’ or ‘I would have written it like this…’, or ‘the whole thing needs rearchitecting’ is unlikely to win you many friends.
Like a screenwriter, once you submit your bug, it is out of your hands. You want to send it into the world with the best possible chance of success. A screenwriter wants their play to entertain (and also come back with a large cheque attached), and build their reputation as someone who produces quality work. You want your bug to come back resolved and build the same kind of reputation.
Understand who your audience is, what they are looking for, and make a point of providing it to them.
Cem Kaner has an excellent document on his site about bug advocacy. Well worth the read.