Skip to main content

Famous Movie Quotes applied to Software Engineering - Cool Hand Luke

I thought it might be a bit fun to do a series of blog posts where we take a famous movie quote, and apply it somehow to QA/Testing or even the software engineering life-cycle.

This is one famous movie quote, and I think it applies greatly to Engineering in general (or anywhere in fact)! I don't think a week has gone by in my career where I couldn't have uttered the following:

What we have here is a failure to communicate (Cool Hand Luke)

I saw this quote (although I haven't seen the film), and I don't even think it needs any explanation....

But I'll explain anyways! I would say that 80% of problems that are in a workplace are down to a failure in communication, if a bug is found, a failure to communicate the effects of the bug properly can lead to a false severity, or a false priority. That's not the only time when a failure to communicate can be damaging, especially for QA, but a failure to communicate when understanding requirements or when explaining what you are testing can lead to a misunderstanding and unnecessary confusion.

Stay tuned for more quotes from top films such as Top Gun, Casablanca, Forrest Gump and more!
Labels:

Comments

  1. www.IHateIreland.com21 August 2013 at 03:53

    "I'll be back".
    That infamous bug that keeps on returning because the regressions tests don't cover it.

    ReplyDelete
    Replies
    1. Gareth Waterhouse21 August 2013 at 04:59

      Ha, that's a good one! I hadn't thought of that one... I had thought of one from the same film though, but I'll share that at a later date!

      Delete
  2. Unknown22 August 2013 at 12:06

    What would you link to 'I think we're going to need a bigger boat'?

    ReplyDelete
    Replies
    1. Gareth Waterhouse23 August 2013 at 01:12

      http://www.testingthewaterhouse.com/2013/08/youre-gonna-need-bigger-boat-jaws.html

      You read my mind!

      Delete
  3. Mangosteen for a Better life.30 December 2013 at 17:02

    That quote is wrong. What he said was "what we have here is 'failure to communicate' "

    ReplyDelete
  4. Unknown16 January 2018 at 14:01

    Pleasantly surprised to see this meshwork of amazing words.
    resumeyard.com

    ReplyDelete
  5. BigTechiess18 January 2018 at 11:15

    too much amazed to see the work
    cracksmalta

    ReplyDelete
  6. Zdeněk Šrámek7 June 2018 at 11:50

    Wow, thank you for such a nice post!

    CLIP STUDIO PAINT EX 1.7.4 Crack

    ReplyDelete
  7. Miriam Trevor16 October 2018 at 10:38

    great.
    http://www.testingthewaterhouse.com/2013/08/famous-movie-quotes-applied-to-software.html

    ReplyDelete
  8. sandeep saxena9 March 2019 at 01:59

    Thanks for publishing this blog, really awesome. Only experienced professional can do this.
    QTP Training in Chennai
    QTP Course in Chennai
    Best QTP Training Institutes in Chennai
    QTP Training in Porur
    QTP Training in T Nagar
    LoadRunner Training in Chennai
    Best Loadrunner training institute in chennai
    performance testing training in chennai

    ReplyDelete

Post a Comment

Popular posts from this blog

Coding something simple.... or not! Taking a screenshot on error using Selenium WebDriver

I recently wrote a little function that takes a screenshot at the end of a test if it has errored. What sounded very simple at the start turned out to be quite a bit of work, and quite a few lines of code to handle certain scenarios! It's now over 50 lines of code! I'll start with what I had at the beginning, this was to simply take a screenshot in the working directory, we are using SpecFlow and Selenium to run the tests, so we are going to check if the ScenarioContext.Current.TestError isn't null, if it is, then using Selenium, take a screenshot (note the below code is a simplified version of what I had at the beginning). [AfterScenario]         public static void TakeScreenShotOnError()         {             if (ScenarioContext.Current.TestError == null) return;             var screenshotDriver = Driver as ITakesScreenshot;             if (screenshotD...
15 comments
Read more

How to manage resources within new teams?

Working where I work we are constantly spinning up new teams to take on new workloads as business come up with new demands and new features they want developed and tested. The problem with this is how do we ensure the work of the newly spun up team is of sufficient quality. One method is by taking people from other established teams and placing them on the new team. This works great for the new team, but unfortunately it will oftenl eave the established team lacking in a resource whilst they try and fill the gap left by the person who has left. We are seeing this often with our offshore teams, it can be damaging to the team structure and the teams velocity, but try as I might, I can't think of another way around it. It's far easier to take 1 person from a team that is established than it is to build a whole new team from scratch. At least by leaving the core of a team in place, you should be guaranteeing that the new team are aware of any coding standards or any QA standard...
Post a Comment
Read more

Considerations when creating automated tests

We recently released to a number of teams our automated regression pack that has been worked on over the past few months. This regression pack tests legacy code, but contains a large number of tests.  As a bit of background, a number of teams are working on new solutions whilst some are still working on legacy code. With this in mind we constructed an email with a list of guidelines when creating new tests that need to be added to this regression pack.  I figured that these can be quite broad so should apply for any organisation, so thought it would make an interesting blog post...  So here goes,  when creating automated tests, it's important to consider and adhere to the following: - Think about data . The tests need to retrieve or set the data they need without any manual intervention - This should help them be more robust and easier to run without manual intervention. - The tests need to be idempotent - By making it so that each test is standalone and does...
Post a Comment
Read more