Boring presentation titles?

I was looking for another person and detoured myself to a WWW page of a Prof Graham Sewell at Melbourne University. Out of curiosity I browsed the titles of past publications and it hit me: the presentation titles of my past presentations are simply plain boring!

I am not a specialist of management as the good professor Sewell, but even I can appreciate the lure of titles like

• “Yabba-Dabba-Do: Evolutionary Psychology and the Rise of Flintstone Psychological Thinking in Organization & Management Studies.”
• “Looking for the Good Soldier Švejk: Alternative Modalities of Resistance in the Contemporary Workplace.”

Of course each profession, each journal and each conference has their own implicit code of desired and not desired article titles. And also: being whimsical or funny in the title does not guarantee good communication value or even marketing value of an article.

My shallow experience in research world showed few daring individuals in computer science and engineering management fields with a skill for tasteful stretching of the local title naming canon. I assume local journal or conference editors can have an effect on this. But reality is this: good article / presentation names can mean a difference of consuming or ignoring some content. Experts, consultants like professors have to "get" the basics of personal marketing or even personal branding. I remember seeing complaints about some AI researchers who intentionally (or who's followers) built a certain "rock star" quality tagged into their persona, especially closer to the end of AI honeymoon of 1980's.

I have to give this a thought and learn a lesson on this. Maybe if I study some of my past article or presentation titles and try to rethink them I could

• improve the lure of them
• highlight the message with analogy to a phenomena from outside my domain
• myself learn new aspects about my own subject matter by finding the analogies or catchy referencies to popular culture
  

As an example we could work out the title

"10 important things in test planning"

10 things of test planning that can go wrong
Risk slant that has somewhat schoolteacher or old educational film feeling on it. Maybe with some old clip art?

10 things of test planning you should worry about
Getting personal on the style of self-help book titles, but not worrying. There is a promise of an improvement.

10 ways to avoid your test plan to fail on you

I am not sure how this would be understood by native English speakers. But a personal risk can highlight the message.

Or how about

"The 5 tasks of a test manager"

(a reference to a book by Mr Royer, further details in a previous post.)

Five ways to fail as a test manager

Hmm, this can be experienced as too threatening, but communicates the risk.

Be a five star test manager!
Motivational, but resembles the "hard sell" approach that I personally hate so much. And I would never trust a consultant that promises to do that for me. But maybe as an article title this would work.

A multitalented test manager

This one has the focus on test manager not being just a planner or being on control.

Format of a title

From examples of Prof Sewell we identify the common title format of "Phrase: explanation" close to the so very common book title format "Boring or Whimsical title -- Subtitle that tells what this is about". So making better use of the title space in journals of conference programs, I should adjust my titles to include not just a new angle but also the catchy phrase too.

What I learned from this exercise is this

• Language is a wonderful tool if you can use it; being a non-native speaker of bad English it is better to probe reactions from few native speakers first before trying something too creative/complicated/whimsical or producing wrong association in a mind of a reader
• Paying attention to the title really is a good idea and I should put more effort on that
• Thinking about presentation titles is an effective way to consume an hour of my time, that maybe would have spent better on learning more about my subject matter :-)

Peace all,
Erkki alias theGromit

Test Management is called “Planning and Control” in TMap

I first heard about TMap from a presentation by a Dutch testing consultant Martin Pol on 1999. The TMAP testing process framework is documented well in the book “Software Testing – A Guide to the TMap Approach”, by Martin Pol, Ruud Teunissen and Erik van Veenendaal (Addison-Wesley, 2001).

I personally like TMap (http://www.tmap.net) a lot. I have used it as a common reference across organizations and as a checklist repository for long time. Sure, it’s heavily plan-driven but pragmatically so. Trying to use it as such as your “process” or “method” would not be wise, but comparing you process against it would give you many ideas for improving. It allows relatively inexperienced test leads get started and learn ways to bring some order to the chaos. After that it is easier to learn other paradigms. So it is a good testing process framework for certain contexts.

In TMap the testing life-cycle is divided into 5 main phases, called

1. Planning & Control
2. Preparation
3. Specification
4. Execution
5. Completion

First phase consists of the test management main tasks “Planning” and “Control”. They both contain several activities. TMap book lists the following activities for higher level Test Planning:
1. Formulating the assignment
2. Global review and study
3. Establishing the test bases
4. Test Strategy Formulation
5. Setting up the organization
6. Specifying test deliverables
7. Specifying the infrastructure
8. Organizing management and control
9. Setting up schedules
10. Consolidating the test plan

And following activities are listed for test control:

11. Maintaining the test plan
12. Controlling the test
13. Reporting
14. Establishing detailed schedules

If you compare this list with the five tasks of the test manager according to Thomas C. Royer, you’ll see that they will be covered in TMap Planning and Control phase tasks. The TMap book has a set of methods for TMap activities and explains well many risks and problems related to each 14 activities. Some even have a chapter in the book of their own. The methods mentioned are not the only ones and sometimes not most useful, but will both provide good picture of one coherent way to manage each challenge and also explain the background of each challenge. Works wonders for people with narrow or shallow experience in testing, but who must tackle the challenges of test management or testing in general on latr chapters.

I have not yet read the new TMap book called “TMap Test Topics”, but what I gather from the book intro, it expands the chapter 29 of the older book mentioned above, “Variations on the theme”. So target of the new book is delivering additional guidance on customizing the generic testing process into specific contexts and challenges.

We at Nordic countries do not like disclaimers, but here goes one for your benefit: I have most of my testing experience from large product development organizations in the telecom context. I really aim at balanced writing but will most certainly fail to anticipate priorities and constraints of different contexts, so reader is encouraged to exhibit critical thinking also on any advice you see in the Net. There. :-)

