Why Testing needs a community ?

Hi Reader,

I am Pradeep Soundararajan from Bangalore, India working as a Senior Software Engineer at Flextronics Software and Systems. I have been considered as a passionate tester by the people who have worked with me and also by those people who have gone through my Testing Blog. I am also proud to be a student of James Bach and have aimed at becoming one of the best Tester's in the near future. I am thankful to Kevin Byrne of EUROSTAR for inviting me to join this community.

Let me now start sharing something that I think/feel, as a Tester from India.

__ Why Testing needs a community ? __

When was Testing born ? Where was it born ? How was it born ? .....
Do you have answers for the above ?

Well, we realized that there is a scientific approach called "testing" especailly after doing Testing sub-consciously. Right from our child hood we have done testing but still every tester feels he is yet to learn completely about testing. Why is that ?

The answer could be : When one form of testing was born in your mind , the other form was born in mine and some other form in someone's brain and we finally end to have a count of whole population of the world giving birth to their own form of Testing.

"Now I don't believe this" by any chance if you feel/say so, I am sorry, whatsoever your native language, was formed only after borrowing a few words from other languages. Had you uttered the above sentence, its time to say "I have started to believe".

Well as many expert like Cem Kaner, James Bach, Jerry Weinberg, Jhonathon Kohl... feel, Testing even maps to epistemology which in turn refers to the study of how people think. Of course you now agree that different people think different from each other. If still you dont agree, that shows we both are thinking different from one another.

I can answer one question for you "How has testing grown and how can it grow in the future?" ,if you think I haven't answered well the questions I put up at first ( vice versa too :P )

Whatever so called definition-methodologies-documents-books-strategies-types of testing we have today, are evolved by people having a passion for testing coming together ( of course after doing some research ) discussing and framing an agreeable standard of defining an aspect of testing. Any process/protocol you take has never been framed by a single person , its people coming together , rather I should call such process/protocols have bought like minded people together.

I can be somewhat satisfied that I know something good in testing, only after mingling with ( or learning from ) Testers coming from a different community, country, relegion, caste...

Take a look at every Test Expert we currently have, they are the people who have travelled across the world, meeting up testers, presenting their ideas and also learning from their juniors.

Why do they do so ?
I think they have realized that Testing can be learnt well only through a community and the community they need to look for making themselves best testers is the ..... whole world.

So when are you going to explore the community ( the whole world, I mean) ?

__End of __Why testing needs a community ? __

"Atlast relegion/caste is useful, in bringing people together to discuss their dimension of Testing"

Thanks and Regards,

Pradeep Soundararajan

Look for more at Tester Tested! or ping me.

A New Programme is Born

The EuroSTAR programme was announced on May 2nd and below is an article from EuroSTAR 2006 programme chair, Jens Pas outlining the highlights of the programme and what to expect from EuroSTAR 2006.

The article was published in the EuroSTAR Newsletter. Click here to view the entire newsletter and to subscribe to future issues

Allow me to introduce to you the keynote speakers:
We open the conference with Filip Gydé, Senior Vice President of CTG Europe who will tell us about how CTG has literally invested a lot in people. He will tell us about being awarded the Investors in People certificate and how for the third time in a row, they became “Best Employer in Belgium”, elected by employees. He will link this investment to their software testers and testify how this that positively impacted on the company’s bottom line.
Those who attended EuroSTAR 2005, will remember Thorkil Sonne from Denmark, who presented a track session on his company “Specialisterne”. He told us his very moving and personal story about his life and the birth of his son who was diagnosed as autistic. Based on a series of events Thorkil made a bold decision and turned his career around. He founded a company to help autistic people by providing them with rewarding jobs as software testers. You may have read his story already in the first issue of this newsletter. Thorkil ‘s session was voted Best Track Session in 2005 and he has agreed to keynote at this year’s conference.

Flying over from the States is Scott Barber, who specialises in Performance Testing. This area of testing is becoming more important then ever, given the high speed at which the whole world is getting online.
We have a special keynote session on Thursday, I won’t say too much as I would prefer not to give away the surprise. All I can say is that James Lyndsay as host, will have a nice chat with a real senior reference in software testing, someone who, throughout his career has trained over 20,000 testers! Be prepared for a different approach to waking up at a conference in Manchester. Senior experience will be shared with the audience. New insights will be held against historical evidence. If you want a history lesson in testing, Thursday will be the day.

We end the conference with a speaker many of our delegates have asked for: Paul Gerrard of Systeme Evolutif. Many of you know Paul and some might also know that Paul is a highly committed rowing coach. Paul will share his experiences of coaching a rowing team and how this can give original and provoking insights into managing and developing a Test Dream Team.
So, I hope these keynote speakers are to your liking. Each of them are definitely experienced testers, witty speakers and just great people to have around.

Next to these keynotes, we added a couple of new refreshing things to the program to enhance the networking at the conference and to facilitate the assembly of a Dream Team. You’ll have a chance to do some “speed dating” with other testers, more details will come later. We will organise a contest which involves assembling the Greatest Dream Team. A bit like the Harlem Globetrotters of Testing!

I also invite you to have a look at the tutorials that we provide prior to the conference, on Monday 5th and Tuesday morning 6th of December. Some of the top trainers in software testing will be there to teach you the ins and outs of software testing. There will be sessions for junior testers, but also for experienced professionals. I won’t go over all the names, but I do like to point out that Martin will be there as well. You all know Martin Pol, Program Chair 2005. Martin is probably the most warm-hearted software tester I know. He embodies the essence of what it takes to make a Dream Team. Meet Martin and the other teachers in Manchester.

If all this is not enough, we have also arranged for an excellent venue for the after-show party.... a Gala Evening in Old Trafford, home of Manchester United. Who would want to miss this?

So I hope you’ll like what we have compiled for you this year. For those who submitted proposals and did not get selected, I do understand your disappointment at not being on the program. I sincerely regret that we could not give each and every one of you a slot. Many proposals were lovely stories I would love to have shared.
A final word perhaps on the Program Committee. Stefan Steurs, Clive Bates and Geoff Thompson who not only reviewed all the proposals, but also did a great job at reviewing and rearranging the program and making it nicely balanced. Thanks a lot guys for all your great help.

I’ll be talking to you in a next issue of this newsletter or meeting you all of course in Manchester.

Best Regards,

Jens Pas
Programme Chair


Click here for EuroSTAR 2006 Programme.

Operational Excellence through Efficient Software Testing Metrics

Below is an article from Ramesh Pusala asking why do we need software testing metrics. It's a interesting perspective & I hope you enjoy it! The article was published in the first edition of the New EuroSTAR newsletter.

Click here to view the entire EuroSTAR newsltter and to subscribe to future monthly editions.

Why do we need software testing metrics?

As we all know a major percentage of Software projects run over schedule and budget, yet they still have quality problems. Software testing is one activity that can provide visibility into product and process quality. Test metrics are among the "facts" that project managers can use to understand their current position and prioritize their activities, so that they can reduce the risk (or impact) of running out of time before the software is ready for release. Test metrics can be a very powerful risk management tool. Metrics help you measure your current performance and allow you to use the data to enhance your future work estimates and quality levels, otherwise those estimates will just be guesses!

What Metrics do we need?

Only collect data that you will actually use (to make informed decisions and alter your strategy). That is, if you were not going to change your strategy regardless of the findings, your time would be better spent doing more testing.

Do not base decisions solely on data that is variable or can be manipulated. For example, measuring testers on the number of tests they write per day could actually reward them for speeding through superficial tests or punish them for tackling trickier functionality.

Use statistical analysis methods to get a better understanding of the data.

Some of the key benefits of having good metrics are:

* Test Metrics Data Collection is a balanced, leading initiative which guides in predicting the direction and scope of an organization in the long term and helps to gain a more holistic view of business and identify high-level goals.
* Provide a Basis for Estimating and facilitates planning for closure of the performance gap.
* Provide a Means of Control / Status Reporting.
* Identify Risky Areas That Require More Testing.
* Provide Meters to Flag Actions - this helps make faster, more informed decisions.
* Quickly identifies and helps resolve potential problems and identify areas of improvement.
* Test Metrics are mechanisms to measure the effectiveness and efficiency of testing quantitatively.
* Supports the collection of usage data and metrics for particular business needs.
* A process is appropriate and is critical to success when it identifies measurement strategic objectives and measures against those using technology and industry accepted methodology.

Challenges in implementation of Metrics Program:

Ø Management Commitment:

Ø Measuring Too Much, Too Soon:

Ø Measuring Too Little, Too Late

Ø Wrong Metrics

Ø Vague Metrics Definitions

Ø Using Metrics Data to Evaluate Individuals

Ø Using Metrics to Motivate, Rather than to Understand

Ø Collecting Data That Is Not Used

Ø Lack of Communication and Training

o Explain why

o Share the results

o Define Data Items and Procedures

o Obtain "buy-in

Ø Misinterpreting Metrics Data

Suggested Metrics Lifestyle:



Goal-Question-Metric (GQM)
The key to efficient measurement is to first determine which goals you are striving to accomplish and which problems you are attacking. Many organizations waste time and money by measuring more things than are necessary. Before beginning a measurement strategy, determine the goals for your measurement. GQM is an excellent technique for selecting appropriate metrics to meet your needs. With GQM, you begin by selecting a few project or organizational goals. Then state the goals to be as quantitative and measurable as you can, then ask questions as to what is it that you want to change to reach the goal, then finally define what is it that you want to measure to quantify your progress towards achieving the goal.

Specially Motivated Test Resource

Below is an article from Thorkil Sonne telling the amazing story of Specialisterne, his company and how he hopes to reverse the terms of normality. It's a great story & I hope you enjoy it! The article was published in the first edition of the New EuroSTAR newsletter.

Clcik here to view the entire EuroSTAR newsltter and to subscribe to future monthly editions.

A fragile world

6 years ago my youngest son was diagnosed with autism (Autism Spectrum Disorder). I was given a chance to get a glimpse of the fragile world of autism.

My son frequently impresses me with his skills derived from strong memory, attention to detail, motivation for tasks, correctness in communication and learning ability.

But he also worries me, as he does not comply with the social requirements in society. As an IT-professional with 15 years background, I can see that his skills are potentially valuable to the corporate sector. After 3 years as president of a local branch of Autism Denmark, I can see that my son will only have a very small chance to use his special skills in a job situation.

Someone has to make a difference - so I quit my job as CTO to establish a company for persons with valuable skills and who are non-compliant with the social requirements of most companies.

Specialisterne

To get a job in most ‘normal’ companies, you have to comply with social requirements like: flexibility, social skills, team player, humour with flair for irony and a high stress threshold. If you do not match the social requirements – then you are left out.

At Specialisterne we reverse the terms of ‘normality’.

We define ‘normality’ as ‘whatever the majority decides it to be’. In our company the employees are the majority and thereby set the standards of ‘normality’.

We expect our candidates to stick to planning, schedules and agreements, require special working conditions, are strong individuals, have attention to detail and concentrate on doing what they are good at.

By being accepted as ‘normal’ at Specialisterne our employees build up their self esteem and put their full efforts into providing unparalleled quality in testing for corporate customers.

The customers

The customers of Specialisterne are small, large and global companies with high test standards. We perform any kind of test, where domain knowledge is not a requirement.

For different customers we perform tasks like:

* test management
* establish or improve test documentation
* static, dynamic, beta and system tests

Our customers will have ISEB test certified project managers as single point of contact to make sure, that it is easy for the customer to get access to the special skills of our employees with no risk to the customer.

Our customers are positively surprised by the skills of our employees and present us with high scores on the satisfaction evaluation report and we frequently see comments like: “The Specialisterne employees have impressed us with their ability to maintain attention to detail throughout the entire test, giving us a thorough result.”

Perspectives

The Specialisterne concept is a success in Denmark where so far 27 employees with the mild form of autism, Aspergers Syndrome, have found a niche to perform tests for corporate customers.

The needs for motivated testers are the same internationally – and so are the needs for alternatives for persons who do not fit into standards of ‘normality’.

I intend to reuse the experiences gained at Specialisterne to spread the concept internationally and build bridges between the corporate sector and the potential of specialist resources worldwide.

The roll out will take place where Specialisterne can join efforts with large and global companies to benefit from adding a new brick to the puzzle of setting up Test Dream Teams.

EuroSTAR 2006

At EuroSTAR 2005 I had the privilege to present the paper ‘Adding Autism Competencies to Testing’. I told about our vision, skills and experiences so far. The presentation was awarded ‘Best Presentation’.

I am very happy for the invitation to do a key-note presentation at EuroSTAR 2006.

I will present to you the Specialisterne concept, experiences, and references – and discuss the perspectives of how you can benefit from the experiences gained at Specialisterne.

Best regards

Thorkil Sonne
Founder and CEO
thso@specialisterne.dk
www.specialisterne.dk/english

It’s About People!

This is an article from Jens Pas, the EuroSTAR programme chair for 2006 which was published in the first edition of the EuroSTAR Newsletter. It is entitled 'It's about people' and pays special attention to the importance of people issues within the testing profession.

You can view the entire EuroSTAR newsletter by clicking here

My biggest surprise when reading all the submissions was that so many people really sent in proposals very closely related the theme of the conference “Assembling the Dream Team”. Many of you have a lot of experience to share when we talk about people issues. Thank you for providing us with all this real life experience. You allow us to offer our delegates a very interesting and, most important, “human” conference.

Aside from the submissions, I also experienced what people can be and can do. As I already said, 20 reviewers and a Program Committee have voluntarily processed the submissions. In addition, many have provided us with great ideas we might want to incorporate into the conference to make it even more interesting, fun and innovative. Combine the lively EuroSTAR-community with the professional team of Qualtech, who manage this event, and you have a highly energizing cocktail. Everybody is very motivated to make this conference ‘the’ event of the year for the European Testing Community. It is this testing community that has given me the energy to try to distill a program that, I hope, you will appreciate. It’s a luxury to be able to work under these pleasant conditions.

If we look more closely at the topics people are proposing, you’ll notice a lot is about communication and the ‘issues’ this generates. It seems that, as opposed to the clear and well defined TCP/IP standards computers use to communicate, we, humans have a lot of trouble in understanding each other. When a computer has a communication hick-up, such as packet-collision, it simply sends the information again. When humans collide…well, they collide… and that’s about it. Communication stops.

On top of that, we seem to live in different worlds. IT professionals have their language, business people use another. Developers even have a different dialect it seems, compared to testers. So, we not only have the challenge of managing a communication process, we have compatibility issues.

I guess everyone has experienced what I describe above. This is confirmed by the vast amount of testimonials that came in with the presentation proposals. As I read through all these papers I saw that many people have found their own way of dealing with this challenge. Some use discussion techniques, such as the Six Thinking Hats of De Bono. We will address the use of the Hats for testing at the conference. Others perform a team analysis to improve communication and co-operation. And again others discuss the infrastructure that we need to be able to optimally work together. They propose frameworks for value setting of the team allowing organisations to assemble a team that has a compatible set of working values. There are even standards and certificates which can be deployed in your organisation to improve the interaction between people. All this will be discussed in Manchester.

Each of these solutions contributes to making a group of people a team that generate value. 1+ 1 = 3 as they say.

In the next edition of this newsletter, I look forward to being able to announce the official conference programme. Names will appear and I hope you’ll like them. After all, it’s all about people.

Let me conclude this first article by repeating a metaphor I used in Copenhagen, last year, when I invited you to come to Manchester:

Take two glasses of water, half filled. Pour the water of one glass into the other glass. You now have one full glass of water. The beauty is that you cannot see anymore which water came from which glass. They are stirred, not shaken, into a transparent homogeneous drink. Wouldn’t it be great if our software team would be like this glass of water, a Dream Team assembling great software.

I look forward meeting you in Manchester.
Best Regards

Jens

Read the entire EuroSTAR Newsletter by clicking here

Ready to Ship? – Using Release Readiness Metrics

This is an article from John Fodeh which was published in the first edition of the new EuroSTAR newsletter. This article is an excerpt from John’s 2005 Tutorial in Copenhagen entitled "Establishing an Effective Test Metrics Programme". This tutorial sold out in advance of the conference.

To view this article and all other articles, view the EuroSTAR newsletter here

Why Measure?

A metric is a measure. "Measurement is the process by which numbers or symbols are assigned to attributes of entities in the real world in such a way to describe them according to clearly defined rules" (Fenton, Pfleeger). As you know, metrics play a crucial role in the advancement of all sciences. This should also include computer science. Tom DeMarco stated, "You cannot control what you cannot measure". In software development and testing we use metrics to:

* Understand: Gain insight into the applied processes and identify relationships. We use measurements to establish a baseline and goals for future assessment.
* Assess: Determine status with respect to plans and goals, and then monitor progress.
* Predict: Detect bottlenecks, early warnings of problems and determine what tradeoffs can be made.
* Improve: Identify root causes and learn from historical data.
* Communicate: Visualize status and trends, and share the knowledge with the rest of the team.

What Metrics Are Needed

Some organisations select a single or a few isolated "golden" metrics to collect and monitor. However, most metrics are not useful when used separately. For example, the number of defects found during testing has limited value until it is combined with other data such as the severity, type and root cause of the defects, the number of defects fixed, the type and effort of testing, the number of defects found by the end-users, etc.

On the other hand, having too many metrics to collect, analyse and report can be infeasible and problematic. There are numerous aspects in software development and testing that can be measured and it can be tempting to do so. However, spamming your team with tons of metrics is certainly not the answer (and will probably not be appreciated as well).

Instead of spending your time on a multitude of metrics that you or someone else might find useful sometime in the future, your time is much better spent doing more testing. The solution is a suite of key metrics. This set of metrics should be simple and balanced and help you track progress toward your target, i.e. release readiness.In this respect, applying a metric paradigm such as Goal/Question/Metric (GQM) can be very effective. GQM provides a formalised framework for developing a metrics programme, prompting you to think; "what information do I need?" instead of "what is easy to measure?" In other words, to derive your set of metrics you need to know what you need to know.

The following describes some basic metrics that you can use and include in your set of release readiness metrics.

Test progress

Test progress metrics include information concerning the status with respect to the plans, e.g. how many of the planned tests have been run? What is the pass rate of the tests? Throughout development this information will show the current status and help detect bottlenecks and early warnings of trouble, e.g. if we have only completed a fraction of the planned tests and the pass rate is low, is it still possible to finish on time with the available resources? When approaching release this metric will speak for itself; can we release the system with the current test completion status?

Obtained coverage

Coverage metrics hold vital information regarding the thoroughness and completeness of the testing. Coverage can be expressed in terms of requirements, code or risks and provide the means for quantifying the portion of the requirements/code/risks that is exercised by the applied testing. A low value reveals an insufficient test effort and the risk of potential latent defects. This metric is typically used in conjunction with the test progress metrics and can reveal details not seen from the progress data. An example could be the situations where many tests have been completed while critical requirements or high risk areas remain untested.

System quality factors

Data about system quality factors contain information on different aspects of the product, such as functionality, performance, reliability, installability and conformance to standards (you might also consider using ISO 9126). I prefer to show the test completeness of these quality factors combined with information about the defect density. In this way I can monitor progress in the different areas and detect if some deserve special attention.

Found defects

Defect metrics are usually collected by applying the appropriate queries in the defect reports database. The metrics typically include the total number of defects reported and categorised in open and closed (fixed and verified) defects, sorted according to their severity.

This data delivers a snap shot of the system state at release time, making it possible to take into account the risk and consequence of releasing the system e.g. If the data reveals a large number of open high-severity or non-verified defects, then it clearly shows that releasing the system at this moment is a high-risk decision. By depicting the found defects over time (or test effort) it is possible to create a defect trend. A defect trend is a graph showing the accumulated number of reported defects as a function of test effort (expressed in terms of test days).

This graph is typically S-shaped. When testing is started, the defect-finding rate is low, as the functionality of the software is restricted to few areas and because showstoppers might prevent testing in some areas. The defect-finding rate increases with the addition of new functionality and the correction of already found defects. As the software matures, the defect-finding rate starts decreasing, as it becomes harder to find new defects. Ultimately, the graph flattens. Finding further defects at this stage requires a huge test effort and shows that the software is possibly ready for release (or that the limitation of the applied testing technique has been reached).

Monitoring the status on the S-curve helps to determine when to stop testing, i.e. is the curve starting to flatten?
It is even possible to extrapolate the graph, providing a predictive evolution of the defect-finding rate and a means of estimating the number of unknown defects.

Customer feedback

User feedback during development is of major importance. During testing we normally verify that the system performs as specified, i.e. "are we building the system right?" The user evaluation data helps you answer the question: "are we building the right system?"

Summary

Successful test management involves making complex decisions. These decisions need to be based on solid, quantitative data and well-calculated risk. Using a simple set of metrics you can get a snapshot of the system state and quality that is useful throughout the entire development process. However, in the closing stages, possessing the right metrics has a tremendous value, in particular when you need to find the proper timing for release.

To view the EuroSTAR Newletter, click here

The EuroSTAR Newsletter

As you may know, EuroSTAR have begun to send a monthly newsletter to tester's throughout Europe. This all new Software Test focused newsletter will contain a variety of articles from some of the industry's leading visionaries in Software Testing.

This months's articles include "Ready to Ship? - Using Release Readiness Metrics" from John Fodeh, and "Specially Motivated Test Resource" from Thorkil Sonne, winner of the best presentation award at EuroSTAR 2005 who tells a remarkable story. There are also articles from the EuroSTAR 2006 programme chair, Jens Pas "It's all about people" and further information on the Free EuroSTAR mini events taking place in the UK & Holland in early May.

To receive the 1st edition of the EuroSTAR newsletter and further monthly editions, Sign up to the EuroSTAR Newsletter

Testing "Big Picture"?

Hi all!

First let me introduce myself: my name is Erkki Pöyhönen (or Poyhonen for those with keyboards without funny dotted characters :-) and I come from Helsinki, Finland. Some might remember me as the EuroSTAR programme chair of 2004. I recently moved back into a consulting role after few years in a R&D management role.

I really enjoyed some of the posts in here, especially the one about the maturity. For most of the past decade I've been concerned about testing competence. That's why I'd like to share my recent quest to the testing big picture.

In large companies test teams or units grow an internal testing culture. It is a natural way to manage complexity: based on our experiences we learn self-evident ideas, what is important, what is possible, and so on. This means that after a while two organisations in different contexts (differing business situations, working with different technologies or producing different products) have developed different sets of axioms -- "self-evidents".

I suppose this really is natural and good for individuals and teams in general. The hard part comes from having to co-operate with other organisations or adapting to the changing conditions. If testers are not aware of their culture or their context, they might totally devaluate everything coming from a person from different organisation. This can be seen in attitudes into literature, training or cross-organisation co-operation; it is easy to dismiss quite valid outside information saying simply "that was not relevant for us; it is made for another organisations; we are special". BTW: good, welded teams share that elite feeling, so feeling special is not bad as such. It becomes a problem only when it prevents us to learn from others for being different in a vague way.

