As an Agile/Testing consultant, trainer and coach there are certain questions I hear often. One of them is: "What tool should we use for test automation?"
My response is usually the same: "What do you want to automate? What kinds of tests or checks?"
Very often I see people and teams make the mistake of trying to find the silver bullet.. the one tool to automate everything. Alas, there is no such tool and I don't believe there ever will be. At least, not in the foreseeable future.
It's about this time that I usually look for a whiteboard or piece of paper so I can sketch a few diagrams to help illustrate the problem. There are two diagrams in particular that I like to use. (Aside: for reference, I first publicly presented this at the DevReach 2012 conference, and it is part of the Agile/Testing classes I teach. This is the first time I am blogging the topic since I am often asked about it.)
Where would you go?
An old friend reached out to me recently to ask me some questions about Ruby, a very handy programming language to know if you are in testing, development or IT/Ops. During the conversation I mentioned that I am presently working as an Agile Technical Coach, and not in a Testing role of some kind.
Two things came to my mind during the conversation: (1) I am happy to have moved on from Testing (i.e. from doing it to teaching it), and (2) I went to some lengths for the job I have now.
After 20 years in various Testing and QA roles, I am happy to have moved onto coaching, consulting and training. I know when it's time to leave the development game to a new crowd with a fresh pair of eyes.
There are two things in my professional life that I love doing: Teaching and Testing. I did the latter for a long time, so I am pleased to focus on Teaching for a while. Unfortunately, it's still quite clear to me that many people are getting into Software Development without much knowledge (if any) of formal Testing and Quality practices. Sigh. That's too bad. It seems I will have many teaching and coaching opportunities in this field for a while yet.
Two things came to my mind during the conversation: (1) I am happy to have moved on from Testing (i.e. from doing it to teaching it), and (2) I went to some lengths for the job I have now.
After 20 years in various Testing and QA roles, I am happy to have moved onto coaching, consulting and training. I know when it's time to leave the development game to a new crowd with a fresh pair of eyes.
There are two things in my professional life that I love doing: Teaching and Testing. I did the latter for a long time, so I am pleased to focus on Teaching for a while. Unfortunately, it's still quite clear to me that many people are getting into Software Development without much knowledge (if any) of formal Testing and Quality practices. Sigh. That's too bad. It seems I will have many teaching and coaching opportunities in this field for a while yet.
Agile Testing vs Exploratory Testing
This month I will be doing two sets of training sessions - one for Agile Testing (AT) and one for Exploratory Testing (ET). I have extensive experience with both and I enjoy teaching and coaching both activities. This is the first time that I have been asked to do both training sessions at basically the same time, so I have been giving the relationship between the two some thought.
Over the past decade I have sometimes struggled with the difference between the two. I admit that I have on occasion even described them as being the same thing. Having given it some thought, I now think differently.
The insight came to me when I had a conversation with someone about both topics recently. The courses I'm doing have different audiences, different outlines, and different expected behaviours/outcomes. Yes, there is some overlap, but not much.
I have written previously about what I believe is ET (it's an interesting post - I suggest you take a moment to read it if you haven't already). Near the end of that article, I mention Agile Software Development and the Agile Testing Quadrants, so there is some relationship between the two.
ET is sometimes described as an exemplar of the Context-Driven Software Testing community. If you read through the seven basic principles of the Context-Driven Testing (CDT) School you may see where there are similarities in the philosophies between it and the values & principles listed in the Agile manifesto. Things like:
So what are some of the differences?
Over the past decade I have sometimes struggled with the difference between the two. I admit that I have on occasion even described them as being the same thing. Having given it some thought, I now think differently.
The insight came to me when I had a conversation with someone about both topics recently. The courses I'm doing have different audiences, different outlines, and different expected behaviours/outcomes. Yes, there is some overlap, but not much.
I have written previously about what I believe is ET (it's an interesting post - I suggest you take a moment to read it if you haven't already). Near the end of that article, I mention Agile Software Development and the Agile Testing Quadrants, so there is some relationship between the two.
ET is sometimes described as an exemplar of the Context-Driven Software Testing community. If you read through the seven basic principles of the Context-Driven Testing (CDT) School you may see where there are similarities in the philosophies between it and the values & principles listed in the Agile manifesto. Things like:
- CDT: People work together to solve the problem
- Individuals and interactions over processes and tools
- ...face-to-face conversation
- Business people and developers work together daily throughout the project
- CDT: Projects are often unpredictable
- Respond to change
- Welcome changing requirements, even late in development...
- Deliver working software frequently...
- CDT: No best practices
- Continuous attention to technical excellence and good design ...
- The best architectures, requirements, and designs emerge from self-organizing teams ...
So what are some of the differences?
Testathon
I received an email recently about an event happening later this month in London, UK. It's the world's first official Testathon (testathon.co). The site describes the event as "like a hackathon but for testers. You’ll be testing apps in teams with some of the best testers in the world." I know some of the judges and think this will be a fantastic opportunity for those who can attend.
When I received this notice my first thought was: this is a really cool thing and I should tell people about it. My second thought was: I don't normally write about conferences so do I blog about this or not? Well, yes, I decided to blog about it.
In the "Context-Driven" Software Testing community, actions speak louder than words. That's one of the reasons that certifications (like those from the ISTQB and QAI) are treated with low regard and even disdain from some people in the testing community. The main issue here is that these paper transactions (certifications) emphasize memory-work over hands-on practice. Here's a Quick Acceptance Test: does the [particular] certification reflect (1) a level of demonstrable competence and ability in the desired field, or (2) the ability to spend money and regurgitate specific knowledge without context?
When I received this notice my first thought was: this is a really cool thing and I should tell people about it. My second thought was: I don't normally write about conferences so do I blog about this or not? Well, yes, I decided to blog about it.
In the "Context-Driven" Software Testing community, actions speak louder than words. That's one of the reasons that certifications (like those from the ISTQB and QAI) are treated with low regard and even disdain from some people in the testing community. The main issue here is that these paper transactions (certifications) emphasize memory-work over hands-on practice. Here's a Quick Acceptance Test: does the [particular] certification reflect (1) a level of demonstrable competence and ability in the desired field, or (2) the ability to spend money and regurgitate specific knowledge without context?
Salary Thieves
Yesterday I attended a Waterloo Agile Lean session on Story Mapping presented by Mark Levison. I had heard of Story Mapping but hadn't worked through it before. I liked the hands-on exercises approach Mark took to help us understand the process and benefits of that technique. This blog post is not about Story Mapping.
I love learning and take any opportunity I can to hear different speakers present on topics that I think may be of value. Sometimes I even attend the same talks and workshops when they are done by different speakers so that I can understand differences of style in presentation, stories, and tips/techniques for getting the ideas across to the audience/participants. Once I even attended the same topic by the same speaker 2 days in a row, and I learned something new/different the second time around! (It was a Cem Kaner talk when he was in our area a few years ago.)
Yes, I gained an appreciation of Story Mapping yesterday. More importantly, I learned a new anecdote from the speaker - one that got me thinking. At one point, Mark answered a question about managing a large backlog on a Scrum/Kanban-style (information radiator) board. The problem with really large backlogs of stuff to do (likely anything with more than 100 items in it), is that the items near the bottom become meaningless over time. You will probably never get to them because something more important always comes up.
I love learning and take any opportunity I can to hear different speakers present on topics that I think may be of value. Sometimes I even attend the same talks and workshops when they are done by different speakers so that I can understand differences of style in presentation, stories, and tips/techniques for getting the ideas across to the audience/participants. Once I even attended the same topic by the same speaker 2 days in a row, and I learned something new/different the second time around! (It was a Cem Kaner talk when he was in our area a few years ago.)
Yes, I gained an appreciation of Story Mapping yesterday. More importantly, I learned a new anecdote from the speaker - one that got me thinking. At one point, Mark answered a question about managing a large backlog on a Scrum/Kanban-style (information radiator) board. The problem with really large backlogs of stuff to do (likely anything with more than 100 items in it), is that the items near the bottom become meaningless over time. You will probably never get to them because something more important always comes up.
Subscribe to:
Posts (Atom)