Testing In History: Part II - Functionality Testing

Here is second set of historical videos about testing. The first part was about stress testing, this part is about functionality testing.

The most interesting is the first one about the carpet. They actually tested a carpet with the whole street in San Francisco! I have doubts about is it a functionality or stress testing - haven't decided yet.

British Pathe doesn't have normal embedding system, so all links will be opened in their website.

Carpet Tested In Gold Street (1962), 00:59	Telephone Tests (1953), 01:28
Splitting Hairs (1949), 01:15	Cigarette Testing (1949), 00:42
Gun Proofing (1951), 02:22	Petrol Tests (1952), 01:56
Mirror Velvet (1954), 01:09	Testing Bowls (1952), 00:46

See also other parts:
Testing In History: Part I - Stress Testing
Testing In History, Part III

Testing In History: Part I - Stress Testing

British Pathe put an enormous archive of historic clips into internet - www.britishpathe.com. First thing that I've searched there was "testing" and got 57 pages of clips (2834 results). I've watched first 10 pages and here are some interesting clips about some kind of stress testing.

They don't have normal embedding system, so all links will be opened in British Pathe website.

Toy Testing (1951), 02:02 – [Charlie] calls it a compressive stress test or something around that.	Army Clothing Tests (1950), 01:03
Bus Tilt Tests (1949), 02:37 They call it stability test. Notice how bravely chef tester steps into bus.	Testing Safety Glass (1950), 02:50 Notice how real first situation is - almost a movie.
Fabric Tests (1957), 02:53 I liked the machine for measuring how hard you can wear a fabric.	British Made - Testing Army Motocycles (1915), 02:37
Science Behind The car (1950-1959), 09:55 – And now the question - will she starts?	Bed Testers (1960), 01:48
Furniture Research (1953), 01:22	A Tragic Test (1931), 01:08 And the final unsuccessful one.

See also other parts:
Testing In History: Part II - Functionality Testing
Testing In History, Part III

Photoshop Can't Open Its Own Files

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

q - Text as Database

Nice software, that allows treat text as database - q Text as data.

Shortly, it allows to perform SQL-like queries in tabular text. For example, we have some file.txt with following data:
1 646524 some_text
5 878060 some_other_text
9 676876 some_text

And if q is installed we can perform SQL query like this (where cN is column number):
q "SELECT sum(c1), c3 FROM file.txt WHERE c2 > 600000 GROUP BY c3 ORDER BY 2"

The output will be:
5 some_other_text
10 some_text



Very simple (for those who knows SQL) and convenient way to work with big files with tabular data.

In our project we use it to obtain data about slow java methods in our application: once a day automated script extracts data about execution time of methods from logs and then aggregates executed text with q to group methods and show the slowest and most frequent of them (and then we use AWK to show final result in HTML table).

So, It's good to know about this tool for those, who encounter with tabular texts.

Heisenberg Principle In Testing

I've found unexpectedly the Heisenberg principle in testing:

Software Testing as a Social Science by Cem Kaner, 2008

XRebel - Revolution in Exploratory Testing

In April Estonian company ZeroTurnaround (authors of JRebel) releases beta version of XRebel. I think it's the most useful tool for testing that I ever had!


XRebel is a -javaagent JVM plugin, that shows you 3 types of data (at least, for now): exceptions, session data and SQL queries. First one is easy - it shows exceptions that were thrown by your application (even if they are not visible in GUI). Session data (attribute name, value, value size, value size difference compared to the previous state of the session) - OK, maybe for someone it is useful.

But the last one - SQL queries - is magic. It shows all SQL queries with parameters that application does in a session. And it shows not only SELECT queries, but also calls for functions (call some_package.function(null, 'some parameter', 13, 'en', null)).
Possibility to see queries with real time parameters without digging a code makes testing way more faster, easier and more complete (sometimes it's not possible to control all conditions, but now you can see them). I think this tool is revolutionary for exploratory testing - now you are able to understand the flow of data with exploring application, not code.

I have 13 SQL queries in session that were executed in 586ms (you can see queries by clicking on the icon);


Total size of session is 887.7 KiB, difference compared to the precious state is +14.3 KiB;


0 exceptions;

Send feedback (it's possible to send log file);

Settings.



Some nice points that are not related to the functionality:

• very easy installation - you should just download XRebel and include it't path into JVM startup arguments
• fast feedback - you can send questions, suggestions, bugs to ZT about XRebel and they answer very fast, which is nice
• daily updates - there are available two builds: stable version and nightly build (which updates every day), so they improve tool very fast

You can't simply download it yet, but you can request a private beta invite and if you are lucky - can use beta version for free for one month.

How Google Tests Software by James Whittaker, Jason Arbon, Jeff Carollo (2012)

I read it in Russian translation

I really-really liked it. It's the most interesting book about software testing that I've ever read (considering the style of language and the amount of useful or enjoyable information).

It gives very good picture about what does it mean to be a good tester no matter where or in what conditions.

«A tester finds a bug and takes a moment or two to savor it. Seriously, this is important. Not only are we allowed to take a moment to enjoy the fruits of our labor, it’s important to understand subtle nuances of the bug and the circumstances of its appearance.» (James Whittaker)

The cover of Russian edition is brilliant: it shows fundamentals of Google quite precisely

Sometimes seemed that there is too much text about roles, hierarchs and responsibilities in Google. The idea about structure of workers is too detailed and takes a lot of space.

But the list of things that I liked is much longer:

• short interviews with key people – you can find there interviews of google people with different roles and positions (which are connected to the testing) and with different experiences and opinions. Reading these interviews I had an idea that it would be interesting to read a book about unsuccessful projects and experiences in Google.
• parts about interviewing candidates on different testing roles – very useful information which helps to understand who big company (not necessarily Google, but actually every normal company) wants to hire and what they are waiting from the good candidate.
• Design Docs chapter – good chapter with nice suggestions such as grammar correctness: «sloppy work that does not bode well for the code they will write later. Don’t set a precedent for sloppiness.»
• the idea that «Testers are there to make developers more productive» – actually my previous post All Participants Work For The Benefits Of The Project is about it (which was written just before reading this book).
• the idea, that testing is privilege that can afford only big and important projects – «quality is not important until the software is important» (Alberto Savoia)

I agree with authors that this book is useful for experienced testers (not for juniors). It assumes that reader has already thought about some software quality problems and maybe even have found some solutions – only then you can do justice to Google's solutions.

«Quality has to be built in, not bolted on, and as such, quality is a developer task. Period. This brings us to fatal flaw number 1: Testers have become a crutch for developers.»
«The second fatal flaw is also related to developers and testers separated by organizational boundaries. Testers identify with their role and not their product.»

About other fatal flaws you can read in Google Docs: How Google Tests Software.