PODCAST FRIDAY: TWiST #47 w/ Randy Rice

So I'm excited about this week's interviewee.

I can't say for sure, but I think Randy Rice may be the first tester to produce a regular podcast. Over at TestingPodcast.com, the oldest entries are Randy's, so if there are older regularly created podcasts, then I don't know about them. Randy did several podcasts early on in an interview format with Mickey O'Neill that were influential in the way that TWiST is formatted today, so it felt really good to be doing an interview with one of my "testing heroes" and a true podcasting pioneer :).

Randy has been in the game awhile and has seen many changes in the industry over the years. I've also read his "Surviving the Top Ten Challenges of Software Testing" book (my review of which is here), have regularly visited his site over the years and read his various articles, and was really excited to hear about his new book, Testing Dirty Systems.

One of the really valuable pieces of this particular interview is Randy's experience and evaluation of literally hundreds of testing tools over the years. One of his presentations that he gives is on "Cheap and Free Test Tools", which he shares more than a few really good examples of here. Bur really, don't take my word for it, go and have a listen to Episode #47.

Standard disclaimer:


Each TWiST podcast is free for 30 days, but you have to be a basic member to access it. After 30 days, you have to have a Pro Membership to access it, so either head on over quickly (depending on when you see this) or consider upgrading to a Pro membership so that you can get to the podcasts and the entire library whenever you want to :). In addition, Pro membership allows you to access and download to the entire archive of Software Test and Quality Assurance Magazine, and its issues under its former name, Software Test and Performance.


TWiST-Plus is all extra material, and as such is not hosted behind STP’s site model. There is no limitation to accessing TWiST-Plus material, just click the link to download and listen.


Again, my thanks to STP for hosting the podcasts and storing the archive. We hope you enjoy listening to them as much as we enjoy making them :

Bringing Lean UX and the Design Charette to Testing

Last night I decided to explore a different element of testing. While I consider myself a strong proponent of User Experience (UX) testing, outside of a couple of books on the topic (specifically Steve Krug’s books “Don’t Make Me Think” and “Rocket Surgery Made Easy”), I haven’t really sought out or communicated with a community that made UX a priority.


I had the chance to attend the San Francisco Lean UX Meetup group. One of the organizers, Zach Larson, is SideReel’s Director of Product Management (former Chief Product Officer before SideReel’s acquisition by Rovi Corp.). Zach was instrumental in convincing me to make the move over to SideReel, so I was excited to see this group that Zach was involved with. In many ways, Zach’s passion for great design and UX matches my enthusiasm for testing, so I felt confident that there would be a treasure trove to mine from such a group setting. I was not disappointed.


The primary focus of the meetup was to hold a “Design Charette”. For the record, I had never heard this term before last night. A Design Charette is an approach to addressing a design challenge and having a group address the challenge in a structured but kinetic manner. There’s a lot of movement, ideas, and fast thinking. To my surprise, the topic of the Charette was SideReel’s Calendar and Tracker page! This was interesting in that I was faced directly with the idea of contributing design ideas to a product that I actively work with. Many concerns immediately came to my attention. Could I give an unbiased feedback to suggestions? Would my involvement with the product from a test end cause me to give prejudicial advice? What feedback could I as a tester give in this scenario? At first I held back and let the designers “do their thing”, but over time I found that I could provide feedback that helped inform our small breakout groups design ideas.


We were given the task of coming up with five ideas to address the problem… and we had to do it in five minutes! For the record, I barely mocked up one idea in that time, but many in our group were game to the challenge and effectively knocked out five or more ideas in the time limit. Many of those ideas on further review and examination were discarded, but several of the ideas were considered and built upon in the second part of our evaluation, and ultimately a cool approach to a potential redesign was submitted to the rest of the attendees (who likewise shared their ideas). What I found interesting was the rapid pace of this design approach. In many ways this is the Agile ideal of “fail fast and fail often” applied to design. Sure, many ideas were discarded, but many elements of other designs were considered, and ultimately, each team came up with what I felt were compelling design ideas.


So what could I, from a tester’s perspective, take from this experience? First, I think I cling too tightly to some ideas of how to approach a problem. This may be in part because I’m a Lone Tester at SideReel, but also because I’m used to the idea of forming ideas and waiting for them to gel. This idea of a Design Charette for testing is interesting. Generate as many ideas in a short time frame as possible, then after that time period, discuss the approaches and discard the weaker ideas in favor of those that will be stronger. Get feedback from others who may or may not specifically be testers (some non-designers were able to provide great feedback to their groups, so accept that some of the really good test ideas may come from non-testers, too).


My thanks to my hosts for a very educational experience, and my thanks to Zach especially for letting me invade his space for an evening. I learned a great deal :).

Twist #46 - with Steve Alexander

It's been a bounty of interviews the past couple of months, so much so that I'm starting to lose count how many are in the pipeline. I've set up a little section in Google Docs so that those of us who actively work with these files can keep track of the schedule and what's coming up, where and when. Seriously, it's a nice problem to have :).

This week’s interview comes to us courtesy of New Zealand and my fellow producer Farid Vaswani. Farid goes to great length to line up and talk to people "down under" that would be good potential candidates for interviews, and this week is no exception. Steve Alexander with Purple Shirt is our guest, and he discusses his specialty area, with is Usability and User Experience. More to the point, it's the intersection between what the user wants and what the organization needs, and trying to strike a balance between providing a product in a timely manner that's effective and providing a quality product that users want to use. If you’d like to hear the interview, then please listen to Episode #46.

Standard disclaimer:


Each TWiST podcast is free for 30 days, but you have to be a basic member to access it. After 30 days, you have to have a Pro Membership to access it, so either head on over quickly (depending on when you see this) or consider upgrading to a Pro membership so that you can get to the podcasts and the entire library whenever you want to :). In addition, Pro membership allows you to access and download to the entire archive of Software Test and Quality Assurance Magazine, and its issues under its former name, Software Test and Performance.


TWiST-Plus is all extra material, and as such is not hosted behind STP’s site model. There is no limitation to accessing TWiST-Plus material, just click the link to download and listen.


Again, my thanks to STP for hosting the podcasts and storing the archive. We hope you enjoy listening to them as much as we enjoy making them :).

Impromptu Testing Miniconference at eBay

Well, this turned into an interesting evening!

When we found out that Shmuel Gershon was coming in from Jerusalem to visit the U.S. for testing conferences and presentations, Adam Yuret decided to come down to the Bay Area from Seattle to meet with him, and invited me to come along as well. We also mentioned to Jon Bach that we were getting together, and he invited us to come down to the eBay campus in San Jose to have pizza and drinks with him. The closing sentence of the invitation said "I expect each of you to be ready to give a lightning talk".

Sure enough, everyone was good to their word, and we picked up an additional participant with Doug Hoffman (he lives nearby, so he decided to drop in, too).  With that, the first San Jose/Bay Area Mini-Conference (tweeted as #sjBAM) got underway.

Adam Yuret delivered an impromptu demo related to using Cucumber on the eBay site, and we discussed the benefits and disadvantages of his approach. I gave a talk on the intersection of Scouting and Testing, and discussed the stages of team development (Forming, Storming, Norming, Performing) and the scouting acronym EDGE (Explain, Demonstrate, Guide, Enable) and how the approaches can be used to empower testing teams. Doug Hoffman discussed the false sense of security that we have when our tests pass, showing that we are missing a part of the equation (passed tests are not just passed tests, there are also silent misses in that, and those are not "passes"). Jon Bach discussed the idea of "open book testing" and how we can construct questions to build testing charters and testing approaches that go far beyond just simple testing missions (and helped us discover some interesting anomalies within the eBay site for fun). Shmuel finished up the talks with a comparison of reductionism and holisticism and how it relates to testing (you'll have to wait for Shmuel to blog about that to see exactly what the talk was about).

We recorded these both on video and audio, so expect them to become podcasts very soon :).

Book Review: The Facets of Ruby: Learn to Program: Second Edition

First, let me be frank. I’ve had an on and off relationship with programming over the years, somewhat akin to my relationship with the Japanese language. Hang on, this is not an irrelevant comparison :). I love the Japanese language, and I’ve even sat down to learn some of the language structure, how to write kana, etc. but I’m hampered by the fact that I don’t really have anyone close enough to me that I can really immerse myself in speaking or writing the language. Thus, while I love watching Anime in its original language and can understand a lot of what’s happening by context and repetition, I wouldn’t dream of saying I’m a Japanese language expert, because I’ve never had, or spent, enough time to learn it and practice it in a meaningful way.

Programming for me has been equally challenging.  I’ve taken many classes over the years, even getting a Certificate in UNIX Programming back in the mid 90s (focusing on C and C++). Still, I never did enough in my testing job to require much programming beyond shell scripts, thus the need for the skill would come and go. Same with other languages I’d focused on (Java, Perl, etc.). I learned enough to be pedestrian and get some important things done, but I never really made it a habit to program in them every day.


Thus, while I often joke that I can ask a lot of the right questions, and I can read code and understand it, it’s about at the level I understand Japanese. With great deliberation and care, I can tease out what’s happening and comment on it, but I’m nowhere near conversant enough to quickly and effectively write it on my own from scratch.

With my new job, I have had to make the realization that automated testing has to be part of my reality. It’s what we do here, and if any additional scripts are to be made, it’s up to me to make them. We are a Ruby on Rails shop, therefore, it’s time to learn some Ruby. Unfortunately, most books start off with the idea that you are already expert or polished in another language. I decided, this time, I’d take Ruby on Soup to Nuts, and approach it as though it were a totally new endeavor.

Learn to Program, Second Edition (The Facets of Ruby Series) is part of the Practical Programmer’s arsenal of Ruby books, and the key reason I chose it was to see if I, a neophyte to Ruby, could get into the flow of the book and “unlearn” a few things while I “learn” the Ruby language itself. To that end, Chris Pine has set up something fun, quirky and entertaining while seeking to give some insights to someone looking to learn how to program.

Chris makes no assumptions about the level of understanding the programmer has (or doesn’t have). He starts from the beginning without being patronizing. This book itself grew out of a much tweaked and worked over tutorial for Ruby (in fact it was the tutorial and its approach that made me interested in learning more about this particular book).

So, does Chris deliver on the promise to teach Ruby to a “beginner” in a manner that will actually “stick”?


Introduction

Chris starts out the book describing what many of us already know... computers are inherently stupid, but they are very fast. Humans are inherently brilliant, but they are generally slow. Putting the two together, you can accomplish amazing things, but first, you have to get down to understanding just how stupid computers are. They don’t do what we ask them to, they do what we tell them to, and we have to appreciate how that telling gets accomplished. Computers are very literal machines, and as such, we have to create programs that are also very literal. Ruby allows for a way to do that in an abstracted way that is elegant, clean, and does not waste effort for needless repetition. Unlike languages like Java or C/C++, many of the declarations and setup requirements for things like methods and system calls are handled internal to the language. What would take five lines in Java (printing a simple text string) is done in one line with Ruby. Chris shares the oft-repeated DRY philosophy of programming, which means “Don’t Repeat Yourself” when you program.

Getting Started

A little time to get the user set up and understand what they need to be productive and able to write programs with Ruby. For me, this meant how to set up Ruby on Mac OS X and download TextMate (just to simplify things; I have an extensive IDE in RubyMine, but I often find the IDE to be distracting, so I went through the book with TextMate and a UNIX prompt).

Numbers

Basic examples dealing with numbers and text strings are placed in front of the would be programmer and the ubiquitous puts statement certainly gets a workout here :). The examples are simple enough to be a quick win for the beginner but not so simple as to be seen as almost irrelevant.

Letters

Along with numbers, dealing with text (strings) is one of the most common aspects of any programming language (loading them, reading them, formatting them, concatenating them, converting them, printing them out, etc.). This section also deals with Escape characters and how to make sure that you are printing what you think you are printing.

Variables and Assignment

This provides a quick lesson in variable assignment and how to overwrite previous variables, assign new ones, and work with them correctly when they are integers, floats or strings.


Mixing It Up

As stated, this is where the various parts start to come together. Handling strings with numbers, converting numbers to strings, using gets to store input from the keyboard or user input for later use, using chomp to cot off the newline at the end of an input string meant for gets, and understanding the error message the debugger gets when a programmer mixes their variables up.

More About Methods

Ever wondered how to sort strings, print variables in reverse, get the number of characters in a string, change the case, or automatically capitalize/de-capitalize strings? This section walks you though doing exactly that, along with how to center, left justify and right justify lines of text so that they appear where you want to see them. This section also covers some higher math functions such as exponentiation, modulus, absolute values, random number generation, and our ever favorite trigonometric functions (sin, cos, tan, etc.).


Flow Control

Programs are very basic unless there is some ways to handle comparisons, branching and repetition. This section demonstrates the comparison options along with the if, elsif, else, and while methods. It also shows how to evaluate statements with ==, <,>, <=, =>, || and &&.


Arrays and Iterators

The ability to handle text and multiple items (integers and strings) relies on the ability to store them in arrays. This chapter goes though the options and syntax required to access elements in arrays as well as how to address and manipulate those elements using the each method and manipulating arrays with options like push, pop, join, first, length and last.


Writing Your Own Methods

The oft repeated DRY philosophy meets its saving grace. Ruby methods work the way functions and procedures do in other languages. They are contained sections of code that allow the user to reuse sections of code without too much unneeded repetition. The def command is used to “define” methods and their parameters. Local variables and local scope are introduced, and the ability to make sure that what you are working on in one method will not affect other variables elsewhere in the program. This section also covers return values (because like the classic mathematical functions, each method does return a value, even if its nil).

There’s Nothing New to Learn in Chapter 10

Don’t you just love titles like that? Well, it’s not entirely accurate, but the spirit is in the right place! While it doesn’t really teach new concepts, it does reframe the ones we’ve already learned to help us understand two important concepts, recursion (when a method calls itself) and sorting (which... well, I’m sure you can figure *that* one out ;) ). Unlike the previous sorting example, though, the book encourages you to create your own with the tools thus far learned.

Reading and Writing, Saving and Loading, Yin and...

So far, the programs we have written have been self contained and have had limited opportunity to wreak havoc on a system. This all changes with this chapter, because now we get the tools to create, read, write to an destroy files. We are introduced to the File.open, File.read and File.write methods (and how cool is it that Ruby automatically closes any file call that’s made when it reaches end?). We also get to experience the hotness that is YAML (which is a way to represent multi-line strings), and wrap our heads around how to accurately quote strings so that they appear the way we expect them to. The last part of the chapter shows a cool way to rename a directories worth of files to a reliable string and integer counter naming scheme (like you would use for photographs).

New Classes of Objects

We go back and revisit classes and show some tricks with some common ones (gotta’ admit, I didn’t know you could use Array.new and String.new that way. Interesting : )). Time is examined and the various methods that can be used with it (including Time.gm, just in case you were curious as to what the time is GMT). The hash class is discussed and compared to an array, but unlike an array doesn’t require a specific ordering. as long as a pair is represented, Ruby will know how to find it. Additionally, the chapter also covers the class class (no, that’s not a repeat, you can actually use a method called class on the class called class... these are admittedly the esoteric bits that normally make me shy away from programming ;) ).


Creating New Classes, Changing Existing Ones

This section walks you through the creation of a class and adding methods to it. Additionally , Instance variables are also covered and explained (that ‘@’ symbol that pops up in Ruby code). initialize gets some stage time and an explanation of the difference between new and initialize is given (new is a class method, initialize is an instance method). the difference between public and private classes are described (along with a somewhat active baby dragon... sorry, you’ll just have to read the book to figure *that* one out :) ).


Blocks and Procs

This sections shows how to take a block of code and make an object out of it. Procs can take parameters or just be called as is, but respond with the call method. The key takeaway with this is that procs can be passed to other methods, where methods cannot be passed to each other. Methods are not objects. Procs are. It’s esoteric (at least to me) but it’s kinda’ cool, too :).

Beyond This Fine Book

Now don’t go thinking that just because you got to here that you are a Ruby expert. You have learned a smattering of Ruby and enough to maybe “watch some Anime” with my Japanese example above. While I’ve learned some details about programming in general and with Ruby in particular, there’s a bunch more out there that I’ll need to digest and practice with before I can say i’m doing anything productive or useful. Tools like irb are discussed in this chapter to help us get a little bit more out of what we can do with the language. A sales pitch is made for “the Pick Axe” which is the book “Programming Ruby”, as well as for the Ruby-Talk mailing list (mirrored at comp.lang.ruby for those of you out there who still understand USENET hierarchy, or even know what USENET is ;) ).


Possible Solutions

Interested in seeing the possible ways the “More to Work on” problems could be solved? Chris has made a listing of “possible solutions”. Why possible solutions? Because “There’s More Than One Way To Do It”, also acronym’d as TMTOWTDI or “Tim Toady”. The point was that, in the first edition of the book, there were no solutions provided, and this cause quite a few complaints. In the second edition, each exercise gets a “How You Could Do It” answer and a “How I Would Do It” answer (note, these pages take up much of the 2nd half of the book. It’s a 150 page book without the Solutions list and index).


Bottom Line:

It’s snarky, it’s irreverent, it’s even borderline silly at times, but I’ll give it credit, it is effective at what it sets out to do, and that’s provide a novice with a programming primer in Ruby. It doesn’t cover everything, nor does it intend to. Learning to Program with Ruby is a good first place to spend some time and practice with the language and learn the fundamentals before jumping into another book (I also have Everyday Scripting with Ruby, which will be my next adventure in this vein along with The RSpec Book).


I feel Chris’ book has given me a leg up to better understand what I’ll need to know to better understand and more quickly read the other books, now that I feel I have a better understanding of how the Ruby blocks fit together. For some, the tone and the attitude of the book may prove to be a turn-off. I found it to be fun and entertaining, and thus, something I was more willing to read to get those “quick wins” and gain an understanding of the language in a less confusing manner. Other books may prove to be worthwhile and offer different perspectives, but for a quick win and a comfortable first look, this ain’t bad at all.

Stay On Target, A Weekend Testing Recap

This was a bit of a departure from normal, but I think well worth it. Adam Yuret, who is a regular weekend testing participant, also works with VolunteerMatch.org. The idea behind Volunteermatch is to have individuals who want to help with a good cause, and for those self same good causes, to have a point where they can intersect.

Adam contacted us after VolunteerMatch had completed three sprints (referred to as an "Epic" in agile parlance; suffice it to say that it reflects nine weeks worth of work. As they were preparing to roll out these changes, Adam felt we'd be an ideal group to focus on this kind of challenge.

Today’s charter was as follows:

“Your mission is to test within the boundaries of the non profit admin interface.
We’re interested in finding meaningful defects within the constraints of this charter.

We’re not interested in any browsers other than the following:

Tier 1 Browsers are IE8 and Firefox 3.6 on a windows platform. if we find issues in Safari 4 or IE7 we’ll certainly address them. Our top priorities are IE8 and FF3.6.

Anything outside this NPAI interface is also out of scope.

I will act as stakeholder and answer any questions you may have. There are a few known issues but we’ll address those if they come up in testing.” –Adam Yuret

Each testing session has two components. The first is the actual testing. the second is the debrief and discussion following the testing session. We debated a number of challenges that we as testers face when scoping test effort, such as:

• Is the scope set in stone?
• Should we as testers challenge the boundaries? 
• Why is it that individual testers are more willing to challenge or question the scope of a mission than a testing group is? 
• Are there times where going beyond the pre-defined boundaries is not only desirable, but necessary?

These questions and more were debated and discussed in today's session, for complete blow by blow details, please feel free to read the Experience Report and Chat Transcript. 

Podcast Friday: TWiST #45 w/ Grand Rapids Testers and Selenium Conference

I've been a little quieter this week than usual. the reason is because I've spent some quality time with Audacity, and you will be getting not just one, but *FIVE* podcasts from me this week.


The first, of course, is the TWiST podcast. This week we have Episode #45, and as a change of pace, we decided to record the Grand Rapids Testers Group as they discussed the ideas related to "Is Complete Testing Possible?" This is more than just a regular TWiST podcast. This is an experiment we are undertaking with the Association for Software Testing in which we use some podcasts that specifically relate to their material in their Black Box Software Testing courses. This is the first one that we have dedicated to a specific topic for that purpose.  We are looking to do more in the upcoming months.


In addition to TWiST, I also recorded about 30 hours of audio from the Selenium Conference that was held in SanFrancisco April 4-6, 2011. I have a number of pieces that I'll be presenting, but I will start out with the Keynote presentations first (Jason Huggins, Patrick Lightbody, Bret Pettichord and Simon Stewart).


All of the podcasts that I have presented (or at least an index for them) are listed on this site's Podcasts page. The Selenium Conference podcasts are currently being hosted on a temporary site, and will be moved to a permanent location as soon as we determine where that will be and when we can move them over. Like all material on TESTHEAD, these podcasts have been produced under Creative Commons copyright. If you want to embed them, comment on them, review them, spread them around, etc. go ahead, but please preserve the CC license details at the end (I'm not asking for money, I just want credit for the things I produce :) ).

Book Review: The Book of CSS3

The web is changing. Every year there is a new piece of functionality that becomes part of a next “killer app” and the desire to have that information online and in the mobile space is changing the way that the web and mobile apps are developed. CSS3 is a developing standard and one that, along with HTML 5, will have the potential to transform the way that we view and interact with the web and apps via the Internet, mobile phones, and other devices that utilize the standards.

The Book of CSS3, written by Peter Gasston and published by No Starch Press, is a welcome exploration into this brave new world. Peter opens the book with the following statement in the Preface:

This book is the culmination of five years’ writing about CSS3, both on the Web and in print. The browser and CSS landscape has changed a lot in that short time and continues to change today, bringing new features and implementations at a rate that’s difficult to keep up with. The CSS3 specification is written in (often dense) technical language that’s intended for implementers rather than end users, and my intent in writing this book was to bridge the gap between specification and web developer.

Can an emerging spec get a good treatment in a book as it’s actively being developed? Will there be pieces missing? How well does Peter deliver on the promise of demystifying CSS3 for the average web designer/developer (not to mention web tester, which is more of where I fall on the continuum)? Let’s find out!


Introduction

The book starts out with the premise that the person reading it is not a web neophyte (meaning they are someone who has some experience working with HTML syntax, has tackled page design by hand a time or two and already understands many of the underlying concepts related to Cascading Style Sheets (if you had to ask if Cascading Style Sheets is what makes up the acronym CSS, then this book may not be for you ;) )). Even with that proviso, Peter sets the expectation that this book isn’t going to be a dense and jargon laden tome, but a practical guide to using the aspects of CSS3 as they currently stand, as well as offer suggestions as to how to implement the more fuzzy aspects of features still in transition and development. Peter also makes clear that the primary audience for this title is the user that is marking up pages for display on a computer screen. While smart phone and tablet development is also affected by CSS3, it’s not his target audience. Nevertheless, there is coverage of Mobile features in places for comparison.


Chapter 1: Introducing CSS3

Peter describes the development and conversations that necessitated the changes to CSS3, and the modular process that was adopted to help streamline the method in which CSS3 standards could be created and adopted while waiting out the necessary time to be adopted as an official recommendation from the W3C. Examples include CSS3 Basic User Interface Module, Selectors Level 3, Media Queries, etc. The key is that, while CSS3 is under development still, many of the options are ready to use today, and many of the available browsers already support them, so don’t be afraid to use CSS3, but you will need to know which modules can be used under which circumstances. Caveat Emptor and all that.


Chapter 2: Media Queries

The days of displaying web content on a PC only are over. Many other devices now consume web data, and being able to format the pages served for the device intended is a big jump and a benefit that CSS3 provides. Rather than have to create a one size fits all option, Media queries allow the web developer the ability to serve up pages based on the device that is accessing it. The chapter demonstrates how to create styles that will show a more extensive site on a PC screen and a more stripped down version if being displayed on a smart phone. Additionally, the demonstrations show the three ways that the Media Query is used (in a link, as an @import, or directly in the style sheet itself with the @media rule). As a side note, I find it hilarious that I run into Merlin Mann and Jon Gruber everywhere I turn, it seems. Funny that the example would be from d'Construct, and the example page would feature both of them from a design conference in the UK :) .

Chapter 3: Selectors

There are now more than twenty Selector options available to CSS3, more than doubler the number that was available in CSS2. This chapter covers the DOM selectors (meaning they act directly on elements defined in the document tree). The key value to selectors is that they can be applied to individual elements either specifically with exact matches or to multiple elements with relative matching. The Beginning Selector, as it is referred to in the book, will provide styling options if the value of the element matches the word at the beginning of the line. The Ending Substring attribute, you guessed it, matches values at the end with a particular value. Arbitrary string value matches value strings and then anything that follows after them. The key here is that a lot more flexibility as to when and where styles are applied can be defined.

Chapter 4: Pseudo-classes and Pseudo-elements

Pseudo-classes have been around since the beginning of CSS, but they have been expanded and the syntax has been modified from previous CSS versions. The example used at the beginning of the chapter is an unordered list with very specific class options. This has a drawback in that it makes the block difficult to edit and write, because it's all styled at the element level and verbosely. this chapter shows how to accomplish the same results with the .css


Chapter 5: Web Fonts

Interestingly, this was first put in, then removed, and then put back in again once the browsers got on board with supporting it. CSS fonts is a working draft, so browsers support it differently, but if the ability of having font level control of your site is important, CSS3 Fonts Module allows you to do exactly that. The @font-face option allows specific definitions for fonts to be defined, including weight, slope, etc. When applied to specific elements, the ability to define font weight, size and aspects can be set with a series of CSS statements, leaving the markup to apply the rules as defined (and not clutter up the markup language). There are additional features such as font-size-adjust and font-stretch which help to standardize and format text on certain browsers, but they are not supported in most browsers right now (none support all of them at this time), but all of the key players support @font-face.

Chapter 6: Text Effects and Typographic Styles

There are a lot of options that allow for some cool type effects using just CSS. text-shadow allows for the ability to sarcastically generate, well, text with shadows beneath it. By designating x/y coordinates, you can create exactly where the shading should occur, and then with a color palette option, the depth of the color of the shadow. You can also stack shadows for more dramatic effects (considering I used to use CorelDraw in the old days and made transparent GIF's to do stuff like this, I do find this genuinely cool :) ). a method of this is demonstrated to show a "letterpress" trick that's rather cool. text-outline and text-stroke also allows for greater control over letters being outlined and the way that they are rendered. overflow is an option that allows for text to not go beyond a boundary, instead displaying ellipsis at the end. resize allows for text areas to be defined with a pull-able border so that the text area can be resized. word-wrap allows the developer to break up long words and wrap them (nice!). text-wrap works similarly, but does so on lines of text rather than just long words. Again, check your particular browser to see if these options are available.

Chapter 7: Multiple Columns

Desktop publishing apps have used multiple column formats in documents for, well decades, mimicking what we see in newspapers and magazines. This has been a challenge to do in web browsers without serious tweaks or table columns and fine control. CSS3 now allows for the Multi-Column Layout Module, and this makes it possible to create and render multiple columns on a page. Mozilla and WebKit have already implemented this feature, and the others will likely soon follow. Columns can either be explicitly set, or columns could be sized and then based o the screen resolution, the number of columns will change with the size of the window. In addition to columns, pictures can be formatted between them (looks pretty cool, I must say :) ) One thing to be aware is that Mozilla and WebKit do these things differently, so if you want to make sure that you are covering both options, you need to either make CSS for both, or choose one and go with it. Opera and IE folks? Sorry you're out of luck on this front for now.

Chapter 8: Background Images and Other Decorative Properties

There's a lot of neat enhancements to image handling in CSS3, where instead of just putting an image in the page and then having stuff wrapped around it. With CSS3, many of the image and text options can now be blended together, where you can make large text titles with actual images used as the text background (really, this looks cool). Again, this is currently optimized for Opera, WebKit and Firefox (no browsers have all of them, and IE won't do it at all w/o IE9).

Chapter 9: Border and Box Effects

This section picks up from the last section and allows the developer to create new options for borders and boxes, such as rounded corners (regular and irregular) using "border[top-left|top-right|bottom-left|bottom-right]-radius" and then the pixel values. border-radius can also be written in a short hand form, and allows for blending of both straight and rounded corners, or regular and irregular rounded corners (which makes for some cool box effects, btw). Sounds cool huh? think that browsers implement the ideas differently? You'd be right. the latest versions of Opera and WebKit support the property fully, but Mozilla requires the moz prefix to use it. Images can also be used for borders (the book shows an example of a drawn Frame that, when sliced and applied using CSS3, very closely creates an expanding frame based on the original image. Multiple colors can be combined to make unique borders, as can shadows to create three dimensional effects (with x/y coordinate control to place the shadow where you want it and at which color depth, both outside the box and inside the box if you so choose). Again, check your browser and see if the effect wilt work with your preferred platform (as of now Firefox is the one browser that supports all of these options).

Chapter 10: Color and Opacity

HTML and CSS have basically been based around the RGB model since its inception, and most of us have used that format to get the colors we want. CSS3 now adds opacity and transparency to colors, and also adds a new color model. With opacity, the developer can designate the contrast they want to set and by using the values between 0.0 and 1.0 they can get the desired level of "blend" they are after. With the addition of the Alpha channel, we can now designate colors as values of rgba(Red Blue, Green, Alpha), or rbga(255,255,255,0.5) as an example. For browsers that don't support rgba, you'll want to use the original variants such as keyword or #RGB along with the rgba(R,G,B,A) statements. You'll be doubling up, but you'll also have a backward compatible mode as well. Note that at the time of the writing of this book, there is an issue with overlapping colors on the borders of boxes. This makes for a neat effect, but it may not be quite what you are after. Check your browser to see what happens. To add to the color soup, there is also HCL (Hue, Saturation, Lightness) which Peter gallantly goes into detail to explain (and I appreciate the challenge that it can be ;) ). HSL also allows for the Alpha channel, too, so HSL can be rendered as HSLA as well. currentColor allows the color to be a variable that can carry over to other elements.

Chapter 11: Gradients

In CSS parlance, gradient merely means the gradual transition between a range of at least two colors. Note: this is currently in flu as far as WebKit is concerned, so many of the examples may not hold up over the coming months or years. Crating simple gradients can be done with -moz-linear-gradient(point or angle, from-stop, color-stop, to-stop) in Firefox. The same approach in WebKit would use webkit-gradient(type, start-point, end-point, from(from-stop), color-stop(color-stop), to(to-stop)). Gradients can be applied left to right, right to left, top to bottom and corner to opposite corner. While the examples show two colors, more colors can be used for more dramatic effects. Radial gradients are are also possible using the -moz-radial-gradient or webkit-gradient commands (each has distinct syntax, so be aware of that). Note also that these options are currently only available for WebKit and Firefox, Opera and IE don't support them, yet.


Chapter 12: 2D Transformations

This section is pretty fun, but I'm not going to pretend that I understood all of it :). If you have wished you could display things at a jaunty angle without creating a static image to do it, Then this section is for you. ranging in complexity from the simple rotate option to more dramatic skew values, that make the image look like it is tipped forward or backwards. the scale function allows for original and copy values to be dramatically different, including mirror images if desired. Examples shown using this are a neat ribbon effect applied to a text box. the matrix function allows for a number of interesting transformation options, but it helps if yo are up to date on trigonometric functions.

Chapter 13: Transitions and Animations

The lines between content, presentation and behavior get a little blurry in this section, as Transitions and Animations are traditionally areas for JavaScript, CSS3 allows the developer to play bait with them in CSS, too. An example of a transition is where a black box, when a mouse is held over it slowly turns to silver, and then just as slowly turns back to black when the user moves the mouse off of the box. To do this, transitions use the following elements; property, duration, timing-function, and delay. There is also a shorthand for reflecting these values, which would be represented as "transition-property transition-duration transition-timing-function transition-delay;". The Animation module in CSS3 goes well beyond the transition options (and at this time, only WebKit browsers actually support these options). The animation element allows for many parameters, such as name, duration, timing-function, iteration count and direction, all of which can be rendered in shorthand as well ("animation: animation-name animation-duration animation-timing-function animation-delay animation-iteration-count animation-direction; ). By the way, as if I haven't said this enough, check your browser to see if it supports these features (if you use IE, yo are out of luck on both counts).

Chapter 14: 3D Transformations

As if CSS3 didn't have enough to brag about, now you can get all 3D with it, too! Note, this is an intensive operation, and so far, browser and system support is limited to WebKit browsers, and the newest ones at that. Peter does a good job of explaining the Cartesian coordinates in three dimensions, which is much appreciated by those of us who are not significantly mathematically geeky. 3D transformations happen at the div level and they utilize dedicated classes to create the effect. The general effects are rotate, translation and scaling. Additionally, there is a matrix option for 3D just like there is for 2D. the 3D matrix option requires 16 values to be implemented. New to the game is the perspective function, which allows the developer to control how "deep" the 3D effect will be.

Chapter 15: Flexible Box Layout

I remember full well making pages with table layouts, so the ability of styling pages with CSS is a big plus. there's cooler abilities in the works, though, and Peter takes on a few of them in the last three chapters. Here he talks about the Flexible Layout module, which has varying levels of representation on different browsers, but that has the promise of really changing things with regard to dynamo page layout (think going from standard web page to smart phone). flex and box-holder values allow the developer to set boxes that will will either remain static or dynamically resize, depending on the options provided i the CSS tags. Orientation can be modified best take advantage of the screen it is being displayed upon with minimal additional tags or interaction with the elements by using the box-orient function and the horizontal or vertical properties. Note that these implementations are currently browser specific and require browser prefix designations to be used. No support for Opera currently and IE9 is needed if you want to play with the flex box goodness.

Chapter 16: Template Layout

The Template Layout Module is currently not directly implemented, but it can be simulated by using http://code.google.com/p/css-template-layout/. With this proposal, the rows and columns can be dynamically created, and can use varying row and column definitions (the kinds that used to take lots of lines of table markup to make possible).

Chapter 17: The Future of CSS

This chapter is a grab bag of "what-ifs". tantalizing looks at ideas that could become commonplace, but as of now have either very limited development or no development at all. Calculation is introduced by using the calc function, which can be used to help determine the appropriate layout options needed to best render the content on the respective screen. The idea of cycling is on the drawing board, and the hope that the ability to cycle values will be included in a future revision. Methods of crating dynamic grids, floating objects, and other options optimized to help bring print quality to the web. Variables and constants are starting to appear, and there's no reason to believe they will not become more common in the future. With the move from the desktop to mobile platforms, the ability to react to touch and movement are adding more impetus to having CSS3 understand dynamic motion as a command. Again, most of this is speculative. When, or if, many of these enhancements appear is anyone's guess.

Appendix A provides a breakdown of each chapter and shows which options are supported in which browser, and which version of browser is needed to see the particular options described. Appendix B is a breakdown of Online Resources related to CSS3 and the latest and greatest of specs, tools and documentation, as well as fonts that can be used and displayed for Free.


Bottom Line:

For a small book (relatively speaking) it packs a big punch (figuratively speaking) and can teach a lot of a challenging topic in an easy to understand way (literally speaking). Peter has written a book that many people involved in web development can understand, even if they are not CSS experts. The descriptions are easy to follow and are well explained, but terse enough to get the idea in a short span. Because of the sheer variety of the browser matrix and what is or isn't supported, it's unlikely that the standard reader will use everything in this book, but even with that, the amount of interesting ideas to experiment with is staggering. The format of the book takes advantage of the diagrams and illustrations without being overbearing, and a nice balance is struck between a conversational tone and a more detailed technical tone where absolutely required. Though Peter assumes his audience is other web developers, the book is written in a way that even intermediate web developers, designers and yes, even testers, can simply and directly relate to the aspects being discussed. If you have been interested in the wild world of CSS3 and wanted a one stop shop to help get your head around it, The Book of CSS3 is a great first stop.

Bug Advocacy Starts Sunday, Come Join Us!

As many of you know, I help teach the Association for Software Testing's Black Box Software Testing Series of classes. I enjoy doing this, and I've primarily been focused on teaching the Foundations class over the past year. This year I made a commitment to take Bug Advocacy and get involve with teaching it as well.

Starting Sunday, May 15th, 2011, another round of Bug Advocacy will begin, and there's still time to sign up if you want to participate. Prerequisite is that you have to have completed the BBST Foundations class, so if you've done that, you're eligible. Also, while Foundations is Free to all AST members, Bug Advocacy costs $200. Still, with a month of focused interaction and assistance by coaches and instructors, that's really a great deal (it's way less expensive than other trainings of its type, and I'd dare say you'll likely get lots more out of it... but hey, I'm a little biased :) ).

To borrow from the Association for Software Testing's main site:

Bug reports are not just neutral technical reports. They are persuasive documents. The key goal of the bug report author is to provide high-quality, well-written, information to help stakeholders make wise decisions about which bugs to fix when. Key aspects of the content of this course include:

• Defining key concepts (such as software error, quality, and the bug processing workflow)
• the scope of bug reporting (what to report as bugs, and what information to include)
• Bug reporting as persuasive writing
• Bug investigation to discover harsher failures and simpler replication conditions
• Excuses and reasons for not fixing bugs
• Making bugs reproducible
• Lessons from the psychology of decision-making: bug-handling as a multiple-decision process dominated by heuristics and biases
• Style and structure of well-written reports

So seriously, if you are looking for an infusion for your testing skills and approach to testing, definitely consider taking this upcoming class. I'd love to see you there :).

Foundations is Over, and the Class Survived :)!!!

So last Saturday, I had the chance to bring to a close my first AST BBST Foundations class with me as the Lead Instructor. This was a cool experience in the sense that, while I've been part of this class for five iterations, this was the first time where I was setting the pace and the expectations.

It's a strange feeling. On one hand, after five times through Foundations, I figured this would be easy to do, but the truth is, there's a lot to keep track of and try to keep everything on track. For those who've taken the class, this may seem obvious, but for those who haven't, this is not an easy class. There's a lot to learn, to accomplish, and to encourage other students to work together over a surprisingly short period of time. It's a month long, but that month flies by very fast.

Each class is different, in the sense that each group of participants brings their own experiences to the course, and as such, each sees things a little bit differently. Each class, it seems a different set of questions develop as people determine the answers for the questions in the class. Oftentimes, I feel inadequate to answer those questions. Not because I don't understand the questions, but because I understand the questions as they relate to me and my experiences. My breakthroughs are mine, and other people's breakthroughs are theirs and come in their own time. My frustration is that, try as hard as I might, I can't teach someone anything they themselves aren't ready or willing to learn.

I remember as a kid reading Guitar Player magazine. Back in 1980, when I was 12 years old, I read an interview with Lesie West (legendary blues rock guitar player in the 70's who went on to teach guitar in New York years later). Leslie said something that I have been thinking a lot about lately... he said "I can't teach you how to play guitar. I can show you how to play guitar, but that's it. I can teach you how to teach yourself!" I had that experience during this class.

Now, don't get me wrong, it's not like we had a bunch of people who were not already good at testing (yes, there were many different levels of experience, some long time practitioners balanced out by some junior testers, as always). What was clear, though, was that the class offers a framework for testing and understanding testing, and each person approached that framework a little bit differently. Were I to take the idea that I would teach them, then I would be teaching them my understanding of it. That's not the point, though, as the challenges I face are not the same ones they will face. The tools and the approaches are context driven, and understanding the context (I believe) is important.

I deal with a podcast each week, and literally each one I produce, I learn some new trick or method that helps make that one better than the week before (subjectively speaking, of course). After more than 40 podcasts, I find it interesting that I still learn some new trick each time I do it, often when I'm doing something I've done dozens of times. Why is that? Is it because I've suddenly become aware of something that was obvious before, or is it because I experimented with something, saw the results, and finally put 1+1+1+1+1 together? I think it's more of the latter, because we are learning at our rate, and often that rate will be different for different people, because they will focus on what is relevant to them over everything else. The other details are nice and interesting, but they will not be at the forefront of my mind if I'm not actually doing something with it beyond curiosity.

This is a long winded way for me to say that I've had a great time being the Lead Instructor for Foundations, and I'm happy that my participants enjoyed and learned through the experience. Whether it was because of me or in spite of me will remain to be seen (and is ultimately irrelevant, really). I think you all were awesome, and it was a pleasure and a privilege to lead your class. I hope to see you in future classes, and thanks for teaching me a lot more than I probably taught you :).

TWiST #44 with Stephen Copp

After my time in the game industry, I always wondered how other game companies handled their testing needs. Much of the requirements for testing the games at Konami were live action and person intensive processes. Much off our testing was done with consoles attached to VCR's that captured all of our play times and we had a library of what was recorded to review later. NOw that nearly a decade has come and gone since those days, I'm curious to see what the process is like today.

Thus it was definitely cool to work on this week's interview with Stephen Copp. Stephen is a QA Architect with Electronic Arts, and he shared some details about what he does and how he approaches testing within a multi-located organization (not to mention multi-national). Stephen also has the benefit that he's able to work remotely from Colorado (And for those wondering how he landed a gig like this, he talks a bit about that, too :) ). But really, enough of me talking about it go to SoftwareTestPro and listen to Episode #44 for yourself.

Standard disclaimer:


Each TWiST podcast is free for 30 days, but you have to be a basic member to access it. After 30 days, you have to have a Pro Membership to access it, so either head on over quickly (depending on when you see this) or consider upgrading to a Pro membership so that you can get to the podcasts and the entire library whenever you want to :). In addition, Pro membership allows you to access and download to the entire archive of Software Test and Quality Assurance Magazine, and its issues under its former name, Software Test and Performance.


TWiST-Plus is all extra material, and as such is not hosted behind STP’s site model. There is no limitation to accessing TWiST-Plus material, just click the link to download and listen.


Again, my thanks to STP for hosting the podcasts and storing the archive. We hope you enjoy listening to them as much as we enjoy making them :).

Do More to Become More Creative?

One of the books that is in my active reading pile (review forthcoming ;) ) is Twyla Tharp's "The Creative Habit". The initial premise of the book is a simple one; if you desire to become more creative, you have to work at it. In some ways, this is counter-intuitive. We often think of the idea that creativity is something we are born with, not something we develop. In truth, though, it no different than any other skill.

The challenge, of course, is determining why we want to be more creative in the first place (and as testers, believe me, we know the value of creativity). So how can someone get past their resistance and make a play at getting more creative?

There are several methods Tharpe covers in the book, and a gain, I'll leave that for a more formal review of the book, but one of the things I thought was interesting was the idea that, to become creative, one must make the commitment to sit down and create (or stand, or hang, or whatever) and once that person does that, the odds of them succeeding at becoming more creative increases?

Again, I found this idea counter-intuitive. I'll agree that it will help with the mechanics, but how really will it help me become more creative? either you have it or you don't, right? Wrong! Each of us has the power to make something, and yes, at first, that power will invariably come off clumsily or not fully formed, and more to the point, it will not be perfect. That's really what's been tying most of us up for so long. It's not that we don't believe we can make something, it's that we don't trust or value what we ultimately make! 

Have you found yourself looking at a picture or an idea, or a problem, then taking a swing at it, and then giving up because your answer is not "good enough"? I know I have, and I'm now realizing what a mistake that actually is. I often get hung up on the perfect idea in my mind, and getting upset that I cannot achieve the perfection I have created in my head. the problem is that a perfectly serviceable idea is already in play. It may not be beautiful, or stylish, or meet every requirement or problem, but it was created by me for the purpose. With continued practice and effort, I just may ultimately be able to create a more perfect model or idea (note, I didn't say "perfect" I said "more perfect"; none of us will ever get to the "perfect" but more perfect comes with practice and effort).

So for those of you waiting for that "inspiration" to strike, I'd suggest rolling up your sleeves and getting down into the muck of whatever it is you're doing. Your odds of catching that slippery "muse" will be much better than if you sit there hoping to sweet talk it into your presence.