Category Archives: agile

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

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

Feature analysis for my Internet banking application

Reading Time: 2 minutes

TL;DR

This post is feature analysis of my Internet banking application. As a user, I am not satisfied how those features are implemented because using them I spent much more time than expected.

As a user, I want to pay my bills reliably and as fast as possible. Feature that I used every month is to ADD MY BILL TRANSACTION TO BATCH OF TEN, and then I confirm that transaction with ONE transaction token.

SELECT PAYMENT TEMPLATES is also very important feature, because using them I only have to change one dynamic part of every bill, that is my PAYMENT ID created by the owner of the bill.

Combining those those two features, I spent less that 20 minutes to pay all my monthly bills. And that is acceptable for me.

Current system is live from the beginning of this year, which means that I used feature, CREATE A PAYMENT TEMPLATE, in the old system. All payment templates were successfully migrated to the new system.

This month, I needed to update one of those templates, and all the frustration and fun began. In user interface, there was no obvious information how to do that (obvious information in user interface is my prefered way of application documentation). Then I checked official user documentation.

Search for predlozak, croatian word for template. Second word will reveal Slika (picture) 10.17 and observe upper right corner. Yes, this is where you select to save NEW TEMPLATE.

So, there is no feature, UPDATE TEMPLATE. You need to delete current template and then create new one.

And here comes the BIG BANG FEATURE! In picture 10.17 you can see how to pay a transaction. Wait a minute, what does this have to do with creating the template? Well, they decide to merge two features, pay ONE transaction and during that feature, mark that you want also to create NEW TEMPLATE from that payment transaction. Simple and logical, if you are a Vogon.

So, here was my workflow:

  1. Add payment transaction to transaction batch of ten.
  2. Remove it from batch because I wanted to update it.
  3. Delete current template.
  4. Create new payment, mark that I want also new template from it
  5. Pay just one transaction
  6. Continue with adding other transactions, using their templates that need not to be updated, to batch transaction

There is also one feature, that I call ANNOYING FEATURE. Remember that in every PAYMENT, I need to update PAYMENT ID, hard coded by the owner of the bill. Croatia Vogons created a set of rules for that PAYMENT ID (and increased croatian employment number for 5000 thousand).

And bank developers decided to implement MAGNIFICENT FEATURE, check that business PAYMENT ID WHILE I am typing it in input field. Yeah for Javascript! Problem is that they trigger rule check BEFORE I FINISHED typing!

How is your Internet banking application these days?

 

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather