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.

Struggling to Convert the Test Case Believers (or: Apparently test cases ARE testing after all)

Frustrated by how attached to detailed static Test Cases my teammates seem to be, I recently presented to them on Session-Based Test Management. I wanted to show that test cases are not the only way to track and report on testing, and even give management those metrics that they love.

Talking about SBTM was also a jumping-off point for introducing other topics including "Testing vs Checking"; how exploratory testing is understood in Context-Driven Testing; and approaches to test design in ET eg. heuristics, personas.

There was nothing special about the presentation and I'm slightly hesitant to include it here.  Anyone who has worked in an organisation that takes ET and SBTM seriously will probably find it lacking.

To try and illustrate SBTM in action I also showed examples from a "home-brew" version of it that I had used in a previous job.  (I was a sole tester in my first testing job so, with no-one to guide me, I put a SBTM process together from blog posts and my own trial-and-error experiments.)

To be clear: although I am generally a fan, I claim neither to be a member of the Context-Driven Testing community, nor qualified to accurately represent their views.

Session-Based Test Management from caltonhill

My Exploratory Testing is better than your Exploratory Testing
My teammates certainly would argue that they do exploratory testing already but my impression is that it tends to be closer to the "ad hoc" approach that got ET an unfair reputation for being vague - and which SBTM was designed to overcome.

Also, in my team ET is definitely seen as a poor relation to test cases. And I have genuinely heard comments like "if there's time left after running all the tests in the spreadsheet we can do some exploratory testing".

Failing to create debate

I'm not delusional enough to think that one presentation from me would start a revolution, but I did hope we might at least have some debate about why they see so much value in test cases. And I hoped to hear some opinions/feedback on SBTM as a possible approach to delivering value through more thoughtful and skilled Exploratory Testing - with proper note-taking!

Sadly that just didn't happen. And what I thought would make a good blog post ended up being this one. Sorry.

It was almost as if what I was describing was a kind of interesting curiosity, but not relevant to them. Like when we watch a documentary about how people live in another culture.

Because they already do exploratory testing (as they see it). After all, exploratory testing is one of the things they use to come up with ideas for the real stuff - the Test Cases!

Now, of course, you'll be thinking that the failure to engage with my audience was down to my poor presentation skills. Maybe so.
Aware of that possibility, and of the fact that I was only skimming the surface of some big topics, I followed up the presentation by circulating links to articles by better communicators than me. (Reproduced below.)

I also offered to demo Rapid Reporter later to anyone was interested; and even emailed them all their own copy of the Test Heuristics Cheat Sheet.

A couple of weeks later, not only has no-one shown any interest, I find myself being asked to write even more test cases (because apparently our problem is that we don't have enough), and even attending Test Case Peer Review meetings.

Not giving up
It has to be said that after moaning about my presentation's lack of impact on Slack, I got some encouragement and a couple of good suggestions there.

Damian Meydac Jean pointed out that in situations like these there's often more to be gained by working on newbies than on people who've worked there for a while.

And Vernon Richards made a good point about how it can be more powerful to relate new ideas like these to specific issues or pain-points facing the team.

Seeking the case for test cases
But maybe I'm the one who's wrong. Why should the rest of the team/business change what they do to fit in with a lot of fancy-Dan ideas I'm repeating from the Twitter-bubble?

If I try to ask colleagues why they find test cases so valuable it does seem to strike them as an odd question to ask. There is just a sense in which there have to be test cases because, you know, we're doing testing. (Although they tend to say we're doing "QA".)
But more specific reasons include:

• they provide scripts which can then be automated 
• this does strike me as a pretty good reason although the reality is we have little automation and only a fraction of test cases written will ever be automated
• they suggest test ideas 
• by this it's meant that team members can read the test cases to get ideas for what tests to carry out on a feature/product
• they serve as documentation
• they can be useful as a way for testers to familiarise themselves with products they haven't worked on before
• we have a situation where test cases are sometimes viewed as an oracle on "correct" product behaviour. Yikes.
• they tell us when we're finished regression testing

Let's have the debate right here!

Now I couldn't resist unfairly undermining some of the reasons I just listed, but I would genuinely be interested to hear more about the positives regarding the test case approach and why it might provide more value than exploratory testing in certain contexts.

There is definitely a possibility that I am against them simply because I am too lazy to write them, and I find executing them boring.  (In which case, maybe I should just get out of testing - God knows I think about that a lot.)

So, if there's anyone reading this with a view on the value to be found in test cases please add a comment.  Despite my overall jokey tone here I really would like to be challenged on my cynical attitude.


-------------------------
For reference, below are the "further info" links I circulated, and added to our internal Wiki, after my presentation
-------------------------

Exploratory Testing

Why Scripted Testing Sucks, Steve Green

http://www.testpartners.co.uk/why-scripted-testing-sucks.htm

Exploratory Testing in a Regulated Environment, Josh Gibbs

http://www.stickyminds.com/article/exploratory-testing-regulated-environment

Exploratory Testing, Michael Bolton

(Describes what ET is, and what it isn’t, according to Context-Driven Testing.  Also has a long list of links to further resources on ET)

http://www.developsense.com/resources.html#exploratory

Session-Based Test Management

Session-Based Test Management (overview), James Bach

http://www.satisfice.com/sbtm/

Session-Based Test Management (practical details of using it to manage testing), Jonathan Bach

http://www.satisfice.com/articles/sbtm.pdf

Managing Exploratory Testing, Rob Lambert

http://thesocialtester.co.uk/managing-exploratory-testing

Learning to use Exploratory Testing in Your Organisation, Mike Talks

http://testsheepnz.blogspot.de/2014/02/learning-to-use-exploratory-testing-in.html

Benefits of session-based test management, Katrina Clokie

http://katrinatester.blogspot.co.uk/2014/03/benefits-of-session-based-test.html

Exploratory Testing Frameworks

Generic Testing Personas, Katrina Clokie

http://katrinatester.blogspot.co.uk/2015/01/generic-testing-personas.html

Testing Tours, Mike Kelly

http://www.testingeducation.org/BBST/testdesign/Kelly_Taking_a_Tour_Through_Test_Country.pdf

James Whittaker’s  Exploratory Testing Tours

https://msdn.microsoft.com/en-us/library/jj620911.aspx

An Irrational Dislike of Test Cases

I don't like Test Cases.

I'm almost certainly the only one among my current teammates who winces every time I hear the term being used. And I hear it every day. (I deliberately avoid using it - if forced to discuss them I might say "scenarios" instead ... which is pretty childish behaviour on my part.)

Or maybe I don't like a certain form of Test Cases.
It depends on what we consider a Test Case to be.

It doesn't have to imply scripted testing, and it doesn't necessarily have to be limiting.

I certainly like to have a number of scenarios, described at a high level in a sentence or two, which I have identified and will cover off during testing.

In the past, when I used my own version of Session-Based Test Management, alongside a charter which set the scope of a test session I would often bullet point specific tests that I want to cover in that session. 

So maybe Test Cases are fine as long as they are a framework for exploratory testing and not used as a definition of "done".

But I definitely don't like detailed, step-by-step Test Cases.

Being tasked to execute them is tedious and frustrating and lets my mind wander to think about all the jobs I'd rather do than be a Tester.

In my current role it's quite usual to have regression cycles where a team of 3-4 Testers may spend 3-4 weeks working through Test Case sets which are:

- incomplete, even as a lightweight regression set (of course)

- out-of-date with changes in the product (of course)

- often unclear. (No doubt the person who wrote them understood them at the time).

- sometimes wrong. (The "expected result" is incorrect and doesn't seem like it could ever have been right.)

I don't blame the previous incumbents for not doing a complete job - they probably realised what a futile task that was. They probably just wanted to make a checklist of stuff that it was important not to forget.

I sympathise because I know that having to write detailed Test Cases - as I am expected to do - can be even more of a grind.

Each time I write a test case, I'm painfully aware of the limitations of the form.

I'm thinking "this doesn't cover the possibilities".
Should I write out all the paths and variations I can think of?  It would use up a lot of time that might be better spent actually testing - but more importantly I won't think of everything.  There will be potential problems I cannot conceive of until I have the software in front of me. (And I still won't think of everything even then.)

So I find myself writing test cases which are often no more than a title, and replacing detailed steps with "use initiative to ...."

But in Test Case Peer Review meetings (yes, we have those) it's made clear to me that my approach won't do.

But am I being cynical about Test Cases simply because I'm basically lazy and don't like having to do the boring parts of testing?

Others around me seem to have a belief in the magical, protective power of Test Cases. That if we have enough Test Cases everything will be ok.
Writing Test Cases early and often seems more important than actual testing. And if all the Test Cases have been written, then there might be time for Exploratory Testing.

