Within your team, do you see the following characteristics:

• When something goes wrong, the first question is “Who messed up?” rather than “How do we learn from this and stop it from happening again?”?
• Is documentation created as a way to defend against the “Who messed up?” question being asked in the future?
• Are individuals focused on ensuring they do not mess up rather than ensuring that the team’s commitments are being met?
• Are individuals afraid to take action on bold ideas because they are too concerned about what will happen if the idea hits some roadbumps on the way to implementation?

Even if you are best buds with the members of your team, if the type of characteristics above are present, you do not have a sufficient level of trust to function as a team.  As a result, productivity is taking hit and you are probably focused on tasks that are more about process adherence rather than product improvement/innovation.

Do you find yourself in this type of gloomy situation?  While team members themselves can focus on avoiding “CYA” type of behavior, your managers can have the biggest positive impact on the situation.  Imagine if a team meeting is called and the key managers come in and say “Going forward, we do not care if mistakes occur.  However, we do care about you learning from your mistakes and improving.  In addition, we care about you meeting your commitments more than having the proper paper trail”.  Now imagine when the first mistake after this meeting occurs and managment follows through on their statements!  By establishing the fact that  continuous improvement is valued over the blame game, teams are now enabled to build a trusting environment for themselves.

Up until today, I had not gained much traction in getting the changes approved.  However, after I stated the opportunity as “we pay people to manage channel X.  This other channel that we do nothing with and serve a “hostile” user experience to accounts for 1.5 times the traffic of channel X.”, people took notice.   Once the opportunity was stated in a way that used easy to understand measurements, the initiative moved from the back burner to “how do we fix this?”.

This change in direction would not have been possible without a proper web analytics platform being in place.  However, even if you have the “best in class” tool in place, it means nothing if you do not actively research and leverage the data being delivered to you on an ongoing basis.

DbFit provides a lightweight and quick way to test this logic.  One of the many benefits of DbFit is that, if you connect to the database in flow mode, DBFit will do transaction management for you.  The DbFit documentation states that when you are in flow mode, “the current transaction is automatically rolled back at the end of the page”.  The alternative to flow mode is standalone mode.  In standalone mode, you need to specify when you want to commit or rollback the transactions (using the DatabaseEnvironment fixture).  In both flow mode and standalone mode, the transaction automatically starts when you connect to the database.

As I was building my DbFit tests, I realized I needed to set up some test data beforehand in the database so that the stored procedure could operate on the test data.  In addition, I would need to delete this data when my test completed so that the test did not leave a footprint.  In my case, I needed to set up a full customer account.  To do this, about 16 tables need data inserted into them.  While I could add all the necessary sql statements to the DbFit test in order to add this data, my group and I had previously created Fit sequence fixtures that we use in other areas that take care of setting up and tearing down a test customer account.  These Setup/Teardown fixtures were already in use in the more “traditional” parts of our FitNesse test suite where the bulk of test pages have been created.

At this point, I am feeling pretty good.  I have a Fit fixture library that can be used to set up a full account and I have DbFit tests that can operate on the test data via the respective stored procedures under test.

However, using database aware Fit fixtures and DbFit fixtures on the same page opens up a slightly thorny issue.  The DbFit tests were originally created to connect in flow mode in order to take advantage of the built in transaction management.    The Fit sequence fixtures I used also created transactions.  As a result, it became very important for me to know what DbFit considers the “end of the page”.

Consider the following flow of my test.  In this example, each line also has a reference to what transaction the statements will run in.

MyAwesomeDbFitTest.SetUp
DBFit:  connect to database in flow mode (TRANSACTION 1)
DBFit: set up a small piece of test data  (TRANSACTION 1)
Fit Fixture:  set up full test customer  (TRANSACTION 2)

MyAwesomeDbFitTest

DbFit:  run queries, execute stored procs, other testing (TRANSACTION 1)

MyAwesomeDbFitTest.TearDown
Fit Fixture:  teardown the full test customer (TRANSACTION 3)

If DbFit considers the test page “the end”,  I am ok.  The DBFit transaction will be rolled back and will not collide with the statements running in Transaction 3 when the Fit fixture is looking to teardown the test account in the database.

However, what I found is that DbFit considers the TearDown page (whether it is a TearDown page for just that page or a TearDown page at the Suite level that is used for each test) as part of the test and thus my overall test started to create blocks in the DB.  Specifically, TRANSACTION 1 was blocking TRANSACTION 3.

As I wondered how long it would be before the DBA police came to my door and revoked my access rights due to the blocks my tests were creating (it was all in a DEV environment, I swear!), I started to think about what I could do to solve this issue.  I thought of two options:

1.  Port the Fit Fixture setup/teardown code to sql statements that could be executed as DbFit fixtures.  This was quickly discarded due the fact that I am not keen on maintaining two copies of code that do essentially the same thing.

2.  Drop into standalone mode for the DbFit tests so I can maintain a tighter level of control as to when the transactions rollback/commit.

After experimenting with option 2, I found that the following test flow will allow for the transactions to commit/rollback as needed and not create any blocks.

MyMoreAwesomeDbFitTest.SetUp
DBFit:  connect to database in standalone mode (TRANSACTION 1)
DBFit: set up a small piece of test data  (TRANSACTION 1)
Fit Sequence Fixture:  set up full test customer  (TRANSACTION 2)

MyMoreAwesomeDbFitTest
DbFit:  run queries, execute stored procs, other testing (TRANSACTION 1)

MyMoreAwesomeDbFitTest.TearDown
DbFit:  issue rollback statment via the DatabaseEnvironment fixture (TRANSACTION 1)
Fit Sequence Fixture:  teardown the full test customer (TRANSACTION 3)

After making the necessary tweaks, the tests ran fine.  However, I still have concerns about the maintainability of this approach.  In order  for other developers to leverage this pattern, they need to understand when the transactions are being created and they need to explicitly manage the transactions.  This is not optimal.  Ideally, a FitNesse page will contain only one type of database aware fixtures, DbFit or homegrown Fit fixtures.  By doing this, transaction management can be pushed to the background and the developer can focus on test writing.

In an ideal world of my own making, another DbFit fixture would be available called QueryUsingFile (this is in addition to the free beer that would be present in this ideal world as well).  It would allow me to specify a path to a file and would execute the SQL statements within the file.  By doing this, I could organize a set of scripts to be used by any DbFit test and I could keep the test page code to a minimum.  DbFit already has a ConnectUsingFile option so it  seems a QueryUsingFile fixture would not be a big leap.

If I get a chance, I’ll post a sanitized version of the DbFit test that illustrates the pattern above.

Of course, as anyone who has built software knows, requirements are never “baked”. This is not the fault of the requirement gatherers, the end users, QA, or Dev. Just like you can bet on the sun rising every morning, you can rest assured that requirements will always change. The question is, how do you handle it? Waterfall dictates you need change control to control/prioritize/approve the changes. From what I know about Agile (I have only been looking into it for the last 9 months), you get around the changing requirements by embracing the fact that they change. A small, cross functional group work very closely together to build the features and release.

For Dev and QA, this approach can be a tad unsettling if the Waterfall approach was used when they “cut their teeth” earlier in their careers. To get the most out of QA in an Agile shop, they should be engaged tightly with Dev from Day 1. Damon lists some great ways for this to be accomplished. Examples include having QA check the quality and coverage of the unit/integration tests. This alone would have gone a long way to helping our product achieve high levels of quality earlier. In addition, QA can work to build automated tests as well to test specific areas.

In the tail end of the project I mentioned above, we started to adopt some of these ideas. Two developers and a QA person teamed up to tackle a complex, brittle area of the system. They looked to find issues that fell into the categories of “it blows up when you do this”, “it works but could work better this way”, “this is missing”, etc. Close, daily contact on this small team led to rapid improvement in the quality of that area of the system and it engaged QA in a positive manner. It came close to fulfilling the idea of involving QA from the start.

As we move into a lessons learned phase for this project that goes live tomorrow, this relationship between QA and Dev will most likely help drive how we approach feature development in the future.