TECHNICAL TESTER FRIDAY: And After Awhile... You Can Work on Points for Style

Last week was a bit of a whirlwind. I took my son out for a quarter cross country trip to check out a University he may be going to. Needless to say, that took a few days out of my reality. Between being in airplanes, rental cars and dealing with less than stellar rural WiFi in spots, let's just say I'm a week behind where I should be. On the bright side, I do have some stuff to show, and a little bit of extending on the theme of PHP being a site driver.

One of the interesting paradigms that shifted for me with some of the abilities that PHP provides is that I now look at pages differently. I used to use simple tools like Sea Monkey or some other cheap WSIWIG editing tool, chopping out anything that would be overhead, and making some simple frame-ups that I could use to quickly drop in text, make changes, etc. It was intensely manual, but hey, I was rolling my own, so I was OK with that.

Then PHP came along and messed up everything, and bless it for doing exactly that :).

The last time we were together I started looking at ways that I could clean up the pages, put some basic style ideas together, and make a site that would be less of a pain to maintain. Did I succeed? In some ways yes, but in others, I’ve traded one series of challenges for another. Some things are much easier with PHP, and some things allow you a wide latitude to do things that are hard to track down later. The key point, though, is that we can emphasize interactivity and automation for the pages rather than brute force updating and modifications. 

I've taken some time and cleared the game on the HTML and CSS module that Codecademy offers, and I have to say it's actually a pretty good synopsis. the HTML is pretty basic, but it made for a nice layering to teach the ideas behind CSS and where to use them. There's a lot of options that allow for fine motor control of the pages, but I think the best is the rapid templating that it can give to a site designer.

Here's my current index.php file, which is what I now use as my base template for all pages of the proposed "Youth Orchestra" site:

Yep, that's it. Pretty much every page in the site now has this as its basic template. What does the main site look like now?

Yeah, I know, I've moved from 1995 to about 2002 ;). Again, this was so that I could focus on using a few key attributes and not drowning in them. The main idea that I wanted to focus on was how to create a fundamental "box model" that would be easy to use as a base for all of the pages, regardless of what they were to display. 

Each of the main sections of the page are spelled out as div's, each with a unique class or ID. We have the header, we have a nav bar, we have a left side bar, a right main content area and a footer at the bottom. Each of those areas is defined (more or less) by a placement of the individual div elements. 

The style page is not terribly expansive, but it gives a little better view than it did before. also, there's a whole bunch of things that we can still do with these pages, and I am not even close to done. Added to that, there's still no JavaScript in any of these pages. I'm aiming to boost that net week, when I start getting more aggressive with forms and media displays.

Here's a look at the CSS file as it currently exists:

Again, these are pretty basic commands. Not a lot of fancy footwork is going on in here just yet, but that's a good thing. My goal is to try to look to see where I can decouple dense HTML and atomize the items, perhaps in small PHP pages,  or perhaps make it purely database driven (or as much as possible). 

Also, while I am starting to use HTML5 conventions for the base HTML structure, I'm using the standard div structure and giving each dive a unique name or attributes, so that I can, again, simplify what each page needs and what I need to maintain. At the moment, the separate PHP files are currently echo statements with raw HTML listing. It's a step up on the maintainability scale, but part of me hears Paul Stanley from his "100,000 Years" banter on KISS Alive saying "Now come on! I KNOW you can do better than that!!" On the bright side, it gives me something to look forward to and tweak a bit more.

For those that want to follow the ideas from this session, my recommendation is to work through the examples on Codecademy, practice all of the examples, and as you perform each step, grab a snippet here and there and use the ideas to build your css file. try to arrange the items as much as possible from most expansive to the most localized, and if possible, try to keep elements that have an impact or relation on each other close together. 

At some point, if the site gets sufficiently complex, that will become more difficult, but seeing each of the CSS elements, classes, pseudo classes and option in plat, it really becomes easier to separate the structure from the style points. I still have a fair amount of decoupling to do, specifically the use of tables, and I also need to look at more granular positioning and locking of elements in place (almost there, but there's still a little fudge factor going on with the divs). On the bright side, we're moving forward and making progress, and that's what matters :).

Congratulations to Packt for 2000 Titles

As many of you know, one of the things I put a lot of focus on are books and book reviews in this blog. Several publishers have been very generous to me and have given me access to a variety of titles to read, apply and review. Packt Publishing is one of those companies, and as a celebration of the fact that they have released their 2000th title, I want to help them celebrate and encourage those who like their titles to take advantage of their current offer.

I feel bad that I couldn't do this sooner, but I've been out of town the past few days (another post is coming on that point, don't worry), but I still want to get the word out about the Packt 2000 title celebration, but there's a limited mount of time to take advantage of it.

So what is this all about?

It's simple. Until the end of the day today, if you buy any Packt Publishing EBook title, you will get another Packt Publishing EBook for FREE.

Click on either of the links above and you can take advantage of this opportunity, but don't delay, as it ends today (Mar. 25, 2014).

Again, I tend to not use this site for advertising purposes, but I appreciate the fact that Packt has provided a lot of titles to me over the past few years to review, and I would like to return the favor. If you appreciate open source software books, and want to support a company that produces many solid titles, then head over to Packt and get your BOGO on :).

Retro Book Review: Connections

History has the tendency of being seen as static and frozen when we view it from a a later time. What happened is what happened, and nothing else could have happened because, again, at that point, it is set in stone. Once upon a time, however, history could have gone any number of ways, and much of the time, it’s the act of change and transition that help drive history through various eras.

James Burke is one of my favorite historical authors, and I am a big fan of his ideas behind “Connected thought and events”, which makes the case that history is not a series of isolated events, but that events and discoveries coming from previous generations (an even eras) can give rise to new ideas and modes of thinking. In other words, change doesn’t happen in a vacuum, or in the mind of a single solitary genius. Instead it’s the actions and follow-on achievements by a variety of people throughout history that make certain changes in our world possible (from the weaving of silk to the personal computer, or the stirrup to the atomic bomb).

“Connections" is the companion book to the classic BBC series first filmed in the late 70s, with additional series being created up into the 1990s. If you haven’t already seen the Connections series of programs, please do, they are highly entertaining and engaging (ETA: the first series, aired in 1978, is the best of the three). The original print edition of this book had been out of print for some time, but I was overjoyed to discover that there is a current, and updated, paperback version (as well as a Kindle edition) of this book. The kindle version is the one I am basing the review on.

The subtitle of the book and series is "an Alternative View of Change”. Rather than serendipitous forces coming together and “eureka” moments of discovery happening, Burke makes the case that, just as today, invention happens often as a market force determines the benefit and necessity of that invention, with adoption and use stemming from the both the practical and cultural needs of the community. From there, refinements and other markets often determine how ideas from one area can impact development of other areas. Disparate examples like finance, accounting, cartography, metallurgy, mechanics, water power and automation are not separate disciplines, but rely heavily on each other and the inter-connectedness of these disciplines over time.

The book starts with an explanation of the Northeastern Blackout of 1965, as a away to draw attention to the fact that we live in a remarkably interdependent world today. We are not only the beneficiaries of technologies gifts, but in many ways, we are also at the mercy of them. Technology is wonderful, until it breaks down. At that point, many of the systems that we rely heavily on, when they stop working, can make our lives not just sub-optimal, but dangerous.

Connections uses examples stretching all the way back to Roman Times and the ensuing “Dark Ages”. Burke contends that they were never “really dark”, and makes the case of communication being enabled through Bishop to Bishop Post to show that many of the institutions defined in Roman times continued on unabated. Life did became much more local when the over-seeing and overarching power of a huge government state had ended. The pace of change and the needs of change were not so paramount on this local scale, and thus, many of the engineering marvels of the Roman Empire were not so much “lost” (aqueducts and large scale paved roads) but that they just weren’t needed on the scale that the Romans used them. Still, even in the localized world of the early Middle Ages, change happened, and changes from one area often led to changes in other areas.

Bottom Line:

This program changed the way I look at the world, and taught me to look at the causal movers as more than just single moments, or single people, but as a continuum that allows ideas to be connected to other ideas. Is Burke’s premise a certainty? No, but he make a very compelling case, and the connections from one era to another are certainly both credible and reasonable. There is a lot of detail thrown at the reader, and many of those details may seem tangential, but he always manages to come back and show how some arcane development in an isolated location, perhaps centuries ago, came to be a key component in out technologically advanced lives, and how it played a part in our current subordination to technology today. Regardless of the facts, figure and pictures (and there are indeed a lot of them), Connections is a wonderful ride. If you are as much of a fan of history as I am, then pretty much anything James Burke has written will prove to be worthwhile. Connections is his grand thesis, and it’s the concept that is most directly tied to him. This book shows very clearly why that is.

Retro Book Review: The Manga Guide to Databases

Since I’m in the process of doing Noah Sussman’s Technical Tester Challenge, and part of that involves setting up and maintaining a server with an actively running database, I figured now was as good a time as any to take a look at Mana Takahashi and Shoko Azuma's "The Manga Guide to Databases” as a refresher and, maybe, teach me a few new things.


I’m already a fan of "The Manga Guide to” series, so I figured that their take on databases would be in the same vein as their other titles (an accompanying storyline, an emphasis on practical topic coverage, and an emphasis on “kawaii”). To meet that end, we are introduced to Princess Raruna, heir apparent to the Kingdom of Cod. We also meet her attendant, Cain, and a fairy named Tico that teaches them about databases… and anyone familiar with Manga has not batted an eye with that kind of a description (and sure, if you looked at the cover, you could probably have figured that out as well ;) ). For those not already familiar with Manga and their tropes, this might seem a bit strange, but go with it. Seriously.


I can see some of you already thinking “OK, sure, I can see teaching about stars, or maybe even math using Manga, but databases? That’s a bit of a stretch, isn’t it?" Well, let’s take a closer look.


Chapter One introduces us to the Kindom of Kod’s main export… fruit (yeah, you were thinking fish. Everyone thinks fish, but no, it’s fruit). Through the bureaucratic and messy system that they have in place, the case is made for why a database is important in the first place, to reduce errors, keep track of important data, and to make sure that data isn’t duplicated in appropriately or not updated when and where it needs to be. This chapter also sets the stage with the scenarios and back story to help define how the database will need to be set up and managed.


Chapter Two takes the idea of a database further and discusses what relational databases are, and how they differ from other system such as hierarchical and networked databases. Fields and records are explained as vertical columns (attributes of a relationship) and records (individual collections of various attributes as relates to one given entity at a time). Tables hold these fields and records, and a variety of operations can be performed to both input and extract/format the data to be viewed.


Chapter Three goes into the process of designing a database, starting with creating an entity-relationship (E-R) model, and establishing the types of relationship an entity can have (one to one, one to many, many to many). From there, a table is designed, and by examining the relationships, we can see where data is duplicated. We can divide the big table into smaller, interrelated tables in a process called normalization. The concept of both primary and foreign keys are also introduced.


Chapter Four introduces us to the Structured Query Language, or SQL. SQL allows users to perform functions that allow them to define, operate, and control data. SELECT statement allow users to select specific fields to display and show values of those fields. The WHERE statement allows users to specify conditions as to what records are displayed. INSERT, UPDATE, and DELETE statements let users insert, update and delete data. CREATE TABLE lets a user create a new table, where DROP table lets a user remove (drop) an existing table.


Chapter Five focuses on how to operate a database, including how to set user privileges for a database, how to use locking and ensures consistency with multiple users, setting up indexes to perform faster searches, examining transactions and how they can be “rolled forward or rolled back”, and options for disaster recovery and database repair capabilities.


Chapter Six shows us how the proliferation of databases affects everyday things that we do, and that we are likely dealing with them in areas we otherwise would not consider (every site that this book review will appear on has a database to store them, and that’s at the simplest level. The chapter also shows us examples of distributed databases, database partitioning, two-phase commits, database replication and the use of stored procedures and triggers to perform commonly repeated tasks.


The book ends with a short Appendix with a summary of the most commonly used SQL commands (which would probably make for a nice little project for a dynamic allocation of commands for a web site example page.


Bottom Line:


If you are an old hand at using databases in general and SQL commands in particular, there’s probably not a whole lot of new material for you here. For those who are just getting into working with databases, this is a much more fun and straightforward way of teaching the ideas than I’ve seen, well, just about anywhere. Do note that this is not going to be the be all and end all of learning about databases, SQL queries or how to effectively design databases. It will, however, go a long way in giving those people who want to learn how to make or manage relational, SQL based databases a simple framework to hang future ideas and learning from.

TECHNICAL TESTER FRIDAY: A Bare Bones PHP Site and a Foundation for Further Work

Last week was a comedy of errors. Between trying to focus on getting a live site to behave itself, having numerous back and forth support calls and explanations of "oh, we're sorry, but you'll need to upgrade to our new hosting service to get those features", I finally said "the heck with this" and built a brand new virtual machine (Windows 7) using EasyPHP (just because I saw some friends mention it and I figured "Hmmm, why not?").

I'm going to go on the record and say, for this first part of the process, if you want to have the quickest, start to finish, least amount of resistance approach to working with PHP to build a basic web site, a VM with EasyPHP may very well fit the bill nicely. With it you get the latest PHP, MySQL, Apache Server and a host of other nice features to help you navigate and manage what you need to do. All of which will help give you spare cycles to actually build a site using PHP.

The first few weeks have been looking at PHP and understanding where I can use it, and why I might want to. At the absolute simplest level, it's a great way to template base pages with pieces that you know you will use over and over again. Headers and footers? Not likely to change very much, so why copy and paste a bunch of code? Make a base php script that echo's out what you want to have appear, and have that item appear in the location you want it to on each page. Change the script, and it instantly changes everywhere it's being called. Seems really obvious after you do it, but there's that moment where you realize "Wait, are you serious? It CAN'T be THAT simple!" Actually, yes it can be!

Another nice thing that you can do with PHP is make your database connection strings, as well as your common SQL commands, and store them in a script. By inclusion, you don't have to go and edit a bunch of scripts to issue the same commands over and over, or change statements in a bunch of files. This is where that whole "red, green, refactor" aspect of Test Driven Development can be felt, and wow, it's kinda' cool.

Another thing that I like about EasyPHP, as opposed to working with the live site that I was playing with, is that the debugging process is much quicker. On my live site, I would get errors and have no clue what was happening. I'd have to comb through several log files to figure out what was going on. Here, the system is set up to put all debug messages to your response pages. May seem a bit obtrusive, but really, it's hugely helpful. 

Also, programmers, I've always known this, but the past couple of weeks have reminded me of it again. Debugging programs can be a real challenge, and you can go through what look to be identical programs, line for line, and you cannot for the life of you figure out what the heck is wrong. I had one of those situations this week where I kept looking at why I couldn't update my database with a submission from a page, and it took me 45 minutes to realize I'd posted a comment with a contraction. Perfectly normal thing for someone to do, and yes, the answer is to make a substitution and escape character to handle the single quote, but that's where I ended up losing 45 minutes of my life wondering "why won't this thing work?!!" This emphasizes why programmers are often the worst testers when it comes to their own code. It's the same reason that writers/bloggers are often the worst proofreaders of their own posts (and oh, am I ever guilty of THAT). 

So have you had enough of me prattling on about all this? Where's my site? What did I put together? OK, here ya' go :).

Please, contain your excitement (LOL!).

Yes, I know what a lot of you are thinking. "Seriously? You spent three weeks and this is the best you could come up with?" Correction. I spent three weeks trying to make sense out of what PHP can do, reading up on it, practicing it and playing around with it, while I spent a week getting a MySQL instance to try to behave itself, and then gave up and created an environment from scratch (EasyPHP, from start to finish, install to fully up and running, a total of fifteen minutes. I kid you not).

OK, but the results look a little... well... 1995!

Right!!!

This set of pages is almost 100% pure HTML and PHP. I have exactly two CSS statements. One defines the size of the Submit button in two forms. The other makes for a sans serif font base for the whole site. That's it. Why? Because the prettified version, using CSS, HTML5 and JavaScript, is the next part of the challenge (consider it Noah's "Chapter 2"). 

I've got to give him credit, Noah Sussman is smart with this first step. CSS and JavaScript are big topics, they can take users into lots of different directions. I wondered why Noah wanted us to just focus on PHP for the first part of this project. I think it's because, with that constraint, we can actually consider just how much stuff we can do using only PHP. 

- Want to have a particular part of your site appear at a particular time or set of days? 

- Want to have a number of simple components, like your header and footer, be 100% predictable? 

- Want to have a single place to put SQL variables and a collection of commonly used queries, and only have to change the function calls and parameters based on input? 

In fact, with enough forward thinking, almost all of a site's content could be made up of just include and require statements. 

Again, these are simple steps, nothing Earth-shattering going on here, but they show that, with a little bit of work, and maybe stashing of some syntax examples to use later, you can get a feel for what to do to make a site that is mostly using PHP scripts for content creation.

So what can be gleaned from the first part of this series?

- Technical testers need to realize that programming, any kind of programming, really does take a different mind set and paradigm than manual or exploratory testing does. A tester looks at a finished Lego model and says "how can I see the structure?" A programmer takes a bunch of pieces and thinks "how can I take all of these pieces and put together the finished Lego model?" Programming requires an ability to string small pieces together, and the patience to "accrete" something from very small components into a larger whole. Testers tend to take items in their larger whole and break them apart to get to their individual components and find the relationships. I've intuitively known that, but these past few weeks have made that a lot more obvious.

- PHP alone gives a site programmer some neat tools to gather up ideas and make little bits of reusable code that can appear in lots of places, or create contexts in which the code can be used in a variety of ways. The syntax and the mechanics are similar to many other languages, and getting the feel for the language and what it can do can be done in a fairly short order just by working through the examples at Codecademy. Syntax alone, though, doesn't do much for you. You need to start looking at your pages and start thinking "hmmm, could I use PHP there?" As I've found out, the answer is, well, yeah, just about anyplace, and for a whole variety of things.

- PHP does give you the ability to automate some controls, send and receive information from a database, display data on the page, and do a number of cool manipulations. Without CSS or other "sweeteners", though, it looks jut like old school raw HTML of yesteryear. We could embed CSS statements inside of PHP, but that gets ugly really quickly, and then it makes it murder to change later. PHP is good for quite a few things, but style isn't one of them. Fortunately, I'll get the chance to play with style in the upcoming week.

Oh, one other mention, and I'm going to do a full review on it in the next couple of days. While the point of these posts is to highlight things that are free, open source or easily obtainable through a web search, I do want to mention that I found the "Head First PHP & MySQL" book to be very valuable for this part of the process. The individual concepts for things like configuring Apache, using MySQL and getting syntax for PHP can all be handled with a Google search, but the Head First book gives a variety of little projects to do, all of which help to get the programmer into the mode of coding up working examples, including mistakes that can be fixed, designs that can be refactored, and projects that can be easily ported to other uses. I have some other comments, both pros and cons, but you'll just have to wait for my more complete review ;).

The wheels are now on the car, I have a little bit of gas in the tank, the vehicle starts and can be driven, at least a little. Now let's see if we can clean it up a bit and make it a bit more presentable. Hope you'll join me as I continue the journey :). 

Retro Book Review: The Manga Guide to Statistics

This is yet another in my series of “books I’ve had from NoStarch that I need to finish reviewing before I feel I can ask them to send me more titles”. I’m saying this because NoStarch has been incredibly generous to me over the years, and has provided me with so many titles I sometimes feel I’ll never get through all of them, at least not to a level that is deserving of a proper and thorough review. On the bright side, I am getting close to clearing my queue, and soon, I will be able to ask again if they can send me some more titles :).


For those of us who do software testing for a living, we know that we have a number of artifacts that come from our testing. One of those classes of artifacts is data. Tons and tons of data. How do we make sense of it all? What is worth looking at? Why is it worth looking at? What decisions can we make if we compile, analyze and distill the data we receive? More to the point, how do we analyze the data so that we can distill it? That’s where Statistics comes in handy.


I’ll be blunt. I took one statistics class when I was in college. I hated it. In fact, I never finished it. Please understand when I say “I have an aversion to statistics as something I have to actually do”, I am not kidding. As a software tester, that puts me in a bit of a bind. If I can’t make some sense of the data I receive, I can’t do as effective a job. At best, I need to farm that work out to someone else on my team who can do the statistical analysis, meaning I need to get their take and explanation to make decisions. That causes delays. Overall, it would be better to just suck it up and learn a bit about statistics. It’s a core piece of domain knowledge any good software tester should possess, if not immediately, then at some point in their career.


There are lots of ways to learn about Statistics, and frankly, most of them are a bit painful. College courses, text books, online videos, etc. can help, but they are often slow, or assume that you have some background in the ideas already. What to do when you want to get the gist of the idea before you tackle the hairier details? That’s where “The Manga Guide to Statistics” comes in handy.


A caveat: this should absolutely not be your only guide to learning statistics. If that’s what you are looking for, then this book will not deliver on that promise. It is, however a good primer to get you started, and help you look at statistics in a way that’s fun and engaging, especially if Manga tropes appeal to you.


To set the stage, or protagonist, Rui, has a chat with the dreamy co-worker of her father (Mr. Igarashi) about understanding statistics. As Rui expresses interest to her dad about learning Statistics, he agrees to get her help. Rui creates a fantasy of being tutored by Mr. Igarashi, only to have her hopes dashed when an employee of her father, Mamoru Yamamoto (read, drawn to not be dreamy), comes to teach her about statistics. Hilarity ensues. There, that’s the Manga trope, and yes, “kawaii” abounds.

If you are familiar with Manga, you know I’ve already spoken volumes about what to expect ;). For those not familiar with Manga, the treatment of the topics are generally amusing, usually at the expense of dignity of either our protagonist or our long suffering tutor, but the light hearted humor is meant to help us relate to the material better. In between the story line, a number of key statistical analysis ideas and concepts are discussed, in a way that makes them accessible and quite a bit less scary than what normally appears in text books. Also, as in the other "Manga Guide To" books, the material is presented in a way that covers a lot of ground. It’s made accessible, but it’s not “watered down” or made to be trivial. The examples actually require the reader to understand some underlying mathematics concepts. If you’ve gotten through at least Intermediate Algebra, most of the math will be easy to follow.


