Daily Archives: 15/05/2012

Pen Game: A Mean to Fathom Software Testing

A handful of testers find the Pen Test an easier way to explain software testing. In a Pen Test, the presenter will hold up a pen in his hand and repeat some questions. With only two possible answers, he would like to know what makes the answer Yes and what makes the answer No.

Michael Larsen, in his blog brought out the relationship between the Pen Game and Software Testing. While testing, the testers are being presented with the program (the pen). The behavior of the testing is displayed (words and actions to display the pen) and based on the behavior, the testers can determine the state of the program.

The next step for a tester is to create a hypothesis and test it. If the result accepts the hypothesis, then we can still continue testing, however, if the results disregard the hypothesis, then we have to abandon the model or the assumptions.

The answer can be determined based on the behavior of the application. We can bring out different clues for the answer. The clues are being tried and if it doesn’t work we can replace it with another clue. Thus, coming closer to the answer.

Sometimes when we have no valid answers at our disposal, we tend to make guesses. However, if we make too many right guesses, there can be a possibility that we might create an inaccurate mental model. For example, if we are able to make four correct answers, we might think that the next answer is a yes because we have created a mental model that all answers are Yes.

However, if a game becomes too popular, it loses its potency as we tend to focus more on the answer. Therefore, a tester would need to look out for other games that can be applied for software testing.

Source:

http://qa.siliconindia.com/news/Pen-Game-A-Mean-to-Fathom-Software-Testing-nid-115076.html

Did you like this? Share it:

How I got to Rapid Software Testing…

The response was great.  Some good suggestions and many offers of assistance!  A few weeks later it was crunch time.  The boss asked for an informal business case (email).  So I emailed everyone that replied to the tweet, and also some extras.  ;0)  Once again, blown away by the help I received.  Great dot points for me to add to my business case.

I thought I would share the I sent to the boss.  May be interesting, may also help others in the same situation.  Obviously I have removed all private information.

Hi XXX,

As promised here are some points as to why I would like to attend the course:

The art of Rapid Testing is critical in most (if not all) organisations.  The need to test something quickly, effectively, and with little information is more and more common (especially considering continuous integration, Agile, etc.).

The art of questioning is key in testing, and it’s also key in the role of a consultant.  To be able to critically think about the client’s problem, and ask important questions (that other’s haven’t) shows them you know your stuff.  The course focuses a lot on questioning and knowing when you’ve asked enough to be able to act.

The sheer number of positive experiences that are spread all over the net.  I haven’t read a bad report about the course.

It’s only available once a year in Australia, so if I miss this one I’ll need to wait for another year.

James Bach is a ‘legend’ in testing.  To be taught by him would be amazing.

There is an industry shift happening at the moment.  A lot of organisations are moving away from the certifications provided by ISTQB, etc. and focussing on context-driven testing as a more valuable skill/trait.  RST is the course of choice in this new world, so the more XXX staff get across it the better (in my strategic opinion).

I’ll get to meet (and exchange business cards) with like-minded testing folk.  Could prove very handy.

I’ll get access to the following private group on the STC – http://www.softwaretestingclub.com/group/rapid-software-testing-graduates

Selfish reason – I love this stuff and have wanted to attend the course for years!

Obvious reason – It’ll make me a better tester!

Also, here are some points on what I could do after attending the course:

Publish a course review post on the XXX Blog (I’m confident this would provide solid traffic).

Make the course material available to other staff members as required and obviously within the bounds of copyright (most are available anyway).

I understand that the course is made up of many exercises and challenges – I could share these (copyright approved of course).

If I feel I’m proficient I could deliver some aspects of the material to other staff members (once again, copyright approved).

Open to others if you have suggestions.  :0)

Read More:

http://martialtester.wordpress.com/2012/05/10/how-i-got-to-rapid-software-testing/

Did you like this? Share it:

Continuous Integration and Testing :Unit and Integration Tests With Maven and JUnit Categories

Introduction

This example shows how to split unit and integration tests using Maven and JUnit categories.
It is especially useful for existing test suites and can be implemented in minutes.

Why use this?

My previous post showed how we to use a maven profile to split unit and integration tests.
http://johndobie.blogspot.co.uk/2011/06/seperating-maven-unit-integration-tests.html
This has been a very well read post and I like how it uses seperate directories. However this example show a much simpler technique that can easily be applied to legacy test suites.
It offers most of the benefits of the original, and sits more comfortably in the Maven world.

Code

The code for the example is here. 

svn co https://designbycontract.googlecode.com/svn/trunk/examples/maven/categor...
mvn clean install

JUnit Categories

As of JUnit 4.8 you can define your own categories for tests. This enables you to label and group tests.

This example shows how easy it is to separate unit and integration test using the @Catgegory annotation.

http://kentbeck.github.com/junit/javadoc/latest/org/junit/experimental/categories/Categories.html

Define the Marker Interface

The first step in grouping a test using categories is to create a marker interface.

This interface will be used to mark all of the tests that you want to be run as integration tests. 

public interface IntegrationTest {}

Mark your test classes

Add the category annotation to the top of your test class. It takes the name of your new interface.

import org.junit.experimental.categories.Category;
@Category(IntegrationTest.class)
public class ExampleIntegrationTest{

 @Test
 public void longRunningServiceTest() throws Exception {
     
 }
}

Categories can be used to mark classes or methods. Really in my opinion you should only mark a class.

If you have both unit and integration tests in a single class then split it.

Configure Maven Unit Tests

The beauty of this solution is that nothing really changes for the unit test side of things.

We simply add some configuration to the maven surefire plugin to make it to ignore any integration tests.


org.apache.maven.plugins
maven-surefire-plugin
2.11

 
  org.apache.maven.surefire
  surefire-junit47
  2.12
 


 
  **/*.class
 
 com.test.annotation.type.IntegrationTest


There are 2 very important parts. The first is to configure surefire to exclude all of the integrations tests.

com.test.annotation.type.IntegrationTest

Surefire will run all of your tests, except those marked as an integration test.

The other important part is to make sure the surefire plugin uses the correct JUnit provider. The JUnit47 provider is needed to correctly detect the categories.


 
  org.apache.maven.surefire
  surefire-junit47
  2.12

Running the unit tests

To make sure this works correctly we can run the unit tests

mvn clean test

You can see from the output below that the unit test is run, but not the integration test.

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running com.test.EmptyUnitTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

Configure Maven Integration Tests

Again the configuration for this is very simple.

We use the standard failsafe plugin and configure it to only run the integration tests.


 maven-failsafe-plugin
 2.12
 
  
   org.apache.maven.surefire
   surefire-junit47
   2.12
  
 
 
  com.test.annotation.type.IntegrationTest
 
 
  
   
    integration-test
   
   
    
     **/*.class

The configuration uses a standard execution goal to run the failsafe plugin during the integration-test phase of the build.

The following configuration ensures only the integration tests are run.

com.test.annotation.type.IntegrationTest

And again the JUnit provider must be correctly configured.


 
  org.apache.maven.surefire
  surefire-junit47
  2.12

That’s it!

Running the integration tests

We can now run the whole build.

mvn clean install

This time as well as the unit test running, the integration tests are run during the integration-test phase.

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running com.test.AnotherEmptyIntegrationTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec

Running com.test.EmptyIntegrationTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec

Results :
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
source:
http://www.javaworld.com/community/?q=node/8374
Did you like this? Share it: