tomhudson's Journal: Finally - code moves to internal testing this week !!!!

For those who have been following, I was brought in last August on a project that was already about 2 years in the making (and a year behind), with a standing team of 4 c/c++ programmers developing 3 different interoperating servers that have to handle thousands of transactions a second on linux and/or bsd boxes.

No documentation, no design specs, no comments, nada. Lots of "fun moments" and WT???s.

Well, this week (tomorrow, actually) parts of it go to internal testing. Finally!!!

Its been a tough slog. Over the last 3 years, we've gone through more than a dozen programmers (and $DIETY knows how many candidates), and in the last 8 months, the team has shrunk down from 4 to 3 to 2 to just moi ... because it IS tough, and in the last year everyone whose resumé looks good on paper is just that - someone whose resumé looks good on paper.

Still not time to "coast", as I have to integrate some code this week, for new features that were thought up a couple of months ago and coded by the "second-to-last" coder ... and modify the databases, and check all the queries, and all the memory maps, etc. BUT WE'VE REACHED A MILESTONE!

The hardest part is done. Inspecting/helping the php/javascript code is childs' play in comparison.

No time yet to take my vacation, but I think I'll take a few days off ... maybe stretch out the labour day weekend by a few days.

In the meantime, I'm enjoying a nice glass or two of this to celebrate. To your health, everyone!

testing, integration, etc.

[jci]

I hail from the land of PPCs running UNIX and 40Hz time slices.

I just had a segment of code that I work on come back for rework again at system level test. I too have inherited the code of the many as the team became the few.

It seems the test set that exercises the timing for a set of six lights likes to just kind of go off in to space and fail one light on ~20% of the test runs. Very frustrating, and the onus is on me to prove the test set wrong. The test has exposed some situations that were either out

Re:

[tomhudson]

Thanks, and good luck on your rework.

I'm just hoping nobody comes up with any more features over the next few months ... I'm only now going to add the last set of features that they came up with (and which should have been saved for a future release, imho). That's this week's major "TODO".

Re:

[plover]

A shop I used to work at decades ago was having a really slow summer after the salesman left with a black book full of our customers, and the manager was busy stealing our parts and selling them on the side to our biggest customer. After one of the few jobs we managed to land was rejected by the customer, one of the machinists noted "if it wasn't for rework, we'd have no work at all."

I felt really bad for the owner that year. But that line sure stuck with me.

Need a solid Black-box tester?

[RM6f9]

Somebody who only knows what I read, and that only to have a contrast ("The docs say this: The software behaves thus, under x,y,z, and so forth conditions - bug!") It is unfortunate that my best talents lie in immediately gravitating toward the broken parts... in any other field but software testing, where finding what's broken and being able to describe it in excruciatingly exact precision *should* have me rolling in job offers, but, alas, not yet.

Re:

[tomhudson]

"The docs say this:"

Docs? What docs?

That's part of the problem. Ad hoc development at its finest. The people involved in testing and coding the UI have worked together for the last couple of years, so they "sort of" know what to expect on the externally-facing software, etc ... unfortunately, all testing has to be done on site - part of the testing involves hitting the server with thousands of queries a second for days at a time, to check for memory leaks (we never free up a thread until shutdown, for

Re:

[RM6f9]

Ah, well: The scenario you describe takes me back to my first week in my previous job - there were release notes (thin), and we were doing either regression tests or end-user level testing (based on the GUI, I expected this, but the program did thus (or, nothing visible) - bug?), but you can find monkeys and teach 'em how to write up those kinds of bugs....

Good Luck!

[Shadow Wrought]

Not that you'll need it cause you're really a genetics professor;-)

On a serious question though, when you're given such a task, are you able to read the code well enough to understand what it is supposed to do, or do you have to take bits and pieces and run them as independently as you can? I have yet to fully pluinge into learning coding, so I'm curious as to how you actually went about untangling the spaghetti.

Re:

[tomhudson]

Read, read, read ... start documenting bits and pieces of it ... rewrite parts as needed, and eventually, it all falls into place. A very long, and painful, process.

There's still a lot of "uggh" in there, but that will disappear over time :-)

Milestones

[Tet]

Gotta love milestones. Phase 2 of my project went live today. No end of teething troubles, but I think it's mostly stable. We've had some problems, but I think they're related to caching of pages from previous builds in the browser. I certainly can't reproduce them, and sadly the guy that's seeing them isn't around at the moment. This is all further complicated by the fact that the action that provokes the bug has a significant monetary cost associated with it, so I can't go mad on the testing. We'll see ho