Sometimes you come across a blogger who’s so thoroughly covered a topic that you can just drill down through years of his writing and keep finding awesome stuff. Alister Scott‘s blog “watirmellon” is such a source. Here’s some highlights…

Make sure to read through his Automated Testing slide deck!

http://watirmelon.com/2012/01/31/introducing-the-software-testing-ice-cream-cone/

“I propose we rename QA to mean Quality Advocate … Whilst their responsibilities include testing, they aren’t limited to just that. They work closely with other team members to build quality in, whether that be though clear, consistent acceptance criteria, ensuring adequate automated test coverage at the unit/integration level, asking for dev box walkthrough, or encouraging collaboration/discussion about doing better testing within the team.“

http://watirmelon.com/2013/02/25/are-software-testers-the-gatekeepers-or-guardians-of-quality/

A:  User stories aren’t ‘done’ until you’ve tested each of them, which means you get to provide information to the Product Owner about each of them. You define the quality bar and you work closely with your team and product owner to strive for it.

B: Whilst you think you may define the quality of the system, it’s actually the development team as a whole that does that. Everyone is under pressure to deliver and if you act like an unreasonable gatekeeper of quality, you’ll quickly gain enemies or have people simply go around or above you.

http://watirmelon.com/2013/05/08/should-you-use-the-givenwhenthen-format-to-specify-automated-acceptance-tests/

A: Given/When/Then format provides a high level domain specific language to specify the intention of automated acceptance tests (very easily transferred from a user story) separate to the implementation of your automated acceptance tests. This separation allows changing the test from testing the UI to testing an API without changing the intention of the test.

B:  One of the selling points of writing Given/When/Then tests is that they are readable by business. But in reality, business never read your Given/When/Then specifications, so it makes no sense to invest in them.

“Quick wins give you breathing space to develop a good solution.”

http://watirmelon.com/2009/10/01/not-ruining-your-test-automation-strategy/

Alister: Automated testing through non-GUI means is smart, but sometimes you have no choice. I have made automated testing through the GUI reliable and maintainable, but it required skill on my part. Automated GUI tests can be used to deliberately show discrepancies in the GUI, often highlighting unintended GUI changes. It’s generally not a good idea to completely write something off because you may have seen it done poorly yourself. It’s like saying Agile is wrong because you worked somewhere where Agile was done poorly.

Bob:  My beef is not with GUI testing tools per se. Rather it is with teams that test their entire app through the GUI. You are correct in that sometimes you have no choice. In such cases very careful test construction can mitigate the fragility problem. But no amount of care can come close to competing with an approach that runs the majority of tests through the API.

QA? Project Management? …or just Paradevs?

http://watirmelon.com/2013/01/31/so-what-exactly-is-a-paradev/

A couple of years ago now, just after I started at ThoughtWorks, I read a tweet from a fellow ThoughtWorks developer here in Brisbane along the lines of “the paradevs at work enjoyed my lunchtime session on networking”. My ears pricked: “what’s a paradev?” I asked. “It’s someone who helps the developers develop” she replied. “Oh” I thought.

http://watirmelon.com/2013/05/07/do-you-even-need-a-software-tester-on-your-agile-team/

A: If you don’t particularly care about quality, have good production monitoring, and can get internal engineers and major partners to do your QA then you may get away with not having a tester on your agile team.

B: Software testers provide a unique questioning perspective which is critical to finding problems before go-live. Even with solid automated testing in place: nothing can replicate the human eye and human judgement.

http://watirmelon.com/2013/04/14/which-is-better-manual-or-automated-testing/

A:  Even when automating a test scenario, you have to manually test it at least once anyway to automate it, so automated testing can’t be done without manual testing.

B: Because the automated tests are explicit, they also execute consistently as they don’t get tired and/or lazy like us humans.  Automated tests also allow you to test things that aren’t manually possible, for example, ‘what if I processed ten transactions simultaneously’.

http://watirmelon.com/2013/04/14/test-in-production/

The key to testing changes as soon as they hit production is to have real time, continuous real user experience monitoring.  More comprehensive automated acceptance tests can be written in a non-destructive style that means they can be run in production. This means that these can be run immediately following a fresh production deployment, and as feedback about the tests is received, any issues can be remedied immediately into production and tested again.

http://watirmelon.com/2013/04/13/choosing-a-language-for-your-automated-acceptance-tests/

