From the site, http://www.softwareqatest.com/qatfaq2.html, I came across this statement. There are many forms of software testing. What I am discussing herein is related to white-box testing, automation and framework development, performance, and security testing

What makes a good Software Test engineer?

“A good test engineer has a 'test to break' attitude, an ability to take the point of view of the customer, a strong desire for quality, and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers, and an ability to communicate with both technical (developers) and non-technical (customers, management) people is useful. Previous software development experience can be helpful as it provides a deeper understanding of the software development process, gives the tester an appreciation for the developers' point of view, and reduce the learning curve in automated test tool programming. Judgment skills are needed to assess high-risk or critical areas of an application on which to focus testing efforts when time is limited.”

In my opinion, more emphasis should be placed on the statement italicized above. Taking it a step further, I would say a developer with previous development knowledge of the product under test is even more valuable. Obviously domain knowledge is what increases this value. From previous experiences with organizations, the development skills of the tester are often largely ignored.

“Writing code? That’s what our developers do, not our testers.”

If we are not placing a greater emphasis on the development skills of the tester, we are missing opportunities to fully test the product. Testers with a development background are more familiar with the developer's perspective. They know the tricks developers do when writing code, they know their shortcuts and tendencies. These testers can also provide developers with insight into defensive coding, adding hooks to make automation easier, securing the product from attacks, ect.

I would argue the inverse is true as well, that having previous testing experience of the product would add value to the transition of a tester into development. A developer with a testing background should improve the testability and security of the product, because they, too, understand the importance and impact of test.

To me, test and development should be shared responsibilities. If a developer is out sick, on vacation, or the team needs a resource, a tester should be able to fill in, developing product code. If a tester is needed for similar reasons, a developer should be able to switch gears and fulfill that need as well. Neither should be more exciting nor glamorous. The organization should respect both disciplines equally. Testing is the last line of defense.  

The software engineer should have two personae, constructive and destructive. Perhaps this is similar to Dr. Jekyll and Mr. Hyde, where we replace the “evil” in Mr. Hyde with “destructive product testing.”

Think your web applications are safe from cross site scripting? Maybe, maybe not. Why take a chance?

I recently put together some notes for a presentation on cross site scripting, or XSS for short. I have decided to share some of the information, because I believe keeping a few thoughts in mind as we develop and test will go a long way when it comes to preventing attacks.

Cross Site Scripting – What is it?

Cross site scripting occurs when a web application gathers malicious data entered from a user, with or without negative intent. XSS can be achieved by exploiting locations in source code where users are able to input data, and the proper preventative measures have not been implemented to format and validate the inputted data. In other situations, session cookies and other sensitive data can be accessed by injecting malicious data and ultimately hijacking or impersonating a user’s account.

There are three main types of XSS according to Wikipedia, so I won’t bother rephrasing. Visit http://en.wikipedia.org/wiki/Cross-site_scripting for more information.

The most common technologies and languages used for XSS are JavaScript, VBScript, ActiveX, HTML, or Flash’s ActionScript. Not only do we need to protect our server code, but we need to think about our client code as well.

Prevention of Cross Site Scripting

The vast of majority of XSS attacks can be prevented by identifying the user input locations within the web application and ensuring the source code handling these has proper measures in place. From a developer’s perspective, this means ensuring all data inputted from a user is properly encoded to remove HTML and script markup to be replaced with text that all browsers can process.

A simple example in C# is to use the HttpServerUtility.HtmlEncode method to convert all HTML markup characters into their text equivalent. For example, if a user were to supply the input for a textbox with the following, “This is my <b>bolded text</b>.” The end result of the HtmlEncode method would result in the following, “This is my lt;bolded textgt;.” This is important because it removes HTML markup, which could be malicious. For example, “This is my text. <script>alert(‘This is an attack’);</script>.” This example is passing a JavaScript alert to open a modal popup on the screen to display to the user.

In addition to HTML inputted data encoded on the server, encoding data on the client can be equally important. JavaScript HTML elements can have two attributes, InnerHTML and InnerText. InnerText will render text, not HTML, so it is the safe option. InnerHTML can be used to inject an XSS attack because it can render user inputted HTML, including script. Ensure InnerHTML has the necessary string formatting to protect against this vulnerability.

Cookies are another vulnerability to XSS attacks. If any part of the website issues cookies and an XSS access point is discovered, it is now possible to steal cookies and private information from the application’s users. If the cookie can be accessed, so can the information with it. Users can be impersonated, and site credibility will be lost.

Encrypted web sites (SSL, HTTPS) are at risk just like their public counterparts. SSL sites appear to be protected, but it is possible to execute the same XSS attacks, they just happen over an encrypted connection.

To protect our web applications, we need to be aware of the XSS vulnerabilities common to attackers and place defensive measures to ensure user confidentiality and confidence. Without becoming an expert on XSS and security, it is possible to develop safe, reliable applications by understanding XSS and the vulnerabilities exposed by our applications.

What to Look for in Source Code

Execute a simple search in source code looking for certain keywords is a good starting point. Many of the XSS bugs I have seen reported could have been prevented with the simple measures. Ensure HTML input is properly encoded on the server using HtmlEncode. Ensure HTML input is properly formatted on the client using string.Format and InnerText.

In source code and wherever, look for the following vulnerabilities.

• InnerHTML
• InnerText is not supported by all browsers but the two can be found together. Look for where the strings are originating and if they are properly formatted/encoded.
• SetInnerText()
• JavaScript’s Eval()
• Don’t be Eval - http://24ways.org/2005/dont-be-eval
• Assigning of strings to page titles, control titles, ect.
• Sometimes we take request object data and immediately process it and render it on the client.
• Check the URL parameters passed in.
• The Request object
• Request.Params
• Request.Forms
• Request.QueryString
• Using HtmlTextWriter or any variation
• RenderBeginTag()
• AddAttribute()
• RenderEndTag()
• HtmlWriter.Write()
• Cookies
• Where are we using them and how are we handling them

Searching for these keywords within source will be a decent starting point for discovering XSS vulnerabilities

Microsoft Anti-Cross Site Scripting Library V3.0 Beta

Feel free to use a Microsoft API designed for XSS prevention within your code.

http://www.microsoft.com/downloads/details.aspx?FamilyId=051ee83c-5ccf-48ed-8463-02f56a6bfc09&displaylang=en

Closing Notes – because this topic can go on forever

There are tools to help assess if your site is vulnerable. Search for them online. Whether or not you think you need third party APIs to help you write defensive code is entirely up to you. You can always write the code yourself.

Cross-site scripting (XSS) can be damaging to a company’s credibility and can cause myriad undesirable effects for individual users. XSS is preventable. Familiarizing oneself with the smells of XSS is a valuable tool to posses as a developer and a tester. At a minimum, educate your developers and testers on the target hot-spots mentioned within this post.

References and Resources

http://en.wikipedia.org/wiki/Cross-site_scripting

http://www.cgisecurity.com/xss-faq.html

http://ha.ckers.org/xss.html

http://www.owasp.org/index.php/Cross_site_scripting

While investigating the file size limitations of Live Mesh, I came across this utility as a means of quickly creating files of specified sizes. FSUTIL is an administrative tool that can be used for managing files, mounting and dismounting volumes, and other file and disk related tasks on Windows XP and later.

To create a new file that is 100 MB, we have this command.

A quick and easy way to generate files of various sizes.

Back to my original investigation, Live Mesh, while it says it supports files of up to 2 GB, the actual uploading of movies (avi, wmv, mpg) greater than 50 MB appear to timeout. I was hoping to share video with family and friends. Hopefully there will be a resolution in the near future.

Read more on FSUTIL.

FSUTIL.exe (Win XP/2003 server)

FSUTIL on TechNet

I am always looking for tools to allow me to do more by doing less. Administering Hyper-V with PowerShell can be tedious. James O’Neill’s PowerShell Management Library for Hyper-V is a great tool to improve automation of Hyper-V management using PowerShell.

As a tester, I am constantly creating new environments, installing our product, taking snapshots, ect. Doing this by hand is a waste of time in my opinion. Doing this with a script makes life easier and frees up my time.

Typically, I prefer to create is to create one VM and to have other VMs inherit from that base image. My second VM (the first child to inherit from the base), I will install daily builds of our product. I will then create a third child, which I use a sandbox. I can easily delete it and recreate as needed without having to install our product over again. I have not consistently found success with using snapshots, so I prefer to use differencing disks. The examples below use differencing disks.

This first code block shows how I am using the PowerShell management library to simply the creation of a base VM. There is nothing magic about it. It’s pretty strait-forward. I create a VM, give it a name, set the CPU count, memory size, network adapters, hard drive, and DVD drive.

$server = "my-dev-server"
$vmName = "TestParentVM"
$vmVirtualSwitch = "My Virtual Network"

# create a new virtual machine
$vm = New-VM $vmName -server $server

# set cpu count
Set-VMCPUCount $vm 2 -server $server

# set memory size
Set-VMMemory $vm 2 -memory 4GB -server $server

# add a legacy network adapter
Add-VMNIC -vm $vm -VirtualSwitch $vmVirtualSwitch -legacy

# add a default VMBus (non-legacy) network adapter
Add-VMNIC -vm $vm -VirtualSwitch $vmVirtualSwitch

# add the hard drive to the VM
Add-VMNewHardDisk –vm $vm -controllerID 0 -lun 0 -vhdpath "$(get-VHDdefaultPath)\$vmName.vhd" -size 20GB

# add the DVD with bootup ISO
Add-VMDRIVE –vm $vm 1 1 -server $server -DVD 

Write-Host "Operation complete."

The next code block will create a differencing disk pointing to the parent created in the previous example. I create the usual, VM, CPU count, ect. What makes this a differencing disk is how the VHD is created by specifying the parent. I do some cleanup in this routine by deleting any previously created VMs or VHDs, and I loop through the creation a failure preventative.

$server = "my-dev-server"
$vmName = "TestChildVM"
$vmParent = "TestParentVM"
$vmVirtualSwitch = "My Virtual Network"

#region functions - feel free to move to a separate file

Function DeleteVhd
{
    Param ($pathToVhd)
    # delete the disk that was added if it exists
    if (test-path -path $pathToVhd)
    {
        Remove-Item -Path $pathToVhd -Force
    }
}

#endregion

# delete the VHD if it already exists
DeleteVhd "$(get-VHDdefaultPath)\$vmName.vhd"

# delete the VM if it already exists
Remove-VM -vm $vmName -server $server

# create a new virtual machine
$vm = New-VM $vmName -server $server

# get the vm
$vm = Get-VM $vmName

# set cpu count
Set-VMCPUCount $vm 2 -server $server

# set memory size
Set-VMMemory $vm 2 -memory 4GB -server $server

# get VM Nics available
$vmNics = Get-VMNic -server $server -vmbus -legacy
$vmNicSwitchList = New-Object System.Collections.ArrayList

# get VM Nic Switch available for each VM Nic and add it to our list
foreach ($vmNic in $vmNics)
{
    $vmSwitchElementName = (Get-VMNicSwitch $vmNic).ElementName
    if ($vmNicSwitchList.Contains($vmSwitchElementName) -ne $true)
    {
        $vmNicSwitchList.Add($vmSwitchElementName)
    }
}

# Use the first available VM Nic Switch - this assumes 
# I do not create more than on per each environment.
if ($vmNicSwitchList.Count -gt 0)
{
    $vmVirtualSwitch = $vmNicSwitchList[0]
}

# add a legacy network adapter
Add-VMNIC -vm $vm -VirtualSwitch $vmVirtualSwitch -legacy

# add a default VMBus (non-legacy) network adapter
Add-VMNIC -vm $vm -VirtualSwitch $vmVirtualSwitch

# add the hard drive to the VM
$parent = "$(get-VHDdefaultPath)\$vmParent.vhd"
$vhdPath = "$(get-VHDdefaultPath)\$vmName.vhd"
Add-VMNewHardDisk –vm $vm -controllerID 0 -lun 0 -vhdpath $vhdPath -parent $parent

# get the VM to see if a disk is attached to it, if it is not, then it failed
$disks = Get-VMDisk -vm $vm
$count = 1

# if the disk was not successfully added, try and add it again
while ($disks -eq $null -and $count -le 5)
{
    Write-Host "RETRY $count - The disk was not properly added. Attempting to retry."
    
    # delete the disk that was added
    DeleteVhd "$(get-VHDdefaultPath)\$vmName.vhd"
    
    Add-VMNewHardDisk –vm $vm -controllerID 0 -lun 0 -vhdpath $vhdPath -parent $parent
    
    $disks = Get-VMDisk -vm $vm
    $count++
}

if ($disks -eq $null)
{
    Write-Host "Operation failed to create this virtual machine. Contact an admin."
}
else
{
    Write-Host "Operation completed successfully. Attempting to start the VM."
    Start-VM -vm $vm -wait
}

I have found that the VM creation is not consistently successful on the first pass, so I have added the while loop. Since adding that, I have not had any issues.

I hope these help. They should be easy to change if you prefer snapshots versus differencing disks. Thanks to James O’Neill for creating this library. It makes administering Hyper-V much easier. It is available via CodePlex, where the latest release, updates, and forum support can be found.

The short story is this. If you are accessing Windows 7 from your MSDN subscriptions, save yourself time and frustration by installing the Windows 7 Beta, not the Windows 7 Beta Checked Build. See available downloads here.

This past weekend, I decided to upgrade my work laptop from Vista Enterprise to Windows 7 Ultimate Beta. I was unable to upgrade from Vista Enterprise to 7 Ultimate because that action is not supported. I then tried to upgrade from Enterprise to 7 Enterprise, but I was unable to upgrade from a staged build to a non-staged build. I decided to repave entirely, choosing Windows 7 Ultimate Beta, and I tried to do all of this on a Friday afternoon, two hours before leaving.

I installed Windows 7 Beta Checked Build (x86) - DVD (English), last updated on January 14, 2009,  from my MSDN subscription. I did not install an internal build. Instead, I decided to go with what is publicly available via MSDN.

Why did I go with a Checked Build? Because I failed to read the details describing it. What it cost me in time and frustration, I gain in valuable learning experiences. So it was not a total loss. I received a number of buggy issues with the checked build, mainly the inability for Windows Update to properly download all of my necessary updates, including my video drivers and smart card reader, where the latter enables me to remotely access my work domain.

I gave up and decided to download and install the Windows 7 Beta – DVD (English). Everything works great. I was able to get online, download all of my updates, and connect to my work domain. No issues found so far, and no annoying assertion error popups.

My favorite Windows 7 feature so far (non-UI related) is that PowerShell 2.0 is installed by default. PowerShell 2.0 provides more functionality for remoting, among other enhancements.

I needed to run some exploratory testing of a web application using FireFox on a Linux OS. In my environment, using anything but a Window's OS requires permission and several hoops through which to jump. I find myself using Hyper-V to avoid these issues, and because it is so easy.

There are so many versions of Linux, so which one should I choose?

I feel like a kid in a candy store when it comes to selecting one, or maybe two operating systems. I began with Ubuntu, essentially, picking up from the last chapter where I grew tired and put down the book that is Linux. Ubuntu worked well, or at least, it did not leave a bad taste in my mouth. Last time I installed Ubuntu, I was using Virtual PC 2004, and it worked successfully.

Installing Ubuntu 8.10 in Hyper-V was incredibly easy. A full installation required 3-4 screens of user interaction. After downloading the ISO image to my server, I fired it up in Hyper-V. First, select a language. Second, choose to try, install, check for defects, test memory, ect. I chose to "install" versus "try" a live version. Third, user input screen, answer some install configuration questions such as language, time zone, keyboard layout, disk space partition, and login information. Finally, after installing, I am prompted for my login and password. Total time was less than thirty minutes, and perhaps it could have been faster, but I was multitasking. After installing Ubuntu and configuring FireFox to work with my network, I was testing my web application.

Still in awe of how easy the installation was, I decided to try out other flavors of Linux. Like Microbrews, Linux distros seem to be a dime-a-dozen. I found some online articles to help me narrow down what distros other seems to like, and so I arrived at the following.

The distros I downloaded and installed (or tried to install) as a Hyper-V Virtual Machine.

• Ubuntu 8.10
• Fedora 10
• Linux Mint 6
• Mandriva Linux One 2009 (Gnome and KDE) - tried both
• Open SuSe 11.1 KDE
• SimplyMEPIS 7.0

In Hyper-V, installing Fedora, Linux Mint, and Open Suse were strait-forward and successful on my first run, just like Ubuntu. I had trouble with Mandriva and SimplyMEPIS. Both of them would hang as they tried to load the ISO image, so I gave up. At this point, I have four working Linux VMs enabling me to test my web applications, so the incentive to get Mandriva and SimplyMEPIS working just is not there right now. I do believe Mandriva and SimplyMEPIS will work with Hyper-V. I must have some configurations incorrect.

One thing I thought was funny about SimplyMEPIS is their website poses a question as part of their advertising, "Why SimplyMEPIS?" They respond with, "SimplyMEPIS just works!" It is sad that to have to advertise that "it just works," because to me, that implies the inverse was the rule rather than the exception with previous versions, or with the technology - in this case, Linux.

I have fought Linux installs in the past, getting my onboard sound card to work, locating other device drivers, and even upgrading browsers. When I see, "it simply works," I am still skeptical. It is unfortunate in my case with Hyper-V, that SimplyMEPIS did not work within the time limits I cared to allow for each distro. I will give it and Mandriva a fair shake by trying other configurations to get them working.

From my experiences, virtual machines are a great place to start getting familiar with operating systems. Having access to Hyper-V certainly made this experience successful and enjoyable. VMware and Virtual PC are two other virtualization software applications I have used as well for similar situations. VMware's support for Linux operation systems is great. I have been able to install Fedora Core and Ubuntu in Virtual PC, but not without swearing at my screen.

Just released today, IE 8 RC 1, install it here.

Faster, easier, safer and more reliable. Check it out for yourself.

Strait from the mouth of marketing.

Internet Explorer 8 RC1 is much faster than previous versions of Internet Explorer, so you’ll notice that difference right away.  But you’ll also notice some cool new features that will make your surfing experience faster and easier—not mention a whole lot safer.

• Highlight a street address in your Hotmail, Yahoo Mail, or other web mail account, right-click on the blue button that appears, and hover over “Map with Live Search.”  Presto!  You’ll see the map with the location right there—no more copying and pasting street addresses from web mail to a mapping site.  Plus, you can choose what mapping service you want to use.
• Go to the search box in the top right, and type a search item—see how the enhanced Instant Search Box is more helpful, providing real-time search suggestions, including images, from your chosen search provider.
• Click on a new tab, and see the options that are presented there, including “InPrivate Browsing.”  Click InPrivate Browsing and watch what happens—you are now in a browser session that is leaving no trail behind, so research gift suggestions for your significant other to your heart’s content without worrying about who might pick up the crumbs after you.

Harder to see are the many security enhancements that will help keep you protected against the ever-evolving online threats—things like protection from cross-site scripting attacks that no other browser offers.

PowerShell documentation, you are too honest.

Get-Help Remove-Item -Full

As I was retrieving information on "Remove-Item," this is what I came across. There is more detail beyond what I am showing, but pay attention to what is bolded.

NAME
    Remove-Item

SYNOPSIS
    Deletes the specified items.

SYNTAX
    Remove-Item [-path] <string[]> [-recurse] [-force] [-include <string[]>] [-
    exclude <string[]>] [-filter <string>] [-credential <PSCredential>] [-whatI
    f] [-confirm] [<CommonParameters>]

    Remove-Item [-literalPath] <string[]> [-recurse] [-force] [-include <string
    []>] [-exclude <string[]>] [-filter <string>] [-credential <PSCredential>]
    [-whatIf] [-confirm] [<CommonParameters>]

DETAILED DESCRIPTION
    The Remove-Item cmdlet deletes one or more items. Because it is supported b
    y many providers, it can delete many different types of items, including fi
    les, directories, registry keys, variables, aliases, certificates, and func
    tions.

PARAMETERS
    -path <string[]>
        Specifies a path to the items being removed. Wildcards are permitted. T
        he parameter name ("-Path") is optional.

        Required?                    true
        Position?                    1
        Default value                N/A - The path must be specified
        Accept pipeline input?       true (ByValue, ByPropertyName)
        Accept wildcard characters?  true

    -recurse <SwitchParameter>
        Deletes the items in the specified locations and in all child items of
        the locations.

        The Recurse parameter in this cmdlet does not work properly.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       false
        Accept wildcard characters?  false

 

"Hmmm... Am I feeling lucky? Ahhh, what the hell, let's do it."

Remove-Item "C:\" -Recurse

I consider myself to be a strong follower of the DRY principle. I practice it religiously. Lately, I have been applying DRY outside of my IDE, more specifically, with my build environments and daily developer tasks.

For example, every night I clean my build environment, sync up the latest code, and rebuild all products within my domain. The total time it takes to clean, sync, and build is over two hours, depending on hardware and connection speed. This has been reduced from over four hours. Now before I do all of this, I need to check my environment to ensure I have all the latest tools and versions of those tools, such as Visual Studio, SQL Server, windows updates, service packs, ect. This is just part of our build environment. Typically, we run this check until we receive a positive response, "all is well."

Rather than spend my time running these commands, I automate them, and run them around the clock using Task Scheduler, a BAT file, and PowerShell.

I create one scheduled task that runs once per hour, indefinitely. My scheduled task runs a BAT file that calls my PowerShell script. Within my PowerShell script, I create a Hashtable of commands to run and at which hour to run them. Each hour as the script is executed, I get the current hour and see if any tasks are available to run. For example, each night, sometime during the 2 AM hour, I start my full build. I realize that running once per hour limits the number of commands I can run, but for now, this imperfect solution meets my needs.

 1 # Local variables
 2 $productRoot = "c:\Projects\dev"  
 3 $currentHour = (Get-Date).Hour
 4 $list = New-Object System.Collections.Hashtable 
 5 
 6 # Define tasks to run each hour
 7 #     Hour 0 = 12:00-12:59 AM
 8 #     Hour 1 = 1:00-1:59 AM
 9 #     Hour 20 = 8:00-8:59 PM
10 $list.Add(20,"environmentCheck dev");
11 $list.Add(21,"environmentCheck test");
12 $list.Add(22,"environmentCheck system");
13 $list.Add(23,"projects clean sync");
14 $list.Add(2,"projects build full"); 
15 
16 # if a task is defined for this hour, execute it
17 if($list.Contains($currentHour))
18 {
19     # Get the command to execute for this hour
20     $buildCommand = $list[$currentHour]
21 
22     # Set the project bat path
23     $pathToBat = $productRoot + "\bin\project.bat"
24 
25     # Set the cmd.exe's arguments
26     $arguments = "/C cd /d " + $productRoot + " & " + $pathToBat + " & " + $buildCommand
27     
28     # Start up the DOS prompt, execute the commands
29     $process = New-Object -TypeName System.Diagnostics.Process
30     $process.StartInfo.FileName = "cmd.exe"
31     $process.StartInfo.Arguments = $arguments
32     $process.StartInfo.UseShellExecute = $false
33     $process.Start()
34     $process.WaitForExit()
35 } 

Every morning, I expect to have fresh builds. My build system will email me with the results. However, adding email capabilities to the above script with PowerShell is doable. The above commands execute on my dev server, but executing them on remote servers is also doable, even with PowerShell 1.0 and something like the following.

1 $toServer = "my-remote-server"
2 ([WMICLASS]"\\$toServer\ROOT\CIMV2:win32_process").Create($command)

If my environment is not current and my builds are not working, I can lose productivity during normal business hours. Using a simple scheduled task and PowerShell helps me administer my server and keeps me from repeating the same tedious steps on a daily basis.

How else does PowerShell help me adhere to DRY? It enables me to administer my Hyper-V machines, configure websites, GAC and un-GAC assemblies, and much more.

This is by no means a comprehensive review of SketchPath, but I just wanted to say thanks Phil Fearon, for developing this app.

I use XML/XPath/XSL less frequently today than with previous positions, but every now and then, when chiseling away at a slab of XML, having an XPath tool can make my life much easier. I always relied on Interactive XPath Expression Builder 4.0, but larger XML files hindered performance. In an effort to find a good XPath editor, I have installed several I have found on the web, used them, and uninstalled all of them.

Ideally, I am looking for a tool that is light and free. By light I mean, I am not looking to install a development studio, nor something that attempts to integrate with all of my existing applications, nor something that requires a reboot when installing or uninstalling, nor something that cannot fully uninstall itself. I plan on using this tool as often as I have to deal with XML/XPath/XSL these days, which is once every few months. Usually the time it takes me to find a tool, install it, author what I need, and uninstall it, I could have written the XPath by hand.

As I searched online for tools this time, I stumbled across SketchPath. While hesitant to install another XML app to only end up in my graveyard of XML apps, I gave this one a try. It is free, so I figured, why not.

"YES! F-bomb YEAH!"

After installing, I loaded up my XML, clicked on an attribute within a node, and sure enough, the XPath needed to locate that element was displayed. It was that simple. After a few more node selections, I had the XPath I needed for my app. In and out like a robbery.

"SketchPath is a free XPath Editor and XML analysis and testing tool supporting XPath 1.0 and XPath 2.0. It provides an integrated graphical environment for viewing XML files, developing and testing XPath expressions against them and managing the expressions in file libraries."

Thanks Phil! This was exactly what I needed. I will not be uninstalling.

For the past six months I have transitioned into a new role at a new company. I am now a software tester. For the past eight years, I have spent all of it but six months developing software, writing code, and thinking testers were individuals who chose a comfortable, stress-free career path, where they might be found playing World of Warcraft or reading science fiction novels in between periods of pretending to do work.

There, I said it. Now the healing can begin.

What was I doing for those six months when I was not developing? I began my career as a tester fresh out of school. I worked closely with a developer, we all worked in pairs back then. I discovered the work he was doing in development was sexier than what I was doing in testing. The rest is history.

"Software testing is  process, or a series of processes, designed to make sure computer code does what it was designed to do and that it does not do anything unintended. Software should be predictable and consistent, offering no surprises."

Yawn.

If you are still awake, I appreciate that. If you share my sentiment about testing, I cannot fault you. For the same reasons I wanted to get out of testing and into development, I was hesitant to get back into it.

Sadly, I had preconceived notions of what testers do and what skills and career goals they possess based on previous organizations.  For example, it was easy for me to generalize that the testers with whom I encountered were not as technical as developers, they were not writing code nor had any desire, and they wanted to get into the technology field but did not want to earn a CS degree. It was an easy way in. These are all erroneous generalizations that I regret thinking at one point in time, and for the most part, they were geared towards black box testing.

With testing comes new challenges. What I have read, and what I am trying to apply to my work, is the idea that the "attitude of the software tester may be more important than the software process itself."

In a nutshell, what this implies is that testers should approach their craft by trying to uncover the errors and failures within the product, rather than trying to prove the product works as expected. A tester should be disappointed when he/she cannot find errors, failures, bugs, ect. The mentality has shifted from constructive to destruction by nature.

As developers, we focus on developing a product, creating or constructing something. The subconscious wants to see it succeed, if not willing it to succeed. The attitude is constructive. If we approach testing the product by proving it contains no errors, we may subconsciously be influenced to choose data proving no errors exist, ultimately reducing our chances of discovering failures and defects.

As testers, our attitudes need to become destructive. This transition is difficult for some, since most of us approach our work constructively, meaning, we are used to building or creating things, rather than destroying them. We need to destroy the product. Do what we can to break it, cause it to fail, and bring it to its knees exposing weaknesses, vulnerabilities, and the many errors and bugs that do exist.

As testers, we write tests, test cases, and we strive to automate as much of it as possible. We even strive to automate the creation of more test cases. If our tests fail, they are successful, because this means our tests prove errors exist. When errors exist, testers are happy - developers are not.

Much has changed with my perception of software testing, starting with a fresh, new outlook and an attitude adjustment. And oh yeah, I forgot to mention, all those core object-oriented principles, practices, patterns, and frameworks, those are equally important in the world of testing as they are in development.

I work for an organization where heavy emphasis is placed on testing. I now spend much of my time developing automation frameworks and controls used to author tests. In addition, I am tasked with building a system to implement and measure code coverage, and investigate fuzz testing and model-based testing. This is hopefully the first post of many pertaining to and influenced by testing. Read more about the SDET versus the SDE here.

References:

I am reading "The Software Architect's Profession: An Introduction," by Marc T. Sewell and Laura M. Sewell. I am not writing a book review with this post. Instead, I would like to highlight some similarities between the two disciplines. Whether we are building with brick and mortar, wood, steel, or computer code, the roles and processes are analogous. The role of the architect is important for both, but when it comes to software, the architect often goes unfulfilled.

Compared to architecting and constructing homes, hospitals, and skyscrapers, architecting and developing software is new to many of us. In our minds, whether we understand the processes required to erect the Empire State building or not, most of us  possess an intuitive understanding of the distinct roles of the architect, scientist, engineer, builder, electrician, and plumber. We realize that buildings provide shelter, make our lives easier, and consist of rooms specific to living activities. We have living rooms, family rooms, meeting rooms, workout rooms, kitchens, ect. If we want to add on a garage, screened-in porch, or modify an existing room, the architect needs to plan for this in his/her design.

When it comes to software and the processes required to plan, design, develop, and test, many of us lack the intuitive knowledge of what is, or should be, necessary to build software. Just like a building, software makes our lives easier and consists of rooms, such as  chat rooms, document libraries, art studios, financial planning, shopping, and home buying to name a few. If we want to add on a new room or modify and existing, the architect needs to plan for this in his/her design.

It becomes easier to see how buildings and software are similar and how the roles specific to each appear to be obvious and necessary. A building needs an architect, a builder, an electrician, and so forth. Software, similarly, needs an architect, a developer, a tester, and so forth.

Ask yourself this, "how many buildings (homes, schools, hospitals, malls, ect.) can I think of that were built without an architect?" Hmmm... I probably cannot think of any, or I should hope the answer is zero.

Now ask yourself, "how many software applications were built without an architect?" This one I can answer more easily - several. I try to convince myself that so-and-so was "acting" as the architect on this or that project, but the nature of it is, too many software projects are built without a dedicated architect.

Why is it that we feel like a building requires an architect, but that software can get by without it?

Is it because over centuries and millennia, we have been exposed to the processes required to construct buildings on a daily basis? Whereas, since software is comparatively new, the processes and roles required are not fully defined, or engrained in us, or we have yet to see centuries worth of catastrophic errors from omitting these roles?

"Blaming software failure or difficulty on 'changing requirements' is merely symptomatic of the lack of true architecture." As owners and builders see what is being built, they realize what is incorrect and begin to make modifications to align their initial expectations with the reality before it is too late.

"It is equally erroneous to blame software failure on poor management. Even the best managers cannot produce a satisfying result from a bad design or a lack of design."

Without this post becoming tiresome and long-winded, this book draws some good comparisons between the nature of building structures and software and the roles necessary for each.

Do you have an architect in your organization? Is he/she only an architect, or is he/she sharing this responsibility? Why?

This is an interesting webcast on Channel9 where Eric Schmidt provides a technical tour of the NBCOlympics.com site built with Silverlight. If you are like me and become frustrated with the limited options of events the stations choose to broadcast, then we are in luck. The video that the NBCOlympics.com site is providing is excellent and covers nearly all the sports. I have heard estimates of roughly 2,200 hours of video, live commentary, live events, and with the ability to choose what we prefer to view. For those events we miss, we can search and view them at our leisure.

I have been able to watch some events I have always wanted to see but the television stations do not televise. Popularity and advertising dollars demand that stations air the usual suspects, swimming, track and field, gymnastics, ect. I have been able to explore fencing, sailing, handball, archery, and weightlifting to name a few.

If interested, check it out. If you have not seen the U.S. Men's 4x100 freestyle relay, check it out. What a race!

The marker interface is an interface that is empty. It does not implement any properties nor methods. It is used to mark the capability of a class as implementing a specific interface at run-time. In languages that do not provide support for associating metadata to a class, this approach can be useful. In C#, metadata attributes are available to apply to a class, and according to the .NET Framework 3.5 Design Guidelines for Developing Class Libraries, marker interfaces should be avoided.

When I first noticed these marker interfaces in project I immediately thought it was a code smell. It just did not seem "right." Why provide an interface that defines nothing? Why provide a marker interface that implements a non-marker interface? Obviously there must be a reason for this?

Two sources encourage me to avoid using marker interfaces and to use attributes in C#. Interface Design and .NET Type Design Guidelines - Interface Design.

There advice is to avoid this...

public interface IFooAssignable {}

public class FooAssignableAttribute : IFooAssignable

{

    // ...

}

And to embrace this approach...

[FooAssignable]

public class Foo

{

    // ...

}

public class FooAssignableAttribute : Attribute

{

    // ...

}

There appears to be more work involved in writing "good" code.

If I am using "marker" interfaces, I can do this...

if(foo is IFooAssignable)

{

    // ...

}

If I am using attributes, I can do something like this...

object[] attributes = foo.GetType().GetCustomAttributes(false);

foreach (string attribute in attributes)

{

    if(attribute == "FooAssignable")

    {

        // ...

    }

}

Or, thanks to Jarod Ferguson's suggestions on using extension methods and LINQ, I could have this...

public static class AttributeExtensions

{

    public static bool IsAttributedAs<T>(this object obj)

    {

        if(obj.GetType().GetCustomAttributes(false).Where(x => x is T).ToList().Count == 1)

            return true;

        return false;

    }

}

// Then wherever I want to check for the attribute marker...

if (foo.IsAttributedAs<FooAssignableAttribute>())

{

    // ...

}

At this point, while "marker" interfaces are a code smell to me, I am still on the fence when it comes to using them versus custom attributes. I will more than likely tend to favor the attribute approach, unless I can prove that the cost of reflection is too expensive for my situation. I admit, I will do what I can to omit marker interfaces, perhaps by using some other interface where possible.

What are you doing in situations like this? Can you offer me a more elegant solution?