Do Not Avoid Technical Discussions/information: 99 Ways Workshop #36

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.

Suggestion #36: Do not avoid technical discussions/information - Boipelo Mawasha

One of the best pep talks I ever received came several years ago by the Director of R&D for a small software company I was working for at the time. I had the interesting experience of being seated in his office each day because were out of office space and I had no where else I could set up my desktop system. It was a blessing in disguise because I got the chance to "pair" dev/test every day for six months. Since I was sitting right across from him in this extremely close quarters environment, he very quickly sized up which technical topics I could handle and which ones were, at that point in time, out of my reach. 

One time, when I was really frustrated while looking at paths in the code, I slumped in my seat feeling defeated. He looked at me with a wry smile and said:

"Michael, working with code, writing code, developing large systems… it's not sorcery. It's a skill, just like any other. We start small, and with practice, we do larger things and cover more ground. Marathon runners start by running around the block. We learn by doing, and we learn by making clear what we don't understand. I get that you may be frustrated, but don't give up, and don't try to evade the challenges. Ignorance is the easiest problem to fix, because we can always teach you what you don't know. We can't teach what you don't know if we don't now you don't know it!"

Workshop #36: Take the initiative to bring any conversation to YOUR level.

One of the things I have received comments about when it comes to my writing is that I use analogies. LOTS of analogies. I relate all sorts of things that might seem weird to the topics I'm discussing. There is a reason that I do this; I want to do whatever I can to help make a mental connection with the person who reads what I am writing. Analogies and comparisons to other concepts, disciplines, and activities take a topic and re-frame it so that other people can make a connection with something they are familiar with.

To that end, the next time you find yourself in a conversation where there are technical ideas being discussed, have the courage and the will power to stop the discussion. Rephrase what's being said using analogies of your own, and then ask "do I understand this correctly?"

By making an analogy and directing yourself to think of one, you get the chance to see if you really do understand what is being described. Yes, you run the risk of being wrong. You also run the risk of looking foolish if you are not grasping something that you think should be obvious. I hereby give you permission to take that risk. Yes, show that you are potentially ignorant. Show that you might be foolish. Most of all, show that you respect the developer and the time that they are taking enough to convince both yourself and them that you either do get what is being discussed, or you don't.

I always feared that a developer would laugh at me if I couldn't figure out what they were explaining to me. To date, no developer has ever laughed at me, or made fun of me. In fact, when I've asked "dumb questions", or used my weird analogies to see if I understood a particular topic, the opposite has happened. They tend to stop, reconsider what they are saying, and then try to re-frame the discussion to help ensure that I can understand what is being said or shown.  

In my current environment, I work with developers that are in the same building, as well as halfway around the world. Because of this, IRC is one of my best "work friends". The benefit is that I have a record of my chats with the developer, and the ability to review and make sure sure I am genuinely understanding what they say. I also get to see if they understand the analogies I am using to try and make sense of what they are showing me.

Bottom Line:

I know what some of you may be thinking… "hey, that's great for you, but that wouldn't work for me if I did that." 

Really? Why not? 

Because you feel you can't ask good questions? 

Because you feel you won't make sense when the time comes? 

Because you're frightened that people might "laugh" at your "ignorance"? 

Yep, all of those risks are real… and most of the time, they never materialize. The fact that you are asking clarifying questions,  and trying to make sense of the technology in question, shows you are making an honest assessment of what you know. Show that you want to make sure you understand, and that you want to improve the areas you don't understand. In my experience, most of the time, you will get help to do both.

Strive to Show Evidence of Skill: 99 Ways Workshop #35

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.

Suggestion #35: Read the ISTQB syllabus from start to end - then use it as a map of the box you need to be thinking outside of! - Geekonomicon

Some people are sure they know where this is going to go. I'm hoping I'll surprise you ;).

Just like any question that's related to BBST may be taken with a grain of salt by some because I am directly involved in its focus, direction and delivery, so I should expect that some will take anything I have to say about ISTQB with a grain of salt as well. Isn't there a conflict of interest for me? If I'm negative, won't that be seen as "of course, he stands to benefit of BBST is seen as a better model?"

I'm going to do my best to avoid all that… not because I don't want to have the debate, but because I want to address what I feel is the bigger picture.

Workshop #35: Regardless of affiliation or ideology, aim for evidence-based proof of your skills.

The BBST course materials can be found here . If you have not downloaded or read the ISTQB syllabus, it's here. While I'm at it, take any testing course, book, video, or resource that you want to put to this test. Take my entire blog and everything I have ever suggested as a good or helpful idea. I'm willing to expose it to the same scrutiny.

Read through all of them.

Make sure you understand what they are saying. If you are not sure what they are saying, highlight sections and review with other resources. Compare what sources have to say. Note contradictions or differences in wording.

Do you agree with the elements as presented? If so, apply them. If not, refute with actual practice or data why you disagree with them. All principles are open to being tried and debated. There are no sacred cows.

Regardless of what you feel you know or understand of any of the areas and topics, ask yourself "can I apply this, and does applying this help solve a problem, or help me identify a genuine issue?"

As you try each area, see how long it takes, see the quality of information you collect, and see if the practice makes sense for what you are doing. If it does, use it. If there's a better approach, use that. If an approach doesn't make sense for what you are doing, don't use it.

Bottom Line:

Regardless of the value or lack of value of whatever approach, school, discipline, association, etc. at the end of the day only one thing matters, and that is demonstrable skills. No certificate of completion or claim of accomplishment matters if, at the end of the process, you are unable to demonstrate actual skills and proficiency in the area of testing you need to. 

Let me put it this way… I care very little about what paper you hold at the end of the day. I care a great deal about the skills you can bring to testing problems and helping to find issues and represent customers and stakeholders. Strive to show genuine skill, and be willing and enthusiastic to show that skill. Every thing else is irrelevant.

Listening Redux: 99 Ways Workshop #33 and #34

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.

Suggestion #33: Listen to what your client has to say. This is, by far, the most important (and underrated) Testing skill, in my humble opinion. - Marcelo Cordeiro Leite

Suggestion #34: +1 for listening. Being really, really good at listening helps you not only to understand your client, but to pick up on areas where the team is confused or unsure about what we're building - a slight hesitation in speech because the dev keeps getting two different entities muddled up, perhaps.

There's no question that the ability to listen is critical, and being able to understand what is really being asked is a skill that we try to foster, but don't often get right. For this one, I'm digging into some old Steven Covey wisdom (this is straight out of the Seven Habits of Highly Effective People, it's Habit #5, in fact). Don't feel cheated that I'm putting two workshops together. Chances are, you'll find this one difficult enough to warrant two places.

Workshop #33 and 34: "Seek first to understand, then to be understood"

When you find yourself in a conversation, do you actively stop and try to understand, really understand what the person you are speaking with is trying to say? How often do you find yourself (and don't cringe, many well meaning adults do these very things all the time):

- Listening just to the things that matter to you, and tuning out or pretending you didn't hear something that was uncomfortable or not pleasant?

- Find yourself saying "yeah" and "u-huh" a lot (I hear talk show hosts on the radio do it all the time and it really does irritate me, since I know what it is they're doing). 

- Use the time that the person is speaking to form a rebuttal or comment of what you are going to say next?

- Drop eye contact with people and look elsewhere (granted, for some people, eye contact is uncomfortable, so it's not necessarily a sign of not listening, but often, it is ).

If any of these feel familiar, don't feel defensive. It's not that your a bad person, it's that you are very typical. Most of us do this, and most of us don't even realize it. The role of active listening takes a lot of effort, patience and practice, and very often, the ones who do it the least are also the least aware of the fact that they are not listening.

Being engaged in a conversation and replying back actively if often a reflex, and that reflex is usually guided by what we want to have the other person hear, i.e. we care a lot about them understanding what we have to say, but what they have to say? Ehhh, not as much.

So how to break through this? It sounds simple, but it's a lot harder than it seems.

In a critical conversation, be willing to sit and listen to every word  that the person in question has to say. take a pier of paper and a pen if necessary and focus, completely on what they are saying. take down notes, make associations, anything, but focus 100% on what they are saying.

Once they finish, pause, review your notes if necessary, and with an honest and direct "so what you are saying is…" or "if I understand correctly, you feel…" and repeat as closely as you can what you heard in the conversation.

How did you do? Did you really capture what they said? If not, try again, and do the same thing. NO talking, no rebuttal, just listen, take notes, make clarifications.

Are you with me so far? Cool.

Once you have established that the person has said what you really think that they meant to say, wanted to say, needed to say… n ow  take the time and calmly either state your position, or ask additional clarifying questions. You may have bad news, you may not be able to do what they want to have you do, but if you take this approach, seriously use active listening and show the other party that you genuinely heard what they had to say, and the other party really feel that you have done exactly that, even difficult discussions are much more easily handled and contention is often minimized. 

Maintaining eye contact, if you can, not fidgeting or making gestures, not folding your arms, or looking at your phone for the time, etc… all of these support active listening. focus 100% on the person yo hare speaking with, so that they are reassured that you hare giving them your undivided attention, for real, speaks volumes to them.

Bottom Line:

We can spare ourselves a lot of wasted time if we really and truly take the time to listen, and confirm that what we have heard is what they other speaker wants to convey and have understood. It's a simple concept, but it is super hard to make happen. It takes will power, it takes a willingness to suppress our own ego, it takes a willingness to want to be effective more than to be in the right (at least as we see it). taking the time to become an expert listener will reward you many times over, but it will probably be one of the most challenging things you ever learn how to do (I've got a ways to go on this one myself). 

Is "Join Software Testing Club!" Taken?: 99 Ways Workshop #32

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.

Suggestion #32: Is "Join Software Testing Club!" taken? I couldn't see it... or maybe it is too obvious :-) - Geir Gulbrandsen

Well, what do you expect? This was a poll started by Software Testing Club, and the results were turned into the "99 Things" eBook. Nevertheless, it makes a good point. Whether it's the Software Testing Club, or some other group or network, the goals are the same. Places where people with similar skills and experiences can congregate tend to help those people grow, learn, and network. Therefore, this post is going to be relevant regardless of the forum you choose to support.

Workshop #32: Be a net producer rather than a net consumer of your respective community 

When you join a community of any kind, often we go in with the hope of getting something from the experience. There's nothing wrong with saying that, it's generally true. Our first impulses when we go to a site, or go to participate in an online environment of any kind is because we want something. we want information, we want something that we think will be entertaining, we want to talk with other people that share our interests. Again, that's totally fine and expected. I'm just saying that, if that's your core reason for going, chances are really good that you will not participate with it for very long. When the novelty wears off, or the ability to find what is tailored for us tapers off, and we are not actively contributing to the environment, then yes, at some point, we will check out or spend less time with that community.

If you are interested in joining any kind of an online community, peruse their site and ask the following questions:

- do the topics that are represented reflect my interests?

- do I have expertise that would fit in with the primary discussions?

- are there opportunities for me to provide content for the site that others can view and comment on?

- if I were to get my five most important questions answered (needs met, etc.) is there additional value to me for coming back here?

- are there tools that I will be able to use to help contribute and participate? Are they replicating things I'm already doing elsewhere? If, so, can I integrate what I am already doing with the community (an example would be the ability to share posts, have a blog syndicated, or referencing other aspects where we won't have to do it multiple times in multiple places)?

- what are the benefits of membership? What makes this community better (or worse) than another community?

- is there a regional aspect? Do those of us who are not located in the primary area feel out of place, or do we have opportunities to participate even if we are not in the general vicinity of where the group is organized? I'm mentioning this last one simply because the Software Testing Club is in the U.K., and those who are in the U.K. or E.U. will have more opportunities to directly interact with members than I will being located in California).

If you can answer all or most of those questions positively, then it's a good bet that it's a positive fit for you as a community. 

Once you have decided that it is a good community to join, I would suggest seeing if there are areas with questions that can be answered, opportunities for mentoring, or otherwise getting involved in a way that directly impacts the people of the community, and has you participating as a net producer for that group. The communities where you you contribute the most to are, generally, the ones you will stick with and continue to participate with. 

Bottom Line:

Regardless of where you choose to place your focus, and with which community, strive to make direct connections with the people there. try not to be the person that just lurks, or reads from time to time. IF that's your goal, then a community isn't necessary. There are hundreds of blogs that can be read, researched and notes taken from that will do the same thing. Communities are there for interaction, and if you decide that the community is what you want, then contribute to the community. Your efforts will be noted, and you may make a number of potential life long friends. Seems to be working for me in the communities I participate in, in any event :).

Join an Open Source Project You Like as a Tester: 99 Ways Workshop #31

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.

Suggestion #31: Join an open source project you like as a tester. - Erick Brickarp

For anyone who takes the Bug Advocacy or Test Design  BBST courses offered by AST, this process is part of the class, and we walk through the process of joining the OpenOffice project (that's the project that was chosen when the class materials were prepared, and hence why we still use it as an example). 

There are lots of projects out there that are looking for testers. If you are willing to participate, and show that you are effective, you may find that you develop a rapport with that community, and you may be invited to participated in other projects. That involvement can certainly be put into a resume or a LinkedIn profile, or making a github repository visible and showing your contributions. If you are not a coder, don't fret, there are plenty of places where testing skills are needed and appreciated.

Workshop #31: Pick a Project and find out where you can make a contribution

First things first... I'm not going to give you a list of projects to consider. 

Why? 

I want to encourage those of you who want to go this route do so because you thought of a project you want to contribute to.

Think about an application or a tool that you find interesting, enjoy using, or that you depend on to do your work. If you are already an active user of an open source tool, you are much more likely to be effective as a tester or filling other roles. The reason? You already have an understanding and an connection to the tool. You have a vested interest in seeing it succeed or have development of new features or bug fixes happen.

Once you have identified a project that fits that criteria, see if they have a link on their site that says something like "Getting Involved". Usually, that will bring you to an information page that will tell you what the project needs. Very often, documentation needs to be written, the web site needs some TLC, unit tests for features need to be written, bugs need to be fixed, automated functional tests may be out of date.

Often, a place that needs a lot of love is in the bug tracker of a project. As I mentioned in a previous post, many bugs are poorly written. There may be a large number of issues that are languishing because there just isn't enough information to get to the bottom of what's going on. Here is where a software tester of any level can be tremendously helpful. By going through the database and exploring the bugs, testing around the issue as described, you may find plenty of ways to make the bug more reproducible, expand the scope (or limit it), better explain the steps to get to the issue, and make the case for what needs to be done ( remember the  acronym RIMGEA). 

Don't be afraid to download the source code and set up a developer environment. With this, and frequently pulling updates, you can become very familiar with the underlying code. This might inspire you to see if you can directly fix some of the issues, or writing unit or system tests to help improve test coverage. If the tests work, and you feel confident of your changes, submit them and have them be reviewed by other programmers on the project. Don't take it personally if your changes are not accepted the first time. Ask for feedback, heed the advice, keep experimenting and try again later on.

Bottom Line:

Every project is different, and every project will have a range of scope, users and footprint. Projects range from small utilities all the way up to full Operating System distributions. Regardless of what project you choose, make it a point to learn as much as you can. Skills learned in one project can greatly enhance opportunities you might come cross in the future, whether they be more open source projects or paid gigs at commercial companies (or a cross section of the two; some Open Source project actually hire and pay people :) ).

Read Articles, Blogs, Forum Posts: 99 Ways Workshop #30

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.

Suggestion #30: Read Articles, Blogs, Forum posts. - Haplerinko

We are currently living at a time when technology can give us, at our fingertips, so much information that we cannot read it all, even if we spent twenty-four hours a day, seven days a week for the rest of our lives doing so. There's a finite amount of time and attention that we can spend, and the details that matter the most to us at one point in time will likely fall out of favor later on due to our needing to focus on something else. 

We've tackled the idea that starting a blog is a good idea if you have the passion to write one and the desire to develop a voice to talk about it. Each of us could write about our own experiences, and that very well might provide plenty of content for any blog. However, we as testers want to do more, be more and seek more (I may be falling victim to hyperbole here, but that's the way that I like to see my goals and approach). 

Chances are, others out there have answers to problems and challenges we face. We can read about them and comment on them all day long, but really, they're just words on a site unless we make a commitment to actually do something with them.

Workshop #30: Create your own "daily read", and make action items from it daily

There are a number of tools that can be used to accomplish this. Some people like to use aggregation tools like http://paper.li to accomplish this. Others will use RSS feed and a variety of RSS tools (Google Reader was the front runner for this, but sadly, they are no longer an option since Google shut it down). Feedly is a tool that I currently use for this purpose.

Everyone is going to need some content to work from, and if I have to suggest any one source to be a definite "first insert", I'd suggest Simon Schrijver and his "5Blogs" site. Simon tracks blogs from a variety of sources, and he publishes daily what he considers to be his top five finds.

Disclaimer: I am honored and humbled that a number of my posts have made his list, but that is not why I'm recommending it. I'm recommending this particular site because it offers a variety of jumping off points for anyone who wants to explore testing ideas, or ideas peripheral to software testing.

All right, we've made our reading list. That's great, but notice the second part of the workshop. I don't want to have you just reading these blog posts and articles. I want to have you make decisions and an action plan from them.

Take a notepad application, scheduler, or anything that you want to use to organize your thoughts.

With your "Daily Reader", I want you to take a look at the articles that appear there and try to find three action items that you can personally do something about. If three is too difficult to focus on at first, start with just one, but get in the habit of doing it every single day. 

Think of the action item… what do you need to do? How difficult will it be to accomplish? Is it specific? Is it time-bound? If you had to do something about it today, to the exception of everything else, what would you do?

Let's walk through an example, and yes, Simon's 5Blogs for August 2, 2013 is going to be my template.

The five posts:

To Benefit From Technology, We Need to Understand Psychology
Written by: Sam McNerney

This post asks us to consider the psychology of innovation, and the ways that we can apply psychology and how we perceive what's around us rather than try to create the latest gadget or massive R&D undertaking. What can I do in my own testing and product evaluation to understand the psychological aspects of what I am testing? What psychological cues help or hinder my overall satisfaction with a product?

Henry Ford on Leadership
Written by: Michael McKinney

This is a piece that reminds us of both the great innovations and the tremendous hubris that Henry Ford exhibited during his life. He was tenacious and determined, but he often relied on his own intuition. In many ways the more successful he became, the more pronounced this trait became. He always thought he knew best. Nevertheless, there are many lessons we can all learn from Henry Ford, from

- failure (even a mistake may turn out to be the one thing necessary to a worthwhile achievement)

- education (All that I personally own of any value is my experience, and that cannot be taken away. One should not complain of having one’s fund of experience added to)

- success (You say I started out with practically nothing, but that isn’t correct. We all start with all there is. It’s how we use it that makes things possible)

- passion (You can do anything if you have enthusiasm. Enthusiasm is the yeast that makes your hopes rise to the stars)

- character (The greatest thing we can produce is character. Everything else can be taken away from us)

- courage (One of the greatest discoveries a man makes, one of his surprise, is to find he can do what he was afraid he couldn’t do)

- initiative (I am looking for a lot of men who have an infinite capacity to not know what can’t be done)

- team work (You can take my factories, burn up my buildings, but give me my people and I’ll build the business right back again)

- personal responsibility (Chop your own wood and it will warm you twice)

Those are all great quotes, and they all speak to various aspects of leadership. Which one's will you choose to consider when you lead others (and let's face it, at various times, we all lead)?

The Importance of Goal Setting
Written by: The Bearded Tester

Most of us are used to setting goals in our professional lives (as part of our performance reviews especially), but how about in the rest of our lives? How do we achieve our personal goals, even small, seemingly mundane ones? What if we chose to use similar processes to help us achieve the variety of goals we have in our everyday lives, both big and small? How would we do it? Would we do something different if it was intensely personal and something we were passionate about? How about if we were to compare personal passions to professional goals? Think about what would happen if you applied the same approach to your personal passions as you did to your professional pursuits?

To Become a Leader, Start Acting Like a Leader Now
Written by: Naomi Karten

Naomi makes a great point in this piece that many of us think that, to become a leader, we have to be granted the power to lead. Someone on high with the authority and magic stick will tap us on the shoulder and say "you are now a leader". The truth is, that almost never happens. The real leaders are those who have long ago chosen that they will be the one's who lead, and have even done so in jobs where they had no power at all to do so. It's an attitude, and it's a choice, and those who show that they are competent tend to be given more opportunities to lead. 

Be honest, be ethical, look out for others and consider what will best help the team reach goals, talk straight, don't play games or toy with emotions. Make mistakes, and own up to them. Expect others will make mistakes, and give them the chance to own up to them, too. Teach regularly. Strive to do what you can to get obstacles out of other people's way. What in your every day job capacity, no matter how low on the totem pole you may be... what can you do to exhibit actionable leadership skills? If you can identify them, start doing them.

M&M’s, Stress and the Quest for a Sustainable Pace in the Tech Rat Race
Written by: Matthew Heusser

This is a parable, and it relates to the stress that we often see in our daily lives. If our desktop gets piled up, if we have a lot of icons on our machine's desktop because we haven't sorted or organized them, it often points to the fact that we are scrambling, or that a challenge has become overwhelming. Rather than focus on the sorted files or the clean desk, are we paying enough attention to the causes of the stress? We can all utilize techniques to organize ourselves and make things tidy, but techniques do not solve stress. Paradigms cause the stress (yes, I'm taking some Steven Covey liberties, but I think it's relevant). Our personal or work paradigm may be the root of the stress. Too few resources, too short a timeline, too aggressive an estimate, unwillingness to challenge the policy maker. Typically, these are the real reasons for stress.

We can clean up our desks, sort all our files, get ourselves to Inbox Zero, or eat all the M&M's we want to, but ultimately, those techniques will only mask the real issues. To get to the root cause of the stress, we may need to dig deeper and question the very paradigm we are working under (and that is a much harder problem). What am I doing to just "finesse" the stress? What might be the deeper underlying issues? How can I make a plan of action to address them? What policies, people, or institutions might I need to consult (or break away from) to ultimately reduce the stress?

There you go. Five articles, several actionable items that can be applied and worked on. Some are one offs, some are character traits that will take years to develop. Regardless, pick some short term and long term aspects, and figure out a way to integrate them into your daily routine. Examine which ones work and which ones don't.

Bottom Line:

We can read blogs and articles all day long, we can post on other people's blogs and answer forum posts, but ultimately, all that reading and pontificating comes to nothing if we aren't willing to make an action plan based on what we read. Do we want to reside in a world of gossip? do we want to reside in a world of watching events unfold? Do we want to just be entertained by ideas? When we just read and move on, that's ultimately what we are doing. To have those articles mean anything to us, we have to make a game plan to do something with what we read. It doesn't need to be earth shattering, but there should be something we take away from any article we read, something where we can say "OK, that's really cool, 'm going to do that!" Over time, the effects of acting on what we read can be staggering.

