Smart Contracts

Updating Solidity code and Testing a Smart Contract

Books on the Blockchain

Publica Self Publishing

Goodbye Contracting

Hello brave new old world...

Ruby-Selenium Webdriver

In under 10 Minutes

%w or %W? Secrets revealed!

Delimited Input discussed in depth.

Monday, 28 July 2014

Ruby - Array: Adding and removing data with Pop, Push, Shift, Unshift

In an earlier post we looked at basic Arrays and some tricks around delimited input (%W and %W etc.) What we saw were a few ways arrays could be built out and data added to them - when being created.

With that understanding however, we need to see how we'd add and remove data once the array is already set-up. Fortunately, Ruby provides a way to do that, albeit in a slightly cryptic way.


Let's say out array looks like this:

testArray = ["a""b""c""d"]

We'll want to do one of the following: 
  • REMOVE data from the START (Shift)
  • ADD data to the START (Unshift)
  • REMOVE data from the END (Pop)
  • ADD data to the END (Push)
Graphically we can represent this as per the below:

To experiment with this, let's set up and array then ask a user what they want to do with it. The array needs to be accessible in the If statement we're going to use in a second, so for each make it's scope up from local to instance by adding @

@testArray = ["one""two""three""four"]

puts "\nWhat would you like to do? (shift, unshift or push, pop)"
action = gets.chomp.downcase

Here the user can select one of the option of shift, unshift for working with the start of the array or push, pop for the end of the array.

Next let's build out an If statement framework;

if action == "pop"

  elsif action == "push"

  elsif action == "shift"

  elsif action == "unshift"


Under each we then need to call the correct method for each action selected.

if action == "pop"

Can you complete the rest?

To help the user see what's going on, let's give a message about what's going to happen, then print out the contents of the array so we can see the result.

if action == "pop"
    puts "\nPoping a value OFF the END of the array (#{@testArray[-1]}).\n"
    puts "The current array looks like this:\n"
    puts @testArray

Here we use some interpolation to return the end value before we remove it.

As above, have a go at writing the rest of the script for each of the methods.


Using these methods, we don't have to modify one element at a time. We can specify the amount of elements to be modified by adding a value to the end of the method, for example;




@testArray = ["one", "two", "three", "four"]

puts @testArray

puts "\nWhat would you like to do? (pop, push or shift, unshift)"
action = gets.chomp.downcase

if action == "pop"
    puts "\nPoping a value OFF the END of the array (#{@testArray[-1]}).\n"
    puts "The current array looks like this:\n"
    puts @testArray

  elsif action == "push"
    puts "\nPushing a value ONTO the END of the array.\n"
    @testArray.push "five"
    puts "The current array looks like this:\n"
    puts @testArray

  elsif action == "shift"
    puts "\nShifting a value OFF the START of the array. (#{@testArray[0]})\n"
    puts "The current array looks like this:\n"
    puts @testArray

  elsif action == "unshift"
    puts "Unshifting a value ONTO the START of the array.\n"
    @testArray.unshift "zero"
    puts "The current array looks like this:\n"
    puts @testArray

  else puts "That wasn't an option"


Read More

Age discrimination in the workplace

On Linkedin there's a spirited, 3000+ reply, about hiring those who are 50+ and needles to say most of the responses are positive about it. I've of course not read anything over about 100 replies, but my reading of the posts is the experience and stability brought are worth various quantities of gold.. For me it's almost a mute point, but then perhaps I 'get' it that you can't just rule out someone for a role base on age. It's ludicrous to think that age alone qualifies or disqualifies someone for a role in our software development and testing profession. I like the fact the UK is pretty hot on age discrimination. When I was in manufacturing virtually all the candidates were 50+ women looking for part or full-time roles on the production line for a bit of extra money. I guess my early working years just normalised the idea of hiring older members of staff. In truth, the 'youngsters' were seen as a liability and sad to say, provide themselves to be repeatedly. As the process engineer it was my role to set-up the manufacturing line, optimise layout and £££ return per square foot, research tool selection, get us through ISO9001, etc.

