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

Posted on 15/12/2010 by markjowen

…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.

The End

The importance of real End User Acceptance testing

Posted on 06/08/2010 by markjowen

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

FirstDoc User Group 2011 – a look back at th...

The true value of CMIS

Killa Hertz & The Case of the Missing Documen...

Killa Hertz & The Case of the Missing Documen...

“User Adoption Strategies” – Sec...

The Wingspan Connection – getting SharePoint...

Using a network file share – a case study

FirstDoc User Group 2011 – a look back at th...

Enterprise Search & Federated Search – what’s the difference?

Posted on 31/05/2010 by markjowen

In this post, I look at the difference between Enterprise Search & Federated Search …

Enterprise Search

In Enterprise Search, content is indexed locally.

That is, the content is made available to the search engine, and the metadata, and if possible, the content itself, is indexed and stored in a database.

Federated Search

Federated Search utilises the search results that are provided by an “external” system. (“External” refers to another document management system or search application.)

Enterprise Search & Federated Search – Different Indexing Methods

There are a few interesting things about the different indexing methods.

In Enterprise Search, the documents are available by the indexer, all the metadata and content can be crawled and indexed.

With a Federated Search, the results are what was returned from the external system. This relies on the external system’s indexing capabilities.

On the other hand, to access, and index documents locally (in an Enterprise Search) usually requires loading the document to a locally accessible location. To do this can chew up a lot of bandwidth. Then there is the corresponding CPU utilization to do the actual indexing. And to keep the index up-to-date, further crawls/indexing need to be performed regularly. If the documents are relatively “close” (within the same subnet) then this should not be too much of a problem.

However, when the documents are located in, or indexed by, remote (outside the firewall) systems, a federated search has certain benefits. All that is being transferred is the query and the results that match that query. The indexing process is being handled by the remote system. And this includes the regular indexing required to keep the index up-to-date.

Should you use Federated Search, or Enterprise Search

So the decision whether to use Federated Search or Enterprise Search, depends on:

the resources available (how much grunt does your indexing server have?),
the availability of the content that needs to be indexed (can the indexer access the content directly)
the bandwidth available
the amount of confidence that the search results returned contain 100% of the content that meets the search criteria. (Are you happy with the results that the remote system provides).