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

vim, show me your colors!

Reading Time: 2 minutes

TL;DR

This post is about vim and how you can start using it in your daily work.

At one point in my testing path, I decided that I should start using vim. I opened Google, and start my search journey. I searched for:

“vim development platform”

What got my intention was search result:

spf13-vim – The Ultimate Vim Distribution

This is “spf13-vim is a distribution of vim plugins and resources for Vim, Gvim and MacVim. Which means that you need to install vim by yourself, and this distribution will add a set of useful vim plugins for development. Adding new plugin is also simplified (although, you need to know linux cat basics to do that).

For me, important one are related to ruby language. Here is one rspec file, opened in mvim:

Yes, you have coloured syntax. For me, this is very important, because with colours, I make less syntax errors!

Ok, you are set to go and you expenses so far are 0.

To get to know basic, run vimtutor (linux and mac os have it, for windows read this).

Here is set of vim cmd’s that I use on daily basics:

  • fire up vim: cd to your development folder and type:
    mvim &
  • enter command mode
  • :
  • start folder explorer vim plugin (note, tab will complete your commands, so you can type Expl, then hit tab, and vim will do autocomplete
  • :Explore
  • open file in new tab
  • select file with arrow keys, then press t
  • close file
  • :q!
  • go to file bottom
  • G
  • go to file top
  • gg
  • go to end of line
  • $
  • go to start of line (this is zero)
  • 0
  • delete line
  • dd
  • undo action
  • u
  • start edit mode (you know that you are in edit mode when you see this in the bottom of vim

  • i
  • exit edit mode (you need to do that in order to do all other commands listed here
  • esc
  • delete character on the right
  • x
  • copy paste action. Note, if you start typing after you hit p, copied item is cleared from the buffer.
  • v, then with arrow keys make a selection, y, go to position when you want to paste, p, text will be pasted on the right of cursor
  • search
  • /, what you search, enter, found text will be highlighted, with n you move to next found item.

 

That it is. This is small set of features what vim can do, but for me it is enough to be productive!

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

What I learned on Testival #29 meetup

Reading Time: 2 minutes

TL;DR

This post is about my learning experience on latest Testival meetup.

We had two talks and one 5 minute talk. We started with traditional introduction of every participant. Repsly was again event sponsor.

#1 Zoran Majstorović, ButterflyMX: Ruby Test Suite @ButteflyMX presented Ruby test ecosystem that his company use on daily basis. Those libraries cover whole testing pyramid.  Their web application is developed in Rails framework and they use following ruby gems (libraries):

  • rspec – test runner, automated checks and Rails mocks
  • FactoryGirl – test data
  • capybara – UI automation framework.

Code is on github, and they use branching and pull requests for deploy strategy.  CI system is Semaphore and Code Climate is set of open source Ruby libraries for code analysis.

#2 Marko Filipin, Head brewer and co-founder at Nova runda brewery: A/B testing beer

Nova Runda is one of the first Croatian micro brewery, they are known for their Indiegogo campaign through which they raised money to brew their first commercial beer, APA.

The best beer is one that always taste the same. Striving to that path, they started A/B beer testing. They presented two beers in three cups, A,B,C. They wanted to get statistics how many participants guessed which cups hold same beer. Participants were forbidden to do any commenting while testing the beer (no influence on other participants).

9 of 23 participants noted the difference. The number needs to be 12 so they can claim that they produced same beer in two different batches.

This is known as difference test. Preference test is subjective test. It gives answer which beer is prefered by the tester.

Yes/no test is acceptance test. Is this beer good enough to sell it?

What is beer quality?

  • from batch to batch, beer must taste the same
  • must have attributes of beer type. If you cooked Pale Ale, it must not taste like Indian Pale Ale.
  • ratio of sugar(malts)/bitterness(hops)
  • any not wanted tastes?

Zeljko Filipin presented problems with Vim UX in his 5 minute talk.

As a regular user of Vim, I suggest you to try this ultimate Vim distro. and start with basic tutorial found in Zeljko’s blog post.

 

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

Bottom up Heuristic

Reading Time: 1 minute

TL;DR

This post is about heuristic that I discovered while I wrote rspec ruby test script. Heuristic can be applied in any situation when you investigate errors reported on file line number.

One of my test frameworks includes Ruby where I write test scripts in rspec. I like rspec because it represents domain specific language (DSL) that makes testing code more readable and maintainable.

So yo have been in situation when you run your test suite, and you get test run report that contains line numbers where your check failed.

You need to update your test script. If you start your edit from top to bottom, your script will be no more aligned with test report. Now you have to run test suite again in order to align it again, and that takes time.

It is time for bottom up heuristic. Start your edits from bottom up directions, and you will keep your test report with test script. You will save some test run cycles and become slightly more productive.

 

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

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

Blog that makes software testing interesting and exciting.