As discussed not so long ago in software-testing mailing list (a wonderful email list of the context-driven testing school with rather high S/N ratio; somewhat slanted to agile thinking) it might be more useful to have 5 times one year experience of different organisations than having a 5-year experience working in similar projects. I agree. And I'd add that working for both product and project organisations is useful, and working both in industrial setting and high-tech IT industry.

Working with one product year, year out (like in Telecoms used to be quite common) allows both testers and developers to optimise their approach and practices for efficiency. But for example changing into another technology can be a disaster. Or a test team might work parallel in tens of different projects for many customers in varied businesses. Of course the focus would be more into adaptability and learning, but achieving repeatable practices or sustained organisational improvement might be harder.

My newest project is building a repository of generic testing information that is useful for induction, competence development and process improvement. Building such a beast for any certain context is simpler: find the relevant sources and then assume this is good for us to know. Trying to be useful for a wider audience means: identifying context behind all sources and material, highlighting the assumed context-dependencies and sourcing the generic ideas from context-specific material.

Suddenly many common words are not so common any longer. Example: a test plan is for many "a reviewed text document, based on a template and that nobody reads". For others it can be a wall in the team meeting room. Or if the main constraint is delivery date it can be very unproductive to assume that quality is the driving factor.

Good news is that we need not fight over certain testing terms with religious intensity, if we identify we come from different contexts. It becomes more important to learn the "one step up" definition - what does this thing really mean, and not focus on how does it look like in different organisations, or "what do we ideologically hope this should mean for everybody".

It is easier to look for material supporting my current view than take the small extra effort to learn from sources of other contexts. But sticking to a strict "one testing" viewpoint takes energy, is counter-productive and prevents us from developing our industry forward. Widening my horizons and listening to (and getting to know) people from different industries has exactly been the biggest pay-back for me from attending testing conferences. And where else to do this better than in EuroSTAR again next December?

Tester maturity

Someone asked me the other day 'What makes a mature tester'? Which set me thinking, as these things do.

Maturity in cheese or wine means age - if kept in the right conditions. A mature cheese or wire is differentiated by a certain quality of smell, taste or appearance that is hard to achieve in any other way. A deepening, a richness, a complex subtlety amalgamating into a coherent whole. This is valued. Sometimes, the dulled mess is only valued because maturity takes time to achieve, and because rareness and maturity are linked. The process of maturing can change, with maturity or inappropriate conditions, into one of spoiling.

For testers, as with cheese, I believe that length of experience is less important than the conditions in which that experience is gained. Maturity is not just experience, but, perhaps, expertise tempered by perspective. I do hope it's not a certain smell.

Maturity in testers might be characterised by a coherent vision, based on a deep and diverse set of experiences and sources. Perhaps there is a process of over-maturing, perhaps a hardening or vinegary sharpness about some testers. Unlike cheese or wine, however, testers can reverse this process.

There are plenty of ways of gaining expertise and developing perspective - the most important for me, so far, have been to do with practice and communication: working in a wide range of businesses; engaging in discussions with other testers, designers, coders and users; showing people why and how I've made a particular decision. There's a difference, of course, between what _makes_ a mature tester, and what _marks_ a mature tester. Training doesn't make a mature tester. Certification doesn't mark a mature tester. There's no vintage certification on testers, or use-by date on their ideas.

Am I a 'mature' tester? Do I want to be? I'd rather be a tester who reverses the process occasionally, and goes back to the fundamental, rapid and joyful changes of immaturity. Hence this half-baked post; I'm going to learn about blogging, and see where I get. I have a handful of other things I'm learning about this year, too - perhaps one will grow to some sort of maturity, but I hope I'll learn from them all.

Short Intro

Hi all!
As my parents always told me to introduce yourself politely to other people, I would like to use my first post to do so.
I'm Erik Boelen, working as a Test Manager/Test Consultant for the company CTG in Belgium.
This is my sixth year in the testing world, and still learning a lot every day over and over again. Therefore, I decided to subscribe to this blog, as its intention is to share experiences, knowledge, ideas and who knows, maybe even dreams about testing!!
Concerning Eurostar, I've had the honour to be a speaker once, in 2003, with the subject 'The Agile Way to Success'. This year, I sent in another proposal and really hope to be selected again.
For me, Eurostar was a learning and fun experience, to put it very simply. I met people from all over Europe who have different opinions about testing and how to deal with it. This resulted in very interesting discussions during the day and very funny outcomes during the "evening sessions".
My personal interest goes out to Agile Testing. Currently, I'm responsible for this area within my company and hope to receive and share some interesting ideas about the subject through this blog.

Cheers!
Erik

Welcome to the offical EuroSTAR blog

Hi,

Thank you for taking the time to investigate this, the new EuroSTAR blog dedicated to the European software testing community and in particular, those testers that have or intend to attend EuroSTAR in the future.

We hope that this initiative will create an online meeting point for European software testing professionals where you can share your individual EuroSTAR experiences, thoughts and importantly ideas for the future. Also, we aim to facilitate continous interaction between those of you that met at EuroSTAR so that you may continue your discussions, debates or even differences of opinion long after the curtain has fallen over the final EuroSTAR session of that year.

Our aim at EuroSTAR is to create the conference you want to attend, to have the speakers you want to hear and the companies you want to speak with. With this in mind, please feel free to let us know what we can do to improve in order to make EuroSTAR an even better experience for the entire European software testing community.

Read through some of the posts below to see what other's have to say about their own EuroSTAR experiences.

Please remember to email us at kevin@qualtechconferences.com so that We can invite you to become a member of the offical EuroSTAR blog. We look forward to hearing from you!

Happy blogging,


The EuroSTAR Team

Reflections of a Programme Chair

Hi, I'm Martin Pol and I was programme chair for EuroSTAR 2005 in Copenhagen.

2006 will witness the 14th EuroSTAR to be held in Manchester, UK. As last year's programme chair, I have been asked to share some of my thoughts about EuroSTAR and what it represents.

I have been fortunate enough to attend 12 EuroSTAR's to date and I am proud to have been programme chair for three of these. EuroSTAR represents quality, networking and socialising with fellow professionals while importantly it offers the testing community the best meeting plaza to exchange experiences in what is a rapidly changing testing scene. It also offers each tester the opportunity of world class training and to learn from the very best practitioners in the field!

Over the course of my association with EuroSTAR, I have met many like-minded people. discussed many challenges with them, had a great time and lots of fun and what is significant made numerous friends over the years. I have witnessed pioneers and innovators take their first steps in presenting to an audience, I have seen their nerves and I have seen them make excellent keynotes in the proceeding EuroSTAR's. I would encourage each tester who is passionate about their profession to get involved and present your contribution or experiences, the call for papers is now open for 2006, so why not take the plunge and submit??

The networking element of EuroSTAR is of huge importance as it is a forum to:

• Bridge practise and theory from the academic world
• Discuss solutions with top experts
• Debate the content of books with the authors the authors themselves
• See how testing is approached in other organisations/countries
• Actively participate in forums and workshops

In addition, the exhibition is home to all of the main players in the testing market and is an excellent place to gather information on the newest tools and most up to date method's, discuss partnership possibilities and to view what is available in the marketplace that would best serve your specific needs. The exhibition is also an excellent chance to showcase your own testing tools and services.

The face of software testing is changing, as a profession it is growing and as a result EuroSTAR has become even more important. I hope to see you all in Manchester this December to discover the solutions to the mutual challenges we face as testers and to share our individual dissapointments and successes - See You There..

Martin Pol