Excel as a Test Management Tool

Because you're going to use it anyway...

Ruby-Selenium Webdriver

In under 10 Minutes

%w or %W? Secrets revealed!

Delimited Input discussed in depth.

Managing Knowledge Transfer Sessions

Read the article, grab the templates

Ask questions

If you don't ask, you won't learn. You won't teach either.

Thursday, 29 August 2013

All the Good Testers

When we get used to an application, because we’ve logged into it 100 times and ran our test cases 1000 times, we start to miss things. Things like regression defects or the fact that the behaviour we’ve accepted as normal may not be normal to others. We miss things because our testing perspective and habits become locked, invariable, familiar, efficient. Familiarity breads contempt.

“They run twice as many cases as anyone else in the team, they really know the system!”. 

Which to many, means they are a good tester.

Conversely, when we’re not used to an application we poke at it with great intent and focus, everything seems new and interesting, we test in variable ways, unhabituated to the testing regime that applies, we’re inefficient (slow), but very precise about what we do. We don’t understand why that data the user enters is in that format, why the user journey is like that when we’d expect it to be like this instead, where that message comes from or goes to, what it means when that status up there in the right corner flashes orange.

“Is this new tester any good? They’re asking a lot of questions, raising a lot of defects that are just getting rejected!” 

Which means they’re not a good tester.

But define good.

Good is not procedurally efficient in a way that sees planned testing executed by or within project timelines, with little or no issues raised. Though far too many people still need educating in this fact.

At either end of the scale there’s a place where testers are not ‘good’ at the job. They don’t find defects that are meaningful or they’ve stopped looking. They don’t … well nothing else actually, if we do nothing else in a given day we should test well and that’s means a high likelihood of finding defects. The oft repeated mantra of ‘shipping working software’ is why our profession exists. You don’t ship working software by just running tests, of course you also don’t do it by not finding defects.

So surely somewhere along the scale of these perspectives, there must be a happy medium that is where we need to reach and stay. A place where the Good Testers are.

There is. That happy medium sees us executing well-structured, well-thought out, strong test cases, finding meaningful defects, remaining interested and curious about the application or system we’re testing, questioning why and how things work as they do, critically evaluating the efficacy of the test pack we run, intuiting new ways to explore the system, testing in an aura of familiarity with the system, yet attuned to pick up those gut-feel tester smells that suggest something is not quite right. Month, after month, after month, after…

It obviously takes time, experience, and proactive engagement to reach a point where we represent what ‘good looks like’, to become a deep technical expert that isn’t floundering about but who also isn't falling asleep. But, we can adopt many of the behaviours as a standard, irrespective of our experience. Being actively interested in the world around us, critically thinking about what is presented to us, carefully analysing the way things are now, were and could be, reflecting on how we acquire and build knowledge, practising building mental models. 

When we stay in that mode of thinking and add in an evolving technical understanding of what we’re testing, enhanced by a growing professional experience, then we are where the Good Testers are.


Liked this post?

Where are all the good testers?

Tuesday, 27 August 2013

Tools & Tech - Mind Maps

Mind Mapping, brainstorming, spray diagrams... whatever name you use, the technique of displaying a large amount of interconnected information on an easily understandable diagram, is one to get a grips with.

The basic idea of Mind Maps is to write up and at the same time connect ideas, concepts and information. In doing so the information is made accessible and usable. For example, think of a car, now mentally break the car down into its main components, now think what individual pieces make those main components, repeat for the whole car. How would you present that information? A long list, bullet points? That’s a long set of lists and indented bullet points!

Take something we do every day in testing, decompose functionality of an application. We have the application itself, then its major functional areas, there may be sub-functions too and key behaviour that depends on the system state.

For example we have Website > Navigation, form, but also images and text, some of which is / is not visible/active when a user is logged in - it’s already hard to list just a few items, now try and relate test conditions;

·         Application
o   Form
§  Valid  / Invalid Data
·         When logged in or logged out
§   Error trapping
·         Pre and post submit
o   Navigation
§  Main items
·         Change on mouseover, onclick, postclick
§  Subitems
·         As per main items, but different colour

It already looks messy and hard to follow, you could number them and come up with a host of other ideas. It also doesn't lend itself to expansion and readability.


Mind Maps offer a simple way around this and done right can replace a surprising amount of documentation. Test Scripts or Cases might be expressed as a Mind Map, Exploratory test conditions and Test Diary might be combined on a Mind Map.

In the short video I show a few tools for Mind Mapping, all free and available for Windows or Mac.

Why not have a look and see how you can start using Mind Maps in your testing?



