Web UI Testing Part 1: Front-door and back-door testing

Llewellyn Falco and I had a conversation many years ago (June 2010?) about the best way to test Web UI.  During that conversation we referred to the two classifications/mechanisms of web testing as front-door and back-door web testing.  That is how I still think of the two types many years later, although I recognize that not many people in the industry use those terms. 

In front-door web testing you are using the browser to drive the test, which more closely tests what the user sees, but offers limited ability to manipulate or control the data and other dependencies.  The other drawback of this type of testing is if the test modifies data, there needs to be some way to get back to a clean slate after the test finishes.

In back-door web testing you call the controller or presenter directly (assumes you are using MVC pattern, or have done a good job separating the Greedy view into a presenter).  The advantage of this pattern is that you can control the dependencies and data context under which the test runs more easily by using in memory repositories, mocks, and things of that nature.  The main issue with this type of testing is that these controller methods return some sort of model and view name, making it difficult to test what the user sees.  Because of this, you can have complete test coverage over the controllers but still have bugs in the view.

In January of 2011 ASP.NET MVC 3 was released which allowed different view engines to be used to render the views into HTML that would be sent back to the client.  Because the View engines were easily pluggable and the Razor Engine was packaged separately (https://www.nuget.org/packages/RazorEngine/) this allowed back door testing to call the engine to produce HTML.  This allowed back-door web testing to get closer to what the user was seeing and eventually resulted in Llewellyn augmenting Approval tests with a mechanism for approving HTML.

http://blog.approvaltests.com/2012/05/testing-views-in-aspmvc.html

However, there are still problems with this approach.  Two of the biggest problems are

1. changes to the layout template break all tests
2. inability to test JavaScript manipulations of the page.

Project Management is a Prioritized List

I just finished forming a new company called Crafting Bytes with Brad Cunningham and Ike Ellis.  We wanted to start taking on bigger projects using the techniques that have made us so successful as consultants.  Over time we have noticed that we do much better with the projects when we take control of the project management as well as the development rather than simply augmenting the development staff.  What is different about our project management style than the project management style of other companies that we work with?

One major difference is that we don't use scrum.   In a sprint developers spend a lot of time estimating the work.  Estimating can be important when the estimate is used to determine whether or not the work should take place at all.  However, in most cases companies were using the estimate to inform management when the product was supposed to ship, so that they could relay that information to the customer.  It would be a better idea to relay the information to the customer *after* the work has been completed.  It is much more accurate that way.  The other reason managers were requiring estimates was to figure out how much work should be completed this sprint.  So in other words managers were requiring estimates for the sole purpose of the project management methodology they were using.

The thing is estimates take a lot of time, and they are rarely accurate.  Our thought was let's forget scrum and just go with a simple Kanban board (from the Lean school of thinking).  By doing this we can save ourselves countless hours of trying to figure out how much time things are going to take, and spend more time simply doing them.

OK, so that saves a couple days every sprint, but then what is the purpose of having a project manager at all?  I admit that the project managers of many companies are totally unnecessary.  You know the type, they spend most of their time polling individual people "are you done yet".  They could easily be replaced by voice recognition software that recognizes the word "yes".  This isn't really project management, it is instead project reaction.  Project *management* would be managing the work of the project, prior to it starting.  In short a project managers job is to figure out which work is the most important and which work is so unimportant it doesn't need to be done at all.  Great project managers remove all unnecessary tasks, that is all tasks that don't lead to working software, and prioritize which features are the most important for the business and the user.  In short they control the prioritized list.

Thinking of project management as simply controlling the list of things that need to get done and prioritizing the most important simplifies the job of the project manager and helps the team achieve minimum "time to value" - a vastly underrated metric.