But if you do any Exploratory Testing then you have to make sure you write up the Test Cases from it afterwards.

Webinar: Getting Started in Security Testing by Dan Billing

Brief notes on this webinar: presented by Dan Billing, and organised by Ministry of Testing
---------------------

Rumour has it that there are no testers in the world who didn't sit in on Dan Billing's intro to Security Testing webinar this evening.

But in the unlikely event that someone out there did miss it I can say that it's highly recommended.

Currently I work for a company whose business is secure technology, although leaning more towards endpoint/device security than web.  Our team doesn't actually tend to do the detailed security testing (because we're not expert Penetration Testers) but we obviously have security as a key point to keep in mind whilst doing functional testing. So the more I can learn about security the better.

For me this webinar dovetailed nicely with the Troy Hunt "Hack Yourself First" course which I've recently started working through. (With Dan himself using Troy Hunt's practice site for one of his examples and, like me, encountering the regular blasting of that site's database when wanting to demo something from it!)

What you'll learn

The webinar sets the context for the importance of security testing before giving an entertaining overview of recent high-impact security breaches.

Dan outlines the factors that define a good security testing approach, and a couple of helpful mnemonics for modelling potential threats to your application - including his own EXTERMINATE model.
And there's a list of areas presented which will typically be sources of security bugs in applications.

Inevitably the most fascinating part of the webinar is Dan's live demos of some of the key web vulnerabilities, eg. SQL injection, cross-site scripting (XSS), and how they can be easily exploited with no more than a browser and a bit of know-how.

The reality today - on the web particularly - is that the tools for malicious attacks are widely, easily and freely available and therefore the threat is very real.

I certainly came away with a couple of new ideas for exploits I can attempt when I get into the office tomorrow.
As I said, highly recommended.


A recording of the webinar will be made available on the Ministry of Testing Dojo soon.

Dan has also previously provided insights into Security Testing for the Testing in the Pub podcast series and those are also recommended.

Maybe testing isn't for me

It seems like every 3 or 4 months I find myself questioning whether testing is really for me.

I consider myself an enthusiastic tester, and I'm always striving to be better at it. (That's what this blog is mostly about, after all.)  
But I'm not sure that I offer what testing needs. Maybe it's an unrequited attraction.

I've been learning testing for a number of years now across a couple of roles but I've yet to find it as fulfilling and enjoyable as I think it can be. Is that because the roles haven't been quite right for me?

It sometimes seems there's an interesting and rewarding testing world that I might hear about on Twitter, but day-to-day testing can be frustrating or boring.

If you're not already in that other world - not already exposed to the "right" technologies and techniques, or at least supported in learning them - then it seems hard to reach it.

I admit I'm picky about the kind of products/industries I want to work with, and about how much I'm prepared to commute. And nor am I looking to be an SDET. So, of course, all of this limits my options.

But even so, in an unscientific sample look at tester job ads on LinkedIn I don't recognise myself:

- either they emphasise test scripts, documentation and following set processes. (And if that's testing then I definitely would prefer to do something else.)
- or they emphasise skills and experience in specific areas (usually tools) that I either haven't used, or don't feel confident I can offer to a good enough level when my knowledge is mostly from self-study.

"It's not you, it's me"

Increasingly, though, I think that wordings in job ads aren't the problem. Rather, the key part of the previous paragraph is the acknowledgment that I "don't feel confident" - arising from uncertainty of my own value as a tester.

When Katrina Clokie tweeted the testing community with the simple question "How do you know you're a good tester?", I had to respond "I don't".

Gaining Confidence
Of course, personality is a factor here - I'm not a particularly confident or extrovert person generally. But that just means I might have to work a bit harder at it than others. That's ok.

It's all very well having a groaning Trello backlog for learning. Maybe I need to put some of that effort into a strategy for understanding my value as a tester, and not base that value mostly on being able to conquer a huge "to learn" list.

So how can I actually find the confidence, or at least the perspective, that my roles up to now and my continuous learning process aren't giving me? Some initial ideas are:

- Wider "experience"?
I've only worked in limited, and perhaps not typical, testing contexts. Can I find more resources like the upcoming New Voice Media webinar which give insight into the realities of being a tester in a spectrum of organisations?

- Find a mentor?

Some short-term mentoring could be a good way to get feedback on what I do, or don't, have to offer.  

- Talk it through?
Simply initiate conversations with other testers, or with hiring managers, to gain a picture of the wider "market" and how I compare to it?

Definitely some things to work on here.