Category Archives: Experiences

Last Family Lunch

14 Friday Dec 2012

Posted by in Experiences, Experiments, Retrospective

≈ Leave a Comment

It’s been a nostalgic week for me as I’m finishing up my time at Daxko today. (Case in point, I’m wearing this year’s bight purple Kickoff shirt as I type this.)

I’ll miss finding you on Twitter, displacing the printer, walks to Taco Mac, counting down my check-ins, dueling LifeSize remotes, commit message mentions, dangerous Centurion helmets, Plank A Day Nation pix, 2 drink tickets, the gangsta Ashoka Scrum-board avatar, mysterious moustaches, Monster-fueled afternoon shenanigans, Keep Calm and…, Portal references,  being kind of a disaster, Hackathons, a closet full of branded T-shirts, sticky notes everywhere, launch party, singing on the patio until we shut down the restaurant, winning The Go Game, the quote of the day, attempting Cajun accents, the Women of SWE, surprise attacks by Angry Birds, Family Lunch indecision, punchy road-trip conversations, Whirlyball, batting long eyelashes, last-minute costuming, musical parodies, calling dibs on the napping couch after family lunch – we love free food! – and most of all the people. (Special shout out to my Atlanta crew! I’ll follow you to whatever end.)

I expect to see some ridiculousness coming out of next month’s talent show, so make it count, people!

So Long and Thanks for ALL THE THINGS!

“Now, bring me that horizon.”

Seize the Initiative

15 Thursday Nov 2012

Posted by in Agile, Context, Experiences, Experiments, Retrospective, Soft Skills

≈ 1 Comment

Antistress Autoreverse

So last year I joined the YMCA. My employer works in this space and they supplement our memberships … on the condition that we attend with a minimal frequency. Nothing to understand your customers quite like becoming their customer! However, working out isn’t really my thing. The “race to nowhere” has no appeal for me. But I went anyway, determined to learn something. Despite my stubbornness on that point, the inertia of years of study was hard to overcome. I needed backup.

Joining the coach approach program was explicitly about wanting to make improvements. The Y coaches promote “adopting healthy habits and changing the way [the participants] live their daily lives.” I knew I wanted to make a change, but I also knew that I didn’t want it badly enough to go it alone quite yet. Having never had a personal coach, I wasn’t quite sure what to expect. What I encountered resonated with my recent experience learning about the role of ScrumMaster.

In particular the sprint activity of retrospective is “an opportunity to learn how to improve.” Defining success in this particular context was the first step. My ScrumMaster watched the process and guided it, making it okay to talk about uncomfortable topics, but it was up to me to do the work. The first big step was being able to establish a safe environment to talk with a more experienced and professional person about a potentially sensitive topic.

In the case of my workout routine, this was my minimal compliance rather than wholehearted adoption of lifestyle change. My Coach Approach coach helped me to develop a vision for the future that would be better than the past. We focused on setting goals while recognizing that the plan had to fit into my work/life balance with the loose structure of frequent check-ins rather than plugging my height, weight, and weight loss goal into a one-size-fits-all spreadsheet.

I was surprised to find that discussion about my health could be fun when my counselor was so friendly and supportive. I would have expected an intervention to be really uncomfortable. Retros can be that way sometimes. But they can also be a welcome change of pace. Roughly every 2 weeks – after we catch up on socializing and the excitement we’ve had since our last chat – my coach and I looked at the artifacts of my progress, paying attention to the time line of events going on in the background and how that influenced the results. Keeping this cadence allowed us to build a healthy relationship that encouraged risk-taking and speaking from the heart. So when my coach suggested adding a weights routine to my cardio, I felt fine with scoffing openly and she felt fine with reminding me of my goals, not allowing my emotions to derail the discussion but remaining fully present and focused.

As our meetings progressed, she offered appreciation of the progress I made, while encouraging me to try new approaches that could yield better results. Even when I felt like I was backsliding, she found a way to put more emphasis on understanding what I had accomplished and focused on encouraging me to keep going. We talked about what parts of the routine were working well, what lessons I learned (like when I hated the treadmill but loved the AMT – hey, participation in individual exercises is optional!), what I could do differently next time, and what might need more scrutiny. We tried to analyze the problems and propose solutions to the boredom, considering a variety of alternatives. It was honest but not accusatory. (Hey, eveybody gets bored with the routine.)

