Would you like some test training absolutely free?
Free like water, free like air?
Often, the best way to get it is to help someone else develop training material. To test the training material, so to speak.
Well ...
I'm developing a test challenge that requires certain physical equipment. Before I order the equipment, I'd like to try it virtually, over email, or, more likely, chat programs.
I expect it would take 15 minutes to one hour of your time - it all depends on how deep you'd like to go. If you are interested, drop me an email - matt dot heusser @ gmail dot com.
If you have questions about it you think many people might have, please feel free to leave a comment.
UPDATE: At this time I have closed the challenge. (The early bird, as they say, gets the worm.) However, I will be doing it live, in person, with real equipment at The Software Test&Performance Conference 2009 - October in Boston. Drop by one of my sessions or shoot me an email.
Schedule and Events
March 26-29, 2012, Software Test Professionals Conference, New Orleans
July, 14-15, 2012 - Test Coach Camp, San Jose, California
July, 16-18, 2012 - Conference for the Association for Software Testing (CAST 2012), San Jose, California
August 2012+ - At Liberty; available. Contact me by email: Matt.Heusser@gmail.com
Saturday, August 29, 2009
Friday, August 28, 2009
Interlude
Taken from UrbanjungleComic.com, which has some funny stuff. In my version of firefox, only 4 panels - the left most two panes, top and bottom, display. Ironically, I think the joke works just fine ...
Thursday, August 27, 2009
How do we see ourselves?
And actual post to a forum I saw yesterday:
Hi
I am new to software testing and want help with learning QTP. I am based in (city) and looking for mentor.
Thanks
(name)
Now, I'm not trying to insult anyone. But imagine, for a moment, this appeared on a Carpentry forum:
Hi
I am new to carpentry and want help with learning The Hammer. I am based in Detroit and looking for mentor.
Thanks
Bob The Builder
Or perhaps plumbing:
Hi
I am new to plumbing and want help with learning The Wrench. I am based in Chicago and am looking mentor.
Thanks
Joe the Plumber
Now, I can forgive the poor English. The author probably doesn't write English as a first language, and is actually working hard to translate each word. I have to respect that.
But will learning QTP teach you to test?
Why are we so reluctant to say, as a community, that we want to get good at testing, that we want to understand and predict failure modes, that we want to get good at risk analysis and triage?
Is it because recruiters scan for buzzwords? Because 'testing' alone doesn't get us in the door, we 'need' to know Quick Test Pro, or Java, or SQL, or C#, or Fitnesse?
Don't get me wrong. Tools are important, but they are secondary. We need to change the debate.
I'm open to new and interesting ideas on how to change the debate. What do you think?
Hi
I am new to software testing and want help with learning QTP. I am based in (city) and looking for mentor.
Thanks
(name)
Now, I'm not trying to insult anyone. But imagine, for a moment, this appeared on a Carpentry forum:
Hi
I am new to carpentry and want help with learning The Hammer. I am based in Detroit and looking for mentor.
Thanks
Bob The Builder
Or perhaps plumbing:
Hi
I am new to plumbing and want help with learning The Wrench. I am based in Chicago and am looking mentor.
Thanks
Joe the Plumber
Now, I can forgive the poor English. The author probably doesn't write English as a first language, and is actually working hard to translate each word. I have to respect that.
But will learning QTP teach you to test?
Why are we so reluctant to say, as a community, that we want to get good at testing, that we want to understand and predict failure modes, that we want to get good at risk analysis and triage?
Is it because recruiters scan for buzzwords? Because 'testing' alone doesn't get us in the door, we 'need' to know Quick Test Pro, or Java, or SQL, or C#, or Fitnesse?
Don't get me wrong. Tools are important, but they are secondary. We need to change the debate.
I'm open to new and interesting ideas on how to change the debate. What do you think?
The testing renaissance
I just posted this in the Software-Testing Yahoo Group; I thought it also applies to Creative Chaos:
--- In agile-testing@yahoogroups.com, "woynam" wrote:
>
>
> It never ceases to amaze me the tremendous contribution
>that Smalltalk, and the Smalltalk community, has provided
>to our field, especially considering the small penetration
>that the language achieved.
>
Indeed. This reminds me of an old Paul Graham essay where he pointed out that the renaissance basically started in Florence, Italy.
What was it about Florence, that it generated more than it's fair share of genius's per capital? Was it something in the water? Probably not, because Florence in 1,000 AD and Florence in 1,900 AD did not have that level of success.
What was it then?
Something about the culture of collaboration and sponsorship, I think. The Florentine middle-class who were allowed to make big piles of money and keep it in the 1,200's (from silk, IIRC), went on to become upper-class a few hundred years later and sponsor artists, and, eventually, the knowledge workers, the Da Vinci's, had the opportunity to pursue a life of innovation and creation.
If you want a similar story, look into Xerox's Palo Alto Research Center (PARC), that invented the Ethernet, the Windowed Operating System, Personal Computing, and Object Oriented Programming - ideas picked up by Apple and the SmallTalk folks.
We may be reaching a similar place in software development and testing. Better yet, it can be led by practitioners who also do. My greatest concern, at this point, is this idea of Dogma and Belief, EG Agile-Testing is or is not this specific thing - without any feedback or evaluation of if that thing works for what environments and how it could be done better.
We may be getting past that. And I think that is a good day, indeed.
Regards,
--matt heusser
--- In agile-testing@yahoogroups.com, "woynam"
>
>
> It never ceases to amaze me the tremendous contribution
>that Smalltalk, and the Smalltalk community, has provided
>to our field, especially considering the small penetration
>that the language achieved.
>
Indeed. This reminds me of an old Paul Graham essay where he pointed out that the renaissance basically started in Florence, Italy.
What was it about Florence, that it generated more than it's fair share of genius's per capital? Was it something in the water? Probably not, because Florence in 1,000 AD and Florence in 1,900 AD did not have that level of success.
What was it then?
Something about the culture of collaboration and sponsorship, I think. The Florentine middle-class who were allowed to make big piles of money and keep it in the 1,200's (from silk, IIRC), went on to become upper-class a few hundred years later and sponsor artists, and, eventually, the knowledge workers, the Da Vinci's, had the opportunity to pursue a life of innovation and creation.
If you want a similar story, look into Xerox's Palo Alto Research Center (PARC), that invented the Ethernet, the Windowed Operating System, Personal Computing, and Object Oriented Programming - ideas picked up by Apple and the SmallTalk folks.
We may be reaching a similar place in software development and testing. Better yet, it can be led by practitioners who also do. My greatest concern, at this point, is this idea of Dogma and Belief, EG Agile-Testing is or is not this specific thing - without any feedback or evaluation of if that thing works for what environments and how it could be done better.
We may be getting past that. And I think that is a good day, indeed.
Regards,
--matt heusser
Monday, August 24, 2009
Last Agile 2009 Interview - Mary and Tom Poppendieck
And InformIT just published the last interview in the series, with Tom and Mary Poppendieck on lean thinking.
For a list of all my InformIT articles, you can refer to my Bio Page on Informit.com.
Who is the kid in that picture, anyway? Oh, it's me. Gosh that's old, and I haven't been active in Civil Air Patrol for years. Perhaps it's time for me to revise that old bio ...
For a list of all my InformIT articles, you can refer to my Bio Page on Informit.com.
Who is the kid in that picture, anyway? Oh, it's me. Gosh that's old, and I haven't been active in Civil Air Patrol for years. Perhaps it's time for me to revise that old bio ...
Why I /like/ Behavior Driven Development
Long-time readers of Creative Chaos will know that I'm not a big fan of X-drive-Y processes. Sure, Test-Driven Development was great, but now we've got so many abbreviations poured on top that things are getting a bit silly. (For the record, I think X-driven-Y jumped the shark at Bacon Driven Coding, but that's just me talkin')
But, after some time of opposing Behavior Driven Development as a "bunch of nothing'", I have to admit, I do believe I was wrong. Let me explain.
Several years ago, around 2005-2006, I noticed a disturbing trend of super-isolated unit tests that weren't actually testing the return results of functions - they were instead testing what the function was doing. So your function would call int() once and printf() three times - that would be the test. According to the unit testing zealots, actually having real objects, connecting to a real database, etc - well, that was "not a unit test."
I found this resulted in real gains in /design/ of the software, but the regression test suite it produced - not so much. The suite was brittle and not good at catching bugs. I found ways to inject bugs a suite would not catch, or refactor the code so that it worked but the suite would trip an error. (For example, change from three print()s to instead build up a combined string, then just print() once. Code still works, regression test suite registers a 'failure'.)
My colleague, Sean McMillan, and I developed a few cautionary tales on this form of ultra-low-level "testing and presented it at the Google Test Automation Conference in 2007:
Our conclusion? This is interesting stuff, but we wouldn't call it "testing" - perhaps "isolation-based design" would be more accurate.
So this intersects nicely with Behavior Driven Development, specifically, the falvor of BDD that gave rise to a /behavior/ framework called RSPEC.
You see, under RSpec, you don't call it a test. You talk about the /behavior/ of the software at a low level, replacing words like "test" and "assert" with "should" and "ensure." BDD is about design and doesn't claim to be about testing.
Sound familiar?
So, I think this is huge. Some of the the BDD people took the same observations I did about low-level testing and design and did something positive about it. David Astels, I salute you.
Now, there is a different flavor of BDD, one that is higher-level, where the requirements are expressed as a specification of the form "Given ... When ... Then." If the team has objects with concrete nouns ("The customer", "A membership packet") and verbs ("Requests"), it's relatively easy to automate those tests expressed in near-English.
From what I can tell, the jury is still out on BDD at the customer level. A few people I respect (Including Chris McMahon) are doing it. I'm cautiously optimistic, in that I suspect the process will have some value, but I'm not exactly sure what.
But, hey, as you can tell from above, I've been wrong before.
So - is anyone here using BDD at the higher levels? What do you think of it? And how long have you been doing it? I'm curious who has used it for more that a couple of years in a row, and what tweaks are required in the process as it gets older.
But, after some time of opposing Behavior Driven Development as a "bunch of nothing'", I have to admit, I do believe I was wrong. Let me explain.
Several years ago, around 2005-2006, I noticed a disturbing trend of super-isolated unit tests that weren't actually testing the return results of functions - they were instead testing what the function was doing. So your function would call int() once and printf() three times - that would be the test. According to the unit testing zealots, actually having real objects, connecting to a real database, etc - well, that was "not a unit test."
I found this resulted in real gains in /design/ of the software, but the regression test suite it produced - not so much. The suite was brittle and not good at catching bugs. I found ways to inject bugs a suite would not catch, or refactor the code so that it worked but the suite would trip an error. (For example, change from three print()s to instead build up a combined string, then just print() once. Code still works, regression test suite registers a 'failure'.)
My colleague, Sean McMillan, and I developed a few cautionary tales on this form of ultra-low-level "testing and presented it at the Google Test Automation Conference in 2007:
Our conclusion? This is interesting stuff, but we wouldn't call it "testing" - perhaps "isolation-based design" would be more accurate.
So this intersects nicely with Behavior Driven Development, specifically, the falvor of BDD that gave rise to a /behavior/ framework called RSPEC.
You see, under RSpec, you don't call it a test. You talk about the /behavior/ of the software at a low level, replacing words like "test" and "assert" with "should" and "ensure." BDD is about design and doesn't claim to be about testing.
Sound familiar?
So, I think this is huge. Some of the the BDD people took the same observations I did about low-level testing and design and did something positive about it. David Astels, I salute you.
Now, there is a different flavor of BDD, one that is higher-level, where the requirements are expressed as a specification of the form "Given ... When ... Then." If the team has objects with concrete nouns ("The customer", "A membership packet") and verbs ("Requests"), it's relatively easy to automate those tests expressed in near-English.
From what I can tell, the jury is still out on BDD at the customer level. A few people I respect (Including Chris McMahon) are doing it. I'm cautiously optimistic, in that I suspect the process will have some value, but I'm not exactly sure what.
But, hey, as you can tell from above, I've been wrong before.
So - is anyone here using BDD at the higher levels? What do you think of it? And how long have you been doing it? I'm curious who has used it for more that a couple of years in a row, and what tweaks are required in the process as it gets older.
Friday, August 21, 2009
Still More Agile-2009 Preview
Yet another article - this one an interview with Mike Cohn of MountainGoat software on user stories, Scrum, and succeeding with Agile.
Here's the interview.
So far, these interviews have been comissioned, themed around Agile 2009. But that brings up an interesting question - if I could interview anyone of note in the world of software technology (or general IT if you want to go broad), who would you like me to interview? And what would you like me to ask?
If there's enough interest, I can put a surprisingly large amount of energy into landing an interview. Just sayin' ...
Here's the interview.
So far, these interviews have been comissioned, themed around Agile 2009. But that brings up an interesting question - if I could interview anyone of note in the world of software technology (or general IT if you want to go broad), who would you like me to interview? And what would you like me to ask?
If there's enough interest, I can put a surprisingly large amount of energy into landing an interview. Just sayin' ...
Tuesday, August 18, 2009
... and another Agile 2009 Interview - Scott Ambler
The interview series about Agile2009 continues. Next, I interview Scott Ambler, asking him about his Agile Maturity Proposal, Agile Methods at IBM, the slow death of technology magazines, and more.
You can even read the complete article without any registration. Now that's refreshing!
You can even read the complete article without any registration. Now that's refreshing!
Unfair test questions
Have you ever seen the cop shows where the good guy asks the criminal "what were you thinking?" The best answer I have ever seen is typically "Well, I wasn't thinking."
The thing is, it wasn't really a question at all - it was a statement, something like "There is no good reason for you to have done this. What is your reason? Huh? Don't I have one? I thought so."
And, while you can understand the motivation of the police officer or prosecutor for asking, I have to admit, I always feel like it's a cheap shot.
We have these questions in software testing ("Why is QA always the bottleneck?") - and I've been getting them for years. So often, in fact, that I have a few stock answers.
After discussing this with my friends at SearchSoftwareQuality.com, they asked me to write an article to cover those impossible test questions - and just published it today:
How to answer unfair test questions
(Free registration required.)
I hope you find it helpful. If you are interested in more, please consider leaving a rating on the site; it could lead to a short series.
The thing is, it wasn't really a question at all - it was a statement, something like "There is no good reason for you to have done this. What is your reason? Huh? Don't I have one? I thought so."
And, while you can understand the motivation of the police officer or prosecutor for asking, I have to admit, I always feel like it's a cheap shot.
We have these questions in software testing ("Why is QA always the bottleneck?") - and I've been getting them for years. So often, in fact, that I have a few stock answers.
After discussing this with my friends at SearchSoftwareQuality.com, they asked me to write an article to cover those impossible test questions - and just published it today:
How to answer unfair test questions
(Free registration required.)
I hope you find it helpful. If you are interested in more, please consider leaving a rating on the site; it could lead to a short series.
Friday, August 14, 2009
Two Laws and a new article
I put this out in a private correspondence yesterday and thought it was worth repeating here:
Heusser's first rule of ethics: When someone ends a proposal with the statement "... and it's all legal!" they are saying that because it probably /should/ be illegal. Don't work with them.
Heusser's first law of guru-ness: To be a guru you don't actually need to be smart, insightful, or even be able to write very well. All you need is to work in a field that has high turnover and a general inferiority complex, work on a sticky meme, be single, and willing to devote your nights and weekends to self-promotion.
Let add: This doesn't mean that all people who talk about software testing or development are charlatans, crooks, liars, or not very bright. Far from it. I just mean to say that we can't sit back and suck in ideas uncritically. We'll have to actually examine the arguments about our field, hold them up to the light of day, challenge them and see if they stick. To put it differently: We have to test the ideas in software testing. I wouldn't have it any other way; would you?
Hey, speaking of gurus, Informit.com continues to publish interviews I had with speakers at the Agile2009 conference. This next one is from Gerard Meszaros, author of "xUnit Test Patterns". In it, I ask about developer-facing tests, how they relate to customer-facing tests, and the future of Agile-Testing. You can read the interview here.
My colleague, Markus Gaetner, continues to be of great help in creating and reviewing these documents. In this one, he contributed a large section of the introductory paragraph. Markus is a student of mine in the Miagi-Do School of Software Testing - which is not a paradigm but an actual School. I run Miagi-do free, non-profit and non-commerical. I have no statistics on how Miagi-Do increases job prospects or gives out raises. Instead, my students are actually /like/ to do testing and want to get better at it. More about that some other time.
Heusser's first rule of ethics: When someone ends a proposal with the statement "... and it's all legal!" they are saying that because it probably /should/ be illegal. Don't work with them.
Heusser's first law of guru-ness: To be a guru you don't actually need to be smart, insightful, or even be able to write very well. All you need is to work in a field that has high turnover and a general inferiority complex, work on a sticky meme, be single, and willing to devote your nights and weekends to self-promotion.
Let add: This doesn't mean that all people who talk about software testing or development are charlatans, crooks, liars, or not very bright. Far from it. I just mean to say that we can't sit back and suck in ideas uncritically. We'll have to actually examine the arguments about our field, hold them up to the light of day, challenge them and see if they stick. To put it differently: We have to test the ideas in software testing. I wouldn't have it any other way; would you?
Hey, speaking of gurus, Informit.com continues to publish interviews I had with speakers at the Agile2009 conference. This next one is from Gerard Meszaros, author of "xUnit Test Patterns". In it, I ask about developer-facing tests, how they relate to customer-facing tests, and the future of Agile-Testing. You can read the interview here.
My colleague, Markus Gaetner, continues to be of great help in creating and reviewing these documents. In this one, he contributed a large section of the introductory paragraph. Markus is a student of mine in the Miagi-Do School of Software Testing - which is not a paradigm but an actual School. I run Miagi-do free, non-profit and non-commerical. I have no statistics on how Miagi-Do increases job prospects or gives out raises. Instead, my students are actually /like/ to do testing and want to get better at it. More about that some other time.
Tuesday, August 11, 2009
Becoming a software testing expert
SoftwareTestingClub.com ($50 USD/year paid registration) has been having a discussion on "Becoming a testing expert" in it's forum lately. A number of the comments were very insightful and interesting. I did put out a short follow-up reply out that I thought might be helpful to Creative Chaos readers:
I've heard it said that you can tell a newbie because they want to be told what to do. You bring them in to remodel your kitchen or write your software (or maybe test it), and they ask for a spec or maybe a test plan. When this is kinda vague, they get mad at you. This is a 'contractual' worldview.
A different worldview is that you are discovering the requirements together. The craftsman doesn't ask for a spec; instead, he asks a bunch of questions, and eventually makes a protoype "is this what you want?"
The first prototype is not a solution, instead, it's designed to provoke a reaction "no, but now that I see that, I know what i really want" and the game continues until the prototype is close enough to the desired functionality for work to continue.
That's how I like to approach testing - as a collaborative risk management exercise. Does that make me an expert? Not alone, and that's really for you to decide in your own mind, anyway. But what I can tell you is the people whining about the requirements are too vague, or they should have been involved up front, or they need a test plan ... well, you can probably guess what my initial response is to that kind of rhetoric.
But that's just me talking. YMMV.
This ideal lines up with my concept of the Boutique Tester in that you have the contributor taking 'the bull' of the test process by the horns and shaping a test strategy for each engagement. It is far from complete. What do you think?
I've heard it said that you can tell a newbie because they want to be told what to do. You bring them in to remodel your kitchen or write your software (or maybe test it), and they ask for a spec or maybe a test plan. When this is kinda vague, they get mad at you. This is a 'contractual' worldview.
A different worldview is that you are discovering the requirements together. The craftsman doesn't ask for a spec; instead, he asks a bunch of questions, and eventually makes a protoype "is this what you want?"
The first prototype is not a solution, instead, it's designed to provoke a reaction "no, but now that I see that, I know what i really want" and the game continues until the prototype is close enough to the desired functionality for work to continue.
That's how I like to approach testing - as a collaborative risk management exercise. Does that make me an expert? Not alone, and that's really for you to decide in your own mind, anyway. But what I can tell you is the people whining about the requirements are too vague, or they should have been involved up front, or they need a test plan ... well, you can probably guess what my initial response is to that kind of rhetoric.
But that's just me talking. YMMV.
This ideal lines up with my concept of the Boutique Tester in that you have the contributor taking 'the bull' of the test process by the horns and shaping a test strategy for each engagement. It is far from complete. What do you think?
Monday, August 10, 2009
Clearing the backlog
The good news is that Informit.com has just started publishing a backlog of articles from me, including "A Chat with Alistair Cockburn."
Gosh that's an old picture of me.
Gosh that's an old picture of me.
Swamp-Ed
I'm afraid we've got a serious push at work, and my brain isn't getting the breathing room it needs to generate blog statements. (Not that I would have time to write them.)
In the little spare time I have, I still do a little bit of writing to relax, and I'm working on a piece about impossible questions - things like "Are we ready to ship yet?" (which you can't know, because you couldn't have completely tested the system) or "why is QA always the bottleneck?"
If you'd like to review my work before it's published, drop me an email: matt.heusser at gmail dot com, or leave a comment below with your email address.
More to come ... but probably not this week.
In the little spare time I have, I still do a little bit of writing to relax, and I'm working on a piece about impossible questions - things like "Are we ready to ship yet?" (which you can't know, because you couldn't have completely tested the system) or "why is QA always the bottleneck?"
If you'd like to review my work before it's published, drop me an email: matt.heusser at gmail dot com, or leave a comment below with your email address.
More to come ... but probably not this week.
Friday, August 07, 2009
Let's overflow the stack - II
Last week I suggested the readers call into the stack overflow podcast and ask testing questions.
And Joel and Jeff answered them - or, at least, they answered Adam Goucher's question.
Adam's question was about hiring for testers. As an answer, Jeff and Joel mostly talked about test philosophy - what kind of person makes a good tester vs. what kind of person makes a good developer. (If you want to jump to the question, just move the time slider to 30:10.)
After answering the tester question, Jeff and Joe answer a question about when to standardize. They suggest waiting for healthy competition in the marketplace and a clear 'winner' from people actually doing it. The direct application to the ISQTB is an exercise for the reader.
For what it's worth, I don't have a problem with ISQTB or CMMI competing in the free marketplace of ideas; I object to the suggestion that the debate is /over/ and ISQTB and CMMI are "the way" to do testing or process improvement.
But seriously, check out the podcast. It's good.
And Joel and Jeff answered them - or, at least, they answered Adam Goucher's question.
Adam's question was about hiring for testers. As an answer, Jeff and Joel mostly talked about test philosophy - what kind of person makes a good tester vs. what kind of person makes a good developer. (If you want to jump to the question, just move the time slider to 30:10.)
After answering the tester question, Jeff and Joe answer a question about when to standardize. They suggest waiting for healthy competition in the marketplace and a clear 'winner' from people actually doing it. The direct application to the ISQTB is an exercise for the reader.
For what it's worth, I don't have a problem with ISQTB or CMMI competing in the free marketplace of ideas; I object to the suggestion that the debate is /over/ and ISQTB and CMMI are "the way" to do testing or process improvement.
But seriously, check out the podcast. It's good.
Wednesday, August 05, 2009
August STPEdia is out!
Hey folks, the August STPEdia is online: Go to www.stpmag.com and click on "Download now!" in the middle-right.
This month Chris and I cover load testing, but our column was made an on-line special feature so the issue could cover the upcoming Software Test&Performance Conference in detail. You can read our column online here.
Plus, I will officially be at the Software Test&Performance Conference, Oct 19-23 at the Hyatt Regency Hotel in Boston. In fact, the full conference program is out.
Yes, I will be in Boston in the fall, along with Jon and James Bach, Scott Barber, Michael Bolton, and the rest of an amazing speakers line-up. To commemorate the occasion, I've selected a short video about going to Boston in the fall. No, really:
Can to join us?
This month Chris and I cover load testing, but our column was made an on-line special feature so the issue could cover the upcoming Software Test&Performance Conference in detail. You can read our column online here.
Plus, I will officially be at the Software Test&Performance Conference, Oct 19-23 at the Hyatt Regency Hotel in Boston. In fact, the full conference program is out.
Yes, I will be in Boston in the fall, along with Jon and James Bach, Scott Barber, Michael Bolton, and the rest of an amazing speakers line-up. To commemorate the occasion, I've selected a short video about going to Boston in the fall. No, really:
Can to join us?
Subscribe to:
Posts (Atom)