Time to start thinking, stupid......

Sometimes it feels like the world doesn't want to think any more. We make decisions for the sake of expediency, gaining satisfaction that there is a tick in the box, sometimes knowing that wrong tick has been placed in the wrong box. The person still asking 'Why' or saying 'Is there another way' in the corner at the end of a long meeting is seen as an inconvenience, blocking progress at best and plain annoying in the worst case.

As a tester, I often find myself at the heart of this deficit of thinking. Teams built with the wrong competencies for the job at hand, products sabotaged by blind fire decision making, compromises made to fit restraints which are beyond aspirational. So what can I, a lowly tester, do about this? I can change my behaviour, mind-set and make sure testing has a voice, that’s what I can do.

First, acknowledge and embrace your own stupidity. Ever felt like asking a stupid question but then stopped yourself and walked out of the room with no idea what happened? Stop doing that. Your confusion is most likely shared and you've just missed an opportunity to expose it. By not asking, you are even stupider when you leave the room than when you entered.

Second, stop being so accepting. Ever with your project team while decisions are made which made you think 'Really? We are going to do that?' Stayed quiet did you? Thought so. Stop doing that. Do not always retreat into your 'I'm only here as an information giver' persona. Testing is valuable, give it the respect it deserves and every so often apply a little thought to what testing gives to the functionality.

Third, talk to your tests.  Serious. Ask them why they need to exist. Ask them if they intend to be around for a while or will expire as soon as they have been executed. Ask them if they prove one thing, lots of things, or nothing at all. Ask who else cares about them. Look at them as group and ask if they are a balanced set of tests, or are they skewed in favour of a particular aspect of the functionality.

Fourth, remember the vision. It’s fairly common practice for projects/products to define a vision. This may put usability or aesthetics to the forefront, perhaps performance and scalability. It’s also pretty common to lose sight of this vision. So if usability is key then ask how does this functionality meet the vision and how does my testing approach show this goal has been met. To put it more succinctly, make sure you are testing the right product before testing it right.

Now that you are a stupid, annoying product visionary who speaks to test artifacts, you are ready to start being part of the solution rather than the problem. Like most habits, little and often is key. Learn short, sharp techniques for teasing out the real issue. 5 Why's for beginners, 6 Thinking Hats, the mighty 'Huh? Really? So?', why not have some fun. Its 5 minutes of your life, spent with your brain engaged. What’s the worst that could happen?

There are many testers out there, but not very many thinking testers. I've seen the phrase 'zombie tester' used recently, so unless you want to be a shambling, undead mess of a tester, it's time to get your thinking cap on. Eating the brains of others will not make you smarter.

Lets compromise....

Compromise. That word doesn't sit well with me, its not a natural state of mind. The further I progress in my testing career I find it around every corner:

'Lets compromise on quality to hit the date.'
'Lets compromise on testing depth so we can increase our coverage.'
'Lets just do a smoke test, it'll be fine.'

I often think that compromising in testing is seen as the grown up thing to do:

'Its your product buddy, I'm just an information giver. Go or no go, no skin off my nose. I'm just a tester.'

Its also a little naive in a way. The customer says:

'Yes lets cut down the testing so I have my stuff when I want it.'

When they actually mean:

'Yes lets cut down the testing so I have my stuff when I want it. Oh and make sure it works perfectly too.'

