On board the Golgafrinchan 'B' Ark

At one point in Douglas Adams' The Restaurant at the End of the Universe the main characters find themselves aboard a huge spaceship filled with frozen bodies.

The ship's captain tells them that his planet, Golgafrincham, was facing impending doom and that the decision was made to evacuate on three huge Ark ships.

'A' Ark would carry all the best thinkers and artists, 'C' Ark all the workers - those who actually make and do practical things.

The ship they are now on - 'B' Ark - carried all the others ... the "middlemen".
Ark B was sent off first, and although they've never heard from them they assume that Arks A and C are following on behind somewhere.

Of course, what the Captain is unable to recognise is that Arks A and C never left, and the remaining Golgafrinchans simply wanted to rid themselves of the third of their population they regarded as "useless".

Periodically - and somewhat bizarrely - being a tester reminds me of this story. Because I can feel a bit like I'm on 'B' Ark. Unable to convince others of my value, and seemingly with little future.

Of course, it's a personal view and I wouldn't want to claim that it's true of testers generally.


What makes testers valuable?

Some of the skills that attracted me to testing several years ago don't seem to be as valuable anymore. Things like communication skills; business-knowledge; customer empathy; critical thinking; ability - and desire - to learn

Value in a tester - at least if you want to get hired - now seems to lie mainly in ready-made automation and tool use ability.
Arguably this is right - those skills are definitely important and useful, and they are certainly in demand.  Personally I'm always impressed by testers with deep technical skills and always striving to improve my own.

"Experience" is good if it means knowledge of the right technologies/tools. (And the right ones vary.)

But "experience" is bad if it means you've been around a few years and you're in your 40s.