The five tasks of a Test Manager

I was updating my old test manager training course material. It was built for certain roles in a certain context and certain time. It was due to be delivered soon again and this time I wanted a more generic approach to testing. I browsed through my bookshelf and bumped into a gem I had ignored: “Software Testing Management – Life on the Critical Path” by Thomas C. Royer (Prentice-Hall, 1993). The book had been sitting in my shelf since year 2000 and I have only browsed it at best, but now I gave it a better look.

The book is hardcover and rather thin, 230 pages. It covers many of the important themes of testing from very plan-driven perspective. It covers most relevant standards, techniques and project dynamics from testing and quality point of view. The approach is somewhat outdated, narrow in solutions and assumes quite much about the organization and its process. The gem was in the book preface, on the first page of text content, page ‘xiii’: it describes the testing dilemma and then lists the five tasks of test manager.

The testing dilemma is that from technical point of view testing is supposed to “search for bugs”, and from management point of view to “prove that it works”. And both of these should take place within reasonable time and cost constraints. Do we even agree what “it works” mean? Royer continues:

And beyond that, we’re given budgets and schedules prepared by others, by people who are filled with the optimism of the developer (“Everything will work fine”) or the urgency of management (“Get this program out the door. Now.”)

Royer shows that test management can take care of the testing dilemma by caring for five aspects of testing, or by executing the five test management tasks:

1. Understand and support the entire development process
2. Plan the testing appropriately with the stakeholders and manage changes
3. Effective test cases must be designed
4. Execute the tests in an efficient way and communicate testing status clearly with all takeholders
5. Monitor the schedule and cost and by being responsible for the money we spend and the time it takes

Some parts of the five tasks are not always a hands-on task of the test manager, but they all very much lie in test manager’s turf. Also, especially if you do not have a matrix organization where someone else acts as line manager of the testers, test manager should care for the team and competence aspects.

Regardless of the actual boundaries of test manager role, if you look these five tasks you’ll see that there is nothing outdated with these basic responsibilities. Test management method i.e. test manager’s tool box, how these tasks can be done, has expanded during the 13 years between writing this book and today. But still if you ignore any of these tasks, you risk facing a failure, regardless of your context or process life-cycle.

The good news is that there are very many ways to tackle these tasks using different tools and techniques and they can be learned. And it sure is wise every now and then to think each task in turn to see if our practices are up to the challenge and we really have covered our responsibility.

A Learning Tester: "Tester Tested !"

I browsed the "EuroSTAR Comunity" blog for recent postings and saw a very well-thought piece by Mr. Pradeep Soundararajan. He wrote about the experience that myself and few colleagues have shared recently: very often when I think of an idea for an article or presentation I see that it's been covered already my more capable and more proactive minds, like Cem Kaner and others.

This similarity and a realistic attitude to research and writing made me have a browse on his own blog "Tester Tested !". It has many quite personal and insightful articles by him. Highly recommended, especially for us who think we know something :-).

Mr. Soundararajan is doing a service for us all with his blog, highlighting in practical terms what is the focus of teachings by many modern testing minds: a good tester is a learner, a good testing expert should be even more so.

"Big Picture" ?

Hi there!

I wanted to post also here that I wrote a blog entry about what could "testing big picture" mean. It is at the EuroSTAR conference blog at http://eurostarcommunity.blogspot.com/2006/04/testing-big-picture.html.

Hope it releases some ideas from us all...

Sincerelly Yours, Gromit

First Test

Testing is my thing. I like testing, especially software testing, that is. I'm into all sorts of SW & IT development, processes, practices and the like. But most I like testing and that's what this blog is about.

On the first blog I suppose is a place for setting a course. I do not have a tight definition about what is coming onto these pages, but just have lots of ideas and things I'd like to highlight about the 'testing business'. I put that on quotes as an increasing quota of testing takes place in companies specialized to test SW and products of other companies.

About myself

I'm a techie on my forties, divorced and have wonderful contact with my ex and children. I love playing and singing music and am quite serious about photographing (the profile of half the nerds I know ;-) English is not my native tongue, so please bear with me and my text.

I work as a test improvement and support person in a large ITC (Information technology & Communications) company, been doing that most of my 13 years in the company. I also have had my share of test consulting and training tasks, even being fortunate enough doing it sometimes outside my day job in other companies.

I have background in programming and especially liked OO (object-oriented) methods, and have taught OO methods and languages in local university. I also have acted as a webmaster for a unit in my company and still play with different web technologies on my free time, occasionally helping some non-profit organizations getting into Net.

During recent years I have become active on facilitating tester networking nationally and continue pushing testing as a profession and real discipline on the industry. I push for improving the competence of testing people via various working groups in national and international forums.

So, that's enough for a simple intro. In later posts soon to come I plan to delve at least into

• The position of testing in the organization
• Improving the organizational aspects of testing
• Dealing with test management in large organizations & related tool support
• Balanced testing process improvement
• Improving development testing
• Training testing & other competence improvement
• Testing as a career
• My favourite testing books
  

I hope to see you later, if these items interest you