Today was the first day or our RST class on Orcas Island.
At the meta level, I thought that day 1 of RST was the closest-to-PSL/AYE but testing focused event that I have been a part of. There were multiple experiential activities in a challenging yet supportive environment. Probably more on the challenging aspect than AYE but appropriate for an audience of testers.
Specific topcs covered today were
- The goals of RST (apparently, there is a video coming on this) and what it isn’t
- The relationship between tacit and explicit knowledge, skills and heuristics
- Things to do before explicitly solving the immeidate testing problem
- Questioning what you are being asked to do
- Professionalism and why missing a bug isn’t the end of the world
I definitely got information and experiences that I can take back with me. I’m anxious to see what the next two days bring.
(Wow, what the heck happened to WordPress? I haven’t edited a blog post in a long time and it’s really slow for me. Plus, it just ate the contents of this initial post which is why I’m editing it again. I hope it works this time…)
- If you could follow only three testers on twitter, who would they be and why?
- If you could subscribe to only three testing blogs, which ones would they be and why?
- If I asked you for a recommendation of the three most important testing books to read, which 3 would you recommend and why?
I’m a big fan of PowerShell. In my experience, PowerShell is often the quickest and easiest way to automate common actions. This post was helpful to me in that realm. It provides a way, using PowerShell, to enumerate all the locales supported by Windows.
Doing this in an automated way makes a lot of sense for the reasons mentioned in the article. Another point: each release of Windows may support a different set of locales so getting it programmatically based on the context you are in is way better than trying to maintain a separate, static list.
I signed up for the late June Rapid Software Testing course. Looking forward to learning a lot.
I’m closing in on completing one of my new years resolutions this weekend. That resolution was to drastically cut down the number of books in our house.
We moved in to our current house about three years ago and I think we brought in more than forty moving boxes full of books. This was all the books that I collected over many years. Many were books that I knew I would never get around to reading and they were taking up a lot of space in the garage that we could use for other purposes.
When thinking about how to approach getting rid of excess books, I thought one way to do it was to have a “budget” for the amount of books we will keep in the house. Since we had a couple of big bookcases in the bonus room I thought that a good idea would be to have that be the amount of space in the house we could allocate to store physical books. Then, I would go through all the books and only keep an amount of books that could fit on the bookshelf. If the shelf was full and I found another book I wanted to keep I would have to make a decision: which book(s) on the shelves would I get rid of to make room for the new book I wanted to keep. In the future, every new book I wanted to buy would be subject to that same decision making process. I’m now closing in on the end of going through the boxes of books. There’s about three more boxes to go through and the shelf is now full.
This process has helped a lot in accomplishing my goal. In some ways, I feel a weight lifted off of me with much fewer books but another benefit is that I think I have a sustainable method of preventing “book buildup” in the future. Another benefit is the process is a method of keeping an awareness of the consequences of some of what would in the past be “impulse buys.”
Thinking about this example it seems to me that it could be useful in a number of areas of work and life. Music and movies are a natural extension. A less direct analog that could apply at work is automated tests. In my time as a tester I’ve run into many people who are loathe to retire tests*. They keep them around even though they don’t really know what they are testing anymore. What if we applied this approach to automated tests? Set a budget for the amount of time a test suite could run in and, if you add tests to the suite that cause the suite to exceed the budget, you have a decision to make about which tests to keep and which to retire. Aside from the benefit of keeping the runtime of test suites under control, it would also incur other benefits:
- Cause prioritization of tests to make sure the ones we run are the most valuable
- Cause re-evaluation of tests to consider their continued relevance
- Cause consideration of ways to make tests more efficient in the dimension of the budget (here, time)
There are likely others.
Based on my past experience, this idea would make a number of people uncomfortable. I think that it is something that should be considered and tried. It’s been a benefit to me in accomplishing my new years resolution.
* For those in the audience that bristle at the idea of calling automated tests “tests,” please substitute the word “checks.”
…another sprint end. Today was the second sprint on my new team. I think we are making progress but there’s more progress to be made. It is only the second sprint.
Thinking about how we can “gel” more as a team…