TESTING PROCEDURES

 

This page will contain a listing of all procedures to be used when evaluating the functionality of a page on the web site. These procedures will be evolving rapidly as time progresses. As there will be a site framework established using web 2.0 technologies, some errors will be encountered along the way. By following these procedures, these problems can be quashed quickly and painlessly. Above all else, we must ensure a high standard of quality for this project.

 

 

 

Initial Testing

 

When evaluating a page after creation and upload, follow these basic steps.

---

 

 

1. Check links to the page (IE, a link from the tutorials page to a specific tutorial)
2. Check any images on a specific page. A common error is image URLs pointing to local copies of images rather than web locations; to confirm this is not the case, check the properties of each image to confirm is hosted on the site.
3. Check any links on the page to make sure they work. IE, if you have a cross-linked tutorial, ensure that link points to the proper page.
4. Check for any layout, style, or other formatting issues. Are the images to the proper size? Do all the text areas and images line up neatly?
5. Check for anything strange or out of place. As this is a database and PHP driven site, there will be occasional issues encountered that are the result of coding issues. In this case, contact Ryan Morash at rcmorashatplymouthdotedu.
6. Above all, ensure the site looks good and the information is correct.

---

 

Phase Two Testing

 

This is the stress test portion of the development phase. It is to be undertaken once a page has passed the initial checklist.

 

1. All pages need to be checked on at least two separate computers. These can be computers in different parts of campus or even just on campus and at a home computer. Any bugs or layout issues resulting need to be documented. (This testing procedure will probably be deprecated once we have a framework that is refined)
2. All pages need to be tested in at least two different browsers. IE, if on a PC, test using both Internet Explorer and Firefox. If on a Mac, use Safari and Internet Explorer for Mac 5.0. Different browsers have different ways of rendering CSS files in certain cases; we need to ensure that what we develop works properly no matter what the person is viewing the page with.
3. Above all, any page must be viewed by at least two people, preferably three or more. This step helps minimize the chances of errors both large and small.
4. After each person has viewed a page, they must mark that they have checked off on the page and pass it on to the next person for review. (Exact mechanism for this TBD)

 

---

 

CSS Development/Changes Checklist

 

As we have talked about in class, CSS will be used in the site to manage the way it appears to the public. The CSS file is stored in \\advtech\css\main.css. Anyone is allowed to edit this file, but the following procedures must be followed when working on it.

 

 

1. BACK UP THE CSS FILES BEFORE EDITING If the CSS file is somehow deleted or significantly damaged, it will take significant time to rebuild from scratch. Always back up the CSS directory beforehand.
2. Use smart naming standards for tags. Don't use generic name standards for text; use direct tag names that at least attempt to explain what you are doing.
3. Use //'s to leave comments where you have made changes. Currently, the existing css file is very basic; as we add things make sure to comment what the tags you have made do. If you make a tag to manage the border colors on a certain page, for example, leave a comment describing exactly what it does so there is no confusion.

 

---

 

SITE MAINTENENCE

 

 

As this website and the content within is going to take a great deal of time and effort to complete, some steps must be undertaken weekly to ensure that it continues to run and function, even if we suffer a major disaster.

 

 

1. Weekly Backups. At the end of each week, if not sooner, the entire site is to be backed up. As our files are not massive, this can be accomplished quickly and easily. (Exact procedure TBD)
2. Directory Maintenance. Overcrowded directories full of old files will slow progress and make maintenance more difficult. Don't leave old copies of files in major directories and ensure that personal files are kept out of group folders.
3. Don't Be Careless. Above all else, use good judgment. Don't delete random files and don't load the web site directories with junk.

 

These simple steps will ensure the steady progress and survivability of our project in just about any situation.

---

 

Copy Editing

 

The Copy Editing process is one that will be crucial to the quality and professionalism of our final product. As we have discussed in class, we all will take part in the Editing process and work within the Copy Editing Protocol. I have also attached the Copy Editing Log which will be filled out after each Editing session.

---

 

Copy Editing Protocol

 

• Each draft of a document will be read by three other people. In order to avoid a kind of familiarity of readers to authors, we should try and switch up who reads another persons work. As was brought up in class, the person we are partnered with to write the tutorials and procedures will be the first person to read the draft then two other people will be selected.

 

• We should leave classtime for editing other peoples' work, i.e., pieces other than your partners. The person you have partnered with should be contacted their work edited outside of class.

 

• Each person/Editor must fill out a Copy Editing Log after they are finished editing then give it to me (Doran). I am going to keep a binder filled with these Logs after they have been used. It is important I think, for us to keep a paper trail of what has been done, by whom and when.

 

• When editing a piece, it will be done on Hardcopy, so each person who has editing that needs to be done must print it out. We all know how much of a pain it is to edit stuff on screen. It does work but having the physical copy in front of you makes life so much easier. After the corrections have been made by the author, it will be placed in a central "Rough Draft Folder".

 

• There needs to be good communication between those who are editing and the author. I believe we discussed last time about using email for this communication. Perhaps when someone is done editing, they can send an email to the author and give a brief rundown of the corrections made and why.

 

• The decision to use the corrections made is up to the author.

 

• On our Peer Editing days we should take a few minutes and discuss what is going on in terms of Editing and talk in general about how things are progressing.

---

 

Copy Editing Log

 

I have uploaded a revised version of the Copy Editing Log, and please feel free to suggest changes. Before we begin the editing process, I will print out a lot of copies of this and keep them in a place that is easy for all of us to access. The new Copy Editing Log is under the Files heading at the top of the page.

---

 

Graphics

 

We should adhere to some basic graphics principles when designing our documents. Nate has provided some in his Style Guide that we can work with.

---

 

Graphics Protocol

 

• Screen shots should be scaled down so they show the most important information that best relates to the step they are illustrating.

 

• The cursor that was created should be placed inside the image pointing to the most relevant information in that image.

 

• Screen shots should be in classic windows theme.

 

• Image resolution should be within the 75 to 100 pixels/inch, and images should probably be no wider than 300 pixels.

 

• Placement of the image will be inside the step that it corresponds to and will be on the right hand side of the screen/page.