Probe Testing in The Martian

The story from The Martian about testing the probe is worth a post (some scenes and phrases are skiped).

10 Mac OS X Terminal Commands for Testers

I really like terminals, command lines, bash scripting etc. They are handy and easy way to automate some routine tasks in my everyday work. Thats why after I saw article Eight Terminal Utilities Every OS X Command Line User Should Know I decided to write something like this, but for testers.

These are OS X commands, but some of them are also working on Linux systems and Windows (if use some UNIX-like terminal like Babun, CygWin or Cmder).

This is defently not the complete list. Here you can find the complete list of all OS X commands, but this post is about my favourite and frequently used (almost) commands.

1. alias
It's the most useful command of all – it allows to replace some command with a short word. That means, that if you have some long command that you regularly run in the terminal you can assign alias to it and use some simple short substitution. For example, you always monitor application logs using tail -1000f application.log, but instead of writing this whole string every day you can create alias like logs and write only 4 letters into the command line. Moreover, you can use autocomplete with aliases (TAB key), just like with regular commands. You can see my previous post Bash Scripts for Working With Documentation for more examples about using alias.

There is one trap that many beginners fall into – you can just type following command into your command line:
alias logs='tail -1000f application.log'but in that case you create alias only for your current session. That means it'll disappear after you close it. To create permanent aliases you need to put them into specific file, which is usually ~/.bash_aliases. You may also need to add following code into your ~/.bash_profile file (you can add it just to the end):
# Aliases
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
And you need to restart your session for taking these changes into use (just close-open you terminal or exit-login to server).

2. crontab
This one allows you to automate some commands. For example, you have some documentation on SVN (or some similar version control system) and you need to update it regulary to get the latest state. You can add following job into your cron schedule, which updates SVN directory every 10 minutes:
*/10 * * * * svn update ~/Documents/SVN-documentaionTo open crontab editor, where you can insert previous command, you need to run:
crontab -e(or sudo crontab -e if you are not under admin user)See Ubuntu CronHowTo article for understanding what are these asterisks mean.

3. grep
Grep is a very powerful tool for finding strings in any output (log files, query responses, script output etc), that you can perform. I use it to filter log files. For example, I can get all rows, where ERROR word is present:
tail -1000 application.log | grep ERROROr I can get all rows, where todays date is mentioned in the beginning of the row:
tail -1000 application.log | grep ^23.10.2015Grep works with regular expressions, so you may need to understand them to perform some complex filtering, but simple search by one word may be enough for you.

4. find
Find searches files in directory. Again, in my previous post Bash Scripts for Working With Documentation I wrote about scripts for finding documents by name or by content – the whole funtionality is done by find there. So I use it in by daily work for finding documents with required data. You can find (ha-ha) a lot of examples in the following article: Find Command in Unix and Linux Examples.

5. open
Simply opens a file, a folder, an application or URL, just as if you had double-clicked the file's icon. It's useful if you first have done some complicated search of required file (using find), got the path of it and open it (with default or some other application).
Second useful case – opening directories (especially hidden ones). For example, open . opens current directory.

6. awk
AWK is actually programming language designed for text processing. It can be used as reporting tool and I usually use it to beautify my scripts' output – for example, to color some words. I am not sure that it's useful for everyday life, but if you want to write your own script, it better has meaningful output.

7. scp
It stands for Secure Copy. It is useful for somebody who works with servers (application updating, logs monitoring etc). With this command you can copy files from one server to other, or from server to your computer and vice versa. You can find some examples in Example syntax for Secure Copy (scp), I copy here one of them:
scp your_username@remotehost.edu:foobar.txt /some/local/directory
8. pbcopy / pbpaste
These two commands may save you from endless scrolling: pbcopy copies output to the clipboard, pbpaste inserts content from the clipboard. For example, you have some log file, that you want to investigate on your computer in you favorite editor. The simplest way is to copy its content to clipboard and paste it into another document. With these commands you don't need to scroll anything to select the text, or google "how to select the whole text in vi" or anything like this, just type:
cat application.log | pbcopy
9. screencapture
Honestly, I don't use this command in my daily work, but I have a feeling that it's important. It does what it says – captures the screenshot. You can set time delay to it and you can write a script for time lapse (taking screenshot every 10 seconds or something like this). It just happens, that I use screenshots quite rarely in my work, but I guess it can be interesting command for testers, who use them a lot.
You can see examples here: Take a screen capture from the command line.

10. sips
Last (and least) one is SIPS – Scriptable Image Processing System. You can use it for processing files, for example, resize all PNG files in current directory to 1024×768 (ignoring aspect ratio):
sips -z 768 1024 *.pngAgain, I don't work with screenshots and picture files a lot, but it's the simplest and the fastest way (and cheapest one, comparing to some Photoshop) to process a large amount of picture files (or if you want to work with pictures in your bash script).



Don't forget the alias! You don't need to know all these commands by heart – you can just figure out how you can use them and which parameters suits for your case, put it into the alias thereafter use only short and nice commands.

BONUS!
telnet towel.blinkenlights.nl
This one is just for fun (once you've already opened the terminal). Some guys did pretty awsome ASCII version of Star Wars IV. You can run it over the Telnet. I don't know how long does it last – I've watched 15 minutes and Luke only meets Chubaka and Han Solo, so I guess they did the whole movie.

The Beatles Stencil "All You Need Is Test"

Recently I participated in stencil workshop. For those, who don't know what stencil is, there is Wikipedia article Stencil Graffiti.

First of all, I needed to choose the picture, that I want to make. I had following requirements: it should be easy to make (as I had only one evening and no experience), it should be about testing (as I wanted to put this picture on my work space wall), it should be legendary, it should be funny.

A week after workshop I had vacation in England, so somehow The Beatles were natural choice for me. In addition, they are also known as Beetles (=bugs) and you can find suitable quote in their songs for all kind of situations. So I decided to make a picture with text "All You Need Is Test" with their outlines.


Third version was chosen. Next step is to print picture on 6 A4 pages (size of my canvas), put them together with tape and start to cut areas that need to be painted:


Cutting is the most hard thing in the whole process. Especially, cutting small details, as Lennon's eye or McCartney's nose.


Fully cut template gives a lot of satisfaction:


Now you need to choose colors (also not easy part).


Finally, you need to put colors on canvas, using the template. It's the second hard part, where experience is very useful. You need to put right amount of paint (to avoid smudges) and you need to put right color into right cell, avoiding mixing the colors.


It's possible to put many layers on one canvas (so you need different cut templates for every layer), but my work had only one layer.

The result is on the top picture (that picture is on my work space wall now). But the colored template itself is also cool:

Song About Test/Check Automation

We started to do [test | check] automation in our project. And here is a perfect song about it, written by Rudy Clark and released in 1962. The video also makes perfect sense.

But its gonna take money
A whole lotta spending money
Its gonne take plenty of money
To do it right child

Its gonna take time
A whole lot of precious time
Its gonna take patience and time, ummm
To do it, to do it, to do it, to do it, to do it,
To do it right child

The Cartoon Tester Vol. I by Andy Glover

The Cartoon Tester – pretty good book of Andy Glover's cartoons about software testing. All cartoons can be found in his blog, but book is cooler: more organized and more pleasant to read.


"I've checked every square foot in this house. I can confidently say there are no mice here."
Making fun of serious things is always healthy and good for the field, so I am glad, that there exists such book about testing. Sad, that there is no paperback version – it would be a great gift for tester.


It's very nice to have this book on my e-reader, so I can always read/see some comics when I don't have much time for reading, but need to somehow entertain myself.


"Look! They've got it all wrong. Mice can get into the house in many ways. Through windows, drains, the cellar, need I go on?"
You can buy book at LeanPub or Amazon, download free sample there or read comics at Andy Glover's blog Cartoon Tester.

Photoshop Can't Open Its Own Files

Sometimes my Photoshop doesn't open its own files on the first try:

Heisenberg Principle In Testing

I've found unexpectedly the Heisenberg principle in testing:

Software Testing as a Social Science by Cem Kaner, 2008

Bad and Good Humor in IT

Here are some video sketches which are somehow related to IT.

Lets start with bad humor. I don't like this kind of attitude to customers: yes, they often don't know what they want; yes, they often don't know how to properly name things - but the mission of IT guy in this situation is to understand what is actually needed, not to prove, that customer is stupid and doesn't understand the topic.
This sketch shows how unprofessional IT "expert" actually is, not how stupid requirements customers order.

This one is better. Not very funny but at least accurate and not offensive:

And these are really good: 2 parts of If Google Was a Guy:

The Worst Hacking Scenes in Movies

About Planning

Technical Support

If God gives you a watch,
are you honoring Him more by asking Him what time it is
or by simply consulting the watch?
A. W. Tozer quotes

Unfair work in tech support means that I should explain documentation just in other words.

There is a beautiful specification document with detailed descriptions, but users (in my case not just anonymous but technical users with years of experience) just don't want to use it or don't understand. So they ask question, I open the document, find the answer and give it to them. And every time I feel like they are writing some facebook interrogative status instead of googling it. It is not just annoying, it is time wasting.

So if you want to work in tech support you should just deal with it - it is not the thing that you can avoid or improve.

Out Of The Box

Very useful quality for tester - thinking out of the box. Tautology, but it helps to find weaknesses that are able to find out-of-the-box thinkers, so there is a chance to prevent failures and crashes.












And very good one about how in-the-box thinking is being grafted to us.

Time To Go To University

First Look Is A Fake

Can you tell what is wrong with this birds feeder? Can you list it's bugs just looking at it?

Sometimes first look of an object does not show you anything important. Look shows you that everything is correct, but it does not show what is wrong. To discover what is wrong tester should touch an object, but some testers think that it is not necessary to touch obvious things - is it possible that I can something to touch what I can not see? I can already tell you that I can not see any bugs. But here is the actually "feeder":

The Importance Of Review

The front view is not always as bad as offscreen view. And sometime tester can find a problem only looking into 'other side' of the product, where can be hidden messy code. Why messy code is bad for the project? One big reason - because it is more likely to do mistakes in it. Second reason - because the other developer could not understand some crazy magic logic of the author.

The second reason is more important to me, than the first one. The bugs can be found and fixed, especially if place of the messy code is known, so you can pay special attention to it. But if you need to fix some bug as fast as possible and the developer of the messy code is on his vacation or being ill, at best it takes a lot of time for other developer to understand the mess. The worst case - other developer "will not better touch anything", because he can not guarantee not making other bugs.

So, if tester have spare-time, he can always do a code review.

Don't Touch Something You Don't Know