Monday, 28 May 2018

Homework with VS Code

Some folk have not yet heard of Visual Studio Code
It's a brand new lightweight code editor from Microsoft that can run almost anywhere. And the surprise is it's not chunky and lets you code fast.


Up till now I have been learning Python properly, but today it's a job interview C exam question, so python is out, and C is in. Here are the steps.
1. install VS code
2. install mingw
3. install check unit test framework
4. coffee (or so it was thought...)

If you have not yet, install Visual Studio Code, the download is small and it's totally not the beast Visual Studio is, it has some nice plugins, don't go to town, but the Python plugin is one I do recommend(, although Pycharm ) is also pretty awesome). Add the C/C++ plugin for now.
// main.c

int main(void)
Getting this far brings back memories :/

Next up is MinGW-w64. I'm going to focus just on getting it to work with VS code. go to the mingw site, it will point you to MinGW-w64 on sourceforge for the download on Windows.
I managed to find a pretty good guide, but for my purposes I was missing some of the runes I had not yet learned.
My build task looks like this
"tasks": [
"taskName": "build compositer",
"type": "shell",
"command": "C:\\tools\\mingw-w64\\mingw64\\bin\\g++",
"args": [
"-g", "${workspaceFolder}\\compositer\\main.c", "-o", "${workspaceFolder}\\compositer\\main.exe"
"problemMatcher": [
"group": {
"kind": "build",
"isDefault": true

Next we get the test (checking) tool up before writing any code at all even.
Go to and find the download link.

This is where it all fell apart. check uses autotools, which come with cygwin.
cygwin is just a confusing piece of software without an uninstaller. I keep on removing it, forgetting and then installing it an having huge regrets, ad going back to Visual Studio. so the short answer, is that it got frustrating at this point. And I caved in.

Rewind. Get Visual Studio Free

After a morning of struggling, I just used my hotmail login details to go to . Then add the free developer pack to your Microsoft account, and viola, you get to download Visual Studio 2017 instead. It's limited, but comes with tool-chain for C/C++ and a debugger that I am familiar with. Just add the plugin or pack you desire, there are a good few, all free. After wasting Saturday morning to get this far, I used the afternoon to progress the job of writing a really tiny program for a job interview test.

Sunday night deadline

I had wasted much of Saturday morning with a old version of Visual Studio 2013 which kept crashing out in the debugger when MSVCR120D.DLL did something it was not"designed" to do. I installed the Microsoft redistributes, many times, but the dll kept on screwing up, but just in the debugger. I think it was heap corruption in my program, but the debugger was not giving me any clues, so it was a relief to have 2017 installed and debugging just peachy. Fixed my pointer management code and made progress - right up until 1am.

A task that was supposed to take 4-8 hours ended up taking more like 12. I am not the only person who this happens to. But a few lessons.
1. C pointer arithmetic is easy, but remember to cast to a char first.
2. Do not comment your code. It's counter productive when you have to change the code later.
3. TDD is very time consuming, but it lets you continue working, long after you are too tired to code.

Friday, 25 May 2018

Rebuild your Windows machine fast

You will need 2 things (3 probably)
1. a flash drive 8Gb minimum
2. another working computer
3. your windows 10 installation key

In my case I could not find the key, but will share 2 ways to find it. In my case the dead computer simply had a corrupted partition table/boot file (exact verdict pending.) but was readable.
1. Go to
Don't choose the options around recovery, you want a download for another machine - choose the media creation tool option. this downloads a 20Mb application , run it, and plug in your flash drive. point it to the flash drive, and it will start downloading. This bit took about 5-10 minutes. Then it starts copying the files, also takes about 10 minutes. During this time, rip the hard drive out o the dead machine and put a shiny one in, and check the bios settings are still looking sane and can see the new disc.

2. Boot the computer from the flash drive, and start installing. While this is going on, you want to rescue your data off the dead disc, I used a drive caddy, since the only problem was corruption. In the past I used to plug the bad disc right into a secondary IDE channel on my good machine. But now we are all SATA, so cabling is simpler, but still a major mission to find power. My experience of the faffing with screwing the drive in temporarily so that it does not come to more harm, so the caddy is slower, but less trouble.

There are many many ways to do this, this one was fastest

3. Find your key, this is the good bit.
Go to
scroll down and download the 64bit version.
Run the tool as administrator.

Point it at the dead disc, and viola.

Oh, a second way to get your CD key back, is to have written it down someplace, like in a document on google drive, which you forgot you had didn't you?

Monday, 14 May 2018

A Python strangle hold

Having a look at a piece of work I built for client reflectively. I noticed that I had early on opted for a bottom-up approach to an implementation where I control a remote machine.

Bottom up is not a design Pattern

I said to myself that it was wrong to have gone that way about it, because bottom up meant starting from a windows mobile API and then wrapping it in Powershell, and then wrapping that in a Python unittest. In balance it's a bit light on Python which means anyone reading or maintaining needs to learn a lot of Powershell. The powershell scripting is managing a remote connection session across test steps. This balance is a side effect of bottom-up.

Python script ~ 300 lines
Powershell script > 500 lines
Mobile API ~ 10 lines <= where all the work happens

If I had written it from top-down and written around 500 lines of Python, it would have shifted the balance but left us with around 200 lines of Powershell and a large performance hit per step in the test because the Python code cannot cache the Mobile API remote session connections. Every test probe or prod, would be a round trip and would need a new connection. My biggest regret is not sticking to my guns and moving more code to the Powershell side because it's easier to manually run pieces of Powershell as scriptlets when manually verifying. You could probably run python functions in the Python console/ide as manual steps too, but I need to stick to my expertise more often in future. Anyway, the Python code balance is annoying because maintainers do have to learn 2 languages. Top down would have been easier to maintain by nature.

Strangle Hold

I am enjoying the Python learning, which was part of the reason for my bottom-up by starting in Powershell, and learning the Python language all over again in the background while I worked my way up. I could not have commanded the Python well enough to start there I suspect. Quite happy with the outcome in terms of the refreshing of my very stale and super-basic Python. But would do it the other way if I did a similar project again.
Wierdest thing is that Python seems to be language lawyer territory in terms of style far more than in terms of looks than for example C code is lawyered over, where performance is 50% of the game. Snakebite on the other hand is 50% of the Python game. By snakebite I mean pretty pythonic code. A lot of time is spent making code look like it is pretty. Python actually has keywords and syntax (above and beyond the indentation rule) to help you make the code pretty. A pity because the excellent pylint tool is actually two tools in one, style and grammar, and because pylint parses the code and the references or lack of usage, which you don't want often. And so I find myself disabling some of the pylint warnings that are not so much about code prettiness, but rather syntactic rules, which should have been totally separated in the debate. I want my code to compile, before I want it to look like it wants to be eaten!

Thursday, 23 November 2017

ffmpeg animated gif one-liner

Commandline to make a quick demo easy and to just by default make it autoplay in for example facebook. sorry if you have seen this all before, but this blog is my braindump.

.\bin\ffmpeg.exe -i .\cbc.wmv -b:v 50k -r 2 -y -ss 2.000 -t 11.000 .\cbc_T.gif

-r 2 = 2 frames per second
-b:v 50k = 50kbits bitrate need to add the k, and need to be specific that the rate is a video rate with :v
The bitrate did not have a significant impact on file size.
-ss = start from
-t = duration to convert

Hope this helps the next person. note, there are loads of similar blog posts, but had to capture some of the more salient parameters, because ffmpeg command parser often just ignores a parameter it cannot parse, so beware typos.

Joining clips

To join 2 clips -is a bit problematic in windows because the ffmpeg separator | character has a special meaning in dos, so I found the easiest was to create a response file.

file y:\20171122_173829.mp4
file y:\20171122_170515.mp4
file y:\20171122_173829.mp4

Save this text as files.txt (note that this file expects the path separator "/" not "\" , for some reason the [drive:\] protocol is fine with a "\", but paths must use a "/".

and then use the concat argument

C:\Tools\ffmpeg\bin>ffmpeg.exe -f concat -i .\files.txt -an -c copy -y .\20171122_173829all.mp4

notice use of -an to kill the audio track off

Add Audio

Lastly, to add and use an audio track using -shortest
ffmpeg.exe -i .\20171122_173829all.mp4 -i elevatormusak.mp3 -c copy -shortest -y .\20171122_173829final.mp4

Wednesday, 1 November 2017

ffmpeg file compress

I really easy trick to shrinking files by reducing them from 30fps to 10fps

..\bin\ffmpeg.exe -i .\largerfile.mp4 -r 10 -y .\destination.mp4

I'm getting about 20x reduction in filesize - and resulting vidoe is very "skippy", but fine for desktop shared recordings that don't animate.

Monday, 23 October 2017

Which Test Cases to Automate

I've decided to blog a bit about my day-job, well, my career and passion really. Software testing, but the kind that makes sense, automated regression. But first and foremost a warning, when a computer validates some software, that's not called testing at all, it's called checking. See here for a bit more on why.

With that out of the way, lets move on. Automating anything is expensive, automating a test case is not a silver bullet, because a computer cannot validate things like a UI layout making sense, or even an API function call rejecting a parameter value either for that matter. Sure we get frameworks that test for UI changes in web pages and in WPF and other forms based applications. But when controls move and we all know that a UI changes cosmetically very often, that incurs maintenance cost. Tools exist to reduce that cost , but they only do so in very specific ways.

Likewise for Automation or Test tooling against public APIs. "Apps" on the internet are the main case here, but this also applies to locally consumed API's not just the web, and all the new kinds of web services available today, its a crazy farm almost. Just about everyone has a web service these days, or at least an API; and since that surface is the really high value customer interface, it's the best place to do testing and best place to automate at the same time. A test script using an API cannot just validate assertions in your test spec, without some skill in writing that script to be maintainable or scale well. Without going into design stasis, arguments about specs, or test frameworks, let's be really Agile; do the parts of the job we can get most early value from first and foremost.

But which test cases do you convert? From that huge batch of analysis done when you looked at this from a manual test perspective last year. The boss wants you to automate all of the things. Now.
Based on my inputs and the way we started doing this, one of the grads came up with using Excel. I'll link the sheet below, but first I'll explain what all of the columns mean.
Test ID A unique test identifier (optional) A pretty basic thing, but very much dependant on your test management tool choices.
Name Description of the test - short is better
Easy to script How easy is it to write a test script for this case. Be pragmatic in your estimate. Give it a 5 if it's trivial , but if it's impossible to, give a 0 (zero)
Manual time cost The amount of interactive human being time it takes to run this test manually, if the test suite has got lots of setup required, count that time separately, only count time for this test in hours needed. If tests tend to take a few seconds to run manually, adjust this accordingly so that quick tests get a 1 and painfully long to run tests get a 5. Also do not count waiting time, if for a file to copy that perhaps takes 30 minutes, that time is not counted.
Data/Table driven Is this a test that really benefits from boundary testing and has multiple simple input output classes that take time to cover most of the meaningful combinations fully if done manually. If Yes, give it a 5 , not really, give it a 1.
Cost of Failure Will it hurt the product and crate risk if this test fails. If Yes, give it a 5 , not really, give it a 1.
Likely to regress Is this case likely to catch useful regressions caused by code or integration changes? If Yes, give it a 5 , not really, give it a 1.
ReUse Is automating this a test now, going to help you write other tests by providing a library of helper functions that will grow your coverage eventually? If Yes, give it a 5 , not really, give it a 1.
Priority Does this verify anything a manual tester would have to do anyway before most other testing commences. Do testers test this functionality very often? In other words, is this a test that has to run early in the cycle. If Yes, give it a 5 , not really, give it a 1.
Some things to notice here, I use a very low resolution scale of 1-5. Higher granularity in the question scales actually end up take much longer on average for a user to guess at a value, and let's face it, this is a game of educated guesses or estimates anyway. It's best if 2 people do this process together. Some of the columns only benefit from entering a 1 or a 5 and nothing in between, some of the columns even allow a 0. As a tester, I'd not expect you not to try entering a 0 in cases where it makes sense to, for these, the sheet will give still you a good answer out. So you can just add these all up, or give each question priorities. In another posting, I'll share the spreadsheet template and the weightings as well.

This only works well after you have obviously captured half a dozen cases and looked at them in relation. Remember, don't spend too much time on each row, this is a planning activity only.

Wednesday, 27 September 2017

Lean Coffee Meetup

A "Lean Coffee" under the Meetup banner is an agile interpretation of a networking event for software testing professionals in our case. Because time is precious the monthly morning coffee is a very intense and quick-fire format. Final moments close with a summary where everyone states one thing they learned. Results here may vary, and I made notes only for our table which was half of the 12 or 13 odd who attended. A voted Q&A format with 8 minutes per topic presented the following ideas.

  • How to develop new testers. Getting up to speed suggestions. 
(Test mentoring, timeboxing, domain learning and process learning discussed)
  • Is the programming language used to write automated tests important?
(pros and cons for Java,Ruby,Python and importance of test fixtures were covered. As well as scale-ability and performance)
  • In a one man test team, how do you plan?
(3 amigos, division of responsibility, assesment of the security risk, assesment of scale risk)
  • How to get others to see your side of a test failure?
(describe the risk to business and cost clearly)
  • Biggest challenge in test 
(horror stories ensued)

In the meet I mentioned a link to this clip to share with people

If you want to join up with us, please follow this link and sign up.