Marlon Brando said in a role he played: “People win with loaded dice“…
This is the exercise we’re building today, loaded dices – for the win!
…I get by with a little help from my friends. One of the friends at work who pushes me into all sort of good experiences is Issi Hazan. At this example, he invited me to join him in a testing class for the Tech-Career project (a social wellbeing program in Israel that works with immigrants from Ethiopia to form them and prepare them for a job in the High-Tech industry. They were mentioned at this old post about building a portfolio, and at work we volunteer by giving them coding and testing classes).
Issi’s aim is to teach the group strategies for Exploratory Testing.
But how to do that in a single short out-of-the blue session? How do you convey the strategy, heuristics, coverage models, quality criteria in a practical easy-to-get form? How to make it dynamic and not-boring?
I am back from EuroStar.
I’ve got lots to write about EuroStar: the people, the lectures, the Test Lab, the venue. However, if my mails are any indication, the thing people are waiting most to read about is the “Rebel Alliance” night.
This night, which went by many names (“Rebel Alliance”, “Oprørsalliancen”, “Danish Alliance”), was an informal meeting of friends. As we did at StarEast, it was “a mini conference after the conference, with beer”. We had there very special people and some famous names from the software testing world, and we spent the night talking testing, debating testing, listening to lightning talks on testing, playing games and debating some more. I am a boring nerd, so for me it was the best party ever.
The content and energy were fantastic, it was a remarkable evening. In this post I’ve collected some pics, videos and links.
Markus Gartner is very skilled in speed-notes. He’s been around EuroStar speed-noting all the session’s he’s been into. He calls it live blogging, but I use the term Speed-Note because, well, I think I coined it ;).
He was live-blogging all the talks, but… who is live-blogging Markus’s talk? Who watches the watchmen? Well, I took the challenge. What you see below are my notes from his ~40 minutes talk.
Markus’s main motivation for organizing this talk was noticing an economic downtime a few years back, where conventional commercial education was costly to follow and pay for by companies or individuals. But even in this situation, if you’re in a position where you want to learn and educate yourself, there are other ways…
Markus’s first conventional/official training course in Software Testing was in 2007, 1 year after starting his work as a tester. By that time he already had got responsibility leading people and projects, and he attributes this to spending that year learning about testing from books and people, thinking “how can I advance in this?”
Who is responsible for your education?
One can assign the responsibility over her education on the employer, on teachers, certifications, family… Markus main message on the lecture is that YOU are responsible for your own education. (editor’s note: I agree. In fact, I believe it can’t work any other way).
Shino (as he’s called informally by school friends) presented some options to self-education:
By writing a personal journal one can assess how his thoughts change over time — that’s self-feedback. By writing to a blog or magazine you receive a different feedback, which is external feedback by other people reading your stuff. For even more direct feedback, you can write on mailing lists or present at conferences. And there’s also an environments built specifically for getting quick and easy feedback, and it’s called, guess what, Social Media. On Twitter, on LinkedIn, the Software Testing Club or Weekend Testing, you can get immediate feedback to questions and affirmations (editor’s note: some of the links point to my own profiles).
Learn to Program
Programming can be a very useful skill for a tester.
You can try to learn some scripting languages to help you during your tests, or study design patterns to understand more about software construction. Learning about programming techniques and technologies or pairing with a programmer can give you a great understanding of what goes on in the code.
There are many more options to learn and advance. Markus divided them by two:
*HYPOTHESIS* – Left Side of the Brain
There are many books you can read, but Markus mentioned specifically three.
This book structures techniques of software technique, in a very short form. This is Markus preferred and recommended book. (editor’s note: I like this book a lot, thanks Justin for the great gift. But the book I like most is Testing Comp Software by Kaner (and thanks Hayim for this gift!))
It’s a commercial course by James Bach and Michael Bolton. You have to take the course frontally in a class room. But the slides are available online (!) at http://www.satisfice.com/rst.pdf and they include models, heuristics and other valuable points from the course.
Developed by James Bach and Cem Kaner, this course is an in-depth view of software techniques and our work as testers (it covers Bug Advocacy and Testing Techniques). One of the ways to take the course is by looking at the videos at the BBST website, the other is by taking the course with the AST association, which include — in addition to that material — collaboration and feedback with peers and instructors.
*SYNTHESIS* – Right Side of the Brain
Solving challenges as a game may condition you to solve challenges in real life. Markus reminded us that James Bach is willing to share testing challenges over Skype to anyone who contacts him (http://satisfice.com/blog/archives/393). Eusebiu Blindu, for example, has challenges on his website as well (link, link, link).
On coding dojos, programmers pair and try to solve one specific coding problem. They include collaboration, a safe environment and a deliberate practice. Markus cloned this idea over to testing, and in Testing Dojos testers solve a problem (test this, evaluate tools, learn new approaches…) in pairs or individually to sharpen their skills.
A weekend testing session is an online ~2 hours session of testing where people work on their own or pairing. They are like dojos in matter of mission, and include a multi-person discussion over Skype on the mission and the results. (editor’s note: It’s certainly a fun way to spend the weekend! I was there and recommend).
This ‘school’ for software testing was founded by Matt Heusser, is non-commercial and zero-profit, and aims to improve testing skills through practice. By proving skills when solving testing challenges you earn colored belts. Markus is a Black-Belt Miagi-Do tester and can be contacted for more information or for initiation. (editor’s note: While is it true that there isn’t much you can do with the belts :), there’s much you can do with the skills.)
Summarizing his talk, Markus says that there are different styles for learning, and you are responsible to discover what your own style is and how you will advance on it. Markus recommends, in any case, trying as many types of learning as you can.
שנה הלכה שנה באה
אני כפי ארימה.
שנה טובה לך, אבא,
שנה טובה לך, אמא.(link)
“For auld lang syne, my dear,
for auld lang syne,
we’ll take a cup of kindness yet,
for auld lang syne. (link)”
Tomorrow we celebrate in Israel the New Year in the Hebrew calendar. Yes, 4 months before December ;), and guess what… we are now celebrating year 5771! The difference between the years counted in Gregorian calendar and the Hebrew calendar is ~3760 years.
New years, calendars and dates are extremely important for Software Testing.
Last month I visited the STAR East conference. It was over two weeks ago, which on the internet age makes it old news.
I follow my own clock, however, and will start posting about STAR East only now. Scott Rosenberg would call this type of blogging ‘history’ instead of ‘journalism’ (link), and it sounds just as fine.
In next blog posts, I’ll write about what happened at STAR. What happens in Orlando doesn’t stay there.
But on this one, it’s a bit about what happened in the way there.
For some time before travelling, I’ve been thinking about physical problems that resemble computer bugs. “Spirits in the material world”. For example:
In this picture you can (barely) see a water bottle that was forgotten by a worker on my neighbors’ roof. Just like a programmer would forget a temporary variable she invented to get some refreshment from the code inherent limitations, a worker will forget his own refreshment once it isn’t needed anymore.
This was an interesting exercise.
What took my interest in this one? – First of all, I liked Pradeep’s post about learning to code.
Learning to code is an important skill for a tester. I can relate to it because I am trying to learn PowerShell. I program in some languages (C#, C++, PHP, VbScript…) and have a programming background (after my Computer Systems Engineer degree, the ‘natural’ path was to code, and I worked as a programmer for many years before finding Software Testing), but PowerShell has different approach and paradigms and learning it will definitely be fun. – Second, I had an impromptu vacation day, and I thought it would be educational to use it for a peer testing puzzle. I thought I could win this one quickly (I was mistaken, it took me long).
So I downloaded Pradeep’s application, and got to work!
Rather than just trying to solve the puzzle, I looked at it as if the mission was:
“This is commercial 'roulette' style game. Stakeholders want to know it the game logic can be broken/learnt, which could mean a substantial loss of money when people start winning every time.”
Testing Hint: Cem Kaner says “Testing is an empirical, technical investigation of a product, done on behalf of stakeholders, with the intention of revealing quality-related information of the kind that they seek“. So it is important to set straight what is the information to seek. Which kind of bugs to look for?
One best friend of mine introduced me to Mitch Hedberg and Demetri Martin, great one-liner comedians. They are/were two funny men!! Three, actually, if you count my friend which is also funny.
After hearing the disks for over a year, not only the jokes aren’t any less funny, but I’ve started to find subliminal testing messages in them .
I’m writing down these “insights” because I find value in them. And even if they fail to teach you something… Hey! At least the jokes are pretty funny!
So here go some favorite quotes, and their parallel in testing: