RSS

Tag Archives: context-driven

Rapid Software Testing – Reading Recommendations

Having just completed Rapid Software Testing twice in two weeks with James Bach, I’m feeling motivated and inspired to continue learning.

Here’s a list of books recommended by James during the course. These will enhance your skills and change the way you look at testing.

RSTReading

The first book may be the most important, and the most difficult to read. I’m still getting through my copy. The content is excellent, and there’s a lot to take in.
The next 4 books are real page-turners, explaining important and complex information is a way that’s enjoyable to read.
I haven’t yet read the last book on this list.

An Introduction to General Systems Thinking by Gerald Weinberg
Thinking, Fast and Slow by Daniel Kahneman
Tacit and Explicit Knowledge by Harry Collins
Lessons Learned in Software Testing: A Context-Driven Approach by Cem Kaner, James Bach, Bret Pettichord
The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully by Gerald Weinberg
Discussion of the Method: Conducting the Engineer’s Approach to Problem Solving by Billy Koen

If you’ve already read these books, I’m interested to hear your thoughts. For example, what was the biggest takeaway you got from each book, and how has that helped you with software testing?

 
7 Comments

Posted by on August 14, 2015 in Learning, Software Testing

 

Tags: , , , ,

What’s Your Context? – Workshop with Fiona Charles

How do you discover the differences in context between clients and projects, and whether those differences matter? While intuition is important, unconscious analysis and choices lead to unconscious assumptions – Fiona Charles

Ask a tester which approach is the best way to test software. The typical response will be “It depends”. But what does it depend on, and why? How will those facors affect testing?

Fiona presented her “What’s Your Context?” workshop to the Auckland WeTest meetup group. We split into 6 groups to brainstorm the elements of context that affect our approach to testing. It’s difficult to report on the value gained from attending a workshop, as the learning comes from being involved in the discussion. Here I’ve recorded my brief notes on the “Aha!” moments described by others at the end of the workshop.

Me: I’ll be doing this exercise regularly for projects I work on. More aware how much context can change during the course of the project.

Natalia: It was very useful to learn about other tester’s contexts.

Pete: Two favourite sayings are ‘It depends’ and ‘Why?’. For example, ‘Why are we doing this?’.

Morris: We say ‘team’ a lot. Testing is a team sport.

Vikas: Highlights the importance of thinking about context deliberately, instead of repeating past processes.

Shaheem: Maintain a risk focus, which things can derail or negatively impact the project.

Chris: The definition of Minimum Viable Product is heavily context-dependent.

Georgia: Focus on the problem being solved. Take history into account. Appreciate the benefit of informal communications (this arose in the context of working with offsite teams).

Vincent: Like the experience of working with his team, learning from their experiences, and the way they grouped elements of context together into personal, product, team and development methodology.

John: So many sources of information beyond just requirements. Stop and consider context first before you get started.

I encourage other testers to take Fiona‘s workshop. Her questions, insights and stories brought the exercise to the next level.
In the meantime consider pairing up with one or more testers and asking yourselves, “Which elements of your context affect your testing? Why, and how? How can you use this information to improve your testing approach for your current project?”

 
1 Comment

Posted by on November 10, 2014 in Software Testing

 

Tags: , , ,

Simplified Estimation

I’ve wasted a lot of my time estimating future testing activities down to the number of days, for minor and major releases of complex systems. Now I’m considering a new approach.

I will review whatever materials are available for the project, speak to stakeholders about their primary values and concerns for the project, gauge the budget for number of test analysts and choose one of the following estimates:
– 6 weeks
– 3 months
– 6 months

The numbers may change slightly of course, but essentially this is the level of estimate breakdown that I’m prepared to provide at the outset.

My reasoning is that any up-front estimate will be rendered inaccurate due to a large number of unknown factors, and past experience at detailed estimation efforts have proven to be futile. I can continue wasting my client’s time and money, or we can take a broader view of estimation and revise that estimate when I’m elbow-deep in the project and have a clearer understanding of the risks involved.

A key success-factor for this approach will be transparency and regular reporting. To be effective in my role as test manager, I need the support of the project manager and stakeholders. They are much more likely to be supportive when provided with a clear understanding of the top few goals, achievements, risks and issues facing the team each week.

So, how can I tell if testing is running on-time or going over schedule? Well, I’d have to ask you to consider – what does that question even mean? If your testing is running to plan (somehow) and you find a defect which causes a decent-sized code re-write, is your testing still running on time? Was it in any way useful to report that you were running “on time”? Instead I report clearly on what has been tested, the most important outstanding issues and the product areas which are yet to be tested.

Another key success factor is commitment to quality and efficiency. Only when the whole team are focused on delivering a quality product efficiently can this approach to simplified\iterative estimation be successful. Simplified estimation is not about laziness, it’s about expending efforts where they will be of most benefit.

Thoughts?

 

 
7 Comments

Posted by on June 8, 2014 in Software Testing

 

Tags: ,

 
%d bloggers like this: