• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer

Satisfice, Inc.

Software Testing for Serious People

Rapid Software Testing A Context-Driven Methodology
  • Home
  • About
    • Privacy Policy
  • Methodology
    • Exploratory Testing
    • Reasons to Repeat Tests
  • Consulting
  • Classes
    • James Bach’s Testing Challenge
    • Testimonials
    • RST Courses Offered
    • Testers and Automation: Avoiding the Traps
    • Rapid Software Testing Explored
    • Rapid Software Testing Applied
    • Rapid Software Testing Managed
    • Rapid Software Testing Coached
    • Rapid Software Testing Focused: Risk
    • Rapid Software Testing Focused: Strategy
  • Schedule
  • Blog
  • Contact
  • Resources
    • Downloads
    • Bibliography: Exploratory Process
    • Bibliography: Risk Analysis
    • Bibliography: Coaching
    • Bibliography: Usability
    • Bibliography: My Stuff From IEEE Computer and IEEE Software Magazines
    • Bibliography: The Sociology of Harry Collins

Mr. Langella Never Does it the Same Way Twice

Published: January 2, 2014 by James Bach 4 Comments

This is from the New York Times:

Its other hallmark is that Mr. Langella never does the part the same way twice. This is partly because he’s still in the process of discovering the character and partly because it’s almost a point of honor. “The Brit approach is very different from mine,” he said. “There’s a tendency to value consistency over creativity. You get it, you nail it, you repeat it. I’d rather hang myself. To me, every night within a certain framework — the framework of integrity — you must forget what you did the night before and create it anew every single time you walk out on the stage.”

I love that phrase the framework of integrity. It ties in to what I’ve been saying about integrity and also what is true about informal testing: if you are well prepared, and you are true to yourself, then whatever you do is going to be spontaneously and rather effortlessly okay, even if it changes over time.

I often hear anxiety in testers and managers about how terrible it is to do something once, some particular way, and then to forget it. What a waste, they say. Let’s write it all down and not deviate from our past behavior, they say. Well I don’t think it’s waste, I think it’s mental hygiene. Testing is a performance, and I want to be free to perform better. So, I make notes, sure. But I am properly reluctant about formalizing what I do.

Doing your best work includes having the courage to let go of pretty good work that you’ve done before.

Filed Under: Agile Methodology, Ethics, Exploratory Testing, Test Documentation

Reader Interactions

Comments

  1. Joe Strazzere says

    2 January 2014 at 5:58 am

    “Testing is a performance” – I don’t believe I’ve ever heard that before. It’s an interesting thought.

    Can you expand on that a bit?

    In what ways is testing a performance? Are all jobs performances? Are all knowledge worker jobs performances?
    If not testing, are there any jobs which should be formalized?

    [James’ Reply: I will do a blog post on that.]

    Reply
  2. Jim Hazen says

    3 January 2014 at 8:05 am

    James,

    Nice! Very interesting post and way of framing the idea/discussion of it. I think you are right in the respect that we all have a particular ‘framework’ that we live in and work within. We all have base perceptions, assumptions and behaviours that we employ on a daily basis. But we use creativity (variability) to expand/change our perceptions, assumptions and behaviours. We are not robots, even though some people outside of testing (and some inside) do think so.

    Seeing “Testing as a performance” is an interesting concept and could be also stated that as part of our daily activities we will have multiple “takes” (changes and redo’s) in that performance. As Edison said “I have not failed. I’ve just found 10,000 ways that won’t work.”

    Reply
  3. Michael Bolton says

    3 January 2014 at 10:08 am

    The idea of testing as a performance, not an artifact, appears as the fourth premise of Rapid Software Testing. James and I co-authored thiis: http://www.developsense.com/blog/2012/09/premises-of-rapid-software-testing-part-2/.

    —Michael B.

    Reply
  4. Christopher Cordray says

    3 January 2014 at 11:44 am

    Hello,

    I have just read your blog “Mr. Langella Never does it the same way twice” and while I don’t have a lot a familiarity with your previous work in the field of Testing I thought I would proffer some comments.

    [James’ Reply: Thank you for reading. I’m going to take your comment seriously, and that means I’m going to argue with you. I hope you like that sort of thing…]

    I think there are times that certainly in testing if not other disciplines that you need to be able to both.

    [James’ Reply: We ought to be able to do what is necessary to fulfill our mission, yes.]

    In my limited experience (10 years) I have always found it very exciting the very first time I see an application or piece of software and I start to explore it (with informal testing) to find how it works and what its failings are. But, as you mentioned you take notes, which I presume is to aid you to reproduce tests if required especially once any issues found are fixed.

    [James’ Reply: There are a number of reasons I might need to repeat actions. See here.]

    Interesting that you have compared Frank Langella an actor, to the career of testing. I would agree that creativity and the ability to do the unexpected is a valuable tool to the testing process. I would argue that documentation and reproducible results are equally valuable.

    [James’ Reply: I would like to hear your argument, then. To me that’s something like saying that love is roughly equal, in value, to punctuality.

    If you were to present your argument please don’t simply list situations or cases where documentation or “reproducible” results are valuable. Let’s just assume that there are many such circumstances. I would not argue with that. But to say “equally valuable” what you have to do is argue for the essential, foundational value of documentation or reproducibility. I believe you will not be able to do that. We can live without documentation of any kind, in nearly all testing situations (and when we can’t it’s often due to regulatory requirements that don’t have anything to do with the quality of testing itself, but rather the level of trust that an organization has done what they have claimed to do). We can live without worrying about reproducibility in many situations. But we cannot call ourselves testers, with straight faces, if we are not able to design tests that find bugs. Design skill (which is what “creativity” means) is truly fundamental. The other stuff is helpful. The values of these things are not equal, and any time people posit them as equal they are actually insulting themselves as testers.

    I’m going to assume that you are a good tester. Well. IF you are a good tester, then your ability to conceive of an experiment that makes it very hard for important bugs to hide from you is the most precious thing you offer, by FAR. Honor yourself for that.]

    I look forward to reviewing your future and historical blog entries.

    Sincerely,
    Christopher Cordray

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

Search

Categories

  • About Me (17)
  • Agile Methodology (14)
  • AI and Testing (4)
  • Automation (20)
  • Bug Investigation and Reporting (9)
  • Buggy Products (24)
  • Certification (10)
  • Context-Driven Testing (44)
  • Critique (46)
  • Ethics (22)
  • Exploratory Testing (34)
  • FAQ (5)
  • For Newbies (25)
  • Heuristics (28)
  • Important! (20)
  • Language (35)
  • Management (20)
  • Metrics (3)
  • Process Dynamics (27)
  • Quality (8)
  • Rapid Software Testing Methodology (23)
  • Risk Analysis (13)
  • RST (5)
  • Scientific Method (3)
  • Skills (30)
  • Test Coverage (8)
  • Test Documentation (8)
  • Test Oracles (5)
  • Test Reporting (11)
  • Test Strategy (26)
  • Testability (4)
  • Testing Culture (96)
  • Testing vs. Checking (18)
  • Uncategorized (12)
  • Working with Non-Testers (7)

Blog Archives

Footer

  • About James Bach
  • Satisfice Blog
  • Bibliography: Bach on IEEE
  • Contact James
  • Consulting
  • Privacy Policy
  • RST Courses
  • RST Explored
  • RST Applied
  • RST Managed
  • RST Coached
  • RST Focused: Risk
  • RST Focused: Strategy
  • RST Methodology
  • Exploratory Testing
  • Testing Training
  • Resources
  • Bibliography: Exploratory
  • Bibliography: Risk Analysis
  • Bibliography: Coaching
  • Bibliography: Usability
  • Bibliography: The Sociology of Harry Collins
  • Schedule
  • Upcoming Public Classes
  • Upcoming Online Classes
  • Public Events
  • Tester MeetUps

Copyright © 2025 · News Pro on Genesis Framework · WordPress · Log in