Category Archives: learn testing

How to expose your reading list using rss

Reading Time: 1 minute

TL;DR

This post is about how I manage blog posts reading list. It list tools that I use on daily basis to collect and share what I read.

My first try was twitter. I use it for collecting my blog post reading list by following software testers that blog about software development and testing topics. Here is my following list.

But very soon, twitter failed me. As they started pivoting their business model, very soon I received in my twitter feed a lot of noise (shares, likes, advertisement, flame discussions).

Then I turned to rss Google reader. RSS is old technology, and you can check if web site supports it by just adding /rss at the end of site url. No noise, no flame wars, just useful data. Notifications about new blog posts. But Google decided to shut down Reader (no advertisements rings a bell).

Rss reader market is not so big, and after short investigation, I found Newsblur . It has browser and mobile desktop and I use paid option (I think 27 us$ per year).

I have around twenty feeds that I am following (security, software development and software testing).

Another issue is how to share what I have red to support the author? I know, there is Twitter, Facebook. But my Facebook friends are mostly not connected with software development.

Here is how I share my reading list. Newsblur has it own share feature, one click away. It is called blurblogs. What I share, directly goes to my blurblogs page. That page also has rss feed. I expose it on this blog first page.

rss is old and very useful technology, give it a try.

 

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Safety nets

Reading Time: 2 minutes

TL;DR

In this post I will present two examples of safety nets created by software industry professionals.

Note the context, I stated software industry professionals, which includes anybody involved in software development.

In Circus, trapeze artists have safety net to catch them if they fell. In modern software development, safety net for developers are software testers. Not to save their life, but to catch as many bugs as possible. In order to resolve that issue, companies started to remove dedicated software testers. Software developers are responsible for all software testing.

This is wrong from two angles. First, software tester job is not to find bugs but to provide information about software to people that matters (doing that, they also find bugs). Second, software testing is a craft that has SOME connection points with software development (writing automated tests). And usually, software developers are very bad at testing. I do not mean they write bad software testing automation code, but they are very bad in performing experiments (James Bach: “Testing is not about creating test cases. It is for damn sure not about the number of test cases you create. Testing is about performing experiments.)

During the Brighton TestBash 2017 open session day, I listened conversation between Anne-Marie Charrett and Paul Holland about safety nets. She consulted in company that removed software testers. They wanted to “cut” developer’s safety net. And guess what, developers found another safety nets.

I also have one example. I created a document with installation instructions. In order to avoid copy/paste effect, all commands were put as screenshots. Guess what? Software tester created his intermediate text file with those commands, so they could be copy pasted. As that created another level of documentation, those .txt files become very soon out of sync with main document that had screenshots.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Speak Easy program

Reading Time: 2 minutes

TL;DR

This post is about my journey start with speak easy program.

During the CAST 2016 in Vancouver, I heard about speak easy program. That program helps you to compose your talk proposal for testing conference. It is voluntary based and created by Anne-Marie Charrett and Fiona Charles.

I applied in August last year.

On patient. When I asked my friend Zeljko Filipin how to make a good homebrew beer, he said: “To make a good beer, the most important part is patient”. With my third batch on the way, I found that it is true. Just to taste your beer, you need to wait for one month.

This month, I got speak easy feedback. I was patient because I knew that this is free volunteer based program.

After few emails exchanged with speak easy volunteer (I stated my time zone and most important testing topic which is at the moment Session Based Test Management) , I was assigned to Gil Zilberfeld.

He asked me a few questions to put me in software testing context, and we are set to go.

For start I need to pick three testing topics, which will be foundation for my future talk proposal.

Why I assigned for speak easy?

As when you want to learn some new framework or programming language, you start by reading and applying a book written by the expert from that domain. SpeakEasy will help me to get professional help from the domain of preparing and giving software testing talk.

Because I think that I have some valuable thoughts about software testing. My goal is to apply testing talk to permanent TestBash call for papers. TestBash is paid conference, and if I would be accepted, I own to participants to give my talk in the most professional manner. SpeakEasy will help me to do that.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Screen size test strategy: always test on smaller screen

Reading Time: 1 minute

TL;DR

This short post is about simple but effective test strategy that varies application environment: screen resolution.

When you test application, ask developers which resolution they use and then set the resolution for your computer screen to value that is less than minimal developers value. Screen resolutions have some standard values.

For example, if minimal developer resolution is 1440×900, you should set 1280×800.

Developers use large screens with big resolutions, so they are not best representatives for users of your application.

Using this strategy you will find corner view cases. If application view contains a lot of UI elements, then you issue will be dismissed. In that case, when you are testing again that application page, set you screen to larger resolution. But do not forget to set it back to lower one when you are done with that screen.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Do not be tester’s police

Reading Time: 2 minutes

TL;DR

This post is about 99 seconds talk that I presented at Testbash Brighton 2017. Idea is that we should not act as tester’s police in agile team.

Doing stand up comedy helped me to do public speaking, and doing 99 seconds talk in front the full Testbash audience was a great experience. Stand up comedy helped me to realize one other important thing. Greg Wilson said in his stand up comedy video course: Do not be the stand up police, you need to worry about you r act in front the audience, not about other stand up comedian acts. Doing that, I improved my stand up comedy act a lot.

Presenting your ideas and knowledge as police officer is not a good approach. How do you feel when you are stopped by traffic police officer? I am always nervous and scared, despite the fact that I had not done anything wrong.

You have to tailor your approach first. When you have some feedback on developer, product owner or conference organizer, try first to understand their line of work.

Being a developer is hard work. New languages, frameworks, IDE, coding katas are what they need to learn on daily basis. So it is possible that they put testing mindset on the side. For start, just try to read some introduction blog posts about their topics.

Project owner has to deal with people and how to direct their talents to final product. And people are emotional machines, they compare with each other, and product owner is in the middle of that story.

Organizing a conference is hard work. Try to organize one, and you will know what I am talking about.

When you comment on blog post idea, do it by writing your own blog post with follow up thoughts. You do not have a blog post and you put harsh words as your comments? Shame on you!

In order to feedback on something, you need to be credible for that. Organize a conference, write a blog post, read about development framework or language. You have to own the right to comment on something.

All 99 talks can be found in this 30+minute video:

https://dojo.ministryoftesting.com/lessons/99-second-talks-testbash-brighton-2017

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

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 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

What I learned on pre TestBash2017 Brighton meetup

Reading Time: 2 minutes

TL;DR

Next series of post is about my takeaways from Brighton TestBash2017 conference. First was pre TestBash meetup.

That meetup was day before workshop day. I came late, and everybody was already in the game mood. I noticed that a lot of games were played.

I joined to table with following setup. One card was on the table, three testers were asking questions, and one was answering them. Game was Dark Stories. Each card represents a puzzle in story form that is written on one side, answer is on other side. One person reads puzzle at loud and keeps answer for himself. Others try to guess the answer.

My takeaway. This is excellent game for practicing critical thinking. Answer is not obvious, so you need to do focus/defocus thinking about the puzzle. You need to have some common general knowledge in order to solve some puzzles. I played with excellent testers, and by listening their questions, I learned about their approach to puzzle problem. Pairing of testers, in this case testers tetrads, is great way to learn, test and solve a puzzle!

Second game that I observed was Otrio.  Think of it as tic-tac-toe with more dimensions. Triplet can be made with same size or different size in ascending or descending order. Each element has three sizes.

Third game was Cockroach Salad. Pace of this game is very fast. it trains your brain to think fast, as rule of games could change. You have four card type: Pepper, tomato, salad and cauliflower. For each card type, there is taboo card. You play a card and say vegetables that is on the card. But:

  • If your vegetable matches the previously played vegetable, the player must lie.
  • If your vegetable matches the claim made by the previous player (perhaps because that player lied), then the player must lie.
  • If you play a taboo card, he shouts “Cockroach!” and the next player starts a new pile next to the first one so that the taboo card remains visible.
  • If your vegetable matches a visible taboo card, he must lie.

If you can not lie and you are supposed to (nightmare of every politician!), you must pick all cards from the table. First player without cards wins.

I was in situations when I was testing application that had feature rules similar to this game. How about you?

That was it. No beer party because I need a good night sleep for workshop day. I walked back to my bed and breakfast place despite the fact that weather had changed three times since I arrived to Brighton.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather