Don’t Forget The Retrospective!

A retrospective is a valuable tool in any organization which values and expects continuous improvement.


A retrospective gives the opportunity to:

• look back and assess;

• consider;

• take everything into account;

• identify lessons learned;

• acknowledge success;

• try to set a better course for the upcoming project, or continuation of the current project;

A retrospective is a chance for the team to improve what they are doing and how they feel about what they are doing. By not holding regular retrospectives, teams are missing out on a valuable opportunity to grow and succeed.

Retrospectives enable whole-team learning, act as catalysts for change, and generate action.

Retrospectives empower team members and allow each and every member of a team to contribute and feel heard. Team members can see how they actively contribute to the increased success of the team.

Retrospectives focus on real problems that affect teams. During retrospectives, teams discover real solutions that they can implement immediately. Note, that it is the team who discover the real solutions. The solutions are not dictated to them from outside the team. This is where empowerment kicks in!

Organization is the key to an effective retrospective. Everyone must be made aware of the manner in which the retrospective will operate and what is expected of each and every participant.

Here are some suggested rules of engagement:

• We will try not to interrupt. (If the meeting is held over multiple sites, please verbally indicate when you are finished speaking – this will aid everyone as sometimes we can think the other person has finished speaking when they have not as we don’t have access to the visual clues.)

• We will accept everyone’s opinion without judgement.

• A reason should accompany each opinion.

• We will accept everyone’s supporting reason without judgement.

• We will talk from our own perspective. We do not try to imagine the perspective of others who may not be in attendance.

Set out the main objective of the meeting, for example, “The main objective of the retrospective is to seek out and understand the perspective and feedback from each member of the team. We will collate all feedback into positive and negative lists.”

Every opinion and perspective is valued!

The collated feedback from a retrospective can then be used to feed process improvement through the next stages of the project or into the next project.

Don’t forget: a retrospective is an opportunity! Don’t miss it!

Freakonomics

Freakonomics is a book by Steven D. Levitt & Stephen J. Dubner.

It has nothing to do with testing.

However, it’s a great read (very easy to pick up, read a chapter, get on with your life, pick up, read another chapter, and so on).

Plus, it makes you think! I love this, I love that feeling you get in your head when your pre-existing ideas and concepts are intellectually challenged and suddenly you can see in your mind all these doors opening that each leading to new ideas and new challenging concepts.

Via real world examples, it illustrates the difference between causation versus correlation.

This does have an impact on testing, albeit subtle and indirect.

When I root cause analyze a bug I’ve found, I need to be able to differentiate between what actually caused the bug and what just happens to exist alongside the bug.

Quick example: Drowning and ice cream sales are positively correlated. An increase in ice cream sales does not cause an increase in the number of people who drown.

I believe that critical thinking skills are essential if you are to become a really good tester – this book helps to develop those skills. And it’s actually pleasant to read!

Reference: http://freakonomics.blogs.nytimes.com/

New To Testing?

Recently, two new engineers joined my team. They were straight out of university and had no formal testing experience (other than an hour of making sure the code does what the professor asked – not really testing).

This afforded me a great opportunity to stop and think about how best to develop people new to testing into truly stellar testers. So what was my training plan?

1. Read Testing Computer Software by Cem Kaner, Jack Falk, and Hung Q. Nguyen.
   
2. In parallel, run through the software under test tutorials which we release to our customers.
   
3. In parallel, learn PERL (our scripting language of preference) where they coded specific scripts to solve a detailed specification. The script would invariable support testing.
   
4. In parallel, study ISTQB Foundation and pass foundation exam. ^Note1
   

This was their first month.

Then they had to use what they learnt.

1. Participate in paired testing sessions with more experience testers (mentors).
   
2. While testing, any bugs they uncovered, they would report while being guided by their test mentor. Thereby learning how to write effective bug reports.
   

Then, it was time to walk on their own.

1. Participate in test bashes where they are given a small bounded area of the software that is well described, has low complexity, with support from peers who have high expertise in the software under test.
   
2. File bugs where appropriate.
   
3. Create summary reports for development and stakeholders on test coverage, test results and quality opinion.
   

Within 2 months I was receiving feedback from testers and developers at other sites around the globe praising the contribution of the new testers. Now, 6 months on? I have two great testers who I trust. They find good bugs, high priority bugs. They are great at critically analyzing the software under test and I continue to get regular feedback praising them.

At the time, it was quite a turnaround to invest so much time and energy in development. Previously, most people joined and started bashing away at the tool within hours of setting foot on company soil.

The investment has paid off and we continue to prioritize their learning in parallel to their project work today. These two engineers have a very bright future in testing and will easily surpass me and their more "experienced" peers in a very short time! Success!

How did you learn to test? How do you train testers in your organization? Please let me know, I'd love to have some external input.

Note1: The ISTQB Foundation Certification by no means equals testing proficiency. Frankly, in my opinion, the foundation exam is more about terminology than anything else. However, it does give a sense of achievement and is something to work towards. Also, I found for engineers who are completely new to test, it was an effective discussion trigger. They would frequently have discussions between themselves regarding the topics covered in ISTQB as well as asking me questions regarding the actual practicality of testing versus the theory. From that aspect, I found it very valuable. The cost? Book + Exam Fee – not bad and the engineers felt a sense of achievement and career advancement.

Michael Bolton's Rapid Software Testing Course, Dublin September 13th

Rapid Software Testing 

• Date: Monday 13th to Wednesday 15th September 2010
• Venue: Xilinx, Citywest Business Park
• In association with Testing Times and Xilinx Ireland
• Duration: 3 day course (9.00am to 5.30pm)
• Cost to non-members: €1,700 per person
• Cost to Software Skillnet Members* after Grant aid: €770 per person

*Membership to Skillnet is Free

The course cost is all-inclusive for the 3 day course and covers all materials and refreshments   
This event is being grant aided by the Software Skillnet
Contact susan@isa-skillnet.com to book your place

COURSE DESCRIPTION 

Rapid Software Testing is a three-day, hands-on class that teaches testing as a sophisticated thinking art. The philosophy presented in this class is not like traditional approaches to testing, which ignore the thinking part of testing and instead advocate never-ending paperwork. Products have become too complex for that, time is too short, and testers are too expensive. Rapid testing uses a cyclic approach and heuristic methods to constantly re-optimize testing to fit the needs of your clients. 

The Rapid approach isn't just testing with a speed or sense of urgency; it's mission-focused testing that eliminates unnecessary work, assures that everything necessary gets done, and constantly asks what testing can do to speed the project as a whole. This class presents an approach to testing that begins with developing personal skills and extends to the ultimate mission of software testing: lighting the way of the project by evaluating the product.

One important tool of rapid testing is the discipline of exploratory testing-essentially a testing martial art. Exploratory testing combines test design, test execution, test result interpretation, and learning into a seamless process that finds a lot of problems quickly. If you are an experienced tester, you'll find out how to articulate those intellectual processes of testing that you already practice intuitively. If you're a new tester, hands-on testing exercises help you gain critical experience.


ABOUT MICHAEL BOLTON
Michael Bolton is an established and recognised leading-edge expert in the area of Software Testing. Michael has extensive experience in delivering workshops, tutorials, and conference presentations on the topic of Rapid Software Testing. He has over 20 years of experience in the computer industry testing, developing, managing, and writing about software.

Contact susan@isa-skillnet.com to book your place

http://www.isa-skillnet.com/Training_Courses/88 Software Skillnet
c/o Irish Software Association
Confederation House
84-86 Lr Baggot Street
Dublin 2
Phone: 086 8067200
Email: susan@isa-skillnet.com

Being an Effective Test Lead

The ultimate expectation of a test lead is to:

   "always do what most needs to be done without waiting to be asked"

A test lead position has both technical and managerial elements.

A test lead:

- is a domain expert of the software under test
- is a testing expert
- has testing experience to draw upon
- has project planning capabilities
- has excellent communication skills
- actively manages all stakeholders

However, the test lead also has responsibilities towards his/her team to:

- energize
- empower
- support
- communicate
- coach & mentor

The most important test lead function is to get his/her people excited and inspired - to energize them!

The second most important test lead function is to develop the skills and capabilities in his/her team so that they can get the job done efficiently and effectively!

A test lead is only ever as good as his/her team and it is the test lead's responsibility to get the most from the team.

A successful team = a successful team lead!

Test leads:

 
 

- get things done individually and through others
- use scarce resources to the best advantage
- cope with change and uncertainty
- achieve and deliver results individually and through others
- assess and proactively manage risks
- allocates testing resources where they are most effective and needed
- gathers evidence to support quality judgments
- coach and mentor
- delegate

Delegation is a vital tool in a test lead's arsenal. A test lead cannot do everything themselves. They must trust their team and delegate tasks to them. Delegation is extremely effective when executed well.

Delegation Hints & Tips
 
For delegation to be effective, test leads must also give authority to their team members and ensure that those team members have the resources necessary to complete tasks effectively.

The seven steps to effective delegation are as follows:

1. Communicate the task.

2. Set the task in context.

3. Determine standards.

4. Grant authority.

5. Provide support.

6. Get commitment.

7. Keep in touch.

Visit your team members and check their progress on a regular basis.

Use a formal system to track assignments and due dates.

Motivation Hints & Tips

Motivated team members are vital to the success of the project and the team.

To motivate your team:

- Personally thank people for doing a good job. Do it timely, often, and sincerely.

- Take the time to meet with and listen to people - as much as they need or want.

- Provide people with specific and frequent feedback about their performance. Support them in improving performance.

- Recognize, reward, and support the promotion of high performers.

- Provide information on how their work affects the greater scheme of things in the company. Show them that they make a difference!

- Involve people in decisions, especially those decisions that affect them. Involvement equals commitment.

- Give people a chance to grow and develop new skills, encourage them to be their best.

- Provide people with a sense of ownership in their work and their work environment.

- Strive to create a team that is open, trusting, and fun. Encourage new ideas, suggestions, and initiative.

- Learn from rather than punish mistakes.

- Celebrate success!

Remember: For the most part, YOU determine how motivated and de-motivated your team is!

Principles for Testers

Lisa Crispin & Janet Gregory propose the following ten principles for agile testers:

1. Provide continuous feedback
   
2. Deliver value to the customer
   
3. Enable face-to-face communication
   
4. Have courage
   
5. Keep it simple
   
6. Practice continuous improvement
   
7. Respond to change
   
8. Self-organize
   
9. Focus on people
   
10. Enjoy
    

I believe that these principles are relevant to all testers, not just agile testers.

Lisa & Janet define an agile tester as:

"a professional tester who embraces change, collaborates well with both technical and business people, and understands the concept of using tests to document requirements and drive development."

Again, this isn't unique to agile testing. In my mind, all the high expectations we have of agile testers should also be applied to any tester.

Why have lower standards for testers not involved in agile software development?

Reference: Agile Testing – A Practical Guide by Lisa Crispin & Janet Gregory