Category Archives: BBST Test Design

Be careful with software updates: example for osx text to speech feature

Reading Time: 1 minute

TL;DR

This blog post is about how OSX update affected text to speech feature that I use as  proof reading aid for my blog posts. I will propose a testing charter based on this experience.

As I am not english native speaker, in order to avoid basic grammar errors in blog posts, I always reply blog post using OSX text to speech feature. This proved to be very useful.

In wordpress editor, (html page) I selected blog post (using keyboard) in paragraph chunks, then I clicked right mouse (using touchpad two finger gesture) and selected speech => Start speaking.

No speech.

In order to decide “Do we have a problem here?”, I used oracle comparable product (FEW HICCUPS by M. Bolton), OSX Notes.

Using same steps as in WordPress, there was speech.

Idea, WordPress editor is html/javascript editor, so ttx can not read html?

Idea, what recently changed with my laptop?

Yesterday I upgraded OSX to Sierra version.

Lets check if state of ttx OSX feature (in the end, this is just another program) is affected with upgrade – BBST Test design (by Kaner and Fiedler).

System Preferences => Accessibility => Speech

Oh there is unselected option, “Speak selected text when the key is pressed”. I enabled Command + Z combination.

Go to wordpress editor, select blog post paragraph, hit command + Z, it works!

Try option with context menu described previously, it worked!

We are taking for granted that complex upgrades, such is OSX upgrade, should work out of the box. In this example, ttx speech was not broken, but was set to initial state because of new configuration option.

I described oracle heuristic comparable product (one C from FEW HICCUPS), and initial values  quick test idea.

You can learn about them in BBST Foundations and Test Design courses.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Google maps offline mode scenario testing

Reading Time: 2 minutes

TL;DR

As I was traveling to CAST2016 in Vancouver, and roaming cost for 1MB of data traffic using my Croatian operator is 10 US$, I decided to use Google maps in offline mode.

Why you did not buy Canadian sim card with data plan? I investigated that option, and I could not find on web simple explanation how to do that. Also, doing business in Croatia is rather complicated, and putting that expense on my company account would be very complicated. So I decided to go with Google maps offline option, and using wi-fi where possible.

Day before travel day, I downloaded Vancouver map. In iOS Google map application, you need to search for Vancouver, and select in main menu offline areas. Touch big blue plus sign, and hit download.

Offline content is valid for one month.

First surprise is that route feature is only available for Cars option, bus and walk is not available. My heuristics is that this is because of security implications for walk option. Google only wants to guide you for walking using up to date information. For example, you do not want to go through some riots area.

Bus option is not available because bus timetables need to be up to date all the time to have the most accurate routing.

My current location works in offline mode, but only when airplane mode is off.

And one interesting scenario (BBST scenario testing) happened. On Paris airport, I enabled data roaming, because those prices are acceptable (Croatia is part of EU). On plain I switched on airplane mode on, with data roaming enabled. Next stop, Toronto, Canada. And guess what, IT IS NOT POSSIBLE TO TURN OFF DATA ROAMING WHEN AIRPLANE MODE IS ON.

I was afraid that I will get some data traffic after I turn airplane mode off. But, luckily, my phone was not able to connect to any of Canadian mobile networks, so I could turn off mobile data roaming without any cost.

Scenario testing is very important part of professional testing activity. It is unfairly called manual testing, giving the impression that it is low skill activity.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Quick test idea: try inverse feature

Reading Time: 1 minute

TL;DR

In this post I will explain one quick, but very important, test idea. Inverse feature.

In order to avoid complex mathematical description and proof, let’s use simple plain explanation. Inverse feature does exactly the opposite from the original feature. And operates on output data of the original feature. Ad in the end, we should get back original data.

Here are few examples.

Every browser has zoom feature. Let's zoom in for 10% of this blog post, and again, zoom out on same blog post for 10%. You should view  blog post in starting resolution.

Or you have feature that exports list of users. The best way to test this feature is using import feature of users. Export users, delete them, do the import, you should get original list of users.

Inverse feature is very important quick test idea, because you can test original feature very quickly. Also, users will be very satisfied with your product if features of that product come in pairs.

This quick test idea is fallible because you can have four possible combinations:

both features work, both features fail, original feature fails, inverse feature fails.

It is important to be aware that using only this quick test method is not enough.

Which method would you use to help you in case when both features fail?

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

URL Test Cheat Sheet

Reading Time: 1 minute

TL;DR

As a reference for my future self, here is the test cheat sheet for universal resource locator.

Elisabeth Hendrickson published some time ago this legendary heuristic test sheet, a set of quick test ideas. Recently I tested one feature that had URL, so here is set of quick test ideas for URL.

This is url structure:

scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]

Here is scheme definition:

“The scheme, consisting of a sequence of characters beginning with a letter and followed by any combination of letters, digits, plus (+), period (.), or hyphen (-). Although schemes are case-insensitive, the canonical form is lowercase and documents that specify schemes must do so with lowercase letters. It is followed by a colon (:)”

Just for possible scheme values, we have explosion of test cases!

As we are smart tester, we will do risk reality check.

Here is test values cheat sheet for modern web application:

scheme: http, https, mailto, ftp, file, data, ftps, tel


various values:

http://user:password@tentamen.hr:80

https://www.tentamen.hr/tools/new

https://en.wikipedia.org/w/api.php?action=opensearch

https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#URLs

 

All those values must be parsable by the web application which means that http 500 error code must not be returned.

I missed mailto which caused 500 http error. This is the reason why I wrote this blog post.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Happy vs. Alternative path

Reading Time: 1 minute

TL;DR

I often hear from developers their definition of done: “Feature is implemented and I have done unit testing that covers happy path”. In this post I will try to elaborate what is on the other side of happy path.

So why they only test for happy path? Because in order to test “alternative paths” you need to have software testing knowledge background. Something like BBST series: Foundations, Bug Advocacy and Test Design. Because testing alternative paths is not SO EASY (like happy path).

And often, alternative path testing is synonym for ALL OTHER TESTING. Like scenario testing, domain testing, risk analysis, taking out requirements from other people’s minds (not literally), non functional testing, …

Which is wrong. For example, functional testing is usually a synonym for feature testing. You test one feature independently from other features. And very often testing stops at that point.

But your product is a sum of all features, your users will use several features in combination just to do one task with your product. And here scenario testing comes into play. And this is heavy lifting, to come up with scenarios that user will possibly trigger. Requirements can only capture just few of those scenarios, which are excellent starting point for software tester to come up with more real scenarios. And that is just scenario testing.

So stop the madness with abandoning your QA team. For those “alternative paths” you do not need developers that know how to code. You need software testers.

And QA is not Quality Assurance, it is Quality Assistance.

 

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather