Archive

Archive for August, 2008

I Hate Bug Reports

August 26, 2008 Leave a comment

I hate bug reports not because I have an ego and I think I write excellent code which can never have bugs or that I don’t want to fix them but because they often leave crucial information to reproduce the bug and/or what was the expected result and why the results are wrong and I end up in a wild goose chase hunting the testers for answers.

If the tester is not reporting the bug correctly, the developer will most likely reject this bug stating as not reproducible and assign it back the tester. The tester would most probably argue that the bug is there and it can be reproduced and a whole mess ensnares where the developer and tester both end up kicking the ball back and forth at each other. Not only is this time lost in non productivity but it gets pretty frustrating pretty fast.

If you want a bug to be fixed you need to report the bug effectively. So here are just a few pointers to our testers:

  • The bug title should describe the issue completely. Bug title will help developers to quickly analyze the bug nature. It saves time when we don’t need to open the whole bug report to know what the problem is. Keep in mind bug title is used as a reference to search the bug in the bug tracking tool so add in any keywords in the title which you think might help in finding the bug.
  • If your bug is not reproducible it will never get fixed. You should clearly mention the steps to reproduce the bug in the minimalist steps possible. Developers need to be able to get to the problem in the shortest time. Do not assume or skip any reproducing step. Always step through the steps yourself and make sure you don’t leave a step. Make sure your steps are robust enough to reproduce the bug without any ambiguity. Don’t assume that the developers can read your mind – don’t assume that they will do a few extra steps you think are obvious.
  • Never include more than one issue per report. If you have multiple issues, post separate bug reports for each and mark them as related. Reporting multiple bugs in one report will most likely cause your report to be closed when only part of it is implemented.
  • Do not post new bug or feature requests about the same bug or feature. Doing so takes a lot of time for us to merge your reports. The search feature of the bug tracking system is everyone’s friend.
  • Report the problem immediately. If you find any bug while testing, do not wait to write detail bug report later. Instead write the bug report immediately. This will ensure a good and reproducible bug report. If you decide to write the bug report later on then chances are high to miss the important steps in your report.
  • To create the highest quality bug report which will save developers time and increase the likelihood the bug is fixed, a little extra work goes a long way:
    • Is the bug tied to a single setting or is there a small range of cases? Identify the range.
    • What other user actions cause the error to occur?
    • Does the error occur with different settings or options selected?
  • Attachments are extremely helpful
    • Screenshots with comments really help understand the problem. A picture is worth 1000 words.
    • At the same time a picture should not be there to replace reproduce steps. The bug should still be captured in text even if a screenshot is attached.
  • A bug report should always contain the expected and observed results. Often times the developers don’t think that the bug is a real bug so it helps to explicitly list the expected and observed results. It is the testers duty to explain to the developers what went wrong.
  • Don’t use the bug report as a stepping stone – we have enough politics in the office already.

No doubt that your bug report should be a high quality document. Focus on writing good bug reports, spend some time on this task because this is main communication point between tester, developer and manager. Mangers should make aware to their team that writing a good bug report is primary responsibility of any tester. Your efforts towards writing good bug report will not only save company resources but also create a good relationship between you and developers.

Oh and one final note; just because the system performs differently that what was expected does not necessarily mean it is a bug. Remember "The best tester is the one who gets the most bugs fixed" – Cem Kaner

Visual Studio 2008 and .NET Framework 3.5 SP1 RTM is here

August 12, 2008 Leave a comment

RTM SP1 for Visual Studio 2008 and .NET Framework 3.5 is out and available for download http://msdn.microsoft.com/en-us/vstudio/products/cc533448.aspx

Visual Studio 2008 SP1 and .NET Framework 3.5 SP1 significantly improve the developer experience during the development process, and at runtime. These improvements address top issues reported by customers. For more information, see Visual Studio 2008 SP1 and .NET Framework 3.5 SP1.

Table-Valued parameter in SQL Server 2005

August 3, 2008 3 comments

In pre-SQL Server 2005 in order to pass in a set of values one had to create a temporary table, populate it with data using INSERT, and then just use it in the procedure or function since they are created for the current session and are available to all processes in that session.

I did a blog on how to pass in Table-Value Parameters in SQL Server 2008 but what if we have a need to pass in multiple rows of data to a T-SQL statement, or a routine such as stored procedure or function in SQL Server 2005?

Turns out the same can be done in SQL Server 2005 without using temporary tables. By using the XML data type you can pass user-defined sets between queries and also between the client and the server.

The following code shows how you can create and use XML parameters.

USE AdventureWorks; GO CREATE PROCEDURE uspEmployeeList(@EmployeeList XML) AS BEGIN SET NOCOUNT ON; SELECT E.* FROM HumanResources.Employee E INNER JOIN @EmployeeList.nodes('/Root/E') AS Tbl(C) ON E.EmployeeID = Tbl.C.value('@EmployeeID', 'INT'); RETURN; END
 

How are XML parameters supported in .NET? ADO.NET allows full support using SqlDbType.Xml type. Adding a XML as a parameter to the stored procedure from C# would have something like:

//string EmployeeXml = "<Root><E EmployeeID=\"1\" /><E EmployeeID=\"3\" /><E EmployeeID=\"5\" /><E EmployeeID=\"7\" /><E EmployeeID=\"11\" /></Root>";
 
// Create the data table
DataTable dt = new DataTable("E");
// Create the table schema
DataColumn dc = dt.Columns.Add("EmployeeID", typeof(string));
// Add a few records to the data table.
for (int i = 1; i <= 10; i++)
{
      // create a new row
      
DataRow
dr = dt.NewRow();
      // populate the fields
      
dr[0] = i.ToString();
      // add the row to the table
      
dt.Rows.Add(dr);
}
... System.Data.SqlClient.SqlCommand cmd = new System.Data.SqlClient.SqlCommand("uspEmployeeList", sqlConn); cmd.Parameters.Add("@EmployeeList", System.Data.SqlDbType.Xml); //cmd.Parameters["@EmployeeList"].Value = EmployeeXml; ...
// Create a temporary MemoryStream to hold the output of the WriteXml method of the DataTable
using (MemoryStream memoryStream = new MemoryStream())
{
dt.WriteXml(memoryStream);
         UTF8Encoding encoding = new UTF8Encoding();
         cmd.Parameters["@EmployeeList"].Value = encoding.GetString(memoryStream.ToArray());
}

Now that’s cool. This is much better than passing in a comma separated list and using a dynamic query in our procedure or function.