Chapter One focuses on understanding data types, and how we can more readily put terms like Categorical (Qualitative) Data and Numerical (Quantitative) data into aspects that more easy to understand (using a High School Slice-of-Life Manga Drama as the basis for the comparisons). By looking at examples like reader questionnaires, we get to the idea of what these data types are (categorical Data cannot be directly measured, while Numerical Data can be). It also shows how categorical data can be given a point value and treated as numerical data.


Chapter Two gets more into numerical data and discusses some key statistics concepts, such as looking at Frequency Distributions and Histograms (conveniently described by looking for the the best ramen shop in the city, by varying definitions of “best”, and by comparing a team’s bowling scores). By looking at data points and other criteria, and examining how that criteria can be condensed into a table of values, Rui and Maoru show us how we can calculate Mean(or average), the Median (actual mid point of samples) and the standard deviation (the “fudge factor” of what’s been collected).


Chapter Three goes into categorical data. By its nature, categorical data, or qualitative data, cannot be boiled down to a number as is, but there are ways that certain aspects of qualitative data can be categorized and that categorization can be made into quantitative (numeric) data and calculated. Using a cross tabulation, some numerical analysis can be performed, and therefore qualitative data can be measured, albeit imprecisely.


Chapter Four goes into the ideas of Standard Score and Deviation Score, or how to look at a specific data point and see how it relates to the rest of your data, or how to examine data points in a variety of ranges or with different unites of measurement.


Chapter Five talks about Probability, and the ways in which we can predict an outcome based on the data on hand (more correctly, make an educated guess as to the outcome, which is what Probability is meant to do). Data can be plotted on a graph, and that graph can be converted into a curve with enough data points. That curve (standard distribution) can be moved based on the mean and standard deviation. Using a number of different models (Normal distribution, Standard normal distribution, Chi-square distribution, t distribution and F distribution)  we can make the curve “move”. By taking into account the way that the curve moves, we can calculate a ratio, or probability, which in turn can allow us to make a variety of predictions.


Chapter Six looks at comparing the relationship, or correlation, between two variables. By charting variable values on a scatter plot, we can eyeball the values and see if we have a positive or negative correlation, or if there is little to no correlation. If we sense there is a correlation, we can use a variety of indexes (spelled out here as Correlation Coefficient for numerical-numerical data, Correlation Ratio for numeric-categorical data and Cramer’s Coefficient for categorical-categorical data) to determine the overall strength or weakness of that correlation. This chapter also points out that these indexes are “fuzzy”, but they are better than nothing.


Chapter Seven examines Hypothesis tests, which are used to help clarify, or understand, if a hypothesis made by examining sample data is correct. We can test for independence of variables, if our tests are looking at variables in critical regions, and gives us examples as to how to perform a statistical analysis of those tests, and a variety of tests to see if variables are independent, homogeneous, and the degree in which they are either, both, or neither. Lather, rinse, repeat.


The book closes with a Appendix that describes how to use Excel and set up the examples explained in the book, and how to get to the functions and create the formulas necessary to do the measurements described in the previous chapters. This is a wonderful addition, and it gives even neophytes to statistics ways to play with the data and see how they can analyze the data, their results, and practice the hypothesis tests or determine probability of future events/actions.


Bottom Line:


Statistics can be fun, if you plot the story right. If following the antics of Rui and Mamoru sounds like a good time to you, and if gaining a fundamental understanding of some key statistics concepts is your end goal, then this is a nice format in which to learn those fundamental ideas. Note, I said “fundamental ideas”. Do not think that this would be an appropriate guide to say “OK, great, now I know all the statistics I need to know”. Granted, you may learn enough about statistics to be useful, and it may give you additional insights, but this is not an in depth study. Having said all that, for those who want to get into the nitty-gritty stuff, the Appendix about setting up tables and examples using statistical functions and formulas is worth the purchase price alone.


