jenk: Faye (FayeAtComputer)
Joel on Software posted this a while ago, I just stumbled on it today via Raymond. Joel details quite a few reasons for why the 97-03 formats are complicated and how to avoid having to read/write them directly. But I1 thought this quote was particularly telling:

Every checkbox, every formatting option, and every feature in Microsoft Office has to be represented in file formats somewhere. That checkbox in Word’s paragraph menu called “Keep With Next” that causes a paragraph to be moved to the next page if necessary so that it’s on the same page as the paragraph after it? That has to be in the file format. [...]

A lot of the complexities in these file formats reflect features that are old, complicated, unloved, and rarely used. They’re still in the file format for backwards compatibility, and because it doesn’t cost anything for Microsoft to leave the code around. But if you really want to do a thorough and complete job of parsing and writing these file formats, you have to redo all that work that some intern did at Microsoft 15 years ago. The bottom line is that there are thousands of developer years of work that went into the current versions of Word and Excel [...] A file format is just a concise summary of all the features an application supports.

Now, I'm not used to thinking about the .doc and .xls files in those exact terms m'self. Most of the apps I work on these days are a lot smaller and have a lot less code than Word or Excel. And yet, every one has some field or feature that isn't used much now, but is around (if only so the app will work if you pull up the older records that used it) and they do tend to trip up devs who are trying to maintain the app. Especially new devs who don't know it's even there! (Smart testers will, of course, feature these things on the regression test. ;)

Backward compatibility headaches are everywhere in software. The longer your app has been around and the more users it has, the more headaches you have.

1Speaking as someone who did not work on Office but did work on such backward-compatible concerns as DOS and Windows. I did work with the Office 97 team during IE 5, which enabled me to learn how different the Office team processes/methods were from the IE team (and from the Windows team of which IE was a part).
jenk: Faye (Testers)
  • 16:43 Downloading yet another IE 6 VHD. Bonus: IE 8 beta VHD.
  • 16:52 Fyi - IE VHDs - tinyurl.com/y64upm

Automatically copied from http://www.twitter.com/jenk3 via LoudTwitter cause it's easy :)
jenk: Faye (daria esteem)
Faulty character set for text messaging results in misunderstanding which results in assault and death.

Because of course if an insult is on a computer / cellphone screen, it must have been deliberately sent and cannot have been a bug or typo. And of course an insult cannot be mended with an apology.

There are days when I really do not understand humans.
jenk: Faye (Testers)
...is that often the metrics aren't what you really wanted. In tech support, "shorter calls" were a big metric. Shorter calls meant more customers were served and problems were solved more efficiently, right? Right?

Some calls, yes. Perhaps even the 50% or 80% most common calls. But not the less common calls. Not the troublesome calls. Those took longer, and one 1/2 hour call would screw up your stats for the day.

"Of course you should take the time to do the job right, just not more time than necessary," management would chirp. And yet the rewards went to those who did the job quickly - and not necessarily well. Since people repeat the behavior that gets rewards, this led to less service.

In testing, focusing on bug counts can be a similar problem1. My first test lead didn't look at how many bugs were reported by each individual on his team. Instead, he read every bug reported by his team. He found it was very clear who was breaking bugs into tiny little bits so's to inflate bug counts (often a habit acquired elsewhere), who was sloppy in figuring out repros, who was noticing that two different symptoms had a common cause and reporting it as such, who was mostly finding bugs in areas other than their own (which if a conversation determined their area just didn't have many bugs to find could be a good thing) and so on.

Of course, it was expected that a test lead would read and know all the bugs for the areas covered by his team. And my first test lead did so. Among other things, this made him aware of what was being reported by those not assigned to test the area. (Often these were bugs on areas that weren't officially released for testing yet and such. But sometimes it was a clue that tests needed revising.)

Sometimes the focus on bug count goes beyond using it as a measure of tester productivity. The Defect Black Market relates just one example. This Dilbert shows a slightly less, er, subtle approach.

1The problems with using bug counts as a measure of tester productivity are discussed in-depth in Testing Computer Software by Kaner et al.
jenk: Faye (daria esteem)
Oklahoma sex offender registry exposes and executes SQL statements in the URL, enabling downloads of social security numbers, birthdates, addresses, et cetera. Who knows, maybe their site executed INSERT statements too.

Nobody accessing sensitive government databases should assume that users don't know SQL. And yet.
jenk: Faye (GeekGirl)
...from The Wall Street Journal:
Talk to your information-technology department before you post naked pictures of Lindsay Lohan on your business’s Web site. The latest reminder of this ironclad rule comes from New York Magazine, which posted photographs of the 21-year-old actress recreating one of Marilyn Monroe’s more scandalous shoots on its site yesterday. (Sorry fellas, the link is to an article.) The site, which was promptly overwhelmed by art-photography fans, ground to a halt. It’s a classic Internet-age problem: The marketing department has some promotion that is bound to drive traffic to a site, but never bothers to tell IT. So the site crashes. In a testament to human nature, these incidents often involve scantily-clad women, such as the famous Victoria Secret online fashion show that nearly brought down the Internet in 1999.
I've been on both sides of that equation - both times involving that little low-traffic domain called microsoft.com. ;)
jenk: Faye (GeekGirl)
I haven't run the Windows debugger (or the Windows debug kernel) since I quit being paid to do so in 1999. But when I did, I made use of crib notes created by Raymond Chen, a Windows dev who also opened a wide variety if interesting and useful bugs.

A few days ago, Raymond reviewed the book Advanced Windows Debugging, stating that "Even the section with the "Oh come on every moron knows this already" title Basic Debugger Tasks has stuff that I didn't know."

Eep.

So if you're doing Windows programming and stepping through the code in the IDE isn't enough to figure out what's going on ... if you're dealing with, say, a deadlock or heap corruption ... this might be the book for you. :)
jenk: Faye (GeekGirl)
Seattle Weekly article on the day labor side of testing, games testing in particular. Reading the article, it's not clear if the writer thought this was a "slice-of-life" article or an exposé.

As exposés go, well, maybe I'm jaded. Sure, it's not a job I would want. On the other hand, it sounds better than other jobs I've had. In the late 80s, I got $6/hr for kid wrangling at a non-profit. According to the BLS, low-level child care a median wage of $8.25/hr now, comparable with the low-level games testing discussed in the Weekly.

Duties? I would keep 10 preschoolers engaged and safe. I also tied 8 or 9 pairs of shoes at a time; cleaned kids (with wipes) and cots (with Lysol) after "napping accidents"; made lunch or snack for 100; cleaned tables, chairs, and the floor after 100 kids had lunch; held a screaming kid under the sink while washing sand out of his eyes (had bruises for a week after that one); carried upset or sick kids; read out loud a lot; organized; cleaned; turned jump ropes; et cetera.

And, of course, there's also the bit about how screwing up as a games tester means a support call, maybe a recall, or being fired. In a day care, negligence can cause a child's death.

Not that child care is the worst job in the world, either. Yes, you deal with bodily fluids (and yes, waste solids) fairly regularly, but they are pretty well contained. Working in a center meant I had other adults for comradarie and assistance. As jobs go, it was steady, had flexible scheduling, and included vacation, sick time, and health insurance.

But I can't help wondering if an article on how day care isn't all hugs around the knees and experiencing wonder through the eyes of children might be a nice companion piece to the one on how low-level games testing isn't the happiest job on earth.
jenk: Faye (GeekGirl)
"A busy CPU is a happy CPU. Leave it running [pseudorandom tests] all weekend, it'll be happy to see you Monday." - Harry Robinson from Google, talking on "The Bionic Tester"

"I am certified to practice law. This means I can be sued for malpractice. I like this." - Cem Kaner

I start posts on this and then get busy and abandon them. A few folks who have posted are here.
jenk: Faye (Kim)
I found a ruby library for testing in IE & I'm working through the tutorial. So I've got IE and the irb window up, and I'm typing

ie.button(:value, 'Login').click

instead of clicking the Login button.

So yeah, it's for scripting. But it's also an oddly verbose way to rest my mouse hand....
jenk: Faye (DariaPensive)
I ran across this quote in a software testing article at Jonathan Kohl's blog.
Weinberg's "Rule of Three", which goes something like this: if you can't think of three ways a potential solution can fail, you don't completely understand the problem space.
Google found a couple other variations.
Jerry Weinberg says, “If you haven’t thought of three possibilities, you haven’t thought enough.”
- quoted at stickyminds
and
Whenever I'm aware that I'm making an interpretation, I have another choice: I can allow myself to know that more than one interpretation is possible. A good check on premature interpretation is the Rule of Three Interpretations:
If I can't think of at least three different interpretations of what I received, I haven't thought enough about what it might mean.
This rule slows down the Interpretation step and gives me, the receiver, a chance to engage my brain before using my mouth. Even after I have thought of three possible interpretations, however, I should always be aware of one more possibility: that my list still may not include your intending meaning.
-- Jerry Weinberg, Quality Software Management Vol 2, Chapter 6, quoted here
So, here are three varations on the Rule of Three...appropriate, no?
jenk: Faye (Kim)
David Gilbert discussed applying hurricane forecasting methods to software. One thing that caught my eye, that he says he has "NEVER seen [in] any model of software planning", is "The Cone of Uncertainty".
Starting at the point where the storm is now, following roughly along the predicted path of the storm, is an ever expanding cone. This cone represents where, given all the information currently available, the storm MAY go if something in the model changes. [...T]his is the part of the model that forecasters talk about the most, and encourage everyone to pay the most attention to. This is the part of that model that takes into account Risk and Ambiguity.
Shipping software is ambiguous, and taking that into account is a good thing. But (to continue the metaphor), project management is all about getting to a particular destination at a particular time; tracking a hurricane is trying to see where & when it will arrive.

But perhaps there's room for both. Yes, aim for the goal. But also track the "cone", and forecast how far off track the project may currently get...
jenk: Faye (Kim)

There's a lot of testing buzzwords that just make me sigh. But I like "Context-Driven". The link has good info, but the example was the "aha" moment for me:
Consider two projects:
  1. One is developing the control software for an airplane. What "correct behavior" means is a highly technical and mathematical subject. FAA regulations must be followed. Anything you do -- or don't do -- would be evidence in a lawsuit 20 years from now. The development staff share an engineering culture that values caution, precision, repeatability, and double-checking everyone's work.

  2. Another project is developing a word processor that is to be used over the web. "Correct behavior" is whatever woos a vast and inarticulate audience of Microsoft Word users over to your software. There are no regulatory requirements that matter (other than those governing public stock offerings). Time to market matters -- 20 months from now, it will all be over, for good or ill. The development staff decidedly do not come from an engineering culture, and attempts to talk in a way normal for the first culture will cause them to refer to you as "damage to be routed around".
Testing practices appropriate to the first project will fail in the second.
Practices appropriate to the second project would be criminally negligent in the first.
The testing is designed for the project, not the project for testing.
jenk: Faye (jen36)
I ran across this at Testing Reflections:
Lesson 1: Know your enemy
  • Lack of Quality is not your enemy, it’s [the] developers enemy. Your enemy is absence of evidence of it.
Lesson 2: Know your equipment and how to use it
  • Armour: standards, guidelines (universal defence against any attacks)
  • Shield: test [plans], test cases (when used properly may block some attacks by “the enemy” – do you remember who is an enemy?)
  • Sword: testing - test execution (use to attack the enemy)
Lesson 3: Choose appropriate equipment
  • Good armour reduces movement.
  • Shield decreases offence.
  • A single soldier may use long sword (knight) or two swords (samurai)…
  • An army [can] use good armour, big shields, normal swords
A lot of this makes sense. Lesson 1: We are looking for facts. Lesson 3 is about tradeoffs...and how test plans are like battle plans - they don't survive initial contact unscathed!

Other thoughts?
jenk: Faye (maggie)
Raymond talks about some locale-specific notes on number formatting, including that China & Japan group in fours. So the US number 12,304,567.89 would be
1230 4567.89
in China or Japan.

I thought this was interesting. But then I have been told I have weird values for "interesting".

I also liked this comment:
Travel broadens the parochial mind you never knew you had, and makes you a better programmer/designer/techie.

As a bonus it also exposes you to better beer.
jenk: Faye (maggie)
from [livejournal.com profile] joelonsoftware, talking about software company management:
Companies need infrastructure ) and if your programmers even spend one minute thinking about this that's one minute too many. ... ) That's why you have management.

