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