In the wider context of software development some hold the view that dedicated testers aren't needed anymore anyway.  Testing might be - but that can be automated, can't it?
Or informed by actual users after going live. And then fixed quickly via a Continuous Deployment / DevOps pipeline. (As an aside: for a craft that is at its best context-driven, there seems to be little recognition in testing these days of a software world that's outside of web or mobile.)

Within the testing community, particuarly on Twitter, the impression sometimes given is that the testers with the most value are those who are able to go to, and especially speak at, conferences.


Conveying value

Of course in Adams' story the punchline is that included among those the Golgafrinchans have cut adrift (in a ship programmed to crash-land) were all their Telephone Sanitisers.

Which leads eventually to the two-thirds who stayed behind being wiped out by an epidemic which starts from a dirty telephone.

I doubt that the neglect of some testing skills will lead to any problems quite that dramatic.
But maybe there's something in the notion that actual value is not always recognised. And that conveying one's value - always a challenge - is harder when the prevailing opinions differ.

Introducing Test Team Lean Coffee

Background
Our team has a weekly hour in the diary for a session called "Experiments and Learning." (It pre-dates my joining.) As you'd guess, it's intended to be an opportunity for knowledge-sharing.  The sad thing is that I'd estimate only 1 in 5 of those sessions doesn't get cancelled because no-one has anything to share.

One reason for that is that we tend to think of them as demonstrations or mini-lectures which would require preparation.  I've done a few myself, including on Inattentional Blindness and on Session-Based Test Management, and they took a lot of personal time to put together.

Rather than waste the opportunity we have every week, I proposed that we try Lean Coffee at one session. If we liked it, then we would always have the option to do Lean Coffee periodically after that.

Lean Coffee, of course, requires almost no preparation. And gets the whole team (or as many as want to be involved) actively involved in the session rather than passively listening.

After proposing the idea to our QA Manager and getting his buy-in, I emailed my teammates to introduce the concept and asked them to let me know if they were interested in trying it out.
I wasn't entirely surprised to find that the vast majority of the team didn't respond at all, but when it was brought up again in our team meeting it seemed that there was interest.
And so, more re-assured that there wouldn't be an empty (or embarassingly quiet) room, I went ahead.

To give everyone a starting point for ideas on what to discuss I shared the list of topics that had been suggested at TestBash 2016 in advance.


The topics on the day
At the session, after combining stickies suggesting the same topic, we ended up with the following on our "to be discussed" list:

- Motivation. Keeping testing interesting
- The testers role. Are testers needed anymore?
- Security testing
- Real-world use cases and environments
- TDD/ATDD/BDD

It was interesting that the first thing we talked about was the one that had been most voted for so - in theory - was the one most people were interested in.  Yet I think it was one of the shorter discussions. That may have been because everyone was a bit unsure/reticent about talking and hadn’t got warmed up yet. (Of course, maybe people also felt they weren't able to talk about feeling bored in front of our manager - although he was one of the ones posing that question!)

It so happened that we covered all of the topics we had in our session with just a 5 minute overrun. This was probably a good thing.  Whilst in general there should be no pressure to get through all the suggested items, as this was the first Lean Coffee session it was nice that no one was left feeling they had wasted their time coming up with topics.

Reflections and lessons learned
- We didn't have the typical group configuration for Lean Coffee. There were 11 of us, and the room didn't allow us to split into smaller groups at separate tables.

This turned out ok because our group weren't the normal self-selecting Lean Coffee group and some of the people there weren't so comfortable talking.  Conversely, I felt I probably talked too much myself. This was partly because as the instigator of the session (and the reason everyone had found themselves sitting there) I felt a need to keep conversation flowing.


- Initially I had intended to take the vote on whether to continue discussing a topic or not after 5 minutes. But in practice that didn't feel long enough - it seemed silly to ask if we should continue with something we were only just getting into.

Throwing myself into doubt about that also meant that I didn't take a proper "roman vote". I tended to ask the group if they wanted to continue and then people seemed to be looking around to see what everyone else was doing before they would risk putting their own hand up. Getting everyone to give thumbs up/thumbs down at the same time would probably have overcome that.

I think next time I might experiment with taking a first vote at 10 mins, and then at 5 minute intervals after that.


- After the session I emailed everyone to ask for feedback, and for any criticism/improvements.  (I felt I was slightly more likely to get honest feedback via email than I was by asking face-to-face.)

I got two responses - both positive and interested in doing it again.

It's hard to tell how valuable the rest of the team really found it.  But now they know what Lean Coffee is, and they know that it's there as a future option any time we want to make use of it.  And it's so simple that I don't need to be there to "run" it.

Using 'hdparm' to reduce the size of a hard disk

Why on earth would you want to reduce the size of a hard disk? Surely we always want as much disk space as possible?

Well, in my current role one of our product streams is full disk encryption for Windows.
And one problem for testing is that large hard disks can take a long time to encrypt - many hours, even days in extreme circumstances.  (Size of the disk isn't the only factor - processor power is another.)  So, sometimes, we want the system under test to have the smallest hard disk possible.

Since we often need to test against specific models of laptop, rather than build our own small-disk test rigs, that can lead to frustrating delays before we get a system into the right state to get the information we want.

A simple and quick solution that one of our developers tipped us off to, is to use the hdparm command in Linux.  It allows you to view and set parameters of your hard disk and one of its, perhaps lesser-used, features is the ability to force the disk to show as only having a certain number of sectors.

If you ever find yourself needing to do this, here are the simple steps which I have found to work for me.  (But, of course, this should be done with caution.  And it's not advised to try it on disks which already contain data you want to keep.)
You'll need to be able to boot your machine to Linux and for that I use an Ubuntu USB stick built from here.


1. Boot your system to the Ubuntu USB stick
You may need to go into the machine BIOS and select a temporary startup device. When it loads choose "Try Ubuntu without installing" to run the OS directly from the stick.


2. Find out how Ubuntu labels the HDD that you're going to change.
Typically, the main system disk of a machine will have the "logical name"  /dev/sda - but do make certain you're working on the right disk before you attempt any changes.  One way to check:
Press ctrl+alt+t to open the Terminal program. (You're going to need it to run hdparm anyway) and enter:

sudo -i  (this gives you the necessary rights to run the commands you need)

then enter:

lshw -class disk

Look through the information returned for disks found on the system and note the "logical name" of the HDD you want to change.  Check this carefully to be sure you have the right one.


Staying in the Terminal....


3. Find out how many sectors the disk has in total.

Run the following hdparm command:

hdparm - N [logical name of your disk]

You'll get a result something like this (depending on the disk size):

4. Work out how many sectors will give you the disk size you want

Assuming you know the original capacity of the hard disk, you can either:
a) Query or calculate the individual sector size, and from that work out how many sectors add up to your desired capacity
b) Simply apply a rough percentage based on the amount of disk space you want remaining after the change.  Eg.  If disk size is 500GB, but you want to reduce it to 50GB (10%), just divide the total number of sectors that hdparm reports by 10.


5. Set the number of visible sectors to the number you worked out at step 4

At this stage it's worth repeating that you should only do this with caution. the "-N" switch in hdparm is officially marked as "Dangerous"!

Enter the following hdparm command:

hdparm –N p[desired no of sectors] –yes-i-know-what-i-am-doing [logical name of your disk]

Note that "–yes-i-know-what-i-am-doing" string!  This is not a joke - you really have to enter that, and it's there with good reason.  Once you enter the command you won't be asked if you're sure - the change will be made.

The 'p' in front of the number of sectors indicates "permanent".  It means that the change to the number of sectors will stay in effect unless and until you repeat this process and set it to something else. (Yes - you can get your original disk size back again!)  If you don't include the 'p' the change you've made will be lost on a system restart.

Once you shut down Ubuntu, remove the USB, and restart your system normally the change should be in effect.
At this stage we would either install a new copy of Windows, or restore an existing image for that machine - giving us a clean OS to work on with an unusually tiny HDD to encrypt.

I haven't used this extensively so I can't vouch for it working on all types of disk and systems. My understanding is that it won't work on removable USB hard disks, for example.

And, remember, some of hdparm's functions can be dangerous to your system.
If you're at all uncertain I'd strongly recommend reading more about hdparm before use.