So I’ll admit she’s done me some good. I agree with another participant who said, “My personality is better, my production has gone up, my mental clarity has improved, and my energy level has increased dramatically.” Granted, I just have a lot of energy in general, so I wasn’t likely to sit back and passively take it in – well, as passive as you can be while sweating profusely. I started to recognize my excuses as just excuses, feeling more empowered to modify the situation, learning to manage that impulse to excuse myself from the hard work of changing. Accepting that I actually knew something about working out and lifting weights and could be responsible for designing more of the workout and analyzing my progress on the path to wellness? Yeah, last week was weird.

One ScrumMaster wrote, “At the end of a successful project, everybody says, ‘Gee, I wish we could do it again.’ Using this definition, was the project a success?” Well, I can’t say that I’ve enjoyed every moment of it, but figuring out that I could test software and sweat profusely at the same time? Priceless! But seriously folks, having my coach express sincere and significant appreciation for the care and work I put into making progress sent the message that she cared about and me personally, not just reducing the failure rate of some anonymous gym member. And that’s where the magic happens.

(Special thanks to my dev James who pointed out that coach approach is workout retro!)
Image source

Pushing the envelope

08 Monday Oct 2012

Posted by in Experiences

≈ Leave a Comment

vicious ATM slot
This morning, on my way to work, I stopped by the bank to deposit some checks. Knowing that I was much too early for a teller to be present at the drive through window, I pulled up to the handy dandy automatic teller machine at my local branch. Some months back, the bank had upgraded its hardware to optical character recognition for depositing checks. I think this is a cool feature as it saves me from sleepily misreading or carelessly fatfingering the amounts on the checks. However, in order to use OCR, the ATM must be able to scan the front of each check, which precludes using an envelope – as is traditional for deposits in ATM machines.

Having some experience with the OCR ATM and this machine in particular, I thought nothing of my task, just a quick errand that would only momentarily delay my commute. So I drove up to the machine, dutifully endorsed my checks, and carefully aligned them for depositing according to the easy-to-read sticker below the deposit slot. After proffering my card and punching in my code, the ATM’s maw gaped and hungrily consumed my would-be dollars. However, this morning was not like other mornings and the ATM encountered an error in reading the checks, displaying a message that envelopes were no longer accepted for check deposit. It attempted to feed the lot back out of the slot, crumpling them up just inside the automatic door of the deposit slot. Knowing that the bank personnel were not available at that moment, I resolved to find a workaround.

With headlights in my rearview mirror and fearing for my fingertips, I carefully shifted the edges until I was able to extract the checks and reexamined them. The only interesting variation that I observed was that 2 of the 3 checks were large, preprinted by businesses, while 1 was small and hand-written. Although the slot sticker showed an image of varying check sizes with small checks on top, the machine’s behavior did not conform to this end-user documentation. Fortunately, I was able to manually feed in the checks one at a time, which was not quite the simplest happy path since I was adding each in turn to a single transaction. Just to confirm, I selected the receipt with check images and verified that my scenario had completed successfully, averting a lot of frustration not only for me but for the line of cars inching closer behind me. Still, I’ll think twice about using the ATM outside of normal business hours… no point in pushing my luck.

Image source

Big Visible Testing

07 Tuesday Aug 2012

Posted by in Agile, Approaches, CAST 2012, Context, Experiences, Experiments, Publications

≈ 2 Comments

Presented as an Emerging Topic at CAST 2012

This was my talk proposal:

I have always thought of myself as an agile tester. After all, my development teams have always delivered features in 2 week sprints. My testing activities included reviewing requirements or stories before the planning meetings to assemble a list of questions and test ideas that I would use to approach the work proposed. I participated in a review before code completion that allowed for some exploratory testing, brief and informal though it may have been at times. In the past couple of years, I also planned and coded test automation.

However, over the past year, I have been transforming from a pseudo-agile tester to a true agile tester. Rather than sitting apart from the software developers in my own quality engineering department, I am now seated in the same room as the other employees from a mix of disciplines who are on my product delivery team. Rather than testing in a silo, I have been gradually increasing the visibility of testing activities through exploratory test charter management, defect backlog organization, and paired exploratory testing with both testers and non-testers. The feedback loops have shortened and the abbreviated time between activities necessitated adjusting how I provide information.

Testers are in the information business. We take the interests and concerns of the business as communicated through the product owner – or in my case the product owner team – and combine those with the needs of the customer as expressed in the story and further augment those with our experience using and analyzing software for deficiencies, abberations, and oddities. We draw upon a variety of resources including the experience and perspectives of fellow testers, heuristics, and product history to approach the goal of delivering a product the customer values, focusing especially on the quality aspects of that value.

Now that the audience for my testing comprises a mix of disciplines and the work environment has shifted from a heavier process to transparent, quick information access, I have been experimenting with different ways to execute testing and to represent the outcomes of that testing activity so that the information consumers understand it in ways that best suit each of their perspectives.

In my brief presentation, we will examine 3 different agile team member personas and their implications for presenting and maintaining testing information as well as the inherent tensions between their distinct and various needs. I will trace my learning curve of adjusting to their needs through the various experiments I have completed in this context, though these lessons extend beyond a purely cross-functional agile product development team.

Other testers will come away with a fresh perspective on viewing their product team members and focus on the value testing artifacts provide to a software development team.

Wedding Crashers

27 Friday Jul 2012

Posted by in Experiences, Testing Humor

≈ 1 Comment

There comes a time in every woman’s life when her friends announce their engagements. The joy she feels about the momentous occasion of the wedding carries her through the mundane details of choosing what to wear and shopping for a gift to wish the newlyweds well. With wedding showers appearing on the horizon, I knew it was time to go back into the fray of shopping at the mall.

American custom encourages couples settling down into a life together into a frenzy of spending. Aside from the gorgeous dress, lovely ceremony, and honeymoon in some secluded far away place, couples select the accoutrement needed to establish their joint household. For younger couples who have not had long to establish their own independent living situations, these gift registries can be quite extensive. Even for couples in which the man and woman have been on their own for a while, there’s the temptation to upgrade furnishings or to plan for the grand entertaining they will do together in the future.

Granted, not all of the domestic needs are so thrilling as fine china. A house needs brooms, wastebaskets, and the like to function well, so some kind friend or wedding guest is likely to select these items as practical assistance. While it might not make for a thrilling hunt, for me it has always been an adventure to find the right items, in the right price range, in the right store.

Last night was one such quest. I steeled myself for the arduous task of tracking down registry items and then plunged in. Wielding my trusty laptop, I expertly navigated to the wedding website and found the registry links. Although I only had experience with single-retailer registries, I encountered the innovation of aggregate registry websites in all their glory, allowing couples to gather treasures from far-flung places together into a unified whole. After some contemplation, I decided upon some likely candidates and clicked the links to review the items more closely.

One aspect of registries that makes them so appealing is the automated coordination of purchases. Since so many well-wishers like to provide gifts a couple really need or want, some items are more likely candidates than others. Desired quantities, purchased quantities, and quantities remaining abound, requiring real-time accurate updates. It has been my experience that these quantities are seldom correct and that the updates are slow and unreliable. Therefore, I resolved to pursue a defensive shopping strategy.

First, I found the item of interest on the registry site. Then, I searched for the most convenient location with the item available. Next, since I would rather not venture out after work only to fruitlessly tug on locked doors, I carefully read over the store hours. As it turned out, the online registry location functionality for this particular retailer’s site did not synchronize with their regular location search and the selected store’s open and close times were both listed as “none”. Having recently arrived at a local bookstore only to find that it had closed for good that week, I had no desire to drive around trying to find an open location. Fortunately, the regular store location search was working, revealing the actual hours of operation as well as the handy main phone number.

As I worked my way through the phone tree to an actual human, I was transferred several times incorrectly and ended up needing to redial, which was a small price to pay to avoid driving all over creation to find the gifts. Eventually, the helpful staff member listened to the numeric item identifier as I repeated it over the phone and manually entered it into the system. However, being a savvy saleswoman, she also knew better than to trust the inventory displayed at her terminal and actually pulled the item from the floor for me, holding it at the counter since I was heading right over to purchase it.

Upon arrival, I wound my way through the various displays and discovered the item in the expected department of the store where the saleswoman found me. The transaction went relatively smoothly, aside from the obligatory sales pitch of the retailer’s branded credit card finding no purchase – though they did sneak me onto their mailing list by offering to email me a receipt. I was all set to head on to the next location when I realized my error: while I had remembered to ask for a gift receipt – granted only after the transaction was tendered – I had entirely forgotten to mention the registry! She directed me to the wedding consultants and the heart of the store.

I tentatively crept past the immaculate displays of place settings I couldn’t afford and that would never be practical with small children in the household until I found the wedding registry consultant with the power to correct my mistake. She was an older woman with neat fingernails, adequate computer skills, and familiarity with my problem. She started the registry software whose interface looked like it had been designed in the early ’90s and struggled to recall the process. She pulled out a notebook scrawled with her somewhat indecipherable handwriting and flipped through trying to find her tips & tricks for this particular task. She resorted to pulling out a large binder that was a mashup of store policies and user manual and found the page of instructions.

Not wanting to rush her but slightly impatient to venture on to the next mall for additional purchases, I read the instructions upside-down from across the desk. They were relatively straightforward but clearly not routine for this user. She looked up the bride’s name, found the registry, and eventually unearthed the screen that allowed altering the quantities for desired, purchased, and received and edited them directly. Before sending me on my merry way, she caught her own deviation from process and navigated to a different window where she again scrolled through a dense grid of product data before finding the item I purchased. She entered my name as the purchaser and the price I paid before attempting to save. An error message popped up and I could tell that this was not meant for human consumption, referring to some internal error code. When she tried again, a different error occurred, resulting in application crash. She fell back to hardcopy, scrawling the details for a later second attempt.

Having thus far survived my shopping ordeal, I doggedly drove to the next mall and planned my rapid strike and escape. This store wasn’t in the mall proper, removing some of the harrowing details or the earlier endeavour. Inside, I wandered until I found the item and then stood dutifully in line until a helpful saleswoman heard me mention the registry. I was pulled out of line to visit a separate kiosk that did not recognize the bride’s name or the groom’s name. After some reflection, the saleswoman mentioned that aggregate registries did not interface with individual retailer registry systems, preventing me from automatically reporting this sale. I forked over the money and toted my prizes back to the car, knowing that I was not yet finished, with the troubleshooting of reporting the bricks & mortar sale to the online aggregate registry system remaining ahead of me.

Still, upon reflection, discovering a bug in the online system and crashing a desktop application without even touching it is all in a day’s work for a software tester, so I can wrap my hard won gifts, don my party frock, and go off to celebrate the wedding with the satisfaction of a job well done.

Image source

Favorite moments from TCC and CAST

23 Monday Jul 2012

Posted by in CAST 2012, Experiences, TestCoachCamp 2012

≈ 1 Comment

I have so much information swirling in my head from the past week that there’s no hope of writing about it all at this time.

Instead, I present you with my favorite unexpected moments – in no particular order – from Test Coach Camp and CAST 2012:

See me live!

16 Monday Jul 2012

Posted by in Agile, CAST 2012, Context, Experiences, Experiments

≈ Leave a Comment

CAST is online streaming the keynotes and Emerging Topics track again this year.

Last year, I was haunting the interwebs watching, Tweeting, and chatting. This year, I’ll be coming to you live through the magic of technology. (This is the first reason I’ve had to crack open PowerPoint so it should be entertaining!)

Catch my agile software testing emerging topic talk Big Visible Testing at 10 AM PDT today!

Again, here’s the link to watch me:
http://www.ustream.tv/channel/CASTLive

Update: Recording uploaded to YouTube

Image source

Ruby Anniversary

14 Saturday Jul 2012

Posted by in Automation, Experiences, Experiments

≈ Leave a Comment

A year ago this week, I first picked up Brian Marick‘s Everyday Scripting with Ruby and gave it a whirl. This week saw me branching out past automating web application checking to creating my own Ruby application.

I haven’t been a code monkey in many a moon, but my company’s recent innovation week gave me the perfect opportunity to try an alternate role. I anticipated either glorious success or failure – and as a tester I’m seasoned at failing gloriously so I was set to be happy whatever the results.

This time around, anyone in the company could propose an idea, perhaps even customer requests of suitable scope. The projects had to be related to our core business but the Lab Days crew encouraged us to try new teams or even new team roles.

Getting to hear and understand ideas from of our team and our customers. Small things that are annoying, new things that will open the door for a myriad of other possibilities and things I never would have thought would complement our existing solutions are all displayed during Lab Days. — Concetta

Since I had only a week of development time available, I chose a project with limited scope: a small utility that would detect information in the data warehouse and email an interested party about it. I planned to develop the simplest thing that could possibly work, which was important working as a team of one. I did not have any software developers to help me with structuring the program, though I did describe my plan to my regular product team folks, who also estimated that it would achievable.

Test-driven development was one of my goals for this project and this was my first time trying it as a programmer. Granted, I have been writing RSpec stubs for my web automation for a year, but I didn’t have to build all of that from scratch on my own. This time around, I began as usual for a story in our Scrum sprints by writing out the tests that I knew would indicate success before delving into the code mines.