It's for the kind of stuff that no company can avoid, but if you have your programmers worrying about it, well, management has failed, the same way as a 100 foot yacht has failed if the millionaire owner has to go down into the engine room and, um, build the engine.

Some companies are too sales-focused, others are too code-focused )

Both of these companies can easily be wiped out by a company that's driven by programmers and organized to put programmers in the driver's seat, but which have an excellent abstraction that does all the hard work to convert code into products below the decks.

A programmer is most productive with a quiet private office, a great computer, unlimited beverages, an ambient temperature between 68 and 72 degrees (F), no glare on the screen, a chair that's so comfortable you don't feel it, an administrator that brings them their mail and orders manuals and books, a system administrator who makes the Internet as available as oxygen, a tester to find the bugs they just can't see, a graphic designer to make their screens beautiful, a team of marketing people to make the masses want their products, a team of sales people to make sure the masses can get these products, some patient tech support saints who help customers get the product working and help the programmers understand what problems are generating the tech support calls, and about a dozen other support and administrative functions which, in a typical company, add up to about 80% of the payroll. It is not a coincidence that the Roman army had a ratio of four servants for every soldier. This was not decadence. ... )

Management's primary responsibility to create the illusion that a software company can be run by writing code, because that's what programmers do. And while it would be great to have programmers who are also great at sales, graphic design, system administration, and cooking, it's unrealistic. Like teaching a pig to sing, it wastes your time and it annoys the pig.
I added the bolding in that last paragraph because I think it does a great job of explaining what needs to be done in the software business besides making great software - in fact, what needs to be done in most businesses. It's stuff that most people don't think about because, usually, no one individual does it all. But it's the stuff that can make-or-break useability, sales, operations, and employee satisfaction. As Joel goes on to say,
Microsoft does such a good job at creating this abstraction that Microsoft alumni have a notoriously hard time starting companies. They simply can't believe how much went on below decks and they have no idea how to reproduce it.
I would amend that to be most people who have worked at successful companies have no idea how much is done outside their own area...and have no idea how to reproduce it.

Full article: here.
jenk: Faye (Default)
A former coworker of mine, Raymond Chen, posed a "what would you do?" question about how Windows Vista should handle getting incomplete data back from a server. Click here to read his post ;)

I think this provides a window into day-to-day software quality decisions that most people don't usually see. In particular, the amount of interdependency that occurs when dealing with an open platform like Intel/Windows.

Note that Raymond does not name the buggy server software in question, other than to note it's not Windows. This is SOP when discussing things outside of NDA.

For the less-initiated, the information would travel from

the server -> Microsoft's network driver -> Windows OS file APIs & Windows Explorer

APIs (Application Program Interface) are how programs interact with each other. Compare to UI (User Interface).

As for what I'd do: I assume you've read the problem already )
jenk: Faye (Default)
"The price one pays for pursuing any profession or calling is an intimate knowledge of its ugly side."
I ran across this while looking up titles for a crossword. It's very true. I would say it's even truer for testers because we are paid and encouraged to focus on what *doesn't* work.

Also: "All roles are dangerous. The world tends to trap you in the role you play and it is always extremely hard to maintain a watchful, mocking distance between oneself as one appears to be and oneself as one actually is."
jenk: Faye (Default)
Raymond's blog entry today is on "ground rules for using function parameters". He's specifically trying to list the "unwritten" rules, aka the rules that are taken for granted. Comparing calling conventions to driving directions, he's trying to write the equivalent of "Don't drive on the lawn" and "Next right does not mean driveway unless you're told otherwise". Overall I found it entertaining (but then I find kooky software errors entertaining :)

http://blogs.msdn.com/oldnewthing/archive/2006/03/20/555511.aspx
jenk: Faye (working)
We now have an internal blogging server at work. I'll probably mostly use it for musings on testing / QA / software dev stuff.

My first post: Read more... )

Profile

jenk: Faye (Default)
jenk

April 2017

S M T W T F S
      1
2345678
9 101112131415
161718192021 22
23242526272829
30      

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 22nd, 2017 10:38 pm
Powered by Dreamwidth Studios