Killa Hertz & The Case of the Missing Documents – Part 9

…continued from Part 8 —  [All Episodes]

While Killa and Trudy were waiting for extra memory to be put in the Web Services server, Killa showed Trudy how she could split up the crawl of the documents in the Documentum server into smaller jobs. It had been several weeks since he had heard from her, and Killa planned to make contact again to see how things were going.


Killa Hertz & The Case of the Missing Documents – Part 9

It had been a month. I hadn’t heard anything from Trudy, so I gave her a call.

“Killa!” was the first thing I heard after I got put through to her. “I’m really glad you called’ she squeaked over the telephone.

“And…” I asked, “how did things go?”

“It worked!’ she cried. “After the extra memory was put in, I did as you showed me, and the total number of documents being crawled is almost the same as the number of documents in the Documentum repository!” “Excellent, I’m on my way over to check things out.”

I drove over to the office where Trudy was working. She met me at the door and led me into where she worked. There was still piles of paper everywhere, and that photo of her dog was still there. Pulling up a spare seat, Trudy logged onto the system. “Look,” she said – “there is 2GB of memory on the Web Services server now”. She showed me the screen, which clearly showed the correct amount of memory.

Pulling up a spare seat, Trudy logged onto the system. “Look,” she said – “there is 2GB of memory on the Web Services server now”. She showed me the screen, which clearly showed the correct amount of memory.

“Ok, let’s see the crawl log.” Trudy switched to another screen where I could see SharePoint’s crawl log. Looking at the bottom of the screen, I could see that the last full crawl had taken place last week. It looked like it had been successful.

Leaning over Trudy’s shoulder, I grabbed a notepad, and one of the pens in the container on Trudy’s desk. I jotted down the numbers of documents that SharePoint had crawled.

Trudy ctrl-tabbed to a spreadsheet she had open. The numbers of documents that SharePoint had crawled were listed. And she had listed the counts from running a DQL query to determine the number of each content type in the docbase. Each value was in a different color.

I looked through her numbers. “Looks good kid” I said to her with a smile. “Looks like that problem is fixed”. She swayed back and forth with excitement. “And I’ve confirmed with everyone here. They can all find the documents they are looking for.” she squeaked.

“Good – let me just check it one more time.” I went back to her spreadsheet. Fired up DA, and ran a few more queries. The numbers still looked good. “Well Trudy, there’s not much more to do.” “She looked at me coyly “I guess we should celebrate.”  The look on her face was adorable. Sort of between puppy dog, and baby fur seal. “No need to Trudy. Just doing my job.”

I picked up my hat, swung my jacket over my shoulder, and walked out to the car park.

Of all the lawyer firms, in all the cities…

Well, it was a good job. I’m glad I could help the dame. I headed in the direction of O’Leary’s.

An ECM Detective story - Killa Hertz and the case of the Missing Documents

The End


Recommended Content on Amazon

Related Post

The importance of real End User Acceptance testing

Here’s a real-life story that shows the importance of End User Acceptance testing and what happens if this is skipped.


Just doing an upgrade

I was a systems analyst in a project for a client once that involved an upgrade for an Enterprise Search application. The application allowed users to locate documents that were scattered across different locations and was one of the important tools that the users relied on to do their job.

The tech guy who was doing the upgrade had worked many, many hours.

The job was not complex, but the server on which the application was installed was also used for other things and so, there were starts and stops as others demanded their own slice of time to do maintenance on other apps running on the system.

Time to test

Finally, Techguy had finished the upgrade. He made sure that all the settings were still correct and that the software was still able to give the logged-in users access only to the documents that they were allowed to see.

Techguy ran the software and checked that there were no errors.

Everything looked fine. The documents were being returned OK.

He did further testing, by physically eyeballing a document in the system, checking the content, and then doing searches on various metadata, as well as content searching. Yep, system worked well.

Techguy even performed Regression Testing, following a scripted Regression Test that he had written. It went through the whole process of creating a document, sending in for review, getting it approved, changing the status of the document, etc.

Everything checked out beautifully. Techguy proudly confirmed that the system was working fine.

Then the errors started

Then the users were allowed back onto the system. Within hours, tickets issues were being lodged. It seemed that the documents that were being returned in a Search were not opening. The user would click on a search result, and get greeted with a page not found error.

Techguy was called back in. He started looking at the system. Everything looked OK. He was told to look harder. After much scratching of head, and flicking back and forth between various screens Techguy looked up sheepishly. “He had forgotten to add one critical setting – the address of the computer that would allow a document to be displayed.

It turns out that all the Search application could talk with most of the computers involved, but when it came to doing the indexing, but when a request was made to open a document from the search results, a different mechanism was used. If the address of another server is not correctly entered, then a big fat nothing happens when a user clicks on a search result.

End User Acceptance testing – Test as a user, not as a techie …

Techguy was just that – a tech guy. When he did the upgrade he was a tech guy, and when he did the testing he was a tech guy. And

When he did the upgrade he was a tech guy, and when he did the testing he was a tech guy. And as a tech guy, he had focused on the technical side. He had made sure that all the main knobs had been turned, he had made sure that the process of indexing was working fine. He had even made sure that the system was returning search results as expected. The one thing that he hadn’t done was to try and open one of the documents that was returned!

Techguy’s oversight raised a very important point.

As well as technical guys doing technical testing, end users are also required to do end-user testing.

Why? Because the end user does stupid things that the technical people never expect…they actually use the system. And, even if there is a Standard Operating Procedure in place, users tend to use systems in ways that the technical guy would never think of.

Recommended Resources

[Important Disclosure]

Udemy Courses
The Best Software Testing Training You Will Ever Get
Software Testing,QA Testing, Manual Testing,SDLC,Test Plan
An Intro to Software Testing: Ultimate Guide for Testers
Software Testing
Testing In Agile

Related Post