1. Every tool has its own plus and minus, and much of it depends on several factors foremost of which is the AUT. In this case, we will be testing a new REST apps that does not have a GUI that interacts with 2 enterprise applications whose inner architecture no one really knows ;-( The choice for the tool for the Acceptance Test was easier compared to the tool we will be using for Regression and Functional testing. I am leaning towards C#, SOAPUI but that is another story

2. Our customers are actually within the technical teams too, as our AUT is sandwiched between the 2 enterprise apps.

3. I want a toolset that would save me time in writing code so the StoryQ’s Converter comes in handy. My humble expertise is exploratory and usability testing so my time is really well spent outside of the automation area.

I will check on StoryTeller, and give my feedback on it too.

Thanks once again, and would love to hear more from you guys!

Tess Rupprecht

Glad to hear that you have come across StoryQ. When we wrote StoryQ it was to tackle similar issues. But the main issue is how do we report out of the code base to the business. This is often the reverse that you find in theory – eg story-test driven development creates stories and acceptance up front. Because I work for a company that does project work on contract and in partnerships that daily link between the customer role and delivery team isn’t as close. My problem had been that I can write a lot of acceptance criteria in the form of stories but that it was often difficult to always do this with the customer role and in fact often the person doing the customer role needed to sit down with them independently to think about all the scenarios. Add to that we needed to allow the acceptance tests to evolve and then be reviewed. In this case, I need to generate reports of working tests that we readable outside the code base. We were working in dotnet and hence the creation of storyq.

So my point here is that each of the toolsets you mentioned have their strength and should be used based on your interactions with people in the team and skillsets and actually, the size of the project. Fitnesse is great if the business/testers generate the acceptance and want to update the criteria – otherwise it seems a bit heavy if it is only developers who are reviewing the acceptance criteria. In contrast, the other tools tend to drive towards a developer focus because we review them in code or on the build server. (ps – I would go an have a look at StoryTeller by Jeremy Miller – he’s got his own hybrid)

Personally, and even given what I have just said, I am less worried about the toolset because I can get any of these to work in my favour (with enough patience) because they all work to create an abstraction that talks to my SUT code; they all have a setup/teardown; they all have the notion of a suite of tests.

I am finding Mike Cohn’s Test Automation Pyramid a good way to help explain the test/code strategy.

Cheers,

Tess Rupprech

Found your blog because you mentioned StoryQ

I really enjoyed reading your posts, i didn’t yet have any tester’s blogs on my RSS feeds. All of this resonates with my attempts as a developer to make agile work.

I am particularly looking forward to your post on gaining management acceptance

If you do find that there’s anything about storyQ you don’t like, please head over to our discussion boards (http://storyq.codeplex.com/Thread/List.aspx), we are always looking for feedback.

Regards – Rob