On the Manga story front… does our intrepid heroine Rui master the art of Statistics? Will her unrequited love for Mr. Igarashi remain as such? Will Mamoru be able to replace the spot in Rui’s heart where she hold an affection for Mr. Igarashi? Even if he does, is such a relationship just a little bit creepy? Ahh yes, all of this, and more shall be answered. For those who read manga, well, you probably already know the answers to all of those questions... but it’s still a fun read. For those curious as to whether or not a Manga can teach you a thing or three about statistics, the answer is “yes”, but you’ll need to look elsewhere to build on what’s covered here. As to my target market (i.e. my fellow software testers), if statistics is not your strong suit, this makes for a very practical introduction, and plenty of takeaways to make you just a bit more dangerous at work, and I mean that in the best possible way.

Happy 4th Birthday, TESTHEAD :)!!!

As I find myself having conversations with a hosting company trying to find out why a database provisioning tool isn't working, a number of modules for SummerQAmp are nearing final drafts and re-visioning, and a few talks are being finalized for conference presentations both near and a few months from now, I came to a realization today. TESTHEAD just turned four years old.

Back on March 10, 2010, I posted the very first message on this blog. It was a bit hesitant, but it made the point of what I hoped it would be:

Welcome to TESTHEAD

"OK, why the need for a blog like this? Well, truth be told, I don’t know that there really is a “need” for this blog, but I’m doing this as a challenge to myself. I consider this an opportunity to “give back” to a community that has helped me over the course of many years, as I have been the beneficiary of many great insights and learned a lot from a number of people and sources over nearly two decades.

[...]

this will be a site where I share my own experiences, both good and bad, and what I've learned from them. Expect there to be talk about tools, both proprietary and open source. Expect some talk about test case design (and how I so hate to do it at times). Expect to hear me vent about some frustrations at times, because like all people, I have my share of frustrations when things don't seem to work correctly or go the way that I planned them to. 

[...]

Most of all, expect to get a real person's perspective on these things and an attempt to communicate them in plain English, whenever I possibly can."

So how have I done on that front? Well, it looks as though many of the initial ideas that I had fell by the wayside pretty quickly. This blog does talk about tools, but it's less specific than I think I initially intended it to be, and I think that's for the better. This blog definitely has taken on a human touch and dealt with a number of the things that I have found to be frustrating and interesting, and sometimes both. 

Overall, this blog has become a repository of a lot of interconnected experiences, and the fact is, one thing leads to another. So many of the things I've talked about these past four years I had no idea I'd be discussing when I first started this challenge. I had no idea I'd join AST, become a BBST instructor, spearhead facilitation for Weekend Testing in the Americas, become a guest blogger at a variety of sites, be invited to speak at conferences halfway around the world, be asked to contribute to a body of knowledge for QA Interns, or be a mentor to other up and coming testers. The opportunities that come my way never cease to amaze me, and very often, those opportunities have stemmed, in some way shape or form, from what I talk about here, at TESTHEAD.

Four years, 889 posts (including this one), zeroing in on a half a million page views, and a lot of great friends and interactions. Thank you, everyone, who has in any way been touched by this blog. Thank you for your Likes, your re-tweets, your favorites, your re-pins, your email forwards and any other ways you've helped to share my blog with other testers and interested parties. It seriously means a lot to me, and I hope to keep making this a destination that you will want to keep coming back to. It looks like pre-school is about to end. Time to get TESTHEAD ready for Kindergarten :)!!!

Strange Incentives

I did something a little bit bold this week, in that I decided to bring my daughters with me up to Boreal ski area for a snowboarding trip. That's not all that unusual, really, but it is considering I did it on a Wednesday, and yes, I actually voluntarily took my daughters out of school to come up with me for the trip. Yes, I did make sure that they knew what their assignments were, and that work was done in advance, as much as possible. No, this is not something I plan on making a habit, but I did feel this was an important thing for us to do. Still, I really wanted to focus on my daughters' snowboarding skills, and being able to teach them in an environment, on a day that wouldn't be crowded, so as to be most conducive to learning.

One of the things I've come to realize is that you can tell people exactly what they need to do. You can articulate everything down to the last detail. You can give them an exact blueprint as to what they have to accomplish. None of that is going to matter if they are afraid, unsure or resistant. My youngest daughter is now 13 years old. She's probably had the least amount of time on the hill compared to all my kids. Once you have three kids and they're in school and doing their various activities, you start to realize that going up snowboarding with everybody, whenever you want to, becomes a little more difficult. Over the years, I've had to balance my trips and take them either individually, or we'd agree to go for maybe one or two days a season as a whole family. Fun, sure, but not really good at making sure you can advance in skills. We live three hours away from the snow at the best clip. That means it's a big deal and time commitment to go riding. A day trip is often 18 hours door to door. Much as I love it, and much is it something that I am willing to spend a great deal of time doing, I can't expect my kids to put up the same things that I would. Therefore, we haven't gone as often these last few years. That meant that many of the skills that I was able to develop in a short period of time, my kids have not had the same opportunities. I wanted to make sure that we had a day that was devoted to better skills, and better riding, because let's face it, if you can ride proficiently, the mountain is much more fun, and there are many more options open to you.

My youngest daughter is not timid. She's willing to ride down just about any terrain a mountain can offer, but she suffers from the same thing that many snowboarders do. It's a condition called "heel-side-itis". So many riders never get past the level of going straight, or braking and turning on their heel side edge. Riding toe side just tends to scare them. Personally, i had the opposite problem. At first I *only* rode toe side. Getting over to my heel side regularly was more difficult. In both cases, though, if you only ride one direction (toe side or heel side), you are somewhat at the mercy of gravity. You're also only using half of your effective muscle mass in your legs, and the half that you are using, you are stressing it almost all the time, which leads to greater and faster fatigue. Mastering linked turns are efficient, they give you more control over your trajectory, and frankly, it just makes riding that much more fun.

So why are so many people resistance to learning how to turn toe side? The simple answer, is especially on steeper terrain, you have to commit to going straight down the hill on a pitch, and then make the turn happen. Frankly, that's unnerving for a lot of people. The irony is, it's easier to turn on steeper terrain than it is on flatter terrain. Gravity does the hard work for you. Getting over that mental hurdle is still a challenge.

My youngest daughter is a fighter. She tends to want to do things her way, but at the same time she also wants to get better, and frankly, she wants me to you give her a "high five" and say she's doing good job. She'll definitely try, but she gets frustrated easily, and irritated, and often that results in fighting between me being the instructor and her being the student (note: this dynamic is not limited to snowboarding ;) ).

Because of this, I've found some interesting incentives to encourage her along the way. Sometimes, those incentives are just kind of off the wall. Case in point: my daughter is a big Korean Pop Music (K-pop) fan. She loves playing the music from her iTouch in the car on our road trips. Recently, my son, since he now has his own car and his own iPad to play music, decided that he wanted to have the cassette-deck adapter so that he could listen to music in his car. Because of doing that, we had no cassette deck adapter, which meant my poor little girl had to suffer through listening to my old CDs of ska, new wave, hip hop, punk rock and heavy metal during the trip. During our day of riding, as I was trying to get her to better link her turns, and be more casual and natural on steeper terrain, she resisted. I thought about how I might be able to get her to respond. At that moment, I just smiled and I said "OK, I'll make you a deal. You give me three picture-perfect runs, on the way back, the very first electronics outlet I find, I will buy a cassette tape adapter, so that you can listen to K-Pop over the car stereo the rest of the way home". It worked like a charm.

Yes, this post is indulgent, and yes I'm covering a topic that seems completely out of place, but for those who are regular readers, when has that ever been a surprise? The reason I mention this is because there are many incentives that drive our behavior, and when you get right down to it, are just not rational. Actually they are rational, they're just weird. we're constantly in a state of where we have to trick our brains into doing what we want it to do. When we use these incentives, and we know what incentives actually mattered to people, we can make amazing things happen. We can also figure out how to streamline the process, and see if it really does work for them.

If we can lower barriers to resistance, and if we can get people to enthusiastically take on a challenge, we can then really see how they adapt to the situation. If they are reticent, or rebellious, or just not in the mood to do something, no matter what we do, no matter how well we teach it, we'll have problems with them accomplishing the goal. The next time you decide you need to take on a testing challenge, or you have something that staring you in the face that's just irksome, difficult or getting over the hurdle to make it happen... pick an incentive that will actually motivate you. Don't be surprised if that incentive is a little bizarre. Sometimes bizarre incentives are the ones that really spur us on.