Would it not be nice, if there was such a tool for Macintosh?

It basically combines the feature of the “tail” command to continously display the last entries of a given file on the screen with the “grep” command, which searches the input files for lines containing a match to a given pattern list and finally plays a sound file via afplay, if the pattern is found.

Command

Richard also has a blog post up, which contains also a link into his Github repository.

Next level

That command is working locally. But the log files I use daily are on a remote server, a sandbox in my case. There are no sound files, no audio player and even it there were, its of no use, if it beeps in the server room. Might scare some admins, if it randomly beeps though.

Plus I also don’t want to install stuff on the sandbox. We delete them on a regular base and make new ones. Installing stuff would be another preparation step, which costs time.

I was wondering, if it was possible to use my local Macintosh files and hardware and started to adjust the above solution.

The Benny Hill theme

Lessons Learned for me

First, we are a global, intensively knowledgable community. As so often in development, someone somewhere might had the same obstacle and can help you out. Or s/he has the right skills to solve your problem. This was an exercise in tester pairing btw.

So reach out and connect. It can only be a win win situation.

Second, if something troubles / irritates you enough, it might be worth to investigate and automate it.

Yes, it can be called automation. We created a small line of code to help us in our testing work.

Third, remember that we have more senses in our portfolio than “just” our eyes, to watch what the software is doing.

Orientation is one of the big features of the current device generation.

Portrait, portrait upside-down, landscape left and landscape right are “strongly recommended”:

Important: It is strongly recommended that your application support all orientations. This includes portrait, portrait upside-down, landscape left and landscape right. iPad apps that require an orientation must support both variants of that orientation.

Does it support different display modes? How does the app (application) handle them?

“The trick is to keep the experience consistent in each view, allowing for a seamless user experience when switching views.” (Quote)

Look at the example given at the website, the color palette looks okay in landscape, but in portrait it takes up a lot of the available space.

Some apps explicitly decide on one kind of mode.

*This has benefits for the developer:

– UI elements are created for one mode, e.g. “Open” is always at the same place.

– The arrangement, field size, font and order of elements don’t need to be checked as how they look in the other mode. Less developing and/or design time is needed.

– Better overview (“guiding”) of how the user will use the program (paths).

Let’s assume there is a user story which consists of only four action buttons:>>> Open, Change, Save, Close <<<

A) For one mode (p=portrait), there is one path (regular use, no tester mind involved).

Open (p), Change (p), Save (p), Close (p)

B) With two modes (p=portrait, l=landscape), there are 16 paths:

Path

Open

Change

Save

Close

1

p

p

p

p

2

p

p

p

l

3

p

p

l

p

4

p

p

l

l

5

p

l

p

p

6

p

l

p

l

7

p

l

l

p

8

p

l

l

l

9

l

p

p

p

10

l

p

p

l

11

l

p

l

p

12

l

p

l

l

13

l

l

p

p

14

l

l

p

l

15

l

l

l

p

16

l

l

l

l

– Each single action can be executed while the device is either in landscape or in portrait mode.

– The combination of actions can be done in either mode: “Open” in portrait, turn to landscape, then “Change”, turn back to portrait and “Save”, last turning and “Close”.

*This also has disadvantages:
– It takes away from the user experience.

Users use the device in any orientation they like. The majority (?) of apps enable this specific user experience, which is a unique selling point of the device.

– Inefficiency, wasting of potential: Sticking to the “wrong” orientation (depending on the app and its purpose). Example: Sticking to portrait mode might not make use of the “wider” landscape screen.

Audio:

Does it support audio? Can it be muted? Can it be adjusted? Can it be adjusted with the device volume sliders? Does it bring its own volume control? If yes, can both be used together? Using the device volume slider moves the app volume slider? Can it be automatically adjusted? E.G. when phone calls come in? When overlays happen? Can it handle headsets or other jacked in audio devices (stereo set, car jack?).

Communication:

The communication part of the heuristic is from Tobias Geyer (@the_qa_guy); he mentioned it in a comment, but it is definitely worth to be included; kudos to him.

– How does your application behave if the network connectivity suddenly drops? Will the user loose data; will the app crash or hang?

– Will the app recommend a user to download a 5 MB feature pack when they’ve only got GPRS coverage or will it wait until they’re logged into Wi-Fi?