As a result of coding solo, I spent quite a bit more time evaluating and troubleshooting Ruby gems than I would otherwise. While this was frustrating at times, I had a chance to form a better impression of the Ruby community and the problems they were trying to solve, gleaned from the gems tailored to different purposes. As it turned out, there aren’t a lot of Rubyists working with MSSQLServer in a Windows environment, as I was trying to do. I even went down the rabbit trail of evaluating Rails development until self-taught MVC under a tight deadline sounded questionable to me.

Undeterred, I dug up some promising leads and made some experiments, most of which failed. I learned a lot of ways not to solve my problem! However, for success you only need one and I found a way. Once I was able to communicate with my data and my email, all that remained was the business logic. Granted, by this time I was halfway through my week, but I had my infrastructure and I had my tests as goals.

I began with familiar code structures I’d used formerly in pseudocode, Visual Basic, and Java. However, I knew Ruby had its own interesting expressions, as I had noticed while studying my pickaxe. At this point, I decided to learn a bit more about the Ruby idioms and so cracked open an ebook version of Why’s Poignant Guide. This made for an entertaining intermission and pointed me in the right direction to enhance my code to be Ruby-style. I’m sure my Rubyist friends would still cringe, but I wasn’t expecting to have production-ready results as a Ruby newbie.

One-by-one my tests went from red to green. All of this gave me much more confidence that my changes were stable, which turned out to be essential. The morning of the competition presentations, I discovered a fatal flaw in my project: although it worked as designed, the data warehouse SLA for the data I was analyzing had a lag of 24 hours rather than the real-time I had anticipated. With the help of some coworkers in the know, I went to the source and found the real-time data. Fortunately, this last minute coding was an alternate implementation of the database interface and did not affect my program’s overall structure. Here here for modularity and DRY principles!

Out of time but satisfied with my progress, I was able to live demo the first solution against the data warehouse. However, I knew that what I really wanted was an end-to-end test from the source application all the way through to the email account, so I continued working and completed that while the competition voting period was still open. While I didn’t get a chance to present my enhanced code to the group, I had the satisfaction of knowing that my tracer bullet had found its target. And what’s more I had a backlog of enhancements needed for production-readiness prepared for the next iteration – if there is one. Anticipating that this project will become a product in the future, I also completed a proof of concept using tests against an API for the source data that’s in the works, applying some of my learning from Alex Kell‘s recent interface testing presentation to the Agile Atlanta group.

While my project did not find a place in the innovation week competition winners circle, I felt like a winner for having the drive and execution to complete even a small application on my own. Since I learned more about my company’s product suite, data warehouses, interface testing, Ruby, and TDD through RSpec in the process, I call the experiment an unquestionable success. I carry forward all these skills to my day-to-day work and can plan my usual testing with much more context.

So while Ruby and I are still in the early stages of our relationship, I think our first anniversary together was a shining moment.

Image source

Staying on track

24 Tuesday Apr 2012

Posted by in Agile, Automation, Experiences, Experiments, STAREast 2012, Volunteering

≈ 1 Comment


A while back, I was talking to Matt Heusser about my sticker shock when it came to conference attendance and he pointed me to his blog post on creative ways to reduce the cost:

No, you don’t have to be a speaker. That may be the most obvious, easy, usual way in, but there are plenty of ways to serve for people not interested in public speaking: you might serve on the program committee, work the registration desk, introduce speakers, organize lightning talks, or serve as a “runner” in some capacity.

I took one of his suggestions to heart and volunteered to be on staff at STAREAST this year, which gave me the opportunity to look behind the scenes this past Wednesday and Thursday. (Sure, I missed out on the awesome tutorials this time around, but I did get that one key day of floating peacefully in the pool.)

This is a considerable shift from last year’s STAREAST, when I was free to simultaneously learn about my professional needs while designing and executing my conference schedule. This became particularly apparent to me as the week progressed and I made new tester friends who turned out to be speakers, inviting me to their sessions and I just couldn’t shirk my duties. Bummer. I’ll know to look for their names in the program next time around.

This year, I put in my bids for track selections about a month ahead of time, based on the published schedule, and hoped at least one of my first choices would appear on my list. When my track chair packet arrived, I delightedly perused the list of my tracks and my speakers. On my roster were several notable testers and several newcomers. I loved knowing I would get a glimpse into the processes of both the polished professionals and the fresh first-timers.

I read over the instructions with a highlighter and multicolored pens, calling out the relevant details so that I could support these live performances without a hitch. I’m not good with form letters, and I feel that it’s fair warning to let others know that I have a more casual and enthusiastic style of interaction, so I drafted my own email for first contact. From there, all of the advance preparation went off without a hitch and I eagerly anticipated getting settled in on Wednesday morning.

