Do not keep your credit card and PIN together in your wallet heuristic

Reading Time: 1 minute

TL;DR

This post is about testing heuristic : “Do not keep your credit card and PIN together in your wallet”.

Heuristic is commonsense rule (or set of rules) intended to increase the probability of solving some problem [WolframAlpha]. Heuristic is fallible.

Captcha is [WolframAlpha]

a type of computer-administered test, usually in the form of distorted text or images, aimed at determining whether the respondant is a human or computer; used as a security measure on many websites to block automatically generated spam, since computers should be unable to respond correctly

Here is how we can apply this heuristic on capcha problem. Developer finished his captcha code. You hit Chrome developer tool Inspect feature on Captcha element, and you see this:

There is captcha question “odaberi kokice”, and three answers, radio values 1, 2 and 3 with appropriate image.

Can you apply credit card and PIN heuristic here?

Credit card is question, and PIN is radio image name. Image name contains PIN value. So it is possible, using simple algorithm, to automated answer to this captcha. In this example:

if captch_question is odaberi kokice the select img/captch-kokice.png.

In proper captcha, img src must not contain easy decodable captcha answer.

<img src="0efc2e4ab9e04bc9dc66833dbb98505438c26f5557713e53c69090b586e62c4ceff814a5def8174f5c6d417aec5c2d2d1829fafaa9d12b461b3b0fff0ab894a4.png">

Also, having more than three captcha answers helps in your fight against crawlers, spiders and robots.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Remote agile teams.

Reading Time: 2 minutes

TL;DR

This post is about using narratives in software development. I presented this idea at Brighton TestBash 2017 Open Space session. At that session we had two groups, one group was collocated agile team that is using in person communication almost all the time, opposite group was me, remote tester that is using communication tools most of the time.

We agreed on the premise:

Any software system begins as a shared narrative about a problem and the people who come together around solving that problem.

But first team is for in person sharing of this narrative (less typing), and I am for sharing that narrative using communication tools (more typing).

I do not claim that second approach is better than first one, but I think that using it, team can successfully share software narrative, along with some advantages.

Here is my tool set:

  • Jira or Github + ZenHub
  • Google docs
  • Slack

In one context, Github + ZenHub contains 95% of all information that I need to do testing. Also, communication is going on using github issues application. Slack has 5% of information. Product owner, developer and tester are all remote. So I think this is one of the main reasons why is all information typed and stored.

Because of that, I can always use tools SEARCH feature, to refresh my memory about the software narrative. This includes my own notes. FUTURE ME will read notes from PRESENT AND PAST ME.

So application domain knowledge is not LOCKED in my HEAD. This is risk for me because I can be easily replaced with another tester, but great benefit for the team and product. And this is what counts.

In another context I use Jira instead of Github. Jira has 5% of information, and Slack has 95%. In Slack we have dedicated channels that must properly named and used. As tester, you must be sure that you are subscribed to all those channels in order not to miss software narrative. Slack search feature works like a charm so I can easily travel back to the software narrative past.

Disadvantage being remote is  lack of emotions. Or maybe it is not because one emotion triggers another emotion and then the real job is not done. Also, it is possible to detected some emotions from the text context.

Conclusion? I think that remote positions are new thing of software development and this is one of the reasons why they are repealed by the traditional collocation teams.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Week 15 reading list

Reading Time: 0 minute Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

UX issue in comic book

Reading Time: 1 minute

TL;DR

This post is about my other passion, comic books. I found one UX issue while enjoying Inkal comic book.

Observe following photo:

Inkal by Jodorowski and Moebius

On the right side, my user experience was broken. Can you identify the issue?

Everybody who reads from left to right, reads comic books in the same fashion. Actually, expects that comic book panels (frames or boxes) follows that flow. On the right side, that flow was broken. Note the arrows put by the editor. Those arrows are there to define panel flow that is different from the other parts of the comic book.

Why? My test idea is that editor needed to satisfy requirement that there must not be empty space on a page.

In first past, I automatically followed left-right panel direction, so I lost the flow. I needed to stop in order to comprehend story flow.

Which is better, empty panel or uninterrupted reader flow?

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

What I learned on TestBash Brighton 2017 Open Sessions

Reading Time: 2 minutes

TL;DR

This post is about the last day of TestBash Brighton2017, Open Sessions moderated by Richard Bradshaw. Here are my takeaways.

Open session conference lets participants to propose topics they would like to discuss. This instance was a little bit different than my previous open sessions because each participant could propose only one topic and there was no voting, all topics were arranged into slots.

As you can see from the above photo, last slot was left empty for possible topics created during the open sessions and based on input and ideas received during the open sessions.

Dan Billing’s Proxy Security Surgery

This session was about security testing of vulnerable web application. It is an example of Dan’s workshop. I volunteered to be Dan’s driver while he was presenting security topics. I used Burb Enterprise on Mac, Chrome proxy switcher, and application was ticketmagpie that is available as docker image. We explored from security perspective payment, login and register features.

  • every tester gets scared when he thinks about security testing
  • security testing etics
  • always asked for permission to do it
  • we used burp in passive mode
  • Burp is Java application
  • Charles proxy is Mac alternative
Storytelling in software development

This session was my proposal and it was based on series of blog posts Software as narrative by Noah Sussman. The point is that software development is more like creating narrative. Every stakeholder has its role in novel called software development of application ABC. it was lively 45 minute discussion and I thank to all participants!

Legends of Charlie by David Christiansen

David read first two chapters from his book that is work in progress. I was there because I am currently reading book Writing the novel from plot to print by Lawrence block in order to improve my blog writing skill. And this session produced greatest takeaways!

  • scrivener is mac tool that helps writers to write a book
  • blog frequency: deep academic once a month, funny stuff once a day, experience based (my frequency for last two years), once a week
  • write draft => put it aside =>print it in double spaces => space after chapter => read it and comment
Simon Tomes testbuddy.co

We provided to Simon feedback which features we would like to have in Exploratory session tool that he plans to implement. For now I know about following tools:

  • Exploratory Testing Chrome Extension (that I use it on daily basis)
  • Rapid Reporter
Heuristics with Paul Holland

And here we were, three of us, last session about heuristics. And two of us get free 30 minutes Paul Holland (Rapid Software Testing teacher) teaching about heuristics.

  • heuristics is fallible method that helps us to resolve a problem
  • heuristics is like metadata for test ideas
  • for example Test Obsessed Test Heuristics cheat sheet: Goldilocks – Too Big, Too Small, Just Right. Goldilocks is test heuristic which helps you to create test idea for integer input box: enter number 9223372036854775807

I noticed a great number of conference speakers at Open session which is great opportunity for every software tester. I joined and listened conversation between Paul and Anne-Marie Charrett. Topic was removing testers from software development because they represent safety net for developers. Ann-Marie said that what next happens is that software developers will create another safety net.

Paul suggested that next Open Session needs to have exposed names of registered participants as a means of attracting more testers to this valuable event.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

What I learned doing open mic stand up comedy in Brighton

Reading Time: 1 minute

TL;DR

On Friday morning while I was having breakfast, I googled for open mic stand up comedy Brighton. There it was, Junkyard Dogs was the place at 7pm. I shoot organizer and email and excitement started to grow in my belly.

I have been doing stand up comedy in Croatian for six years, but only last two should be counted for. I have never done it in English. During conference breaks, I prepared my three bits and isolated punchlines that I need CORRECTLY to translate in English.Person on the right was Irish so I asked person on my left for help because he was an English.  He was happy to verify my translation. I was set to go.

I arrived at 6.30 PM. Another thing that I was interested in was to meet Brighton stand up comedians (amateurs like me). What are they thoughts and drives about stand up comedy. 21 people applied (in Zagreb we usually have up to 8 people and Brighton is three times smaller than Zagreb), and they were most of the audience (some brought relatives or friends). Also, I was interested how was open mic conceived.

EVERYBODY was extremely friendly to me. This was very important for my confidence.

Act had 5 minutes time limit. My first English act went very well. Most of my punchlines got laugh, one that were not related to English “known things” did not. That was expected, by I also wanted to execute negative test case.

I had trouble to understand all the jokes because of local accent, English facts and talking speed.

In order to do stand up comedy internationally you either have to do universal material or to do local facts material. And for local facts material, the best way is to experience those local facts.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

What I learned on Testival #28 meetup

Reading Time: 1 minute

TL;DR

This is learning report on Testival #28 meetup that was held today. Our host was again Repsly in HUB385.

There were 15+ participant with three long talks/hands on presentations and four 5 minute lightning talks.

First we had Dario Đurić from Altima. He presented how to create and test web components. I learned that Polymer is Google framework for web components. As any good framework, polymer has out of the box testing support. Polymer enables developer to couple html, css and javascript in components, making your application frontend easier to develop and maintain in TDD manner.

Marko Elezović from Oradian presented how to write concurrent integration tests for api towards the database. Language was Scala, specs was framework for writing tests. Developed testing framework runs tests concurrently. In order to do that, Marko showed us how he resolved issue where every test suites has dedicated postgres database.

Marko Varat, Repsly Inc: presented UX Testing – Product Development Sanity Check.

I learned about tools UXpin, MixPanel and FullStory, tools that help in testing UX aspects of new features.

There were four lighting talks:  Kreso from Repsly explained how Repsly successfully hired senior tester in tough market, Zeljko presented Selenium bindings in Scratch, Zoran from ButterflyMX explained which frameworks they use in order to do TDD in their  Ruby on Rails project. I presented Ministry of Testing TestSphere cards and possibilities how to use them.

 

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

What I learned on conference Brighton TestBash 2017 day

Reading Time: 2 minutes

TL;DR

This post is about my takeaways from TestBash Brighton 2017 conference day.

The testers survival guide to joining a continuous delivery project by Amy Phillips.

Amy suggested us to read two books:

  • Project Phoenix
  • Continuous Delivery.

Tester must now continuous semantics: dead canary, walking skeleton and dark lunch are some of them. In first week tester should know his project role, project deadlines and establish code review procedure.

Another book was mentioned: What is trunk based development.

Be aware of all communication channels: recurring meetings, trello, slack, github, jira,…

Catalog information that you do not know (need answers), ask same question to different people, be alert on information changes. Think about support staff as one persona that is using your application. Read bug reports!

Assess your environment and note HOW THEY DIFFER!

When you think about bug that is not resolved, think about a cost if this bug would be shipped in deploy.

Read code if you can. Even better, ask developer to explain to you part of his code. Doing that, maybe some issues would pop up!

AI language and the net by prof. Harry Collins

Oh, this was a goodie!

We have two elements for computers: the clockwork and computers as social prostheses. Every computer IS DOING LESS THAT REAL STUFF. The goal is that this become equal!

Some programs have passed the Turing test just because it was not  hard enough.

We have tacit and explicit knowledge. Every knowledge has author (producer) and critic (consumer). Objective experts should be somewhere in the middle.

There is no deep learning, there is VAST amount of data to which computes have access and they represent social machines. Complete knowledge has not yet been achieved.

Testers have important role in creating AI.

Rediscovering Test Strategy by Mike Talks

On Thursday meetup, I played with Mike and his friends Monty Python’s Flux card game (at that time I did know that this was Mike). This was my first play of Flux, before that I just read the instructions. I learned that there can be several RULE cards at the table, the only rule is that RULE cards must no be exclude (logically) each other.

Testers usually create their test plan based on previous work (experience). Mike noted that strategy is different than plan.

Testers have a lot of test ideas. We should capture them (e.g. post it), cluster them and discard ones not relevant for the project scope. With all test ideas in front of you, it is easier to find gaps in your test strategy.

Mike created Oblique Testing cards that can help you with your test ideas. He also mentioned Ministry of Testing TestSphere cards.

Testers usually have test ideas related with keyboard and mouse because those inputs are most available!

How to turn 403 into 202 at the API party by Gwen Diagram and Ash Winter

I learned about BINMEN acronym that is useful for API testing:

Boundary

Input

Null

Method

Empty

Negative

Always put less logic in User Interface!

Building customer happiness with a tiny team by Paul Campbell

Following technology stack enables them to do that with tiny team:

  • AWS
  • Stripe for payments
  • aurora database
  • happroxy
  • webmon
  • neustar/loader.io
  • opsworks
  • intercom
  • pivotal tracker
  • slack
Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

What I learned on workshop Brighton Testbash 2017 day

Reading Time: 3 minutes

TL;DR

This post is about my takeaways from workshop Brighton 2017 day. I attended Alessandra Moreira’s Agile Exploration and Michael Bolton’s Critical Thinking. Post is not an easy read.

First we had opening keynote by Kevin Harris Kick-Ass-Kick offs! It was about project kick off meeting. Here are some points that sticked with me:

  • freeze requirements
  • be prepared, do your reading
  • small is beautiful (stories context)
  • ASK QUESTIONS!
  • reveal your testing strategy (I am going to test like that) in order to get feedback
  • test on developer machine early
  • other stuff (performance, security)
  • definition of done
  • create your mnemonics

In Q&A session, I applied advice: ASK QUESTIONS! I asked audience: Have you ever been in situation were requirements were frozen in Kick off meeting?

Kevin answer was that requirement change requires new kick off meeting, but what about scenario when customer frequently changes requirements? Does that increases frequency of kick off meetings, or do we wait for “customer cool” off time?

Workshop: Agile exploration by Alessandra Moreira

I have read (and practice) a lot about exploration testing, so my goal with this workshop was reality check about the topic. Here are my takeaways.

  • We use exploratory testing to find additional problems. For me this is just extension to it, one way of using it.
  • Software testing is to provide many types of information about product to interesting parties.
  • Software testers bring to project their specific MINDSET.
  • How to do exploratory testing: heuristics, critical thinking, questioning
  • Critical thinking is thinking about what we think.
  • Weinberg rule of 3, think of three different ways to do something
  • Six honest man, 5 W questions + how.
  • James Bach session test management
  • tool for session test management?
  • Michael Bolton created spread sheet for session test management automatic report creation

We created groups of three to implement session test management on Instapaper. My group decided to test search feature and one group member, experienced with Jira Capture, made notes for our session. In cooperation we made great notes, and found some interesting behavior in advanced search feature.

 Workshop: Critical thinking for testers with Michael Bolton

Here are my takeaways:

  • Calculator test assignment. Fell in trap again, despite the fact that I have done it on Rapid software testing course
  • Testers help to remove risks that jeopardize quality
  • assumptions => state them => their become your proxy for questions => do not go too deep
  • NEVER MAKE ASSUMPTIONS!
  • We often state that our ASSUMPTION is TRUE but with NO EVIDENCE
  • From assumption (premise), using reasoning to real cause
  • assumptions: reckless (high risk), risky (risk is acceptable), safe (no risk), required
  • assumption is more dangerous when it is hard to support it, there are too many factors to support it and has high impact
  • Reading: Validity and reliability in quantitative studies
  • Assumption can be: foundational, unlikely, blind, controversial, impolitic, volatile, unsustainable, premature, narcotic, latent
  • assignment: bat costs 1$ more than ball. Together they cost 1.10$. How much ball cost?
  • Reading: Thinking fast and slow
  • Keep your eyes on the ball and the game
  • When you are too focus, you will miss something else
  • Alternate from wide to narrow view
  • Experience is the best teacher
  • Learn from every bug
  • Reading: Nassim Taleb: Black swan
  • Some bugs are obvious
  • Justify why you think this is a bug (unconscious factors, memory habit)
  • system 1 (reflex, fast, loser) and system 2 (reflection, slow, surer)
  • SOFTWARE TESTER MUST NOT GET FOOLED
  • Three stories: project, testing, product
  • Cognitive bias, help us to survive, but not help us with bugs (illusion, miss, quick decision, memory errors)
  • PEOPLE SHOULD (NOT) ARGUE ABOUT SEMANTICS
  • What is an integer?
  • Heuristic is way to solve a problem that could fail in that mission
  • As tester, you must give SYSTEM 2 time to WAKE UP!
  • PAUSE
  • I do not understand, I understand but it is not true, what is whole story, does it matter?
  • Conversation flow: intake => meaning => significance => response
  • Builder has focused mindset and tester has defocused mindset
  • Reading: Asking the right question. A guide to critical thinking.
  • A vs THE
  • And, unless, also, so far, not yet (be careful when you here those!)
  • Reading: How to not be wrong
Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather