I had a discussion at lunch with a colleague of mine who was saying Erlang was the new language to learn. Strange how the conversation turned into research for me. After lunch I had a quick peruse of digg.com and came across this article on the front page, "Learn as Many Languages as You Can (or just learn Scala)".
Interesting to find out about what languages you should learn; corollary to that, what languages testers should learn. We're in an effort to do more Java development, on a scale that we've never seen before. From a testers perspective, what language would you need to learn? Ruby with Watir? Python? I think its actually a lot more than that. I think its about making sure you testing between the cracks. Think of the tests first before you start learning to code in a new language. If you can think of the tests, your language of choice because a natural result of the test.
Its back to the hammer and what's it for... its like you learned how to use a hammer and really needed a saw. Same thing with testing and languages. Again, critical thinking is required to do a lot of things. Being multidisciplinary too is an asset since testing involves so much more than coding. I'll write about that later.
Friday, March 28, 2008
Thursday, March 27, 2008
Keep your ear to the ground
I've been asked over the years, how do I know stuff about things (could I be any more vague). My usual answer is "I dunno". With regard to development and testing, I was asked this question last week, so I pondered it and thought to myself "maybe because I keep my ear to the ground". If you're wondering how to keep your ear to the ground, I can give some general ideas.
General:
Read, read, read. But what to read, that depends. I'm not saying for you to start surfing around, but to be more discriminating on how to do it. For example, I keep my ear to the ground by getting my daily dose of what's going on via RSS feeds. If you don't know what RSS is, I highly suggest finding out; its a quick way to aggregate your news/blogs/sites into one neat package. How do you read RSS feeds, well with Google reader of course! This is my RSS list for testing & development related things. Its huge source of inspiration and education and on a daily basis I have about 12 articles to skim through. Since I'm not surfing and only getting the latest materials related to those sites.
Talk to people:
I recently needed some advice that I couldn't get from any internal sources, so I went to a group discussion and met a few people there. Its easy - I went up to the person giving the presentation after the talk and said "Great job, I especially liked....". Being shy is not an excuse for me and what's the worse that can happen? They say "thanks" and the conversation ends. Or, you might spark an interesting discussion. Anyway, meet people who do things like you do.
Blogs:
Blogs are a great source of information because they tend to be from practitioners that do the work and share the experiences. I have found the more I give, the more I get, so my blog here is meant to give as much information as I can. Who knows where that might lead. For me, I have a source set of blogs I started with, specifically from Kent Beck (Agile), Sticky Minds (Testing) and TestingReflections.com. In fact, today's Testing Reflections comments on how people can get information. I'm in the same boat with getting daily information. Blogs in general give you information about the latest on what's going on in the field.
Create your own list. I wanted to do a blogroll here, but I think everyone needs to figure out their own niche. Again, its all about context. I'm trying to learn more about context-driven testing, so my list has a heavy helping of that along with all the TDD stuff I am used to doing. I don't have a lot of "automation" blogs because I found most are woefully unaware of the huge spectrum of testing there is out there. Maybe that's my new niche. :-)
Books:
There are lots of resources out there... but its hard to figure out what ones work. So much out there, but which one do you choose. I'm leaving this for future posts since I have a few books I have read and done some reviews for. Books are always a great investment, I have PDF books, but having something that you can flip to, have notes attached, and bent pages can't be emulated with a PDF.
General:
Read, read, read. But what to read, that depends. I'm not saying for you to start surfing around, but to be more discriminating on how to do it. For example, I keep my ear to the ground by getting my daily dose of what's going on via RSS feeds. If you don't know what RSS is, I highly suggest finding out; its a quick way to aggregate your news/blogs/sites into one neat package. How do you read RSS feeds, well with Google reader of course! This is my RSS list for testing & development related things. Its huge source of inspiration and education and on a daily basis I have about 12 articles to skim through. Since I'm not surfing and only getting the latest materials related to those sites.
Talk to people:
I recently needed some advice that I couldn't get from any internal sources, so I went to a group discussion and met a few people there. Its easy - I went up to the person giving the presentation after the talk and said "Great job, I especially liked....". Being shy is not an excuse for me and what's the worse that can happen? They say "thanks" and the conversation ends. Or, you might spark an interesting discussion. Anyway, meet people who do things like you do.
Blogs:
Blogs are a great source of information because they tend to be from practitioners that do the work and share the experiences. I have found the more I give, the more I get, so my blog here is meant to give as much information as I can. Who knows where that might lead. For me, I have a source set of blogs I started with, specifically from Kent Beck (Agile), Sticky Minds (Testing) and TestingReflections.com. In fact, today's Testing Reflections comments on how people can get information. I'm in the same boat with getting daily information. Blogs in general give you information about the latest on what's going on in the field.
Create your own list. I wanted to do a blogroll here, but I think everyone needs to figure out their own niche. Again, its all about context. I'm trying to learn more about context-driven testing, so my list has a heavy helping of that along with all the TDD stuff I am used to doing. I don't have a lot of "automation" blogs because I found most are woefully unaware of the huge spectrum of testing there is out there. Maybe that's my new niche. :-)
Books:
There are lots of resources out there... but its hard to figure out what ones work. So much out there, but which one do you choose. I'm leaving this for future posts since I have a few books I have read and done some reviews for. Books are always a great investment, I have PDF books, but having something that you can flip to, have notes attached, and bent pages can't be emulated with a PDF.
Wednesday, March 26, 2008
How do you test a potato...
This is one of the questions I ask when I interview anyone/everyone. Seriously. Project managers, managers, senior developers, testers, co-ops... everyone.
I know its a total rip off of from the book from Microsoft on How do you move Mount Fuji which is filled with riddles that anyone interviewing for a technical job should study just for the sake of people like me.I don't use this book as an interview guide though; don't fool yourself either. Its not a good guide, its just a fun read that contains a few lessons. To that, I have a real reason why I ask it. My interview tends to be very technical with the subjects ranging along the software engineering continuum and are not just about testing. When I ask this question, I'm forcing someone to look beyond an answer and to talk to me as a person. This question requires you to have a discussion on a topic that is totally out-to-lunch. Well, a lot of the subject matter made by software companies are totally out to lunch... how do you test an enterprise level web application that requires 100,000 hits per minute to be sustained? If you can answer me that question, give me a call. :)
This question requires someone to step out of the interview and evaluate the question for its merits and ask the right questions. Its not about how you answer, but how you question the question. This creates a fun little discussion that gets you talking to me.If anyone is looking for the areas I usually interview, here's a general list of the things I cover:
- People
- Tools and Techniques
- Estimation
- Reuse
- Requirements
- Design
- Coding
- Error removal
- Testing
- Reviews and Inspections
- Maintenance
- Quality
- Reliability
- Efficiency
- Research
I also make it a standard part of the interview to solve simple math problems or have people code something for me (e.g.:how do you multiply two numbers together without using the multiply operator).
Anyway, the point here is that everyone should strive hire the best people around the world and don't settle. If you're not evaluating people against a similar set of criteria around the world, we get an organization that is disjointed from many angles or you get people who slipped through the cracks. I look to the engineering community to help drive this effort along.
Tuesday, March 25, 2008
So many ideas... so little time.
I'm up to 35 ideas for blog posts. I'm really thankful that I have as many ideas to talk about, but because of this writing torrent, I'm having writing paralysis because it. I need to finish one post before starting the next one. The pattern so far as been that I end up getting 2 or 3 more ideas for one post, so I move on before I finish.
So, this is a short little post for today. I'll have more stuff up later in the week.
Monday, March 24, 2008
Selenium and the Wii hunt
Selenium is a great tool for automating mouse clicks on web applications. It does AJAX and other nice things that some of the professional tools don't do. (aside: bye-bye Winrunner/SilkTest/QuickTest for your pricy way of testing web applications.)
Anyway, here's the story. About 2 years ago I was looking for a Wii (around November 2006). As like everyone else at the time, I wanted a Wii, but couldn't find one. I remember checking about 5 different sites that had online inventory, so I looked for a tool to do grep (search) of those shopping sites around Ontario. Futureshop, Best Buy, etc...
Selenium fit the bill. So I did a script to check all the sites every 20 seconds to check for stock. This was running on an old Windows XP box in my basement (I have gone to mac, so my old desktop is now my play-time server). I setup the script up to send me a text message to my cell when one was available. I was quite proud of the fact that my script was constantly checking the sites, but unfortunately weeks went by without a hit.
Then, while driving on the highway from Waterloo to Toronto I get a buzz on my cell phone. 100 Wii's available at Futureshop. Since I was in my car and my phone is a cheapy nokia flip phone, I couldn't exactly buy it.
Remember how I said the script would send me a text message every minute; I only got ONE text message. ONE? ONE! When I got home, I looked at the logs. Since the script was checking every 20 seconds, but was setup to send a text every minute while the number was not zero (for the geeks out there -- while wii_qty != 0), the logs showed a fast and steady decrease in the number of wii's during that minute. 100, 81, 65, 43, 27, 8, 0.
So, what did I learn from this?
1) I should have tested my logic first. The reality was I wasn't looking for a Wii. I was looking to purchase a Wii. If I wrote a charter to my activity, I would have recognized this flaw. So, I should have setup the script to automatically PURCHASE the Wii once one was available.
2) Notify me when I owned one.
3) I wasn't the only one with a script looking for a Wii. :-)
I had to wait until March 2007 until I got a Wii... and I got it the old fashion way; by driving clear across town after a phone call blitz to about 20 places that sold Wii's.
Anyway, here's the story. About 2 years ago I was looking for a Wii (around November 2006). As like everyone else at the time, I wanted a Wii, but couldn't find one. I remember checking about 5 different sites that had online inventory, so I looked for a tool to do grep (search) of those shopping sites around Ontario. Futureshop, Best Buy, etc...
Selenium fit the bill. So I did a script to check all the sites every 20 seconds to check for stock. This was running on an old Windows XP box in my basement (I have gone to mac, so my old desktop is now my play-time server). I setup the script up to send me a text message to my cell when one was available. I was quite proud of the fact that my script was constantly checking the sites, but unfortunately weeks went by without a hit.
Then, while driving on the highway from Waterloo to Toronto I get a buzz on my cell phone. 100 Wii's available at Futureshop. Since I was in my car and my phone is a cheapy nokia flip phone, I couldn't exactly buy it.
Remember how I said the script would send me a text message every minute; I only got ONE text message. ONE? ONE! When I got home, I looked at the logs. Since the script was checking every 20 seconds, but was setup to send a text every minute while the number was not zero (for the geeks out there -- while wii_qty != 0), the logs showed a fast and steady decrease in the number of wii's during that minute. 100, 81, 65, 43, 27, 8, 0.
So, what did I learn from this?
1) I should have tested my logic first. The reality was I wasn't looking for a Wii. I was looking to purchase a Wii. If I wrote a charter to my activity, I would have recognized this flaw. So, I should have setup the script to automatically PURCHASE the Wii once one was available.
2) Notify me when I owned one.
3) I wasn't the only one with a script looking for a Wii. :-)
I had to wait until March 2007 until I got a Wii... and I got it the old fashion way; by driving clear across town after a phone call blitz to about 20 places that sold Wii's.
Thursday, March 20, 2008
Are you an Agile shop when it comes to testing?
Are you an Agile shop when it comes to testing?
What do organizations do when they are trying to create an agile shop? I have been making this one of my main goals for the past few years, helping to transform a hardware focused, waterfall driven, stacks & queues organization into an effective agile software organization. We've had some success and challenges along the way. I'm a firm believer in the agile way, but what does that mean for the group that came from the waterfall way? People assume they are being led to the water, but in fact the leader may or may not know what they are doing. Over the last few years I have had opporunities to work with people that thought tools were the way to salvation. The reality (as I see it) goes a lot deeper than that.
Education is one of the keys.
If you give people tools, they may or may not know how to use them. If you give them a tool in context of what they are doing, I think then you can bridge the gap between how tools are useful for evolving the job. For a software company, I think we are interested in reducing long term costs, maturing processes and intellectual property value of regression testing. Some of this is related to automation, and some of it is not.
Think of a hammer - at some point in history, people used rocks to bang things (I assume they were banging open coconuts... I don't know why, that's just the image I have), then the introduction of the fulcrum allowed for more energy transfer to the hammer. Context: it made bashing things easier.
Same is true in software, but not always so obvious. Automation is a bad term because it takes the critical thinking out of process. A recent post talked about test automation and the snake oil (I'm hugely paraphrasing). To summarize, test automation as a concept was wildly adopted but often not understood. It can't be treated in the same way as other project because of its nature, to be curious and to find things outside the norms. You can't take the person out of the equation and I think that's where the term makes it sounds like people aren't important.
In a related post, Corey Goldberg had a different slant on the idea (and he says it better than I do) -
So, are you an Agile shop... I think the real question is are you an Agile in your job? Do you know what it means to be Agile? I'm still figuring it out. I think its about focusing on people and how they use the software as opposed to the whether or not development is complete. Automation needs to be a part of this vision (this is my stake in the ground), but remember that it is just a tool, not the end-game.
What do organizations do when they are trying to create an agile shop? I have been making this one of my main goals for the past few years, helping to transform a hardware focused, waterfall driven, stacks & queues organization into an effective agile software organization. We've had some success and challenges along the way. I'm a firm believer in the agile way, but what does that mean for the group that came from the waterfall way? People assume they are being led to the water, but in fact the leader may or may not know what they are doing. Over the last few years I have had opporunities to work with people that thought tools were the way to salvation. The reality (as I see it) goes a lot deeper than that.
Education is one of the keys.
If you give people tools, they may or may not know how to use them. If you give them a tool in context of what they are doing, I think then you can bridge the gap between how tools are useful for evolving the job. For a software company, I think we are interested in reducing long term costs, maturing processes and intellectual property value of regression testing. Some of this is related to automation, and some of it is not.
Think of a hammer - at some point in history, people used rocks to bang things (I assume they were banging open coconuts... I don't know why, that's just the image I have), then the introduction of the fulcrum allowed for more energy transfer to the hammer. Context: it made bashing things easier.
Same is true in software, but not always so obvious. Automation is a bad term because it takes the critical thinking out of process. A recent post talked about test automation and the snake oil (I'm hugely paraphrasing). To summarize, test automation as a concept was wildly adopted but often not understood. It can't be treated in the same way as other project because of its nature, to be curious and to find things outside the norms. You can't take the person out of the equation and I think that's where the term makes it sounds like people aren't important.
In a related post, Corey Goldberg had a different slant on the idea (and he says it better than I do) -
"When I say "this test can be automated", I don't mean a computer can magically replace a sapient process to create a useful test. All test design and methodology is devised using a sapient processes (obviously). However, testcase generation, data generation, test execution, results analysis, etc, can often be done without human interaction. This has been described using terms like: "Automated Testing, "Test Automation", etc. Among some of the more vocal people in the testing community, these terms are considered confusing, inaccurate, harmful, or just a cover up for what is actually a non-scripted test"Goldberg coins the term called "programmatic tested" as opposed to "computer assisted testing"; I'm a fan of using this term instead and have been trying to get people to use it at work.
So, are you an Agile shop... I think the real question is are you an Agile in your job? Do you know what it means to be Agile? I'm still figuring it out. I think its about focusing on people and how they use the software as opposed to the whether or not development is complete. Automation needs to be a part of this vision (this is my stake in the ground), but remember that it is just a tool, not the end-game.
Wednesday, March 19, 2008
I have been playing with some blogger clients and I found one that will work with both roller and blogger. I'm using w.bloggar and this will be my first post using that. Before I was using bleezer, but it didn't quite meet my needs. Also, it seemed to be a little buggy... I'll make it a point to create a bug for them.
Tuesday, March 18, 2008
Perspective
Over the past few months I have been searching in myself about where I belong in software development. I felt as if I was in limbo about the work I was doing. I'm a developer who ended up doing a lot of test automation because I saw that we weren't doing that in many of our
projects. I excelled at it and then I had an great opportunity to go deeper into a testing role; in fact last year I had an amazing career year, but I still found I was searching for more. Recently, in a direction setting moment, I was able to get some clarity, direction and sense of purpose. Basically I realized that I have been making a career of being a tester but always from a developer perspective.
From 20000 feet - quick reference on what "schools of testing" are:
- Analytic School - sees testing as rigorous and technical with many proponents in academia
- Standard School - sees testing as a way to measure progress with emphasis oncost and repeatable standards
- Quality School - emphasizes process, policing developers and acting as the gatekeeper
- Context-Driven School - emphasizes people, seeking bugs that stakeholders care about
- Agile School - uses testing to prove that development is complete; emphasizes automated testing
A couple of years ago we had a leader that came in and showed us that waterfall model for software development was passe; it had its time and is now only good for support systems. Agile was the way we were moving forward. Without a lot of training, we were told to make it happen. Like I said, that I idea only solidified in me recently.
What does this all mean? I'm looking to widen my scope of what I know. I think there are lots of tools and techniques that can be applied to help give a sense of direction and purpose. I want to remain a good generalist and a critical thinker. So, I decided to start looking more into context-driven testing. I'm an agile tester and I make it a responsibility to mentor my peers. From my perspective, I'm trying my best to understand them, but I think I need to understand myself too.So, hopefully my followup posts will give you the context and perspective of where I'm coming from. Anyway, enough of the heavy stuff; on to more fun posts! :-)
No time like the present ...
No time like the present to put yourself out there. I figured doing it internally would help to put some thoughts out there about things I learn.
I have been keeping a journal for years at work. Sometime in 2006 I tossed my written notebook and put stuff into a wiki style. But now I'd like to open up my journal and let everyone in. Over the past year I have had little awakenings about what I do or how I do it. Its all about context and synthesis of the information. I guess that's what blogs are for!
I have been keeping a journal for years at work. Sometime in 2006 I tossed my written notebook and put stuff into a wiki style. But now I'd like to open up my journal and let everyone in. Over the past year I have had little awakenings about what I do or how I do it. Its all about context and synthesis of the information. I guess that's what blogs are for!
Subscribe to:
Posts (Atom)