Fortunately for me, my first track was Agile Testing, so the speakers were predisposed to understand iterating to better and better results. It helped that I knew the first few speakers from in-person and online interactions. Speakers aren’t the only ones who get nervous! One of my tester friends from Twitter was in the audience to help me work out the kinks of the tasks set before me and to tune my results to make things easier on all the session participants and to keep me from stressing out.

One thing I quickly realized was that my introduction of a speaker could hardly do him or her justice, especially when we had just met for the first time, so I resolved to keep it short and sweet, trusting everyone could read the program’s bio and knowing that we were all there for the benefit of the speaker’s wisdom, not my scintillating 30-second background recap.

Though troubleshooting the hardware was certainly on my mind, I was particularly concerned with making sure the session feedback was collected and returned to the conference organizers so that they could tabulate results and provide it to the speakers in a more succinct and organized way. I know from observation and discussion how much work speakers put into their presentations and how open they are to comments. Speakers care for their audience members!

The hardest part of track chairing for me was not being free to type, scribble, or live tweet all the wonderful information flying past me! Normally, I write everything down, but I had to take it in stride and trust that my familiarity with some of the material would carry me through. However, I was also supporting sessions I might not have chosen from the program since they seemed to have a focus that didn’t match my day-to-day duties or needs – so I snuck a moment here and there to note some new revelation. As it turned out, I gleaned some value from every session, despite my expectations. Sure, I don’t work on specialized medical hardware or ERP systems, but the generalizable lessons will stand in good stead as I broaden my understanding of the variations of software testing.

When it’s all said and done, when the conference attendees have all gone home, it’s the information transmitted that can make a difference in people’s work lives – and perhaps even their personal lives – that gave me a warm fuzzy feeling to go along with the sore feet.

Image source

Creeping CRUD

13 Friday Apr 2012

Posted by in Context, Experiences

≈ 1 Comment


I recently tweeted that I was feeling frustrated with the medical billing industry. At that moment, I was particularly bothered by the seemingly endless wait of navigating the phone tree to get to a human being only to be shunted to voicemail. However, miracle of miracles, I did in fact get a return call from a person to discuss a recent explanation of benefits (EOB) I had received from my insurance company.

While my family had benefited from the services of this provider over the course of the last couple of years, we decided to move on and I was looking to settle accounts. I couldn’t help noticing that the EOB included Dates of Service that occurred after we had changed providers. Not wanting to immediately proclaim insurance fraud, I called up the provider to discuss what I imagined to be a data entry mistake.

The helpful billing staff member at the other end of the phone call fielded my questions calmly and clearly had heard this complaint before. She explained to me that sometimes there have been data entry mistakes related to the intake of a patient. Since recurring billing is scheduled based on this intake date, she had encountered situations where all of the billing they ever submitted for a patient had incorrect Date of Service values. She said that in this case she would have to make a note of the error, remember that it had occurred, and continue to submit that note with any problematic records since she wasn’t permitted to alter the medical record. I don’t think she meant that the software provided the option to enter an explanation:

If possible, explain why the earlier note was incorrect, the reason for the error, and the reason the error was noticed.
— Medical Economics

Rather, I think she had some separate, manual workaround for note-taking related to someone’s file.

Apparently there was an update/edit capability in the software but she was instructed not to use this due to legal concerns around altering a medical record. Presumably, their software did not provide differentiation between original and updated values with appropriate timestamps:

With electronic medical records, the computer program must show the dates of the original notes and the dates of any changes or new entries.
— Medical Economics

For the user, the result was effectively having no way to edit data. What a difference that context makes!

However, this was not our problem. She also elucidated a software bug in the system that involved a gradual creep of date ranges. For example, a monthly shipment of supplies would be billed over the course of 4 weeks after each ship date. After 2 years of shipments, the weekly billing dates had a lag of 11 days, which happened to put them after the date they discharged us from their care, making the incorrect billing appear to be fraudulent.

Despite having full CRUD functionality to allow correction of incorrect data entry, the staff would not correct records and in addition to that had to live with the pain of a creeping inaccuracy, leading to enough friction for the billing staff user that she had a canned answer for my concerns, which she had clearly addressed many times with other patients and their families. What a knot of confusion for the staff to untangle over and over again.

I can only hope that my new medical provider has a different medical record software provider and that the creeping crud doesn’t prove to be highly contagious.

Image source