Achieving an expected level of quality with limited resource and budget

Sometimes there is just no money for testing or QA. Testers leave your team and don’t get replaced. The team dwindles, but the developer base either maintains or grows. Your reduced team has more and more to do. The worst case scenario here is that your remaining testers become overworked, can’t do their job properly, get thoroughly de-motivated, and leave, and who could blame them. You now have even less resource.

Despite the scenario above, when it does happen, you will still hear the mantra of “quality is not negotiable”, and probably even more so, requests by product and company leaders to support everything and everyone.

So what is possible? How can you achieve the expected system and product quality with a limited budget?

Looking back at some of the successful projects on which I have been involved, and which have also been struck by similar limited test resource scenarios, it is possible to identify some common characteristics that contributed to their success from both a product and quality perspective.

- a product that the customer really needs
- customer input from the start
- a team that cares about what they are building
- a product manager that knows how to ship products and that trusts in the development team
- a strong work ethic
- innovation throughout the team
- the right tools
- a simple iterative development process

Without going into the psychological aspects of building the right team and processes, most of the above I would weigh as being far more important to foster or implement in a product development team than fretting too much about test and QA resource. Why? Having all the above, for me, goes a long way to ensuring the quality of both the idea and build of your product. Good people, processes, and tools will do far more for you than hammering your application to death, and don’t usually come out of your budget. If you don't have much of the above then life will be difficult.

As a final comment, if you are faced with the scenario described above, you should ask yourself, and maybe the business, the following questions:

- Can we compromise the quality of the system?
- Is quality negotiable for this product?
- Will the customers accept a less than perfect solution?

If the answer is yes to any of these questions then you have the answer as to why you have no  budget, and with this knowledge you can then focus your test and quality efforts in a different and more effective manner.

Kanban eBook

I blogged about Kanbanery a while back but failed to notice their really concise ebook on Kanban. Definitely worth a quick read if you are thinking of doing Kanban and need a quick introduction.

Kanban eBook

Integration testing of stored procedures using c# and NUnit

In a recent post I described setting up a database test framework to test an MS SQL database. The purpose of creating this framework was to ensure that in stored procedure heavy applications, we could still get a high level of automated test coverage (which is incredibly important for any application that uses any kind of continuous delivery process). That framework didn’t include an easy way to iterate through a result set and was limited to testing just the number results returned. (See this post for the original framework. Let me know if you need the source and ill get it zipped up).

I have now extended the framework to include the capability of executing a stored procedure with parameters, and then iterate through a result set by mapping the output to a data model.

Model the data

First set up a model of your data

public class CustomerBasicAccountModel

{

        public string CustomerID { get; set; }

        public string CustomerSortCode { get; set; }

        public string CustomerAccountNumber { get; set; }

        public string CustomerAffiliation { get; set; }

}

To facilitate reading of the data returned from a stored procedure I extend the datareader class to consume the reader using linq. This will allow me to easily manage the data once it is returned from the database.

using System;

using System.Collections.Generic;

using System.Data.SqlClient;

namespace  Database.Integration.DAL

{

    static class Extensions

    {

        public static IEnumerable<T> Select<T>(this SqlDataReader reader,

                                       Func<SqlDataReader, T> projection)

        {

            while (reader.Read())

            {

                yield return projection(reader);

            }

        }

    }

}

Finally in the test we can do something like this

[Test]

public void TestSortCode()

 {

            using (var session = _dbFactory.Create())

            {

                var z = session.GetTransaction().Connection.CreateCommand();

                z.CommandTimeout = 0;

                z.CommandType = CommandType.StoredProcedure;

                    var query = session.CreateQuery(

                    @"[GetCustomerBasicAccount]");

                query.AddParameter("@customerid", 3, DbType.Int32);

               

                var dataReader = query.GetAllResults();

                while (dataReader.IsClosed==false | dataReader.Read())

                {

                    using (dataReader)

                    {

                     customerBasicAccount = dataReader.Select(r => new                    CustomerBasicAccountModel

                                         {

                                         customerSortCode =

                                         r["CustomerSortCode"] is DBNull

                                         ? null

                                         : r["CustomerSortCode"]

                                         }).ToList();

                    }

                    Assert.AreEqual(customerBasicAccount[0].customerSortCode, 278222);

                }

            }

        }

Although this is a somewhat crude way to run integration tests on a database, it really does the trick. My original idea was that developers would simply use existing data mapping within a project and write the integration tests using that, but it has always been difficult to get them to commit to doing this. This framework is generic and can be used in any .net project with ease.