Tools & Tech - Mind Maps

Wednesday, 21 August 2013

Project ‘Coding Oledium’ – Part 4 and 5

I thought I’d bring both of these together, parts 4 and 5 of the adventured in scripting Oledium up with VBScript. The main focus of the next two videos is getting some input from the user and deciding how we’ll react to that, what functions will be called based on how we evaluate the input from the user.


In VBScript we have the items we’d expect to see in other scripting and coding languages, JavaScript, Ruby, etc. Just they’re obviously in VBScript style; an InputBox to get input from the user, Function to work through a series of commands and come out with a result and Case statements to evaluated an input and decide what to do based on it.

sPlayerAction = Inputbox(“What would you like to do?”)

In our game, we’ll often be asking the player ‘What do you want to do?’, so we’ll set up an InputBox to get that information. Asking them what they want to do of course means we’re defining what valid actions there are. On our Mind Map design we had actions such as; Attack, Flee, Rest, Search and so on. These will need to be Functions, so we’ll add them to the ad_method_lib.vbs file. For now we can declare them, but no implement them.

By declare them we mean just put in place holders, something that shows us it’s there and needs completing later, for example;

Function PlayerAttack()
                MsgBox “Not yet implemented”
End Function

In this way, we can call it and nothing nasty will happen, nothing useful either, but one step at a time. As a design principle it’s easier to build on a framework than try and write perfect and complete code first time!

The next main item to add is a Select statement. In my mind these are just regular Case statements as I’ve used them in other scripting languages and which always feel like If statements to me, but are somewhat different.  Here’s the basic template:

Select Case sPlayerAction
                Case “Attack”
                                Do some stuff
                Case “Flee”
                                Do some other stuff
End Select

With the above in place we have the basic framework ready to build out the functions and start seeing something interesting happen.


There is a key next step though. We need to add a way to loop over asking what the player wants to do. Right now you make one choice and the game ends. We need a global If type statement

If sPlayerHealth > 0 Then
                Keep asking them what they want to do
ElseIf sPlayerHealth =< 0 Then
               MsgBox "Oops.. you're a bit dead!"
End If

We’ll implement that in Part 6, then elaborate the functions a little so the fun can begin!



Tuesday, 20 August 2013

Software Testing - all around the City (Photos)

Walking home late one night...

Automatic... Software Testing

No Unauthorised... Software Testing

Department for... Software Testing 

This may take... Software Testing

Here when you need... Software Testing

This way to... Software Testing

Stop valve for... Software Testing

London Borough of... Software Testing
Want to help us... Software Test?

Protected by... Software Testing

A bottle of... Software Testing

Cappuccino, Latte... Software Testing

Emergency... Software Testing

No Ifs, no... Software Testing

We won't charge for... Software Testing

Stay on top of ... Software Testing

See more by... Software Testing

How to guide to... Software Testing

Grade A offices for... Software Testing

No flat... Software Testing

The best... Software Testing

This taxi welcomes... Software Testing

Clean toilet for... Software Test

Enjoy... Software Testing

Please close the door after... Software Testing

Liked this post?

Sunday, 18 August 2013

Project ‘Coding Oledium’ – Part 3

In previous posts I warned readers that I was learning on the fly, in this part you'll see evidence of that. As often happens when coding, especially when learning coding, there's a lot of little glitches on the way to getting the code right. Some of those glitches might be simply getting the structure wrong or maybe not knowing how the language in question is structured in the first place.

Other glitches might be the fact that tyoping errors creep in or that when calling remote files to use their contents, it's not the same as having the contents in the same file, though technically it should be right? Just to say it, all these glitches are good. Learning by mistakes is accepted as the winning way these days, so get on with making those mistakes. Fail often and early remember!

At this stage of the project we've got the full set of files to use agreed, they 7 files that have been settled on are:

  • ad_index.vbs
  • ad_class_lib.vbs
  • ad_method_lib.vbs
  • ad_background.vbs
  • ad_hero_generator.vbs
  • ad_help.vbs
  • ad_inventory.vbs

Here's what I think each should contain:

The main control file, with the flow of the game here. It will call all other files and allow us access to the Classes and Methods they contain. 

A library of all the Classes in the game. Some of these will be Hero, NPC, Mob, BackPack, etc. Anything that we want several instance of essentially the same thing and/or we want to have unique attributes.

Similar to the Class_lib, but for Subs and Functions. Maybe we could have them all together but I feel that will mix up what the files do and the design is meant to keep it easy to maintain.

This file will be a collection of strings or arrays full of text. Some will need a dynamic reference to the Hero name which will be part of the Hero generator.

This will likely be a collection of If statements, Subs and Functions to get the Hero generated. We'll have a bunch of attribute from the Hero_Class (see above) such as Strength and Dexterity. These will be created using some rules about min and max values plus a rnd number generator.

We need a way for the player to know what commands the game supports, these will be in a help file they can call at any time in the game. Like background.vbs, I'm seeing this as a bunch of large text in strings.

The world of Oledium will contain artifacts  weapons, armor  treasure, etc. and we need to know what they are, how many, what attributes they have. I'm not sure if this will be a bunch of arrays and text like background.vbs or classes. We'll see on implementation.

# First things first... calling other files

As the plan is to have similar stuff, such as functions, classes, text, hero generation, etc. in dedicated files for ease of maintenance, we need to think how to call other files. That will allow our game to idea work. I've written the code for this before, re-factored from various forums and sites, however I got a bit stuck at the end though.. mystery revealed in the next video (simple issue too!)


In part 4 I'll pin down the error and get the Proof of Concept file-linking working, we can then really get moving building out elements of the game!


Links for items mentioned in the video:

Functions, Subroutines, and How to Call Them From Other Scripts

File System Object

Open Text File

TextStream Object

Thursday, 15 August 2013

Project ‘Coding Oledium’ – Part 2

It’s (not) surprising how much study there is to get going on a coding project like this, especially when you’re learning on the fly! But, VBScript like Java is something I’ve ignored for too long given my distaste of all things ‘mainstream’. Which randomly reminds me, go and listen to Liam Frost if you like clever lyrics and regional accents in music… (not mainstream, geddit?)

Anyway back to the project. I decided the most important thing to do, than just wade in coding was to, oh yeh… wade in and try and randomly lay some code down. After finishing the design to a good-enough standard first, I thought to crack on and start thinking what the main control file will look like.

I see that as the way to keep the project simple, thinking about how I’ve done test automation with Ruby in the past. Have a simple, sequential script that calls in all the other stuff. All the functions, subs, methods, classes and whatever else there is to use.

As you’ll see I decided to use Scintilla text editor instead of some more heavyweight IDE. Visual Web Developer, Visual Studio, Expression Web and all the others I can’t think of are a bit too involved. That and not wanting to pay for anything, rules them out.

At the level I wanted, Notepad++ was an option and so was Notepad 2. But Notepad++ is based on the Scintilla editing component and so is Notepad 2, so poo to that, straight to source. In truth, straight back to one I used before and know how to use.


As you’ll see from the video, design complete, first codey bits down. Thinking about it now I’m going to build out the blank files and then set up the linking to other files next. Without the ability to call other files the game in this structure (with a single control file) just won’t work.


Wednesday, 14 August 2013

Don’t get too close to the team

Don’t get too close to the team. They are not your friends and you need to maintain a professional distance from them at all time. The issue is, if you get too close and they become your ‘mates’, well then you will have problems getting them to do what you want. Especially if what you want involves say, extra hours working, completing some task by a deadline or doing work they’d rather not be doing.

Now I agree, very few people in work are really your friends, I mean true, long term, trust with your life friends. Actually, in any given company over the length of your career, I bet you establish that kind of relationship 2, maybe 3 times tops. 99.9% are acquaintances, colleagues or just strangers.

However… the advice is wrong.

You absolutely SHOULD get close to your team. You certainly need to know ‘who’ they are, how they think, what they care about, their motivations and dislikes in the workplace, you should create an environment of open dialogue, trust and honesty. You CANNOT do this except by ‘getting close’ to your team.

Let’s be clear, there is a way to get close that sees you maintaining the meta-position, keeping your position and relationship clear and strong. There is a way that is the opposite to this, where you submit to your teams whims, undermine yourself and lose their professional respect because you are a weak leader. People want strong leaders, they don’t want assholes or wimps.

This is the central problem I have with ‘don’t get close to the team’, it assumes you are an intellectual, social and professional moron. It encourages you to slide to the wrong end of the interaction scale and become an asshole, who thinks being tough with the team is the best approach. We all leave bosses like that, we leave bosses that are distant and unconnected to us. We stay with companies where opportunities are limited, pay less than we’d like, etc. because the boss and the team are the best we’ve known. I stayed at AOL about 2 to 3 years longer than perhaps I should have, because my boss was awesome and so were the team. It took me 18 months to leave, because my boss cared about me, professionally.

Get close to your team, but maintain your professional stance. Make it clear you all have roles to fulfill, yours is to lead or manage and you won’t allow yourself to fail at that (or allow anyone else to make you fail). Make it clear you want to encourage, mentor, support, guide, advise, collaborate and work WITH your team – but they need to be professional and fulfill their roles fully too, if they don’t then it will be a performance management issue THEY brought on themselves. Show them you care about them being away from their ill spouse, you note their reticence to take a day sick when they’re obviously ill, etc. and when you need that urgent job doing, snap overtime, etc. they’ll be there. (If they’re not, you hired the wrong person and should manage them out).

Treat people like professionals and you can act like one too. Then you can safely connect with them on a personal level, in context of the workplace – not their personal lives. You can have lunch and after work drinks and still knuckle down when the need arises, you can make it clear the deadline is set and you expect delivery, but once the project is over it’s time for Nandos!

See the difference? You will if you get close to your team, professionally.


Liked this post?

Tuesday, 13 August 2013

Project 'Coding Oledium' - Part 1

Well, much for cranking out lots of YouTube videos in quick order, editing videos has proven more of a challenge than I expected! Avid, Edius, Sony Vegas, Adobe Premier, Final Cut Pro, Windows Live Movie Maker, Lightworks  and other video editing software were all on the list, that enough to choose from?!

In the end it proved hard to get any working as I could hope – until I found Camtasia Studio 8. So far so good, though the second video seemed to have wobbly audio. It may need me to get used to the Snowball Ice from Blue Microphones that I’ve just bought, with Pop filter don’t you know. Blimey… it’s a whole other world eh?

But enough of that nonsense…  back to the software testing! I may begin to question the wisdom of Vlogging as-I-learn-to-code but hey, in an alternate universe I used to video blog in the same way as  I painted miniature models… no really, search for HantsWarhammer on YouTube. Hmm, maybe I shouldn’t admit that?

# So what’s it all about?
The idea of the ‘Coding Oledium’ video series is for me to have a live project to practice VBScript on. How it will work with me learning as I record I’m not sure, might be totally boring or it could be interesting like Big Brother for Geeks, though reality TV isn’t my kettle of fish to be honest ;p Having said that, I remember watching thekamloopian on YouTube a few years back and it was oddly compelling, can I do the same with Coding Oledium? It’s an interesting idea.

Oledium should contain VBSCript classes, functions and subs, smatterings of arrays, plenty of variables and a host of other stuff to be sure. I want it to be a fairly structured software development project, but also loose enough to do a little agile development and testing. Oh, and very very simple, that plan is NOT to develop a real game. I’m sure I’ll get myself lost down a track a few times but that’ll help teach myself all about VBScript and coding! Let’s see if I can crack the video production techniques and sort out the audio rendering et al.

Here's the first video, a little rough in terms of production quality but you'll get the idea :)


First step was to create a Mind-Map as a basic design, good for thrashing out what file and features might be needed. I'll post the full MM when it's done so it can be downloaded, which reminds me I need to think where to put the code files. I have played with Git Hub in the past, but it's a pain in the arse. Maybe Microsoft Skydrive or Google Drive public folder might be an option.

Well, Part 2 is pending, when I start to write up some code!


Thursday, 1 August 2013

VBScript - Call a function in another file

Well.. long time no blog. I've been learning a bit of VBScript, a bit more VBScript in truth. As usual I've played with it previously as part of QTP testing but never liked it. (you'll have to guess which I never liked...). One thing I tried to do recently was convert my 'game' files from Ruby to VBScript. I did it with JavaScript a while ago and my blood laptop died. The re-practice will do me good.


A thing I have in the files is a class and function library. In Ruby it's easy to simply include a file with other stuff in, literally include somestuff.rb, then use whatever got included, gotta love it. Not so easy in VBScript. For brevity I'll jump straight to the solution.

NOTE: this is not MY solution, I trawled many a forum and grabbed the code, but in doing so didn't note the forum. SO APOLOGIES IN ADVANCE. Oh, and it was finished off by Majiec at BJSS, so ta for that!

Create a file called moduleCall.vbs and include the following:

Sub Include(file)

  Dim fso, f

  Set fso = CreateObject("Scripting.FileSystemObject")
  Set f = fso.OpenTextFile(file & ".vbs", 1)

  str = f.ReadAll


  ExecuteGlobal str

End Sub

' Now call Include and then call Doit
Include "The_Module"


Then create a file called The_Module.vbs and add the following:

Sub Doit
  MsgBox "Hello"
End Sub

Now run moduleCall.vbs and watch the pop-up open.


Pick up a more complete set of files at www.cyreath.co.uk/code/vbscript - the "005" set.


Liked this post?

Read More