Category Archives: Test Annotations

Reviews and comments on other people’s writing

Alternative Paths for Self-Education in Software Testing by Markus Gaertner (EuroStar talk)

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.

Alternative Paths for Self-Education in Software Testing by Markus Gaertner

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:

  • Feedback.
    • 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
    • Books
      • There are many books you can read, but Markus mentioned specifically three.
      • Testing Computer Software – Cem Kaner
        • Gives a very good understanding of software testing and it structure. Markus heard rumors that a 3rd edition might be on the way. (editor’s note: Can it be? Remember, you heard the scoop here first! :) )
      • A Practitioner’s Guide to Software Test Design – Lee Copeland
        • 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!))
      • Lessons Learned in Software Testing – Kaner/Bach/Pettichord
        • An easy reading book with a multitude of different aspects and ideas about testing in all its aspects.
      • Secrets of a Buccaneer-Scholar
        • This book by James Bach includes heuristics for learning (like the SACKED SCOWS, Long Leash Heuristic, Obsess and Forget…) that can be used in most contexts.
    • RST
      • 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.
    • BBST
      • 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
    • Testing Challenges
      • 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).
    • Dojos
      • 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.
    • Weekend Testing
      • 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).
    • Miagi-Do
      • 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.

Should/Need Testers know how to Program (a Testing Question from Brazil)

There’s a very active Brazilian software testing discussion mailing list in Portuguese, called DFTestes.
When I say “very active”, I mean an average of 215 messages/month in 2009, and January 2010 has got more than 404 messages. Compared with other mailing list I participate, this is the most active one, and a tip of hat goes to the testers and list-admins that make the discussions interesting and vibrant.

Recently a big argument was held (link in Portuguese, requires registration) on whether “testers need to know programming” or not. I made some contributions to the discussion, and I’ll try to translate my point of view to English here.
Please note that there were a lot of people participating, and the post below does not present the entire debate or even an entire opinion, just the messages I wrote as answers. I hope you enjoy them.

The proposed question was:

Do testers need programming skills? Until a few years ago, most people would definitely answer NO… But I’ve known both people that seek testing jobs as an alternative to coding, and testers that write code routinely. So, do testers need or not to know programming?

Continue reading Should/Need Testers know how to Program (a Testing Question from Brazil)

Yay, another Happy New Testing Year! A decade in review…

This is our fourth Happy New testing Year post, after this onethis one and this one:)

So, a few hours before January is over, I’ll transpose here an answer to Testing.StackExchange about the last decade on testing:

Question: What are the most important software testing developments of the decade?

My Answer:
The question asks about the most important developments… Not the best or the worst, the beneficial or the harmful.
I’ll try to answer here with considerations by me and others I found on the net. Not everybody will agree that all these are good — even I don’t agree with all :) — but my approach here is more of a reporter than a judge. Continue reading Yay, another Happy New Testing Year! A decade in review…

Software Testing is Funny! with Demetri Martin

Demetri Martin

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: 

Continue reading Software Testing is Funny! with Demetri Martin

In August, a rewrite of July's uTest post (and maybe official feedback)

Hi.

Instead of a new post, I revisited and modified last month’s post, About youTesting with uTest.
It has now more content, and still has a discussion of pay-per-bug models.

The initial opinions are still there. While the pay-per-bug model presented by uTest is certainly innovative and interesting; the model still misses a lot. It will certainly be center of discussion many times in many circuits :). Continue reading In August, a rewrite of July's uTest post (and maybe official feedback)

Read the bugs

Eric Sink is very well known in the software development community. I would say he’s a legend, but he says he’s not one.

He writes books, software, and gives interviews about the craft and business of software. Not only that, but (not surprisingly) he’s also got a blog.

Two months ago he wrote that reading your colleagues code check-ins is a good practice, and I think this is good advice. And good advice for software testers too: I read the bugs submitted by my team on a regular base, and it’s been very enlightening (often to me, at times to them too).

I don’t like copy-paste, but as an experience on the parallels between development/testing, I’ll copy his entire post, just changing the parts that are development-related to testing-related words.
Great artists steal“, right? Let’s see if it is intelligible :) (my changes are in blue). Continue reading Read the bugs

Testing Insights – The Graphing Calculator

I’ve recently heard The Graphing Calculator Story, a ~54:00 min long Google Tech video on YouTube. On it, Ron Avitzur tells the story of the development of his (and Greg’s) Graphing Calculator, an impressive mathematical software that shipped with Mac computers for years.
What’s special about the story? Well, he did it at Apple, but for free (his contract was already closed), and in secret (Apple had cancelled the project). As he says, sneaking into the building and volunteering for an eight billion dollar corporation. :)

I enjoyed the story very much. It is very exciting to see the passion he had (has) for his software and how he was committed to it. Plus, Ron is a great story teller.
The graphing calculator had all the ingredients of a cool app. It scratched a developer’s personal itch, and is a great example of NeoVictorian computing: built for people, built by people, crafted in workshop, inspired.
Actually, if we’re commenting on NeoVictorianism, Ron was one that really “woke up one day to find himself living in the software factory“. The night got very cold, they said the factory is going to close and he should move somewhere else. The cool part? He kept doing his individual craftsmanship inside the corporation. Secretly.

Continue reading Testing Insights – The Graphing Calculator