Use Cases

By Mark Gunn

In previous issues we have discussed solid business requirements, a master test plan, and a defect tracking system. The next step in the process, and one which is often overlooked, is to create use cases or test conditions.

Before you can begin to write test cases, you will need to understand how the system is going to be used. The system design documents will reflect how the system will be accessed and how data can be entered. This will be evident in the design or layout of the application. The application users will be able to explain how they intend to use the application. Of course, that has all been worked out and documented by the Business Analyst when the new SOP’s were written that reflect how the new application will impact the work flow. To best reflect how the work flow will affect the application, use cases should be written.

The use case should be a straight forward step by step process for how the users of the application will enter and use information. In its simplest form, they will cover how to Add, Change, and Delete information. Based on the type of application, this will require more detail but these are the basic constructs for a use case.

Without use cases, the test cases may be testing work flows that will never happen or more importantly, overlooking work flows that will happen.

For example; if you didn’t know that an end user will not have all of the information for an application module the first time they begin a new record, then you might construct a test case that was testing a first time completed module. Since a first time completed module initially can not happen, you may overlook in your testing that the system does not allow the user to save a partial record. The use case will cover this scenario and your test cases will accurately reflect these test conditions.

When you have completed your use cases, test cases can now be written so that they will completely test all of the applications requirements, designs and work flows.

Next time….writing good test cases!

Mark Gunn has 25 years experience in the Quality Assurance and FDA validation fields. If you have any questions about these topics, please email Mark at Mark@mgdservices.com

FDA Watch: Thinking like the FDA

By Mark Gunn
MGD Services

Those of us in an FDA regulated industry sometimes get caught up in all of the regulations and documentation and forget why the FDA is requiring us to create what seems like never ending documentation. At its core, the FDA has a very simple job, to assure quality.

The FDA is charged with assuring the quality of the products of the pharmaceutical industry. This can be manufacturing (GMP), laboratory (GLP), clinical trials (GCP), medical devices, etc. The FDA requires you to prove you have a quality process in place. They need to know the public can be assured that the products produced are safe and do what they were intended to do. The only way the FDA can be assured that quality is being met, is to demand that we prove it. And if you think about it, the FDA should not really be located in Washington DC. They should be located in Missouri, the “Show Me” state.

Thinking like an FDA auditor, no matter how scary that thought might be to you, is really very basic. They are much like a very inquisitive 5 year old. I don’t mean this to be demeaning any way. If you have ever explained a very complicated process to a 5 year old you know what I mean. After every statement you make the child follows it with “but why?” You then have to back your last statement up with another explanation. The FDA works much the same way. They really don’t have any choice.

For example:

FDA auditor: How do you know the data I am looking at is accurate and correct?

Client: We know who entered the data and we know that they are qualified to enter it.

FDA auditor: How do you know that they are qualified?

Client: We have their latest CV on file and it shows the training they have taken.

FDA auditor: How do you know they attended the training?

Client: We have a signed record of the class attendance.

FDA auditor: So you know that the person who entered the data is qualified to enter it. How do I know they are the ones that entered the data?

Client: We have done our Risk Assessment for 21CFR Part11 and we know we have to be compliant and we are…

And so the line of questioning will continue. But you get the idea.

If you think along these lines, you should be able to embrace what the FDA requires rather than avoiding it. Ask yourself these types of questions for any risk assessed task and you will understand why the FDA has the regulations and guidelines that they do.

The next time you have to make a change to a regulated process you have to be able to back up that change with all of the documentation necessary to prove what affect it will or will not have on your current validated process. For an auditor to assure quality, they must be able to prove that what they are observing is accurate. That is why the regulations and guidelines are in place, so that you can show them that you have a quality process.

And the Validation Library is the place where the FDA auditor starts to look. More on that next time…

Mark Gunn has 25 years experience in the Quality Assurance and FDA validation fields. If you have any questions about these topics, please email Mark at Mark@mgdservices.com

In the News: Revlon Run/Walk for Women

by Gretchen Gunn