A: Automated acceptance tests shouldn’t be developed in isolation, so having these written in the same language as your application (usually C# or Java) will ensure that the programmers are fully engaged and will maximize the liklihood of having these tests maintained alongside your application code.

B: If your software testers are responsible for writing and maintaining your automated acceptance tests then it makes sense to allow the testers to write in dynamic scripting languages which are popular with testers as they are lightweight to install and easy to learn, have no licensing costs allowing an unlimited number of build agents to run these tests as part of continuous integration. As testers develop their skills in these languages they can quickly create throwaway scripts to perform repetitive setup tasks required for their story or exploratory testing: such as creating multiple records or rebuilding a database.

http://watirmelon.com/2013/04/13/who-should-write-your-automated-acceptance-tests/

A: The benefits of having the programmers in your team writing and maintaining these tests is that they will be maintained and executed as soon as any change occurs, so they’ll be kept more up to date and less likely to go stale.

B: Software testers are particularly good at building automated acceptance tests that cover an end-to-end process in the system; often called user journeys. This is because they have a good understanding of the journey whereas a programmer may only understand the logic behind a particular screen. Testers should be involved in writing this style of  acceptance tests so they are representative of real usage.

http://watirmelon.com/2013/03/10/is-test-management-wrong/

Now, each agile team is responsible for its own quality, the tester advocates quality as accurate acceptance criteria, unit testing, automated acceptance testing, story testing and exploratory testing. These activities aren’t managed in a test management tool, but against each user story in a lightweight story management tool (such as Trello or Mingle). The tester is responsible for managing his/her own testing. Step by Step test cases (such as those in Quality Center) are no longer needed as each user story has acceptance criteria, and each team writes automated acceptance tests written for functionality they develop which acts as both automated regression tests and living documentation.

http://watirmelon.com/2013/05/20/do-you-need-an-automated-acceptance-testing-framework/

A: If you’re starting off with automated acceptance testing and you don’t have some kind of framework, eg, page object models, in place then you can quickly develop a mess.

B: Over-engineered automated acceptance test frameworks are harmful for a team as they dictate certain ways of doing things which means the team can be less efficient in developing what they need to deliver.

http://pragprog.com/book/achbd/the-rspec-book

Caution! You’ve fallen for a trap. You’ve picked up this book thinking it was about RSpec. Fortunately, you decided to read the foreword. Good! That gives me the opportunity to tell you about the mistake you just made and possibly save you from an unexpected fate. -Uncle Bob

http://watirmelon.com/2011/05/31/an-automated-testing-journey/

Back in the day, Phil Haack wrote up a good guide for unit testing the routes created in ASP.NET MVC. I just set up these tests in a new MVC 4 project with JustMock as my mocking framework, so I wanted to put up my small modifications of his code to work there.

First we have a few helper methods that mock up an HttpContextBase and allow the routes to be rendered into RouteData.

[code language=”csharp”]
public static void AssertRoute(RouteCollection routes, string url,
Dictionary<string, string> expectations)
{
var httpContextMock = Mock.Create<HttpContextBase>();
Mock.Arrange(() => httpContextMock.Request.AppRelativeCurrentExecutionFilePath)
.Returns(url);

RouteData routeData = routes.GetRouteData(httpContextMock);
Assert.IsNotNull(routeData, "Should have found the route");

foreach (string property in expectations.Keys)
{
Assert.IsTrue(string.Equals(expectations[property],
routeData.Values[property].ToString(),
StringComparison.OrdinalIgnoreCase)
, string.Format("Expected ‘{0}’, not ‘{1}’ for ‘{2}’.",
expectations[property], routeData.Values[property].ToString(), property));
}
}

public static void AssertIgnoreRoute(RouteCollection routes, string url)
{
var httpContextMock = Mock.Create<HttpContextBase>();
Mock.Arrange(() => httpContextMock.Request.AppRelativeCurrentExecutionFilePath)
.Returns(url);

RouteData routeData = routes.GetRouteData(httpContextMock);
Assert.IsNotNull(routeData, "Should have found the route");
Assert.IsInstanceOf<StopRoutingHandler>(routeData.RouteHandler);
}
[/code]

Dests for the default route and the basic controller/action route.
[code language=”csharp”]
[Test]
public void RegisterRoutes_AddsDefaultRoute()
{
var collection = new RouteCollection();
RouteConfig.RegisterRoutes(collection);
var expectations = new Dictionary<string, string>();
expectations.Add("controller", "home");
expectations.Add("action", "index");
expectations.Add("id", "");
AssertRoute(collection, "~/", expectations);
}

[Test]
public void RegisterRoutes_AddsControllerActionIdRoute()
{
var collection = new RouteCollection();
RouteConfig.RegisterRoutes(collection);
var expectations = new Dictionary<string, string>();
expectations.Add("controller", "home");
expectations.Add("action", "index");
expectations.Add("id", "1");
AssertRoute(collection, "~/Home/Index/1", expectations);
}
[/code]

…and an easy test to make sure that axd handlers are not routed with the routing engine.
[code language=”csharp”]
[Test]
public void RegisterRoutes_IgnoresAxd()
{
var collection = new RouteCollection();
RouteConfig.RegisterRoutes(collection);
AssertIgnoreRoute(collection, "handler.axd/somestuffhere");
}
[/code]

You may not know that I have a couple of iPhone apps which I’ve submitted to the Apple store, and which have not been approved because of a lack of polish or focused value to the people who would buy them. It’s a pain for me, but in the end I have to be thankful that Apple takes an interest in the quality of what’s on the store.

I was just browsing the Windows 8 App Store and found two “Top Paid” apps, one called “Word++” and one called “Windows Media Player 9”, neither one from Microsoft, but each looking as close as they can to being an actual Microsoft app. I’m not impressed that Microsoft can’t keep that kind of fraud-ware out of their store.