Start a Test Blog, and Comment on Others: 99 Ways Workshop #28 & #29

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.

Suggestion #28: Start a test blog - Erick Brickarp

Suggestion #29: And comment on others. - Amy Phillios

As can be expected, some of the workshop ideas I've suggested are going to correspond with other suggestions, so it's only inevitable that, if you have followed the examples up to now, that you'll get to these two and say "cool, I've already done that!" So I'm going to take this in a slightly different direction.

Blog? Yes, please do. But what about?

Workshop #28: "Don't have a blog about Star Wars. Have a blog about Jawas, or that one Jawa that appears on the screen for just a minute." - Merlin Mann

I well remember this talk that Merlin Mann and Jon Gruber gave at SxSW 2009 (http://www.43folders.com/2009/03/25/blogs-turbocharged) where they made a number of really great points about the value of a blog and why it might be worthwhile to start one. In it, they examples as to what people could do to make their blog as effective as possible, and one of the best suggestions, I think, was to define what your thing will be. 

Some testers are really hyped about automation. Some are really keen on tester games and puzzles. Some people like experience reports and examples of what they have done. My blog, in the most general sense, actually does have a central theme, and that has been Tester Education. In fact, this whole "99 Things" series is being done because it really does fit perfectly with the mission of my own blog. 

If you decide you want to create a software testing blog, decide where you want to target what you are doing. You may want to have an all purposes, general testing blog that give you the freedom to publish anything you want to. You may decide that you are interested in a specific area of testing (performance, security, automation tools, mobile devices, etc.). You may decided that you want to do a "co-thing", where a number of you decide that you'll make blog posts together. All of those are great ideas, but build an identity around something, and try to, at least for the short term, be consistent with that  identity.

From my own experience, I have found that blog posts tends to be three things: Technical Evaluation, Event Driven, or Philosophical Interpretation. 

Technical Evaluation

This is the classic "hey, here's how to do something". It's often geared towards using a tool, or an application, or a technology, and telling others how they can leverage it for their own benefit. Considering this, take a  tool or an application that you find interesting. Is there some cool trick about it that you like? Is there something you would like to share with others about that piece of tech? If so, write it up.

Event Driven

I do a lot of these, and they are, whenever I can arrange it, done as Live Blog" events. One of the values I find in doing this is that I can share information, in somewhat real time, with others that can't be there. While this can be very cool and very fun to do, it can quickly trail off into a travelogue or a "who's who" commentary. 

For me personally, I try my best to say "imagine I'm writing this for the "me" that, for some reason couldn't be here tonight. What would I want to make sure that he knew about this event? What's the most critical takeaways I can deliver to him? It may seem selfish, but I've found that I write better "Live Blog" entries when I focus my comments this way. It's what I need, right then and there, and I try to write it as though I couldn't be there, but really want to know what I can move on and do something about. Surprisingly, a lot of people have similar goals and trajectories, so what works for me, often works for other people.

Philosophical Interpretation

This is what  refer to as my "navel gazing" posts. I try to make sense of a lot of things, and try to apply them to my own life and circumstances. I make a lot of comparisons to my every day life, and how I can talk those comparisons and apply them to what I do every day. Truth is, much of what I discuss, consider, ponder, and try to apply are all philosophical questions that have already been posed by thinkers far more ancient, and therefore far more advanced, than me. Still, in my world view, philosophy not applied is just flowery words. If we try to embrace a philosophical discussion, go for it, but do more than just reiterate the philosophy, try to see how it applies to you and how you can make actual use of it.

Workshop: #29: Commit to Comment on Five Blogs Per Day for 30 Days

Why would this goal be worthwhile? One of the best reasons to generate enthusiasm for and inspire our own posts is to see what others are writing about. I don't want to go out and copy anyone else's work (though in some ways, that's a bit impossible; we're not all born with ideas, after all), but often, I find inspiration for new posts when I see someone else make a post. Having said that, when I say comment on 5 blogs per day, I don't mean to say "great idea, thanks for posting that". Seriously, that's not going to challenge your thinking, and it's not going to really challenge the thinking of the writer who wrote the blog post. 

Challenge yourself to make five comments per day, and do so on five different blogs, but look to see if you can make a comment on what was not mentioned, something you want to have clarified, or something you may genuinely disagree with. Put these ideas to your comments. 

Take this post, for example. Is there anything in this post that seems ambiguous? What do I mean when I refer to "Philosophical Interpretation"? Am I making a case for something that seems like a mis-fit? If so, please, comment and tell me. That way, I can see if, perhaps, my comments actually make sense. If not, I can reply and either say better what I mean, or ponder a different facet to my initial post that I might not have considered. 

Bottom Line:

Writing a blog post is more than just putting words to paper. It needs to mean something to you, and it needs to mean something to your target audience. Consider what matters to you, and where you want to target your blog's focus. 

Additionally, engage with other bloggers out there, and make comments that go beyond the "Good Job" or "I agree" variety. If you really appreciate something in a post, explain why you appreciate it. If you disagree with something, politely explain why you disagree. If you are not sure you understand what is being explained, ask for clarity. doing this has two additive effects. First, it allows the original author to reply and provide clarity, and second, you will probably find that the comments you post on other blogs will often spark ideas that will filter back into posts that you write on your own blog. 

What's the Risk? Weekend Testing Americas Returns August 10, 2013

Again, I figured some of you would like to have a break from the barrage of 99 Things posts, and what better way than to announce our next Weekend Testing Americas session.

First, the formalities:


Weekend Testing Americas - Session 42

Date: Saturday, Aug 10, 2013

Time: 12 p.m. - 2 p.m. (Eastern Daylight Time).

World Time: http://www.timeanddate.com/worldclock/fixedtime.html?msg=Weekend+Testers+Americas+%2342&iso=20130810T12&p1=179&ah=2

Facilitator: JeanAnn Harrison


Risk Based Testing for Mobile Application

All will need to download onto their mobile device a mobile email application. You can use either Yahoo Email app or Gmail app. Set up an email account if you do not already have one. Be sure to have notifications set up to be sent to phone when a new email is sent.


Agenda:


1) Brief discussion of risk.

2) Group participates in creating a risk based plan/approach for testing

3) Group implements testing (we can split up into groups to cover more testing)

4) Debrief: includes did we follow our risk based testing plan, how much test coverage do we feel we achieved


Logistics:


Add "weekendtestersamericas" to your Skype contact list if you have not done so already.


About 20 minutes prior to the start of the session, contact us on Skype and let us know you would like to participate.


Please let us know if you have any questions.

Learn to Program: 99 Ways Workshop #27

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.

Suggestion #27: Learn to program, some lines can help so much - Stephan Kämper

I've already suggested that understanding programming, even if it's just to make shell scripts for your chosen OS, go a very long way in helping to understand how systems work. They can also help make programming concepts more understandable and relate-able at a high level. At some point, though, to really understand how computer systems work, it is helpful to learn a bit about actual programming with a programming language, or a variety of them. 

Software testers do not have to commit to being expert programmers, or making programming the core part of what they do. Let's face it, there are many testers who can do some programming and have, for various reasons, decided that it really wasn't what they wanted to do as their primary focus. I'm one of those people. I just reached a point where I decided I was much more interested in seeing how a system performed in its user facing state than I was in making the components that made a system possible. I am also one of those people who has primarily used scripting and programming to do repetitive work for myself, but hasn't really written much in the way of larger programs beyond school projects. To date, the largest piece of code I've ever written manages registration details for a local music festival. I wrote it almost ten years ago. I still maintain it for the festival organizers today. It's in Perl if anyone cares ;).

Having said that, I have spent time over the past 30 years learning how to program in various languages at an elementary to intermediate level. I still remember a fair bit of GWBASIC, QBASIC, Pascal, C, C++, Tcl/Tk, Perl, Java, SQL, Ruby, plus a dash of Python and JavaScript, too. Having been exposed to writing programs in all of those languages has given me some understanding about how many computer languages work, and the commonalities between them.  

Workshop #27: Learn the basics of TWO programming languages (one procedural language and one object oriented language)

I need to give the credit to this suggestion to James Pulley, since he was the one to suggest it to me. The rationale here is that there are two major mindsets and approaches to programming. Personal preference and need may indicate which language an individual uses (as well as where we work and what the developers use), but James makes the case that a tester could learn a lot by just focusing on C and C++. That would provide the minimum requirements, and also show how procedural and object oriented ideas work within related languages (C++ is an object oriented super-set of C). 

It's possible that you may want to pick different languages to use, and that's cool, too. The point is to make some basic programs that will allow you to learn the major language elements, perform common operations, and create libraries, functions and structures (procedural) as well as classes, objects and methods (object oriented). Try to write the same programs in both spaces. If you wrote one procedural program in C, consider what it would take to write an analogous program using object-oriented approaches in C++ (or any combination of procedural / object-oriented languages).

There are a variety of books and online tutorials that will help out with this. Do a search for the language of your choice. Since I've geared my example to using C and C++, for those who want to use that as your basis, Cprogramming has a pretty nice tutorial based approach for C and C++ in one place.

Also, I am very much a fan of the Zed Shaw "Learn Code the Hard Way" philosophy. Zed has a tutorial called "Learn C the Hard Way", which really should be called "Learn C the way most people learned how to program back before the web made ubiquitous copy and paste so easy", but that's not nearly as catchy a title.

Bottom Line:

Each language has its own quirks. Each language will do things that will make sense in some contexts and make no sense in others. Learning the two paradigms can help the aspiring programmer read and understand other languages as well. The beauty of most programming languages is the fact that they all use many of the same concepts, and most of them use them in very similar ways. Looping, branching, true or false decisions, opening, writing to and closing files, accessing directories, creating structures to represent larger data concepts, and making libraries where procedures and objects can be stored to be used in other programs are all fundamental aspects of today's languages.  

The examples for C and C++ are shown simply because we can install one environment and cover both approaches (as I said earlier, C++ is a super-set of C; we can write 100% ANSI C programs in a C++ compiler and it should work just fine). Using different languages will require the overhead of two development environments, but that is also beneficial, since you will be able to see the differences in each and what they require to work on your system. 

No matter how you look at it, having a little programming knowledge can be a big help when it comes to talking with programmers. We may not be able to come up with all of the answers, but having this level of knowledge will definitely help us in getting to the right questions.

Teach Testing: 99 Ways Workshop #26

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.

Suggestion #26: Teach testing. - Stephan Kämper

I mentioned a few posts back that the Association for Software Testing offers a series of Black Box Software Testing courses. Part of that opportunity is the ability for interested and motivated people to teach those courses after they successfully complete them. I've gone through that process and so have dozens of others, and we are always interested in having more people do the same. We have a formal Instructor's Course that we offer for those who want to become Lead Instructors for BBST.

Having said that, you do not have to take a formal class to teach software testing to others. There are plenty of other ways to do it. Speaking at meet-ups, starting local user groups or chapters of test societies, or even an informal Lunch and Learn with you fellow testers at work can help make this a reality. It's this last idea I'm going to suggest for this particular workshop. 

Workshop #26: Make a training topics board, and show which ones you want to learn about and which ones you would like to teach 

This is the board that we have in our QA area where I work right now. It's a list of topics that anyone can post, and the colored dots are associated with a particular tester. Purple is my color. The solid dot means it's an area I can teach about. the open circle means it's something I want to learn more about (with the idea to potentially teach on later). I should note that, right now, the only color you see on the board is purple. That's because I just posted this. I expect other dots will fill in soon enough ;).

By posting a variety of topics, you can see if there is something that someone know about and is willing to share and teach/train to. 

I've personally found that "Push" training is not very effective in a work environment. In other words, if I were to say to my team "Hey, I think it would be great to talk about "Session Based Test Management", so I'm going to do a brown bag on it this Thursday". The team may come, they may support me, but the adoption rate or the effort to use it will actually be fairly low. Why? Because I'm the one telling the team "hey, we're going to get trained on this!"

On the surface, that may not seem like a big deal, but the issue is that it may or may not be that important or motivating to the individuals at that time. I much prefer the idea of doing "Pull" training, and that's where this board comes in. Instead of me telling the team "Hey, we're going to talk about SBTM", one of my colleagues comes to me and says "hey, I noticed you have SBTM listed as one of "your topics". Could you tell me more about it? Maybe this afternoon around 4 p.m.?"

This, I feel, is a much better model, because now I get a chance to talk to someone who has identified a need or an interest in the topic, and we can focus on the ideas one on one. I get to teach the ideas and the concepts, and I will have a much more engaged participant (this can also work with groups, too). 

In this Pull model, it's important to be aware of the needs and the interest of the participants. I'd suggest keeping training and teaching sessions short. Thirty minutes at a time makes the most sense to me, because people will start to lose focus or start thinking about other things they need to deal with. If it takes multiple sessions, do that. Keeping the participants engaged is what's important, and making sure they understand what you are showing them. This also works when you go the other direction. When I ask another tester what they feel they can teach me, I also try to respect their time, keep the sessions short, and see if we can regroup another time to pick up again.

Bottom Line:

Teaching does not have to be an elaborate and formal process. You do not have to be someone with a master syllabus and some grand plan to present material. Organizing your thoughts and being able to focus on key areas for the people you want to teach is important. Doing it with small groups, or one on one, at the request of the person(s) interested in the training is, in my opinion, the best approach. One additional added benefit of teaching… it will really help you understand if you know what you think you know. Teaching others, and having to explain concepts in a way that they will understand, can have a huge effect on how well you understand topics, too.