Thing is, I'm not just a tester. I'm a fierce (some would argue too fierce) believer in testing as craft, who leverages business facing, technical, exploratory, automation and performance focused testing to deliver the best service I know how. Whether that is critically assessing a user story (I'm usually the last person asking why) or writing a set of automated acceptance tests which continually add value the word 'compromise' is not at the forefront of my thinking.

Perhaps it's time for me to grow up, but for now, I'll keep fighting what I believe is the good fight.

The testing marathon...

The world may or may not know that I'll be running the London Marathon next week. During my long hours pounding the streets to be ready for the marathon itself I've reflected on a few ways my training has reflected my testing journey:

Push yourself a little bit further over time - you can only prepare your body for a marathon in one way, and that's very gradually. I believe this can be applied to your mind too, specifically how you develop yourself as a tester. Acknowledge that you will not reinvent yourself overnight, pick a development path and review regularly to check progress and verify you are on the right path.

Find a sustainable pace - a marathon is made more difficult if executed at an ever changing pace. The same can be said for testing. If your testing does not flow, your execution of testing as a craft will not be as effective as it could be. Testing in small chunks, incrementally and continuously is the aim.

Do hard yards - there have been a few times I haven't wanted to train at all. This winter has been awful, a couple of feet of snow drains your enthusiasm. We've all had projects which feel like ten foot high snowdrifts, remember the power of seeing how things should NOT be done is as useful as seeing perfect execution. Use that experience to improve yourself and your craft. Share your frustrations and solutions.

Take time to reflect - When I started training, the furthest I'd run was a half marathon. Now a half marathon is a relatively light jog! Two years ago, even beginning to write code was beyond me. Now I can put together effective technical tests and automation. Often we can think we are never quite good enough, or the team hasn't come far enough down their path, or that new skill I'm learning is beyond me. A quick personal retrospective on a regular basis will work wonders.

Trust your training and step into the unknown - Finally, a marathon is quite a scary thing. It will be one of the hardest challenges of my life. I'm nervous. However, I'm trained and armed with skills and knowledge to help me. I treat my testing journey in a similar way. I have continuously evolving toolkit which helps me face testing challenges with confidence.

So, wish me luck for next week, any sponsorship gratefully accepted, for the fantastic WellChild who do such great work for children in the United Kingdom:

http://www.justgiving.com/wellchild-LM2013

Flat file creator in Groovy for SoapUI

Quick code share for creating flat files in SoapUI via Groovy.

I used this to create a linearly increasing file size for an extract, transform and load tool to do some basic load testing.

SoapUI is great for this kind of thing, nice and simple IDE, with the ability to extend to use pretty much any jar you can think of. Enjoy!
 

/*This script will create a new flat file with number of records taken from a test case level property:
* Steps:
* 1.Create the basics for use throughout the file. Primarily dates and account numbers 
* 2.Create the relevant filename
* 3.Create the header
* 4.Create the body of records with amended account numbers
* 5.Add a footer
* 6.Output the lot to a separate file, its size configurable by test case property. 
*/

import java.util.*;
import org.apache.commons.lang.RandomStringUtils;

//Create the static bits to be used
def number_Records = context.expand( '${#testcase#Number_Records}' ).toInteger();
def outputDir = context.expand( '${#testcase#Output Dir}' ).toString();

//What we need to be build the filename
def date = new Date();
String month = date.format('yyyyMM');
String today = date.format('yyyyMMdd');
String headerDate = date.format('ddMMyyyy');
String randomString = (RandomStringUtils.random(7, true, false));

//Create the filename
String filename = month+randomString+today+".src"

//Declare a new file object
File file = new File(outputDir+filename);

//Create the header
String fileHeader = headerDate
file.write(fileHeader);
file.append '\n'

//Build the body of the file
for (int i = 0; i < number_Records; i++){
String newAccountNumber = (RandomStringUtils.randomNumeric(15));
String lineToReproduce = newAccountNumber;
file.append(lineToReproduce);
file.append '\n';
}

//Create the footer
String fileFooter = ""
switch (number_Records.toString().size()){
case '3':
fileFooter += "9999999999999999999900000"+number_Records+" ";
break;
case '4':
fileFooter += "999999999999999999990000"+number_Records+" ";
break;
case '5':
fileFooter += "99999999999999999999000"+number_Records+" ";
break;
case '6':
fileFooter += "9999999999999999999900"+number_Records+" ";
break;
case '7':
fileFooter += "999999999999999999990"+number_Records+" ";
break;
case '8':
fileFooter += "99999999999999999999"+number_Records+" ";
break;
}

file.append(fileFooter);

log.info("File "+outputDir+filename+" created with "+number_Records+" record(s)")

Test cases? This is 2013 you know....

Test cases are getting a very bad press of late. There is a perception that they are a wasteful practice, built carefully and slowly in a dark corner away from all collaboration, sprung on unsuspecting programmers to expose the unanticipated obscure edges of their code.

I don't believe it has to be like that, and I haven't practiced building test cases in that fashion for a long time. I prefer:

Test Ideas - your team are delivering a piece of functionality. You have basic understanding of its aims, maybe a few acceptance criteria. Its time to brainstorm. Grab the people who you think are useful (and perhaps some who are not directly involved), have a time-boxed brainstorm. Thirty minutes should do it. An all round view is required, stay away from the detail. FIBLOTS is an excellent heuristic here. Lets say we've walked away with 40 ideas of areas to test.

Test Scenarios - Time has passed, the team has made discoveries, you've had your first bit of the new functionality. You've realised that of your 40 ideas, there might be 20 you actually really, really need, plus another 10 that you didn't think of in your ideas stage. Give them a bit of care and attention now, adding personas, descriptions, pre-conditions, post-conditions, however you wish to flesh them out. Not too much detail and no steps!

Test Cases - right, now we get down it. You have an idea. You have a resulting scenario. If there are any key tests (hint - attached to acceptance criteria), you can add further details, even a few steps. I personally use this to automate my acceptance tests, rather than creating a manual script, where I think the value of a test case begins to drop dramatically.

In addition, you can show your decisions about what to cover and when in a meaningful way. Always treat your test assets as something which can be iterated on, and bring your test cases out of the 'dark ages.'

Your tests tell the real story.......

Projects and products are increasing in complexity. That’s life at the moment, ask our many financial institutions. Change embracing methodologies, legacy systems interfacing with new development mean that most systems of documentation struggle to keep up, coupled with the belief that being ‘agile’ means that even basic documentation is frowned on.

We, as testing focussed individuals are perfectly placed to bridge that gap. An organic set of acceptance, exploratory and automated tests which flex with changing business needs and technical design modifications, document the flow of the project and patterns emerge for key decision points. Coverage areas, non-coverage areas, tests which prove legacy behaviour, new tests added, and old tests retired as functionality has changed all add context to the project or product story.

This is also a slight riposte to the ‘automate everything’ theory, clicking ‘go’ is not a facilitator for analysis or learning. Learning is gained from a stepped approach, I have fielded arguments that it’s a little heavy, but I think in terms of story telling a little effort goes a long way.

• Mind Map – for each item of work (user story for example), create a mind map, nice and simple. This is your one stop shop for recording business needs, test ideas, caveats, technical details and anything else you wish to record. This tells the project story at a high level without too much detail and acts as a prompt for conversation. Print off and make it visible every so often.
• Test Management Tool – this usually raises a few eyebrows, given the current mood in a lot of organisations. I see tests being created all over the place in text files, spreadsheets and a plethora of other tools. If your organisation has a Test Management Tool, don’t fight it and use it to store acceptance tests. You get free version control and safer storage in the main. Creating your business driven, scenario based tests and storing means you have one place to begin collaborating from.
• Automation – You might have many automated tools, for creating data, setting environments to the right state and tests themselves. Regardless of tool choices, your tests should tell the story from a business facing point of view. Better to say ‘Create an Online Customer with a Balance of £50’ rather than the ‘Insert Cust into Offshore DB’. And comment your code; the amount of non commented test automation code I see is frightening.

 So, tell the story of your project or product and use the above thoughts to radiate that information. The team will thank you for it as future decision making is much better when history and context are simple to find.

File asserts and manipulations with SoapUI and Groovy

Very quick one, re adventures with SoapUI and Groovy.

Have recently been building tests which need to run batch jobs and then assert against their output within the file structure. Below is a simplified implementation of what I've been up to:

//Build the file name to look for


def date = new Date();
fileName = "OutputFile" + date.format('ddMMyyyyHHmmmss') + ".csv";
folderName = testRunner.testCase.testSuite.project.getPropertyValue("sftpPath");
filePath = folderName + fileName; 
log.info(filePath);

//Read in the data
def inputFile = new File (folderName + fileName);

//Create a new list for asserting against
assertList = [];

//Populate with Contents of Text File
addContentstoList = {assertList.add(it)};
inputFile.eachLine(addContentstoList);
log.info(assertList);

//Assert the number of records in the array, plus for the existence of a specific object
assert assertList.size() == 5;
assertCustID = assertList.any {3};
assert assertCustID;

Found this simple and effective. As an added bonus, this creates and deletes directories and builds CSV files from lists:


//Create New Directories
def inputDir = new File("C:/temp/in").mkdir()
def outputDir = new File("C:/temp/out").mkdir()

//Create an Array for Inputs
def inputFile = [
    [id:'1',description:'One'],
    [id:'2',description:'Two'],
    [id:'3',description:'Three'],
]

//Create a csv file
def BuildFile = new File("C:/temp/in/team.csv")
inputFile.each {
    def row = [it.id, it.description]
    BuildFile.append row.join(',')
    BuildFile.append '\n'
}

//Copy to output folder
def sourceFile = new File ("C:/temp/in/team.csv")
def destinationFile = new File ("C:/temp/out/team1.csv")

sourceFile.withInputStream { is -> 
  destinationFile << is 
}

//Finally delete to tidy up
def delInput = new File("C:/temp/in").deleteDir()
def delOutput = new File("C:/temp/out").deleteDir()