Looking back now, it was fun having these 50+ people (mostly ladies) work there, I mean it, I looked forward to getting into work and wandering over to the line, saying "good morning ladies" in a charming / slightly comedic way and having them take the micky with their "ooh, young maaan" response. I'm pretty much always happy, I don't laugh that much as a rule though, but I laughed every day with them. Thinking about it now I have a sense of colour, sunlight and fresh air, memories are funny eh? What really made it work was the mutual respect. As a 20 something I was in awe at the incredible experience they had, I would constantly ask their advice about how they'd set the line up, write up the instructions, sequence the build and so on. In turn, they produced so little bad quality product, the company let the 'quality controller' go, woops! We ended up just throwing the few defective units into recycling.

Now I'm in software testing and development, I don't see a massive amount of age discrimination. However, there are certainly roles that naturally fit with a person of a certain age. Senior Programme Managers are rarely 22, agile Ruby on Rails developers are rarely 55, except where these individuals are exceptional. But then, hey... they're exceptional so you'd expect them to break the typical patterns. Not that it isn't tricky to get exactly the role you may want for the salary or day rate you'd like. I'd really like to get hands on for 12 to 18 months with Ruby, Cucumber, RSpec, Selenium, etc. but there's younger more technically focused talent out there. I'm sure some of the younger talent would love to be at an investment bank running automation programmes through multiple off-shore teams, but they don't have the experience. That's not age discrimination, it's fitting the best person to the job, sometimes age means you aren't in the right place experience or career stage wise, but it's not the age that's the problem as such.

Talking of exceptions, the youngsters I come across today are a class apart from those I encountered 15 years ago. Our profession certainly breeds them like this to some degree, but I think da yoof have changed. The, let's say 22-25 year olds that I work with now, are in the main pretty inspiring. I consider myself to be the most educated, experienced, erudite, etc. that I have ever been, but I'm not convinced I was as bright and well educated as they are at their age. On the reverse, I don't think the 40 and 50 years olds of today are as old as they were 15 or 20 years ago either. My parents seemed ancient to me when they were 35, at 42 I feel like I've just left university. A general youthfulness of perspective permeates society more so than ever. Daily, I'll be asked for some guidance and advice from a slightly panicked more junior member of staff and I can barely feel a flicker of worry in my mind. Conversely, I turn clueless to the same people and ask for technical guidance and mentoring on how to best approach a problem, to see them answer the problem as if it were the simplest thing in the world. There's definitely a greater equality age wise, it's not perfect, but I don't see it as the disaster some would like to paint.

The 'age' problem exists when an employer assumes if you're over 50 you can't do the role, without any qualification than 'but you're over 50'. It's just like saying you can't do it because you're too young, you're black, an immigrant, a woman. Your blood should rightly boil in all cases. If you apply to a company like this or work for one, do everyone a favour and walk away as fast as you can. Their time is done anyway, they'll fade away into the black hole they deserve to be in soon enough, get away before you and others get sucked in.

The main question when applying for a role or hiring for the same, should of course be whether the person represents the best talent for the role. Career paths to date, education, experience, attitude, interests and outlook are all factors that play hugely into whether you're the right candidate for the role. The youthful and mature alike cry foul at not being able to get the roles they want.That the 50+ crowd shout that it's unfair is a great sign that times and expectations have changed. It's fantastic that people refuse to be limited by a false sense of limitation due to age, that a Linkedin post can get 3000+ responses agreeing age is irrelevant. Finally we're starting to see the first sparks of (some portions) of human society refusing to be held back. It can only be for the good.

However, despite my positive view on this point, there is a very real workplace issue that is not getting the notice it should.

A seriously bad issue. Bad as in as bad as racial and sexual discrimination. A problem so serious, so abhorrent, that no right minded individual should be staying quiet about it.

That problem, is workplace and pay inequality for women.

I'll talk about that in a future post.


Friday, 25 July 2014

More Reporting - Pitching at the right level

As mentioned before, a key part of any test delivery is the reporting we provide. In my experience, management are often not interested in the majority of what we do. Sure, at a high level they care about whether we know what we're doing, but they're not interested in the low level details as we are. For us, the fun is in the cleverness of analysis, writing great sets of test cases, executing in different ways, maybe adding some automation into the mix and so on. That for us is the important stuff and rightly so, you don't get a delivery without it. However, the management team need mainly just to know what was planned, what happened and where it leaves us. Hence the need for reporting that is informative, easily understood and readily actionable.

When looking at what reporting to provide remember, it's all an 'interpretation' of what happened and you can describe your activities in a way that fits with management expectations. If they're completely on-board with your approach that makes it easier, if not, you might need to get creative. An example that springs to mind was on an engagement where management wanted an approach that followed the typical SDLC phases, weekly steering committee meetings and dashboards produced in Powerpoint slides. Meanwhile the implementation team wanted a more agilistic approach. The desire was to deliver 'something' demonstrable, if not strictly usable, on a weekly basis. That meant following a Scrum like approach to planning and delivery, seemingly opposite to that which management was expecting. Leading this team in a not quite Scrum master role, was a manager who wanted not only weekly reporting updates but end of day updates too.

As the lucky one in charge of environments and testing, it was my job to reconcile the needs of all sides and report out on what the test team were delivering. The technique is to expose essentially the same information but in the way requested. Wow, that was insightful! Let's look at what that means in practice.

The SDLC approach means high level dates on a schedule, spanning key phases, perhaps at best breaking the phase down into key sub-milestones. Phases from this perspective are 'big' - Analysis, Planning, Execution and end of phase Reporting. As these phases proceed a weekly summary of progress for is provided to senior management and execs. This is a sequential, big-up-front approach so senior management expect reporting in that context. Reporting contains data in context of the phase, not so much the activities underneath. For the agilistic mindset, reporting like this can be frustrating, but it needs to be remembered that at some point up the chain, all reporting morphs into this. Board members and Shareholders don't want to know how many test cases in what state there were today. The daily detail needs to be rolled-up into one higher level report.

Where are we through the SDLC phase, are we on target for the end date?
What No. or % of the total are we at and is this matching our plan?
What are the high level common issues being faced?

This provides insight into management concerns which usually revolve around money. Is the implementation of the new software on-track with Product Lifecycle plans? Will the product hit market in time for the marketing activities planned? Is the ROI achievable in the time expected to maintain share price? It's a rare tester that sweats this stuff, it's a rare marketeer that sweats the defects and test automation details. For the team closer to the actual work, this level of reporting is too high - it's not adhering to our rules above of being informative and readily actionable.

Back in the team, the reporting needs to be closer to what we discussed in the End of Day Reporting blog article. With their agilistic mindset, the team need information that shows the heartbeat of the project day by day (half-day by half-day is my preference!). In this way they can slow down or speed up as required. This is informative and actionable for them, but isn't useful by senior management. Rolling the daily reports up into a weekly at the same level is also something the team management can respond to.

Looking in on the project, senior management see the sequential phases, following the SDLC as requested. Underneath, the team can be slicing delivery up into small chunks of daily usefulness.


Wednesday, 23 July 2014

Skills Matrix & Development Plan - Template Walkthrough

One thing we'll get asked at some point is to assess the skills and competencies of the test team. To do that we need to understand what the skills competencies actually are and how we're going to assess them. We also need to decide what we're going to do with the information we gather.

Skills and competencies come in many shapes and forms. They draw on hard learning from the team members study up to raw experience gained over many years and projects delivered. As such we need to agree how to group them, then break them down into our Skills Matrix.


In the Skills Matrix on the site, we have the following examples:

  • Technical - Tools and Technology
  • Testing
  • Application

Clearly you could break these down in many ways, but these are a good start. Under each category we have entered specific examples such as;

  • Tools: ALM, UFT, Jira, Toad, PuTTY

Technology is more general and could include scripting languages, protocols or maybe servers and operating systems. As with all templates, it provides a guide but it's up to you to interpret and apply it to your unique testing or management problem.

In order for the team to be ranked (or rank themselves), we need to understand what those ranks are and what 'value' we're assigning. On the About tab, you'll see this has been defined as:

  Level   Definition
1 No knowledge   No practical, working knowledge, should be able to use if provided clear guidance
2 Awareness   Can work with existing solutions and practices, understand what to do but perhaps not fully why
3 Proficiency    Can maintain and provide minor improvements, notable skill in some areas
4 Competency   Full understanding of existing solutions and practices required for day to day work
5 Expertise   Able to critically assess and improve on current use and build future capability

Clear definitions are essential, but in no way perfect. Use these as a guide but encourage the team not to labour too much over them.

A word of warning...
When rolling out the Skills Matrix and asking the team to rank themselves, the first question will be 'Why?'. It isn't unreasonable that you'll spook the team into wondering what it might mean to rank low on the items you want to assess. You wouldn't be getting them to complete it if it wasn't relevant.

Be sure to reassure them, that this is to help identify the skill base of the team, to make assignment of testing tasks more effective, to identify ways in which the team members can be trained and so increase the team's capability. 

Professional Development Planning
You would do well to introduce a strong process of review and assessment of the team, before you roll out the Skills Matrix.

To help with this, grab a copy of the PDP Scratch Pad template and have a read through of the Developing the Team paper to learn more about implementing an appraisal process, both are on the main site.


Liked this post?

Tuesday, 22 July 2014

Test Status Report - Template and Walkthrough

As mentioned in the End of Day Reporting - Worked Example article, EoD reporting is something we'll get asked to do as software testers, on virtually all our projects. In fact it should be literally all our projects, even when we're not asked we should provide it.

In order to do so, we need a means to capture the data that will be included in a report. That data is just data though and we need to convert it into easily digestible information. Be mindful that raw numbers may be accurate and are valuable, but they are often devoid of meaning. When reporting, don't be shy about including context and narrative - your report may be unreadable without it!

The previous article on End of Day reporting covered some points around presentation, so let's look at capturing and interpreting the raw data here. When reading through this article, have a copy of the template open in front of you. We'll walk-through each of the key sections here, but it's best to watch the YouTube video and refer to the template for a more in depth look at the Workbook.

Get a copy of the Test Status Tracker Template


Oh, watch out for formulas, there are plenty of them on the Worksheets!


Project Details
Enter the following details about the application. This data is used throughout the Workbook.

Project Name: [Enter the name of the project or application under test]
Start Date: [Enter the date as nn-mmm, e.g. 21-Jul]
Total No of Cases: 
[Enter the total Test Cases in scope]

Daily Tracker
There is nothing you need to enter on this tab. It is generated from the Data Table and Issue Tracker tabs. However, you will need to manually edit chart symbol colours. Refer to the status table and review variance against plan on the chart. You'll then need to select the individual data point on the green Actual line, then fill the correct colour into the point.

Data Table
There are two main sections, Planned and Actual, where you need to enter data. Before completing the table, enter the names of the testing staff in the left hand column. When planning out the amount items that will be worked on each day, enter the total in the above 'Total No. Of Test Cases' box first. Then map out what can be delivered on a day by day basis, for each member of staff.

At the end of each day, enter the Actual numbers achieved by each team member.
With the data in place you will need to select the calculation cells at the bottom of the 'Actual' table and using the fill handle, populate the cells under the day you have just entered data for

This is done daily to avoid showing zero figures on the chart, making progress easier to see.

Issues Tracker
Where an issue or risk emerges during delivery, track it on this tab if your project has no other central place to record the data.

Downtime Tracker
Each time the team are unable to progress with delivery due to some issue, this is 'downtime' and should be recorded on the Downtime Tracker tab.

The tracker forms a historic record of time lost and allows reconciliation of lost time against plan, to support reporting and re-scheduling activities.


As stated above, watch the video for a clearer run-down of the tracker. This is one worked example to show some tricks and tips of how you can make your own. If you make any interesting changes be sure to let us know!


Liked this post?

End of Day Reporting - Worked Example

Reporting the status of testing, at whatever stage, is critical to effective management and ensuring the business is confident about our ability to deliver. Reporting accurately, consistently and frequently are key. It would be great to have a tool that did all the reporting for us, but often we don't have a test management and reporting tool in place. In fact, sometimes the tools we get burdened with are more trouble than they're worth, being unable to produce the reporting we want. Either in the style we need or with the ease we'd like to see. In that case, Excel and Word along with a simple email become our best friends. If we do revert to this simpler approach, we still need to ensure accuracy and consistency.

When working as a member of a team or as a consultant, my preference is always to send an end of day report out.
The benefits of doing so include:

* Ensuring you have a think-through of what the status actually is, what you need to be doing and any issues that you need to raise
* Providing information to the line manager and stake-holder that they can take into their own meetings and reporting
* Creating a record that can be referred to in post implementation reviews, to help identify areas to be improved on

The main trick with these reports is to keep them short. My rule-of-thumb is that if it takes more than 5 to 10 minutes to complete, it's too long. The EoD update should be simply collating what you already know and information you already have, into an easily digestible email or post on some internal forum perhaps. There are many ways to structure these EoD updates, but here's what I'd typically expect to include, in the style I'd provide it.

The objective is to keep them informed at a high level. Imagine they're stopped by the project sponsor and asked "How are things going?", the below should be enough to answer the question. Remember, it's just a snapshot. If the audience for this wants more information they need to dig.

In the next post, we'll look in detail at a Excel Daily Status Tracker workbook that can be used for this.


Example Project - EoD Update: Tuesday 22nd July, 2014

Current RAG: Amber
Planned Complete Date: Mon 21st July, 2014
Expected Complete Date: Thu 24th July, 2014

Due to environment downtime, caused by network outage, progress for execution is 10 Test Cases behind schedule. The issue was escalated and is now resolved. Expectation is delivery will be back on plan by Friday 25th.

Of 126 Test Cases in scope:
- Execution is 10 Test Cases behind plan
     - Total executed to date is 87 (+7) or 69% (+6%) , of which;
        - 65 (+6) Passed
        - 12 (-2) Failed
        - 10 (+3) Blocked

- 3 Test Cases Blocked due to test data being for transactions already expired. Will create new data tomorrow and execute as a priority
- 12 Cases in a Fail state with Development, 2 Fails retested and passed
- Team will conclude Feeds testing tomorrow and move onto Reporting and Transactions areas
- Pleas note: David is out of the office Thursday, therefore no Test Cases for Reconciliations will be executed

Daily Tracker Chart


Liked this post?

Monday, 21 July 2014

Ruby - If Ternary, Until, While

We’re making good progress getting some of the key basics of Ruby understood. Variables are of course central, Arrays allow a more complete way of data handling, Case and If statements are the building blocks of ‘flow control’ in our program.

In looking at these, we’ve also learned a few tricks with getting, printing, chomping and interpolating data and a few neat tricks to present and evaluate data in different ways, to get a True or False state so we know what to do next. That’s quite a bit in a few hours, congratulations if you’ve followed along so far!


With this stuff understood, let’s loop back on ourselves somewhat and add in more detail on a couple of things. To start with, let’s finish off a few more aspects of flow control.
The if statement as we saw it before also has a shorter version, called the ternary or base three operator. Here’s an example:

a = 2
a == 1 ? (puts "Banana") : (puts "Cheese")

Here we set the value of our variable a to 2, in the next line we ask does a equal 1? If True then puts Banana, else puts “Cheese”. In the brackets we could include whatever code we wish to, just like the longer form If statement. However, the ternary or base three version easily gets difficult to read and should only be used for small tasks. This might be concatenating two string or doing a quick piece of math.

In addition to Case and If statements, we also have Until and While loops available to us. These allow us to execute a block of code until a certain condition is true or false.

·         For Until, the code executes so long as a condition is evaluated to false
·         For While, the code executes so long as a condition evaluates to true

First, here’s an example of Until in action:

c = 1
 until c == 6
   puts "C = #{c}"
   c +=1
We’ll see five lines printed to screen, stopping when c evaluates to 6, as the condition is now true. Note in the last line how we increment the value of our variable.
Let’s look at an example of While in use:

d = 1
 while d < 5 do
   puts "D = #{d}"
   d +=1
As with the Until, here we’ll see five lines printed and the code will stop executing once the condition is false. The do keyword is optional. However, it’s more correct to use it, just like adding then in our If statements.


Read More