Step 1: Copy the following batch files to your c:\Program Files\Perforce\ directory.

• p4diff.bat is for diffing files
• p4merge.bat is for merging files

Step 2: In Visual Studio, navigate to the Configure User Tools dialog.

• Launch Visual Studio.
• Go to Tools > Options… > Source Control > Visual Studio Team Foundation Server.
• Click on Configure User Tools.

Step 3: Click Add.

• You’ll need to do this Add step twice.
• …once to configure p4merge for file compare.
• …and a second time to configure p4merge for file merge.

Step 4: Configure Visual Studio to use p4diff.bat for file compare.

• In the Configure Tool dialog, enter the following details.
• Extension: .*
• Operation: Compare
• Command: C:\Program Files\Perforce\p4diff.bat
• Arguments: %1 %2 “x” “x” “x” %6 %7

Step 5: Configure Visual Studio to use p4merge.bat for file merging.

• In the Configure Tool dialog, enter the following details.
• Extension: .*
• Operation: Merge
• Command: C:\Program Files\Perforce\p4merge.bat
• Arguments: %1 %2 %3 %4 “x” %6 %7 %8 %9

Summary

After saving all your changes, you’re all set. The next time you do a file compare or file merge operation in Visual Studio, p4merge will be launched. The file merge operation uses 3-way merge. The left-most pane is the file on the server, the middle pane is the version you had before you made any modifications and the right-most pane is your modified version of the file. The bottom pane is the merged result of the 3-way merge.

References

Using P4Merge with Visual Studio 2008 and TFS

The basic solution is to use a silent ringtone for numbers you don’t want bothering you. This consists of 4 basic steps.

1. Get yourself a blank mp3.
2. Make it a ringtone in Zune.
3. Sync it to your phone.
4. Set it as a ringtone.

Step 1: Get yourself a blank mp3

• Download a blank mp3 from here: http://www.xamuel.com/blank-mp3s
• You can also make your own.

Step 2: Make it a ringtone in Zune

• Copy the blank mp3 to your Music folder.
• Launch Zune.
• Zune should pick it up in its collection.
• In Zune, navigate to Collection > Music.
• Find the blank mp3.
• Right-cilck on the mp3 > Edit.
• Change the title to: Silent
• Change the genre to: ringtone
• Click OK.

Step 3: Sync it to your phone

• Connect your laptop to your phone via USB.
• Right-click on the mp3 > Sync with <your phone name>.
• Disconnect your phone from your laptop.

Step 4: Set it as a ringtone

• In your apps, go to Phone.
• Click on a phone number in your call history to block.
• After the profile for the phone number displays, click the pencil icon to edit.
• Click on Ringtone.
• Select the Silent ringtone which should be in the Custom section.

There you have it! Now you’ll never hear  that caller calling again (unless they change phone numbers)!

A full database is likely never encountered during development and probably completely forgotten during testing (it was in our case!). It will likely cause numerous issues for your software under test, since it’s usually forgotten. Here’s 4 easy steps to simulate a full SQL Server database without spending loads of time and resources filling up your database. This test is designed to mimic a full disk drive.

1. Prepare the database
2. Create a TrueCrypt volume
3. Copy the database to the TrueCrypt volume
4. Bring the database back online

The idea is to put a copy of your database on a TrueCrypt volume just big enough to hold your database. As you add records to this database, it fills up quickly. Below is each step in detail.

Step 1: Prepare the database

• Take the database offline. The simplest way to do this is to run the following SQL.

ALTER DATABASE your_database_name
SET OFFLINE WITH ROLLBACK IMMEDIATE
GO

• Make a copy of the original database.
  To find the location of your database in SQL Server Management Studio, simply right-click on your database and select Properties. Make a copy of all files associated with your database and store them in a separate directory. The idea is to keep a copy of your database in case something goes wrong. This is highly recommended.
• Bring the database back online. Running the following SQL will do just that.

ALTER DATABASE your_database_name
SET ONLINE
GO

• Shrink the database.
  Right-click on your database in SQL Server Management Studio. Then select Tasks > Shrink > Database. Database files are frequently bigger than the space the records occupy. The goal of this step is to make the database files about the same size as the space needed to store the records. This step also makes the database files a bit easier to deal with, since the shrunken files will be smaller. In addition, it means you’ll waste less time creating a TrueCrypt volume as a container for a gazillion GB of database files.

Step 2: Create a TrueCrypt volume

• Determine the size of your shrunken database files. This size determines the size of your TrueCrypt volume.
• Launch TrueCrypt.
• Click Create Volume.
• In the TrueCrypt Volume Creation Wizard, select Create an encrypted file container. Click Next.
• Choose Standard TrueCrypt volume. Click Next.
• Enter any filename for the Volume Location. Click Next.
• Use the defaults for the Encryption Options. Click Next.
• For the Volume Size, enter a size nearest to the size of the database files. Click Next.
• For the Volume Password, enter a password. Click Next.
• Click Format.
• Using TrueCrypt, mount the volume.

Step 3: Copy the database to the TrueCrypt volume

• Take the database offline. Use the SQL from Step 1.
• Detach the database.
  In SQL Server Management Studio, right-click on your database. Select Tasks > Detach… Click OK in the Detach Database dialog. Detaching the database allows you to re-attach the database at a different location.
• Copy the shrunken database files to the TrueCrypt volume.

Step 4: Bring the database back online

• I got errors when trying to attach a database using my own username. To work-around this, run SQL Server Management Studio as Administrator.
• Attach the database in the TrueCrypt volume.
  In SQL Server Management Studio, right-click on Databases, select Attach… In the Attach Databases dialog, click Add. Select the MDF file for the shrunken database you copied to your TrueCrypt volume.
• Bring the database online. Use the SQL from Step 1.

There you have it! You now have an identical copy of the database running in a volume with just enough space. Adding just a few more records will make the database full.

The top 3 most powerful elements of a bug report are…

1. Bug title
2. Screenshot
3. Steps to reproduce

Bug title

Your bug title is your gateway to your entire team. Everyone scans bug titles. The easier your bug title is to digest, the more likely your bug will be fixed. If someone evaluating your bug needs to open your bug again and again because your title is too long and cryptic, you have wasted their time. Your bug title should describe at a high level what observation you are seeing and when you are seeing it. There are exceptions to this general template, but following this formula leads to bug titles that save people time. Your bug is already a plea for someone’s time — why take up more time with a poorly worded bug title?

Developers scan bugs assigned to them by looking at the bug titles. Management scans bug titles to quickly determine which ones need to be fixed. Testers scan bug titles to look for duplicates and see which areas of the system are unstable. With so many people looking at bug titles, it’s frequently baffling why more time isn’t spent crafting a concise and informative bug title. Here are a few examples of clear bug titles…

• Client crashes when copying to clipboard while clipboard is busy
• Save dialog is blank after browsing to network drive

The 2 examples above exemplify a similar formula:

• observation WHEN something happens
• observation AFTER something happens

Screenshot

Coupled with a great bug title, a well-taken screenshot is the next key to an awesome bug report. If the bug title and screenshot are really good, someone reading your bug might be able to skip the other details all together. It’s a great sign when with only the bug title and the screenshot, someone looking at the bug already understands the bug.

A screenshot with clear direction about what to look at and just enough explanatory text is priceless. This is the best kind of bug, because it saves everyone time and communicates precisely what you’d like the team looking at. If they want more information, they can read the rest of the bug, steps to reproduce, stack trace, etc. If they want just enough information to understand what the bug is about and the impact of the bug (that’s what most people want to know!), then your bug title and a great screenshot are really all they need.

Steps to reproduce

Despite the awesomeness of the bug title and screenshot combination, the steps to reproduce a bug are another important item and are generally most important to the developer looking to fix the bug. Developers frequently complain about the steps to reproduce. Sometimes it’s the lack of detail in the bug. Frequently, it’s that the steps to reproduce the bug don’t really reproduce the bug.

Adding a great set of steps to reproduce the bug makes the bug easier to fix. However, it’s generally much harder to get these steps just right than at first glance. The amount of detail to put in these steps is crucial. You don’t want to waste your own time crafting super detailed steps to reproduce the bug. You also don’t want to waste the time of someone who knows the bug area super well, since they’ll be trudging through mundane detail trying to extract the steps that really matter. Finally, you don’t want to include too little detail so that someone new to the bug area can’t reproduce the bug. You need to find a balance. Unfortunately, finding the right balance means that someone will be unhappy. The real question is how you keep the majority of people happy.

Two-phase approach to repro steps

A two-phase approach to repro steps is what I use to address this balance. In the first phase, start with high-level steps for someone familiar with the area. Assume domain knowledge and familiarity with the bug area when writing these steps. Leave out the “click on this,” “enter this,” “launch this” steps. Think about how you would write the bug if you were reporting it to yourself. You probably wouldn’t care about all the mundane steps to accomplish an action. Instead of click File, then click Save, then enter your new filename, and finally click the Save button, something like “Save your document” is enough.

Once you’ve gotten this squared away, we move onto the second phase. Under each high-level step, add enough detail so that someone unfamiliar with the bug area can reproduce the bug. Make the high-level step more recognizable by highlighting it, underlining it, bolding it or putting asterisks in front of it. The idea is someone familiar with the bug area can scan the high-level steps, and someone unfamiliar with the bug area can dive into the more detailed steps.

Conclusion

So there you have it! The top 3 most powerful parts of an awesome bug report. There are lots of other things to include that may help with the bug investigation: your environment, the build you’re using, observations, perceived customer impact, priority, severity, any debugging you’ve already done, etc. Include anything you think that will help the team understand the bug, but make sure to use a concise, descriptive bug title, a great screenshot of the bug and two-level repro steps. Happy testing!

A straight-forward approach is to treat the clipboard as an external resource. It is an external resource! Generally, we normally don’t consider it an external resource — it’s part of Windows, it’s just a simple API call and it’s almost always available. However, the clipboard is a resource shared by other applications. Because of this characteristic, all the issues that come with sharing a resource (waiting for access, locking, deadlocking, etc.) become higher risk areas.

The advantage of this approach is you start thinking about things that may happen if the shared resource is unavailable. But the clipboard is always available, right? Like any shared resource, it can be held up. So what  does your application do when it’s held up? That’s exactly what this piece of code does. It holds onto the clipboard a bit longer than it should. It’s not the nicest thing to  do, but it can happen. Another application may have a bug, or perhaps a large amount of data is being copied to the clipboard causing a slight delay. The application you’re testing should be able to recover from such errors, because there’s no guarantee that every other application is a good citizen.

The key risk being assessed is… Does a busy clipboard cause issues for your application? It caused a crash in my case. This C# snippet does the magic of hanging onto the clipboard for 30 seconds. Enough time for you to get into your application under test to do your investigation.

class Program
{
    [System.Runtime.InteropServices.DllImport("user32.dll")]
    static extern IntPtr GetOpenClipboardWindow();

    [System.Runtime.InteropServices.DllImport("user32.dll", SetLastError = true)]
    static extern bool OpenClipboard(IntPtr hWndNewOwner);

    [System.Runtime.InteropServices.DllImport("user32.dll", SetLastError = true)]
    static extern bool CloseClipboard();

    static void Main(string[] args)
    {
        int secondsToLockClipboard = 30;

        IntPtr handleWnd = GetOpenClipboardWindow();
        OpenClipboard(handleWnd);

        for (int i = 1; i         {
            System.Threading.Thread.Sleep(1000);
            Console.WriteLine(i);
        }

        CloseClipboard();
    }
}

The difficulty is coming up with this particular scenario. In this case, by modeling the components in the software and thinking about how to make components unavailable, the test ideas started flowing.

Here’s the exam question he gives his students:

Suppose you have written a test tool that allows you to feed commands and data to Microsoft Excel and to Open Office Calc and to see the results. The test tool is complete, and it works correctly. You have been asked to test a new version of Calc and told to automate all of your testing. What oracles would you use to help you find bugs? What types of information would you expect to get with each oracle?

Note: Don’t just echo back a consistency heuristic. Be specific in your description of a relevant oracle and of the types of information or bugs that you expect.

As other comments on the post point out, I also find Hoffman’s list better suited for this exam question. As Cem Kaner already mentioned, they do indeed lend themselves well to being coded. After all, that’s exactly what they were designed for.

With respect to teaching a tester to generate oracles for the question, perhaps the student might be confused by the question itself. I don’t find it straight-forward to think about what oracles I would be using before I think about what information I’m trying to find out about the new version of Calc. As a tester, how often do we think about the oracle before thinking about what information we’re trying to ascertain?

As an example, perhaps I’m interested in finding out more information about Calc’s implementation of the SUM function. I may have used the Hoffman list which triggered a thought about the reference program oracle. Maybe this lead me to using the command feeding test tool to compare with Excel. Or perhaps Bach/Bolton’s comparable product heuristic triggered a similar thought. Why not use the “consistent with itself” heuristic to use Calc as its own oracle? After all, SUM should have an equivalent result when using a Calc addition operation? Would I have missed this if I were using the Hoffman list? Would I have been preoccupied with using Excel as a reference program rather than Calc itself?

In my own test design experience, I don’t find that the Bach/Bolton list triggers as many ideas as let’s say the SFDIPOT list or even just a giant list of test techniques/objectives (function testing, scenario testing, compatibility testing, etc.). Although I’m not as familiar with Hoffman’s list, you can bet I’ll be making use of it now. As Cem and other commenters on the post have mentioned, each list is not complete. Once we know what information we’re looking for, the Bach/Bolton list, Hoffman list or some custom combination of lists could be used to trigger thoughts about useful oracles which may or may not be automated.

In Martin Anderson’s Why QA needs to change? post, he wrote:

…The ability to deliver code into production at will has a direct effect on your bottom line but to do this effectively you need two things, 1) understand the important areas of functionality that the customers really use and 2) be able to test these areas as quickly and easily as possible.

The first is a business issue but the second boils down to automating your testing.

I agree with all points, except I do not agree that it always boils down to automating your testing. I agree understanding the important areas of functionality and making testing faster and easier is the right direction. I agree automating certain aspects of the testing process can help speed up parts of the testing process. I agree automation certainly seems to make it easier to run the automated aspects of the testing process.

However, we’d probably benefit from redefining what “automating your testing” means. To me, it means automating the verification of facts that we know about the system under test (SUT). The test code arranges the system, an action is performed and then one or more assertions (facts!) is made about the state of the system. Or… given a certain state of the system, when some action is performed, then certain facts about the system are true.

However we spin it, running this automation is not testing, it’s just verifying facts that we believe should be true when the system is behaving as expected. What’s testing?

1. Designing the test code to perform the verification. That’s testing.
2. Evaluating the results of the verification to determine whether a failing verification is a bug in the system or a bug in the test code. Yes, that’s testing.
3. Redesigning the test code so that a failing verification provides more useful information to the individual evaluating it. That’s testing.
4. Making the determination that a failing verification is actually a bug in a programmer’s interpretation of an ambiguous requirement. That’s testing, too.

Whether the act of designing, evaluating, redesigning and requirements follow-up is done by a programmer, tester or anyone outside these roles, it’s testing. At this moment, these testing activities are very difficult if not impossible to automate.

Going back to the original goal of delivering production code at will, rather than prioritizing by areas of functionality that the customers really use and then focusing your testing on those areas, why not focus on those areas that represent the biggest risk to the business value of the software for the customer?

If you’re unlucky, these might be the very same areas. More likely than not, the riskiest areas are a subset of the functionality that the customer uses plus any other new areas that might present new risks. These are the areas that testing should focus on.

Re-running that tired, old test on an area of the system that hasn’t changed but was deemed an “important area” tells us virtually nothing new about the system and adds no value to the testing process.

However, targeted testing (using manual or automated verification) on those high risk areas (areas that have changed recently, areas that have been the source of numerous bugs, areas that were recently added, etc.) is one shortcut to delivering high quality testing as quickly as possible.

Will this allow testing to happen more quickly? Probably. This approach allows testing to zero-in on the riskiest areas to find important issues quickly. It won’t find all issues (that’s impossible!), but it should give feedback to the team faster than attempting a singular focus on automating as many of the important areas as possible.

Will this be easy? Probably not, but testing is not easy either. Yet another reason why testing is so difficult to automate.

Getting a physical book onto your Kindle requires 3 basic steps:

1. Capture the book content using a camera.
2. Pre-process the captured content using Scan Tailor.
3. Use ABBYY FineReader for optical character recognition (OCR) to produce an eBook.

In this post, I’ll be covering step 3.

Materials

3 items are needed to produce an eBook  using the *.tiff files from step 2.

1. ABBYY FineReader 11. ABBYY FineReader is “an optical character recognition (OCR) application developed by the Russian software company ABBYY.” We will be using it to process the *.tiff files and generate an ePub eBook.
2. TIFF Image Files. You will need the *.tiff image files from step 2. These image files should all be residing in a single directory.
3. Calibre. Calibre is a “free and open source e-book computer software that organizes, saves and manages e-books, supporting a variety of formats.” We will be using it to convert the ePub file to a .mobi file. Then we will use Calibre to sync the .mobi file to your Kindle.

Opening the generated *.tiff files

1. Launch ABBYY FineReader.
2. In ABBYY FineReader, click the Open button.
3. Navigate to the directory containing the generated *.tiff files.
4. Select all of them.
5. Open them in ABBYY FineReader.

The Hard Part

1. Verify that the text generated by the OCR process is what you want in your eBook.
2. Depending on the quality of the *.tiff files, this may involve a lot of manual work.

Generating the ePub

1. I’ve found the best FineReader format for getting onto the Kindle is ePub.
2. By default, FineReader is configured to generate an MS Word file.
3. Look for a Word icon in the toolbar labelled Save.
4. Change this to ePub, but don’t generate just yet (click Cancel).
5. Look for a wrench icon in the toolbar.
6. Click on it, and configure the title and author of your book.
7. Now, click on the ePub Save button.
8. Voila, you’ve generated an ePub file!

Getting it onto your Kindle

1. I’m a heavy user of Calibre.
2. Import the newly genereted ePub.
3. Convert it to the *.mobi format.
4. Then sync it to your Kindle.

Enjoy reading your newly created eBook on your Kindle!

Getting a physical book onto your Kindle requires 3 basic steps:

1. Capture the book content using a camera.
2. Pre-process the captured content using Scan Tailor.
3. Use ABBYY FineReader for optical character recognition (OCR) to produce an eBook.

In this post, I’ll be covering step 2.

Materials

Only 2 items are needed to pre-process the captured book content  from step 1.

1. Scan Tailor. The Scan Tailor software is an “interactive post-processing tool for scanned pages. It performs operations such as page splitting, deskewing, adding/removing borders, and others. You give it raw scans, and you get pages ready to be…” fed into optical character recognition (OCR) software. Scan Tailor is Free Software.
2. Book Image Files. In step 1, you captured a book chapter as image files. These image files should all be residing in a single directory.

Creating a new Scan Tailor project

1. Launch Scan Tailor.
2. Create a New Project.
3. When prompted for the input directory, choose the directory containing your image files.
4. Scan Tailor will now load your image files.

Let Scan Tailor do its magic

If I press the hyperlink, the text appears to change for a moment like it’s downloading something, but then it plays a ding sound and the hyperlink returns.

This is an issue with receiving MMS messages and can be fixed by resetting your cellular network. My phone specifications are given below:

• Model: HTC T7575 (HTC Arrive)
• Software: Windows Phone 7.5
• OS version: 7.10.7720.68
• Firmware revision number: 2305.13.40301.651

Follow the steps below to fix the issue:

1. Go to your Settings app.
2. Select Cellular.
3. Select Change prl.
4. Allow your phone a few moments to search for the prl.
5. After the search is complete, navigate back to the mysterious SMS.
6. Select the Get media content now hyperlink.

The MMS content should now download, and all is again right in the world of Windows Phone.