– What about the server side of things? Will it cause problems if the IP address of your device changes between requests?

– How does the app behave in airplane mode?

– Does the communication have to be secure – and if yes: is it? Think of network sniffers, proxies …

– Is the app using the network connectivity economically? Does it cache data locally or is it requesting everything from the server? Not everybody has unlimited network traffic.

– Is it possible to make your app work with a test system or are all requests hardcoded to your production system? This will affect testability a lot…

Overlay:

What is overlay? Overlay is the message pop up of one app, while the user is in another app.

Does it support overlay? What other common apps use overlay, that will *most likely* pop up? Skype? Facebook? Other chat tools?

How does it handle the overlay? Could there be data loss for the user, when the overlay happens? Is there a choice for the user to ignore the overlay? Is there a timeout for the overlay? What happens, when the timeout comes? Will the overlay disappear? Or come back in x minutes?

Origin: The idea started on twitter (24th September 2010) with a question from @Siggeb: “I am testing a new cool Twitter client for the ipad; give me some test heuristics.” At that time I quickly sketched PAOLO and now I found the time to fill it with some life.

Does it support different display modes? How does the app (application) handle them?

“The trick is to keep the experience consistent in each view, allowing for a seamless user experience when switching views.” (Quote)

Look at the example given at the website, the color palette looks okay in landscape, but in portrait it takes up a lot of the available space.

Some apps explicitly decide on one kind of mode.

*This has benefits for the developer:

– UI elements are created for one mode, e.g. “Open” is always at the same place.

– The arrangement, field size, font and order of elements don’t need to be checked as how they look in the other mode. Less developing and/or design time is needed.

– Better overview (“guiding”) of how the user will use the program (paths).

Let’s assume there is a user story which consists of only four action buttons:>>> Open, Change, Save, Close <<<

A) For one mode (p=portrait), there is one path (regular use, no tester mind involved).

Open (p), Change (p), Save (p), Close (p)

B) With two modes (p=portrait, l=landscape), there are 16 paths:

Path

Open

Change

Save

Close

1

p

p

p

p

2

p

p

p

l

3

p

p

l

p

4

p

p

l

l

5

p

l

p

p

6

p

l

p

l

7

p

l

l

p

8

p

l

l

l

9

l

p

p

p

10

l

p

p

l

11

l

p

l

p

12

l

p

l

l

13

l

l

p

p

14

l

l

p

l

15

l

l

l

p

16

l

l

l

l

– Each single action can be executed while the device is either in landscape or in portrait mode.

– The combination of actions can be done in either mode: “Open” in portrait, turn to landscape, then “Change”, turn back to portrait and “Save”, last turning and “Close”.

*This also has disadvantages:
– It takes away from the user experience.

Users use the device in any orientation they like. The majority (?) of apps enable this specific user experience, which is a unique selling point of the device.

– Inefficiency, wasting of potential: Sticking to the “wrong” orientation (depending on the app and its purpose). Example: Sticking to portrait mode might not make use of the “wider” landscape screen.

Audio

Does it support audio? Can it be muted? Can it be adjusted? Can it be adjusted with the device volume sliders? Does it bring its own volume control? If yes, can both be used together? Using the device volume slider moves the app volume slider? Can it be automatically adjusted? E.G. when phone calls come in? When overlays happen? Can it handle headsets or other jacked in audio devices (stereo set, car jack?)

Objects

This is at the moment a kind of placeholder for me. I am thinking of the developed structure, the code, the files it installs on the device, but also new ideas which might come up.

This is an interesting read, where shaped flowerpots are used to draw corresponding leaves on an iPad: ArticleVideo

Landscape

Same as in Portrait, needed the “L” letter to make a nice heuristic word

Overlay

What is overlay? Overlay is the message pop up of one app, while the user is in another app.

Does it support overlay? What other common apps use overlay, that will *most likely* pop up? Skype? Facebook? Other chat tools?

How does it handle the overlay? Could there be data loss for the user, when the overlay happens? Is there a choice for the user to ignore the overlay? Is there a timeout for the overlay? What happens, when the timeout comes? Will the overlay disappear? Or come back in x minutes?

Origin: The idea started on twitter (24th September 2010) with a question from @Siggeb: “I am testing a new cool Twitter client for the ipad;) give me some test heuristics .” At time i quickly sketched PAOLO and now i found the time to fill it with some life.