Using a USB Flash Drive to Install Windows XP.

I recently had to re-install Windows XP onto a laptop and was wondering to myself if there was a way to install XP onto a computer without using a CD. After doing a Google search on the subject and testing many different ways that were suggested. I found the following websites that worked for me.

Hopefully, they will work for you too.

URLs:
Installing Windows XP from a USB key
Make a bootable USB installer for Windows XP, Vista, 7 with WinToFlash
WinToFlash

I used WinToFlash to create a Windows XP install on a USB Flash Drive. Worked great - very cool.

One more reason to love Snarfer.

So, I had this dilemma...

How do I get all my RSS feeds updated to a second computer without the need to always export the feeds to an OPML file and import them to the other computer? Basically, feed syncing.

Some questions I asked myself were:

• What tools (Desktop Feed Readers) out in the "wild" already do this? Are they FREE?
  
• What Online Feed Readers can I switch too?
  
• What features do I like / don't like?
  
• Most important - Can I "leave" the current reader I use?
  

Over the years I have tried numerous amounts of RSS feed readers. Yet, none of them really have everything that I wanted. Back in December of 2007 I blogged about a RSS feed reader that I had been using for about a year and a-half prior to this post called Snarfer. You can read about Snarfer here. URL - http://www.snarfware.com/snarfer.htm

To this day I still think it is the best.

Anyway, back to my dilemma...

Since, I was using Snarfer daily and I loved its features I felt that nothing would compare to the usability experience that I had come accustomed too. During this past week I wanted to sync my feeds with another computer I use. After poking around in Snarfer I found that the functionality is not built-in. Using Snarfer as long as I have you would think I would know by now if it had a sync function. Well, the thought never crossed my mind until now. I was disappointed to find this out.

I then started looking around to see what I could do to accomplish this task. I found FeedDemon. FeedDemon is a popular RSS Feed Reader that is installed on the desktop of a computer and it is FREE. Before I started using Snarfer full-time I used FeedDemon for a few months. I was checking out the features of the latest version of FeedDemon and found out that it now supports feed syncing with Google Reader. This would allow me to install FeedDemon on two computers and sync the two with Google Reader. I was happy I found a solution.

I then installed FeedDemon and "synced" it with Google Reader. SUCCESS!!!

Back to my other issue though...

Could I leave behind Snarfer which has proven to me to be the best RSS reader created?

Answer: NO

Google Reader is good because of its ability to display web pages quickly inside a browser that is already loaded. It supports all kinds of multimedia that can come in RSS Feeds. And it is a FREE online service - meaning you can access it anywhere.

FeedDemon is good because it can save multimedia quickly to your computer. It has an OK interface - it seems sluggish to me when it is updating feeds or when you are trying to navigate quickly within the program. And it is updated regularly.

After trying these two readers out I decided that I still wanted to use Snarfer. I just could not bring myself to leave it - I know it sounds weird being in love with a program but, I love its features and the ability to organize feeds inside more then one folder.

Anyway, I started poking around the now closed (don't know what that's about) Snarfer support forums - here. I went to their Plug-ins thread and found something that I have apparently missed all the times I visited the support forums for various reasons. They have a Google Reader Synchronization plug-in that I somehow have missed all these years. See the post here. URL - http://www.snarfware.com/forum/viewtopic.php?t=737

Well that settled my dilemma - I promptly installed the plug-in put in my Google Account details and BAM - I had Google Reader syncing with two computers running my favorite RSS Reader. AWESOME!!!!

Now all I want is Snarfer to be updated with a nice notification system, etc., etc., etc.

Jing - FREE software that allows you to add visuals to online chats, etc.

A friend of mine suggested an application that would help me at my job as a Software QA Analyst. The program is called Jing. It allow me to quickly record screenshots and short videos with sound that can help developers understand defects or steps to reproduce defects within software.

The saved visuals can be shared instantly via IM, web, email, etc. And it does all this for FREE - Very Cool!!!

TweetDeck - A simple way to update tweets and your Facebook status.

As I was researching a way to quickly view and update my Twitter account (by the way it is TimF1x) I stumbled upon this cool application that uses Adobe Air technology - http://www.tweetdeck.com/beta/


After I installed it and got the settings how I wanted them. I quickly become excited about the program and the features that it has.

I have only been using it for a day and so far it has proven itself useful for what I wanted. I highly recommend it to anyone looking for a quick way to stay on top of Tweets and Facebook statues.

Rights of an End-User.

More great information on the rights of an End-User. Taken from the source and not modified.

***************************************

When considering product usability issues, testers should take the stance that these issues are not merely "Requests For Enhancement", but are violations of the end-users inalienable rights to workable and usable software. With that in mind, I've started a list of the "Bill of Rights" for End-Users, which are those things that I see, which testers should have in the forefront of their minds when performing usability testing.

These rights are not features, they are not version 2.0 enhancements, they are the inalienable and intrinsic to every user of our software.

• The end user has a right to change their mind.
  * Anything that can be installed must be able to be easily and completely (cleanly) uninstalled restoring the system to it's previous state without damage to other dependent software.
  * Users have the right to use the installer program to not only install and uninstall the program, but also to reinstall and repair.
  * Anything that can be configured can be unconfigured...
  * Anything added can be removed...
  
  
• Users have a right to simplicity. They should not have to know about inter-library dependencies and the like. The install should take care of all of these things auto-magically behind the scenes for the user, or when that is not possible it should explain clearly to the user in simple terms, what is needed and how the user can go about getting it.
  
  
• Users have a right to quiet control. Do not pop up windows in front of a user and take the focus. Users have other things in their world besides your crappy application; they don't want to be interrupted every time your application wants attention. Do not ever capture and mess with control keys .
  

• Users have a right to non-interference. Never, ever, mess with the value in the clipboard (Firefox). The clipboard is in the users space and belongs to the user, even though you have the means, you do not have the right to copy anything into the clipboard unless explicitly instructed by the user.
  
  
• Users have a right to privacy and peace of mind. Never scan the file system, never place anything in the filesystem or registry that a user may not be comfortable being accessed by others. Do not send ANY user data out to the network without notifying and gaining approval from the user.
  
  
• Users have the right to customize their view and environment. To change display settings, language preferences, ... Users have the right to run in 600x800 resolution and still navigate the page.
  
  
• Users have the right to use computers even if the users are differently-abled (various degrees of sight-impairment and colorblindness, hearing, one-handedness) (Section 508).
  
  
• Non-native English speaking users have the right to still use our software (I18N).
  
  
• Users have a right to the most simple and intuitive interface possible. Everyone should have the ability to be a power user in the application. Shortcut keys should be available and intuitive for common tasks. A user should be able to get to an area of the program in the least number of clicks and keystrokes possible; remove unnecessary transitional navigation pages.
  
  
• Users have a right to know what version they're running. Product name and exact version number need to be displayed in file names and in the install, before the installation process begins. It is unacceptable to display the version sometime after the install process has begun, or even worse, only after it has completed.
  
  
• Users have a right to graceful failures. Crashing the application or losing user data is unacceptable at any time under any condition short of OS intervention or powerfailure. Displaying ugly, unduly alarming, or unintuitive error messages are also unacceptable. The error messages need to avoid being unduly complicated, but they also must be honest about the cause of the problem. Sugar-coating a serious problem or treating an error condition as a mere warning does not help anyone.
  
  
• Users have the right to notification of service unavailability. An install should never restart any service without first asking the user.
  
  
• Intuitive interface. The onscreen text should explain exactly what is expected from the user. Users should never have to guess or go to some other documentation in order to configure or use. If additional information is needed, it should be redily available (links on the UI or in an obvious Help file).
  
  
• Identity Modifications. Users have the right to change names and passwords and everything should still work. Users have the right to make changes to other personal information (address, weight, spouse, etc.) and still maintain their identity and everything works.
  
  
• Instructions and Product Use Information. Documentation must be easy to find (all modern software products have a readme file at the root which contains vital information and links to all other needed info). It must contain instructions on the installation, configuration, administration, and use of the product. All documentation must be accurate and complete.
  

***************************************

Reference:
http://test-of-mettle.blogspot.com/2007/12/bill-of-end-user-rights.html

Great advise and a relevant take on software QA testing.

I have to say that I agree with the following information. This is taken directly from the source and has not been modified.

************************************

* Expose all issues. As a tester, you must report all software problems that you encounter. The ones in your own product take first priority, but defects found in other products along the way should not go unreported. A Tester has the moral obligation to make all problems visible to the appropriate people. It doesn't matter if the bug is in someone else's product. The user will see the issue in your product and they will blame you if they don't know what to do. At the very least, you should document issues like this in the Readme or Troubleshooting docs and provide warnings or workarounds.

* Every minute wasted is a bug lost. Good Testers are constantly active constantly looking at the product and constantly looking for ways to save time. There is never enough time to test the product completely and so every minute wasted is another bug that you're letting slip by. Cannot afford to take the stance of being "Perfectly Content to do absolutely nothing until someone tells me twice." Never stop searching.

* Every minute of someone else's time that is wasted is 2 lost bugs. The bug that you could have been finding and the bug that the other person could have been finding. DO NOT WASTE OTHER PEOPLES TIME. If you have a question, Google it, read the doc, stop and think about your question. There are not very many questions in this Universe whose answers exist only in the mind of one person. Dropping in on a developer or another tester who is busy working should be your last resort.

* Regressing defects. Testing that a defect is fixed, that the issue no longer happens, is only the beginning of regressing a defect. The most valuable part is also the hardest part, it comes in testing around the fixed area to verify that nothing else was broken. Knowing what is "around the fixed area", guessing what could have been affected by a fix (or not affected when it should have been), attaining a knowledge of the architecture of the product.

* Defects must be fixable. There is no point in entering a report for a defect that cannot be fixed. An issue cannot be fixed if it cannot be duplicated and there are not sufficient trace information to determine the cause. There cannot be a fix if the subject of a defect is not an identifiable, quantifiable issue and if a case cannot be made that the issue will cause damage or inconvenience to a user. Writing observations without qualifying them as Defects is an unacceptable waste of other peoples time. Part of writing fixable defects is to investigate the issue so that you can provide enough information to determine (1) Where the problem is happening (at a minimum, who's component it is happening in, i.e. who should be responsible for fixing) and (2) How to reproduce the problem consistently. When the resulting damage or inconvenience of a defect is not obvious, you may need to make a case for why it really is a defect and why it must be fixed.

* Developer helpers. Our job has nothing to do with helping the developers to do things that they are able to do but would rather not do. We are not machine jockeys. We are not customer support. Our #1 priority is the quality of the product that we have been assigned. Anything else is a distraction and should be avoided. Our job is to examine all aspects of a product to evaluate the products quality and it's fitness to meet the expectations of end users. Playing the part of developer-helper, or unit-test-automater should be reserved for Developer Interns. It wastes of the time of a QA Engineer and ultimately stunts the quality of the product. Occasionally we will help other groups when they're under the gun, because we're geared for it. However, we can not afford to let those groups believe that helping them is our only calling in life. The most useless waste of a Quality Assurance persons time is engaging in a task that a developer could do themselves. Sometimes for the overall good we must allow ourselves to be distracted from testing, but don't let distractions run your day. We are not Developer Helpers or lackys.

* Study voraciously. Google is your best friend. Always search for an answer to a question before asking it. Always research the technology of the product that you will be testing. In many ways the tester has a responsibility to know, even more intimately than the developer, the architecture of the product, it's environment, and the technologies that it is built upon and that it interacts with.

* Functional testing is only the first step. In order to be truly useful in this job, a tester must get beyond functionality testing. Functionality testing is preliminary to any other testing. If the product doesn't do what it's supposed to do, then any other issues are not terribly relevant. Developers could and should be doing functionality testing themselves in the form of Unit tests and other pre-check-in checks. If this is not being done, then that issue in the software development process of the team must be tackled before testing can archive full productivity. Where a tester adds value to the process is when he is able to go beyond those things that should be readily apparent to developers and casual users.

* Credibility is everything. There is no room for lies in this profession. Conjecture about something you don't really understand is the same as lying. Agreeing with something that someone else says that you don't know to be true, is the same as lying. Since our primary objective is to show the true state of the product, if what we say is not trusted by others then, even when we have done the work and the information is right, we have failed the primary objective. "Honra y dinero se ganan despacio y se pierden ligero" ~ "Reputation and money are earned slowly and lost quickly".

* Be a Devil for Details. Writing a bug report that just says "IT DON'T WORK", is NOT good enough. You must investigate the problem enough to provide the "Why it doesn't work", or the "When it doesn't work".

* If you're not part of the solution... Good testers don't just point out problems, they also suggest solutions. Examining the problem to the level that you can suggest solutions helps to verify that you understand the problem.

* Stand for quality. The #1 job of QA is to hold software development to a high standard of quality. This entails both the product and the process, in order to enforce both, you need to strive to have a maven understanding of both.

************************************
Reference:
http://test-of-mettle.blogspot.com/2007/11/testers-creedo.html

Tip of the Day - Where's the Clipboard in XP?

When using the copy/cut & paste features on a computer there can be times that it will become confused. This happens most often when working with remote connections, such as Remote Desktop. This also can happen when using VM software.

I have needed on occasion, the ability to clear the clipboard and start with a fresh copy/cut & paste session. Here is how I go about doing this.

• In Windows XP – Microsoft removed the shortcut to the clipboard from the Start menu.
• So, I created my own on the Desktop.
• Right click on the Desktop.
• Goto New -> Shortcut.
• Item location is – C:\windows\system32\clipbrd.exe
• Change Windows path to correct drive.
• Give the Shortcut a name.
• Finish

Now whenever you need to quickly view the contents or delete the contents of the clipboard – you can.

Reference:
http://www.andyrathbone.com/tips/clipbrd.html