Created in 1993 through the committed and collective efforts of the Entertainment Industry Foundation, Lilly Tartikoff, Ronald O. Perelman, and The Davis Group, the Revlon Run/Walk For Women has grown to become one of the nation's largest 5K fundraising events. To date, the Run/Walks (NY/LA) have raised over 30 million dollars for cancer research, counseling, and outreach programs. Thanks in part to these funds, new treatments are being developed and lives are being saved.

Some of MGD Services, Inc. employees and friends are participating in this worthy cause. Team captain, Gretchen Gunn shares some of her thoughts on the event and why she is participating. We welcome anyone interested in joining us! Click here to join the team.

Running has been my way to maintain both a healthy body and soul. And now it is a vehicle that will allow me to support others. On April 30, 2005, I will be participating in the Revlon Run/Walk for Women. I have also convinced a group of my friends to join me. Our team is called the Band of Babes. What started as a way to do something I enjoy and help others, has moved me in ways I did not expect. I have learned that many of my friends have either felt the sorrow of losing someone to cancer or they have lived the terror of having cancer themselves. Please donate and help support research to find a cure for women's cancers. A donation from you would be gratefully appreciated. Thank you for joining the Band of Babe's efforts to find a cure!

Save a Life, Make a Pledge

It is estimated that one in eight American women will develop breast cancer at some point in her life. In 2004, 272,000 women will have died from cancer. Behind this staggering statistic is the face of a woman who needs your help - a mother, a wife, a sister, a friend. The need is great and that is why I would like to ask for your help.

Click here to make a pledge.

Master Test Plans

By Mark Gunn

Prior to writing test cases for your project testing, you must create a master test plan that encompasses the complete range of testing tasks to be accomplished. To continue the construction analogy from my previous article (I just finished building a game room in our basement so forgive me) you can’t construct a building without a blue print and the same applies for testing a system.

The Master Test Plan is the blue print for how you will conduct your testing for the entire project life cycle. This is the vehicle that will communicate the testing scope and strategy to the rest of the project team. Development, project management, the test team and the user community will review the plan to ensure that all aspects of the application are being properly quality assured.

The information that encompasses the Master Test Plan must be detailed and well thought out. Putting together the plan requires many hours of reviewing the system design documents, project scope, business requirements, and the release schedule from development. Part of developing the test plan will be ascertaining the proper staffing needs for the testing the application, how those resources will be utilized and when.

The following are the major areas that all Master Test Plans must cover:

1. System Overview – a description of what the application is intended accomplish.


2. Purpose and Scope – the purpose for what QA will accomplish and the scope of the effort the QA team will be making.


3. Assumptions and Risk Assessment – what are the assumptions QA will be making on the nature of the project and what risks QA will be taking.


4. The Strategy – the overall approach QA will use for the testing. An explanation of testing methods to be used.


5. Data Preparation – what type of preparation will be required to prepare data for testing. This could require database refresh or data refresh scripts to be written.


6. The Build Matrix – each phase of the testing Unit, Functional, System Integration, Volume and Stress, Data Conversion (if necessary) and UAT will be outlined as to what will be tested in each phase and each build within each phase.


7. Work Plan – the Work Breakdown Structure (WBS) for what resources will be used and how they will be applied to each phase of the project. Also included will be milestone and target dates and any environmental requirements (PC’s, Networking, software, etc.) the team will have.


8. Testing Procedures – consists of version control, change control, and defect tracking procedures that will be used for all project participants.


9. Sample Forms – this will include a sample test case, sample defect tracking document and any other relative documents QA will be using for the project.

Once your test plan is approved, NOW you can start to write test cases. It is still not time to start testing yet, more on this in the next issue.

Mark Gunn has 25 years experience in the Quality Assurance and FDA validation fields. If you have any questions about these topics, please email Mark at mark@mgdservices.com

FDA Watch: Documented Training in a Qualified Network Environment

By Eric M. Stroud
GMPNetworks / Syvax Inc.

In order to complete the validation process for networks that require FDA Validation, one must provide evidence that training on network-related SOPs was conducted. A record of the training that was given for the network must be produced. This training record may be electronic or hardcopy.

Electronic training records are usually implemented at companies with a strong CBT program (computer-based training). After reading and possibly taking a short quiz, the electronic training record captures the name, date, topic, procedure #, score, employee ID #, and so on, as evidence of compliance.

More commonly, a training record is a simple form, which records the procedure title, trainer’s name, date, duration, and attendees.
Hint: Distribute the attendance list at the end of the training session!
The hardcopy training records must be maintained in a documentation repository.

If your company has a history of noncompliance with procedures (people not following SOPs consistently), taking attendance is not enough. It is good practice to implement a competency test following the training. This is typically a short quiz, not lasting more than 30 minutes. A threshold score is set, and all of the attendees meeting or exceeding the threshold score are allowed to perform a certain function. Those who fail the competency test must take the training again, and this highlights those colleagues that may need shadowing and observation.

In closing, “informal” training is not enough! Accurately record your training sessions, even if it is just one person in attendance. The creation of the training record is one of the key ingredients to show compliance with your own procedures.

Eric is an FDA Validation expert for GMPNetworks/Syvax Inc. Eric has over ten years experience with FDA validation for the pharmaceutical industry and has been specializing in validating IT data networks.
http://www.gmpnetworks.com

In the News: Firefox Web Browser

KEY BISCAYNE, Fla. Jan 24, 2005

By age 10, Blake Ross was designing Web pages on America Online. By 14, after mastering complex programming languages such as C++, he was fixing bugs in Netscape's Web browser from home, a hobby that landed him a job offer. "What, at the local store or something?" David Ross remembered thinking when his son told him. No, at Netscape Communications Corp.

Ross, now 19, a sophomore computer science major at Stanford University, has an even more impressive resume than most of his peers. Before graduating high school, he helped develop Firefox.

Colleagues who worked with Ross only online were surprised when they met him to find "a scrawny 15-year-old kid," recalled Chris Hofmann, engineering director at the Mozilla Foundation.

To take an internship at Netscape during the summer of 2001, Ross moved with his mother to a rented apartment near Netscape's offices in Mountain View, Calif. She drove him to work each morning.

He continued working on the browser on contract after returning to Florida to attend Gulliver Preparatory School. He breezed through computer classes, finishing projects in a day that took others two weeks, said Dean Morell, a former teacher and chairman of the school's computer science department.
Ross soon took on a much more demanding project.

America Online Inc., which bought Netscape in 1999, was trying to resurrect the once-mighty Netscape browser. AOL added features, but they bogged down the software and reduced performance, Ross said in recent interviews by e-mail and at his parents' condo in Key Biscayne, a Miami suburb.

At 17, Ross and another Netscape programmer, David Hyatt, started a side project that became Firefox. They wanted to strip down Netscape and the Mozilla suite on which it is based. By reducing the software to its browsing basics, they figured it would run more efficiently.

Ross and Hyatt created an early version of the browser. Because the project was open source, thousands of volunteers could examine the programming code and suggest ways to improve performance and fix bugs.

"I have fond memories of long nights spent at Netscape just poring over all the feedback people submitted about our programs," Ross said.

Hofmann, the Mozilla engineering director, said Ross dealt with the pressures of Silicon Valley quite well for his age.

"I don't think that he was intimidated or awe-struck at all," he said. "With open-source projects you rise to a level based on your skills. It is really a meritocracy. Anyone who has the skills rises quickly and Blake had all those skills."

AOL ultimately spun off the project and created the not-for-profit Mozilla Foundation to develop Firefox and related software.

Hyatt left to design Apple Computer Inc.'s Safari Web browser, but Ross stayed and helped fix Firefox bugs from college.

Firefox was officially released Nov. 9. It was used by 4.6 percent of Web surfers in early January, and that number could reach 10 percent by mid-2005, according to WebSideStory, which tracks browser use. Microsoft's Internet Explorer has dropped to 90.6 percent this month from 95.5 percent in June.
Security experts like Firefox, saying it isn't as vulnerable as Internet Explorer to viruses, spyware and other malicious programs.