The ongoing search for simple solutions.

Showing posts with label agile-testing. Show all posts
Showing posts with label agile-testing. Show all posts

Sunday, 6 September 2009

TIP - Starting And Stopping Selenium Server Automatically

Found a nice article which explains how to start/stop your selenium server automatically using FixtureSetUp and FixtureTearDown of AssemblyFixture.

http://igorbrejc.net/development/cruisecontrolnet/gallio-starting-and-stopping-selenium-server-automatically-during-testing-using-assemblyfixture

Monday, 24 August 2009

Some notes on Slim (getting started)

To use Slim instead of Fit, you need to define Slim as the test system
  • !define TEST_SYSTEM {slim}
Symbols
  • $name= sets the symbol
  • $name uses the symbol
  • $name= also in script tables as first cell$
Decision Tables (aka Slim Column fixture)
  • Check/Check not – value test pass/fail
  • Ensure/Reject - bool test pass/fail
  • Note - comment
  • Show – display result
  • Start – sets up a different system under test
  • Optional constructor arguments after class name

Thursday, 30 July 2009

This feels scarily familiar...


I would be lying if I said that my department do things any better than this...

Tuesday, 16 June 2009

Debugging FitNesse Fixtures within Visual Studio

I came across a great article from Jim Holmes on his blog "Frazzleddad".
In his post, he explains how to debug FitNesse fixtures within VisualStudio - which is great, because if a FitNesse test fails for unknown reasons, it can be painful to get to the root cause of the problem - and I currently write unit tests to test the fixture code independently of the tables. By introducing Fixture debugging, I can run my FitNesse tests directly from VisualStudio, and use breakpoints to find out what is happening inside the fixture code.

Setting this up is very simple. Folow these steps:-

  1. Open the Project Property page for the fixture.
  2. Select the Debug tab.
  3. Select the "Start external program" radio button, and enter the path to TestRunner.exe in it's field.
  4. In the "command line argumants" field, enter the host, port and page which relate to your FitNesse test (e.g. localhost 8081 EmailSystemTests.TestSendMail)
  5. Set the fixture project as the startup project.
  6. Add breakpoints and click Run(F5)
* First time I tried, VisualStudio complained about the TestRunner.exe.config file. I just renamed the file, and everything worked as expected.

Here is a screenshot of the VisualStudio Project Properties dialog (stolen from frazzleddad)


Original post - http://frazzleddad.blogspot.com/2008/01/debugging-fitnesse-tests.html

Monday, 1 June 2009

Agile Testing Quadrants

The "Agile Testing Quadrants" diagram is a great way to understand which testing techniques can be used at different stages of software's development - and also helps to understand the benefit's which can be derived from each testing technique.


The original idea for the Agile Testing Quadrant was taken from Brian Marrick (www.exampler.com), although I took this version from Janet gregory's presentation at Agile Vancouver (http://agilevancouver.ca/sites/agilevancouver/files/speakerslides/Vancouver-Quadrants.pdf).



Monday, 27 April 2009

Testers: The Hidden Resource by Lisa Crispin and Janet Gregory on Informit.com

I came across this great article by Lisa Crispin and Janet Gregory on Informit.com. I think it sums up a lot of what they wrote about in their book "Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley Signature)"

Lisa Crispin and Janet Gregory point out the hidden asset on many development teams: the testers. By learning from agile teams, software teams using any type of development methodology can improve their use of testers and testing.

What do the words tester or QA engineer bring to mind? They're those people who think of ways to break the software, right? Isn't QA the team that comes in after the coding is done, to tell the programmers what they did wrong? It doesn't take all that much skill to be a tester; anyone could pound on a keyboard and check whether the software works, right?

Wrong. Think again.

In traditional projects, requirements are defined up front, usually by business analysts or product managers. Testers have learned to analyze each requirement—looking for completeness, ambiguity, correctness, and much more—so that they can write detailed test cases. However, development teams using this type of phased and gated methodology often tie the testers' hands, giving them no way to get requirements changed if they find contradictions or unclear specifications. By contrast, testers on agile teams get the opportunity to accommodate and embrace change. By observing how testers contribute value on agile projects, we can see how agile testing principles and practices may be applied, regardless of the development methodology being used. The key is making testers full partners with developers, giving them access to business experts, and involving them from the very beginning of each project.

Read the full article on InformIT

Monday, 6 April 2009

How to expect a non-matching result in FitNesse.Net

Using FitNesse.Net, it is simple to create a test which specifies what the expected result of a test should not be. For example:-

One plus One should not equal Three.

To do this, you simply put fail[{result}] in the result cell. For example:-

Other Blogs