Wednesday, March 18, 2015

Learning: Twitter, LinkedIn and Other Communities

I find it fascinating how many little testing communities there are.  There are those in who love to tweet to each other, those who like to use LinkedIn either to simply create networks of testers or the forums.  There is Matt Heusser's community, James Bach has a following and does Skype coaching sessions.  There is the offer Isaac received to write for TestHuddle.  There is StickyMinds, STP, Professional Tester, Tea Time with Testers.  There is the top 100+ blog list.  This is not nearly all the data being generated about testing but it is a start.

The offer from TestHuddle brought up a discussion between Isaac and I.  Isaac has received credit for a few blog posts I have done, mostly likely due to the fact that Isaac's name can be found in Twitter where as I don't have a Twitter account.  I am not angry or bitter over that.  I hold Isaac in high regard and even though he posts less often, he often helps edit my blog posts.  It is a true collaboration, so credit isn't at all a concern.  However, I do find it interesting that testers often miss the detail of the "Posted By" at the end of each post.  The fact that these folks don't notice who is doing the posting suggests that they don't filter by who did the writing.

So What?


Everyone gathers information in different ways, but I suspect many people don't seriously consider the community and how they choose their community. Different people have different amounts of effort they wish to put into their profession, even when they do more than on the job training.  Even as prolific a reader as I am, I have not read even 1% of that content on testing.  In my writing on this blog, I try to reach a particular audience, those who have some advanced knowledge and particularly with interest in automation.  However, I also spend a good third of my posts to think about the community at large, that is to say either the CDT community or the entire testing community.  What I want to examine isn't just my own views, but to help get you on the road to thinking about the communities you help create.  To help you see that knowing who wrote something is important in deciding whether to spend your valuable time reading it or not.

For me, I am not well enough known to continuously hold a place in the entire testing community's consciousness, but occasionally I write something that gets some attention.  I sometimes write comments on other people's blogs.  I write for StickyMinds on occasion if I feel the content makes sense for that community. I co-run a user group.  However, I refuse to get on Twitter or accept LinkedIn invites from people I don't know.  In fact, this and email are basically the only reliably consistent ways I communicate to the outside testing community.

Why?


What I want to address is the reasoning behind this and what strategies you can use to filter the data you get.  First of all, using the Dreyfus model of skills, I would label myself as an expert within automation/tools and proficient with in the world of manual/exploratory testing.  I am only competent with handling social situations outside of my interactions with technical people.  This is of course just a self evaluation with approximate labels, but you too can evaluate yourself (but beware the Dunning-Kruger effect).  What is it you bring to the table, what is it you value?  What gives you energy and what annoys you?  As a quick example, if you read my writing often, you might notice I don't speak much of my personal life.  I prefer being private in that regard.  I don't enjoy registering my email over and over again.  I often use mailinator to avoid registering with my real email.  These are both for personal privacy reasons and because I hate being spammed even more, zapping even more life out of me.

With this in mind, many communities feel invasive to me.  They want to force me to sign up.  Twitter is pretty bad about this.  I do have a LinkedIn account, but I use that to maintain contact with people I know, not as a social network.  I have limited time and energy, and while I will respond to reasonable questions to my work, I can't be everything to everyone.  I don't want a huge set of people I don't know giving me endorsements when they can't truly know my skill set. For me, I want to get deep into a topic and I want to hear from other people who will deep dive into interesting and hard topics.  I don't care about the fluffery of social networks and I dislike the corruption LinkedIn encourages.  Why spend my time annoyed at people for claiming I have skills that they can't possibly know?

There is one other thing that I mentioned earlier that I think is of value.  I write both here on this blog and on StickyMinds.  In part because my work gets more exposure, but more importantly, the people who read StickyMinds are a different audience.  The level of knowledge and expectations on what they have come for is different.  If I started writing about national politics in this blog, I would lose audience I have and perhaps would get a different audience.  Knowing how the communities you 'live in' are seen by the outside can help tell you what sort of content the outside world is likely not discussing in the community you are in.  For example, I would not talk in detail about my multi-threaded load test implementations in StickyMinds.  Having that level of source code would not likely be published, much less be helpful in that community.

What you can learn!


So what do you value and how can you improve your signal to noise ratio?  I have found very few blogs that are always useful.  Instead I look to see if at least one in the last few posts has been useful.  Those that I personally don't find useful, I will ignore.  I would define useful for me in this context as something that is challenging.  I don't mind if I ultimately disagree with the conclusion.  In this post, I hope not to convince you that my opinions are correct but rather that you should develop your own.  I sometimes listen to youtube videos to see if the speaker can provide me with insights I would otherwise not have.  If it seems like that might be the case, I then will actually watch the video.  I find that the firehose of data can sometimes introduce me to new bloggers who I get value from.  The way I do that is by looking to see if there is a topic I want to read about.  Then I glance at who wrote it and if I don't know them, I will read it.

I wrote previously wrote about leveling up your skills in which I suggested nearly a dozen different ways to gain new skills or level up your existing skills.  The question is, what do you value and thus what skills do you want to work on?  Go find the sort of blog that will help you.  Or maybe you want more videos.  Go look at youtube.  There is plenty to learn there.  Or use pod casts.  That is partly about presentation and how it fits into your life (and how you learn).  The other question is what sort of content do you want. It might ultimately become clear that our blog is not the sort of blog you want to read.  That's okay.  Perhaps you need more data around a wiki based acceptance testing framework like FitNesse.  You probably won't get that from here, so find a blog or community that will help you.  Sometimes learning should not have a goal, and if you only do goal-based research, it might be valuable to try looking at something you wouldn't normally read about.

One of the major goals I have in teaching others is getting them to think for themselves.  I may use myself as an example to consider, but I am just an example, not necessarily the model you should follow.  In a sense, this post is about getting people, such as yourself, to be more reflective in your learning.  If you learn to learn just a little better, that will be a gift that will keep on giving for the rest of your life.  So spend a little time and reflect on how you gather information and learn.

Wednesday, February 25, 2015

Talking Topics

So we had a Lean Coffee about 4 or 5 months ago, where everyone wrote down what they would like to hear at our local Testing meeting group. BoiseOnTest

Over that time, JCD and I have had those cards on my desk, and randomly gone through them and tried to find people to talk about the topics rated the highest (don't comprehend, see http://leancoffee.org/)

I've grown tired of these sitting on my desk, and I think other people might benefit from having a list of topics to talk about for test meetings, blogs or use them as you see fit.

I have purposely NOT provided context or organization for these, as I think that stimulates more creativity.

Future of Testing / Ways to Evolve
Bridging the gap between manual and automation testing
Automation: What it can and shouldn't do
Mythbusting as part of testing
Ambition, Drive and Contribution
Change (Company, Position, Attitude)
Where do experienced tested provide value (vs monkeys)
Test Design
Test Strategies for continuous integration / deployment
Risk Management
How to find great testers
Test automation classification (unit, acceptance, BVT, smoke, etc)
Training resources for testing (recommended courses, books, blogs, etc)
Effecting change
Job satisfaction
SDET or Not
Advancement / Promotion in a Test organization
Planning
Time management
Speaking / Writing
Social Skills
Communication
What's hidden in the remaining 10%
Test technology (tools, trends, etc)
Web Security Testing
Testing in different states, conditions and combinations
Gathering useful information (logs, databases, etc)
Have speakers give talks on what they do on a day-to-day basis
Experience reports
Modeling
Strategies to influence development teams to test more
Data Driven Testing
Session Based Test Management
Testing Approach / Strategies
Waltzing with Bears - Communication up (specifically talking with authority, management, C levels)
Load testing techniques
The Scientific Method
Risk Analysis
Logic and Rational Thought
Math
Equivalence Classing
Deciding what to test when you're "Testing Everything"
Grey box vs White box testing


And now my desk is slightly cleaner.

Wednesday, February 11, 2015

The World Wants to Replace You With Something Better

In a world where technology is constantly getting better, with fewer jobs and more automation (speaking generally, not 'test automation'), the world appears threatening.  However, the world has always been this way, just less extreme.  Politicians have always looked for better funding, new ways of communicating and ways to look better.  They slowly edged each other out, but in doing so changed the world, each forging more and more ways of getting funding/communication channels/etc.  The world doesn't want you, it wants the next guy's better idea.  I speak of politicians because it is an easy way to see how people 'vote' for what they like (not what they need or should get, but that could be a whole blog post of its own).  Darwin speaks of this in terms of evolution.  Markets speak of this in economic terms using money as a voting mechanism.  One general term that is used is progress.

The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man. ― George Bernard Shaw

Automation of all stripes appears inevitable.  Will all jobs go away?  I doubt that, at least not in my life time, but what will the world look like?  Have you read and considered The New Luddite Challenge?  Like Bill Joy, I have and I still don't have a lot of answers.  I want to automate things because I hate wasting time doing the same boring things over and over again, but I don't think all work is a waste per-se.  Some people really like cooking, and so they are not wasting their time cooking, even if they cook similar dishes over and over again. On the other hand, just surveying some of my co-workers, I am sure cooking is not a pleasure for everyone. Even worse, waste in cooking is not just time, but also in burnt meals and trashed leftovers no one wanted.   In fact, in the last 50 or so years, we have started seeing food automated be it via fast food or food in a freezer.  While we are not forced to have those sorts of meals, automation has left many of us without particularly strong cooking skills.  The world has replaced what might have been superior meals for meals that require little-to-no washing up or cooking at all.

If you look at recent history, we had different people doing whatever it was that they enjoyed.  They would then hire other people to do the things they didn't want to do.  For example, I test software, but I don't much care to do my own garage repair, so I hire someone to do that.  If we automate some jobs or even just sub-tasks in jobs away, what do we do with those who want to still do the job that was then automated?  One of the easy examples is what happens to truckers when we automate driving?  Obviously children that don't know the 'joys of truck driving' won't dream of being truckers, so maybe this is a self-correcting problem, but I don't like saying 'wait until all those old school folks die off'.  I am not here to give answers to this topic, certainly not for such a complex set of questions, but I think if you write automation, you should seriously explore the effects and ethics of the profession and how it changes the world, before you create a world you don't like.

In fact, I would go so far as to say you should frequently examine what you are doing to see if it is what you want to see done.  That is to say, if you work for a company that gets cat pictures to people, is that something you care about?  Do you feel that another cat picture platform is what matters?  Perhaps you'd rather hack together a bunch of low-value apps and make a few hundred per app.

A Real World Example


Ultimately, our automation of simple tasks might eventually cost society some of our jobs.  Yes, test-related jobs can be lost by automation.  To get the regression I have produced with automation would require more people than we could hire, but to even reach something near that level, my company would have to hire 3-5 people with low levels of knowledge ("Beginners").  My wage might meet these theoretical low-level beginners, but they would be simple button pushers.  While there are pros and cons to automation (E.G. Testing vs Checking), I think the coverage could be argued as less for the human side, but to be fair, given enough training, the quality of the testing might go up.

Let us speculate in my circumstances.  There are 50+/- fields that have to be filled out, with different types of allowed values based upon different modes across 12 different version of the product.  These are all API-based, and with very simple text-feedback.  It took me about 6 to 12 months to automate to the level I expect these low-level testers would work at, and maybe 3 of those months were around discovery of how the system worked.  It was all regression work with only 2-3 new features over that time, all of which were covered by a different tester.  In my speculation, I would imagine these beginner testers would only do the regression, not the new features.

So let us consider what would happen if we hired those testers.  The testers would work for ~6 hours a day, and would be typing in input and checking the output.  It would increase headcount, and they might need another manager or at least a lead.  The other pieces of automation wouldn't have been able to leverage the work and we would have had to hire even more people.  Our organization would have ballooned into a factory school testing organization.  It would have been ineffective, but would have had more human-coverage.  I have worked in such an organization 10 or so years ago, we had ~100-150 people banging away at 20+k worth of written tests.

I believe automation in this case was the right choice.  I think it adds serious benefits to the organization and those benefits are long lasting.  I think it is best we never hired those fictional testers.  Yes, I recognize that I have created a false-dichotomy in that there could have been other possible choices in the hiring process, such as 2 mid-level exploratory testers.  I still think automation was a better choice.  Perhaps not testing this system could have been an option, but I think automation was a good idea... or using unit tests... or ....  Perhaps there was a better option, but they got me and my automation.

The Future Is Now

As I have documented before, many organizations are moving towards a No Tester view of the world.  In a very real possibility, some software may not need to be tested in the traditional manner.  The future may not need you. In some ways, I think that is reassuring, but for others it is indeed sad.  Charles de Gaulle popularized the quote, "The graveyards are full of indispensable men."  My efforts, as valuable as they are, are only temporary until the next innovation, but also my mistakes are only temporary until they are patched.

Everyone must leave something behind when he dies ...  It doesn't matter what you do, so long as you change something from the way it was before you touched it into something that's like you after you take your hands away. ― Ray Bradbury, Fahrenheit 451

As we keep moving forward, change will continue to come.  The lesson in this is not to give up.  It is not that you shouldn't go for a testing job.  It is not that you shouldn't bother coding.  Rather, go learn a new skill and tomorrow learn another.  The future wants a better world, and while none of us know exactly what that will ultimately mean, it certainly does not mean you should stagnate and quit learning.  Go learn.  Then find hard problems and work on them.

Tuesday, February 3, 2015

Resumes, Lying and Embellishment

I was reading how Raji Bhamidipati had noted how many people with little experience were using fake experience on their CVs (I will use the term resume).  They had several questions on why people choose to be unethical and fraudulent on their resume.  Furthermore, she states that many of these people end up being hired using their fake resume.  These hollow resumes, were not caught, but leave the person in question of being caught for the rest of their time at their job.  This entire article is speculative based upon my experience and research, but should not be taken as a sure thing.

History and Brains


I won't pretend this is a new issue, or something that 'our generation' started, but I suspect it has gotten worse over time.  First of all, economics and social history is a part of this.  Speaking specifically of the United States, after the 1950s, most of Europe was in a economic ditch due to the destruction from World War 2.  People could easily get jobs and brought up the 'baby boomer' generation.  The US invested a lot into tech, and made a large number of advances.  Without digging deep into the history, the boomer generation slowly amassed wealth and was able to assist their children to go to college and unlike any other time in history, the US population mostly has college education.  Unlike many areas in the world, in the United States it is often the case that you take out what is effectively a long-term loan for education.  While this is overly broad, many people excepted quick success or ignore the bill until after they graduated. The US slowly moved away from manufacturing jobs, leaving us with many 'service' jobs, like changing oil and child care.  One of the few other sectors with significant growth was tech.  Also part of the cultural zeitgeist was that the boomer generation encouraged a belief in their children of being special.  With large debts from school, few places to work (that pay well) and unreasonably high expectations in life, much of the younger generation has been forced to compete in an environment they were not prepared for.  Add in pressure from social networks where your successful friends are highly visible, and lying to get a job might seem like a way out and up.

There is another real set of reasons involving the brain.  The first one is, many of those who lie on their resume are young.  They have little life experience and don't have a sense of the possible consequences.  They also don't have the brain to handle the risks.  Literally, those who are young enough don't have as many connections to the executive part of the brain and make dumber choices.  It is also why crime trends towards youth as well.  Notice how the drop off age is about 25.  About the same time the brain develops.

Another factor involves the Dunning-Kruger effect, people don't know when they aren't very good and when they are very good they think less of themselves.  Those who don't know there lack of skill think they are amazing, so they tend to inflate their resume with less truthful statements.  Worse yet, since they are lying to themselves, they are in some ways more capable of lying to others.  Those who are more knowledgeable tend to know how little they really know.  They therefore seem less capable, which helps bolster the case of the less skilled.

Employers Worst Enemy: Themselves


The final factor is the automated checking of resumes that looks for keywords in a resume.  Sometimes playing alphabet soup can help you get a job.  If you have little to no experience, alphabet soup is about the best bet you can make.  If you can back up the claims even a little it might make sense to do so.  Sometimes this is referred to as 'Embellishment'.  However, that can become a slippery slope.  In what might have been the worst interview I ever observed, in looking to find an upside, my coworker choose a technology the candidate had listed and asked him to talk about it.  The resume had categories, like 'familiar' and 'expert', with this technology being marked as expert.  I believe it was Tomcat servers, something I think most of us were not expert in and was not used in that company, so we were not evaluating his actual knowledge.  His first comment was that he only used it in a testing context, and that was how he was an expert.  So we asked how he'd find a bug in said system, or how he'd get updates deployed.  The best answer we eventually got after digging into his background was other people did everything for him.

But what did we do?  If he was smart, we taught him perhaps how to answer that form of question better without ever learning any of the tech he claimed.  In essence, even though we didn't hire him, he could learn the wrong things from that interview.  Worse yet, while he didn't get our job, we had no way of notifying other employers of his behavior.  We couldn't say how we caught him in several lies because his former employers included employers we had, so we knew some of the work was not his.

From an employers point of view, when they are first hiring, it is not unlikely they don't know what a good tester looks like.  They do some web research and come up with a list of properties that sound reasonable to them and come up with a job description.  If you follow the CDT view where things depend on context, it will be hard for an employer to ask smart questions.  Worse yet, ISTQB is about the only thing an employer might be able to use to filter with.  Ignoring my personal opinion on the value of such a cert, since an employer probably doesn't know much about testing or  ISTQB, they are not likely to go doing the validation of such a certificate.  If someone feels ISTQB is of little value, they might justify in their head, "My employer won't know the difference."

The employer is more likely to offer on the low end of the pay scale, even if they want experienced people.  Sometimes this is because they can't afford anyone more advanced, else they would already have a test team.  Other times it is because they are small and thus don't have enough cash to afford senior people.  Even if they have a test team, not everyone treats this as more than a job, and might not take their interviewing seriously.  This allows beginners in, as well as those whom lie on their resume.  In my experience, often these sorts of companies also have death-march-like development processes because the company has not matured.  This makes it so that many newer recruits end up leaving.  Another area where this happens is in contracting.  When you need 30 testers in seats and you are contracted to have them, or your pay is tied to the number of people, you have a conflict of interest between hiring just anyone and keeping the customer happy.  You might hire a few 'iffy' people because you can hide them in the middle of some better employees.

 What Do We Do?

The truth of the matter is I don't know that we can as a society eliminate this sort of low-level corruption.  I worry as automation gets better and less high paying jobs come available what sort of world we will live in.  One likely result is with increased competition we will see an upswing in this sort of falsification.

In trying to evaluate my own predictions, I tried to find any data around trending, to see if this problem is in fact getting worse.  I couldn't find anything substantial, but a variety of different percentages were thrown around and nothing that felt authoritative.  The one thing I did notice was the numbers were typically large, like 40% of resumes have some form of fraud in them.  Okay, you caught me, it was 39% with other numbers on that page lower.  Oh, and that was percentage of organizations, not resumes.  Darn, you're reading up on my data now?  I just wanted to make the number seem more round and dramatic.  What's wrong with that?  The point is, we all have to be careful with our language and clear on what we expect.  I imagine you expect that I try to get my facts straight and while some rounding might be implied, that the unit of measure would remain consistent.  For example, culturally, Latin Americas commonly include pictures with their resumes, while in the United States, that is unusual.  So if you send a resume to Latin America, you better include a picture, as that is the norm.  I know no one of us can set such expectations, but you can set them for yourself and ask about unclear parts of resumes that don't seem to follow your standard.  We have to make honesty the norm by being honest ourselves.

Obviously if you are having people ask you about advice regarding lying on your resume, the answer should be no.  I have given recommendations for people, and I have had one friend list work he did for me in his resume when I was about 16-18 years old.  He actually did do some testing, but it was not for a formal company.  I said he could because he did the work, formal organization or not.  Some people might see that sort of buddy system as flawed because you can use contacts to get jobs, but those without contacts are disadvantaged.  I have even heard claims that this can be accidentally racist/sexist, based upon who you know and trust.  The fact of the matter is, that hiring people you know and trust has always been a thing.  The reality is that hiring based upon personal knowledge of someone else's previous work is one of the best filtering mechanisms.  Hiring based in part upon the recommendation of someone you know is probably helpful.  Dr. Kaner suggested a entire packet of stuff be used to track someone's career, but that doesn't help much for those starting off.  Perhaps a broader network, like that of Dr. Kaner or LinkedIn is also of value, but that only helps vet people you know.  I recognize that some people may disagree with the idea of hiring people you have formerly worked with, and I welcome discussion around that.  I think it is better to have an open discussion than for me to stand on my soap box and expect you to just accept what I say.

There are two things we can do today for every candidate.  The one easy thing we can do is be careful with our hiring.  Get to know the candidate, ask lots of questions, and in the end, if you aren't sure, don't hire them.  I know that can hurt candidates, but I think it is important to choose the right person rather than getting the wrong person but moving faster.  The second piece is to investigate the claims of a candidate.  While I think it is better to do so in an interview, even after an interview, if a candidate makes a claim, it isn't too late to go look into it.  Better to spend ten minutes now than waste 6 months with them and another 3 months trying to get rid of them.  If that means calling the candidate to ask them a question, get on the phone and call.

While most of this has been about the interviewer insuring they are not being lied to, the candidate too should be concerned about the company.  From a candidate side, ask detailed questions, and dig into the details.  What is your bug count?  How much does it vary?  What flaws are there at the company?  What strengths?  And again, don't assume the interviewer isn't embellishing in their answers.  I don't think any interviewer would say "It's hell here.  Go somewhere else."  So investigate the company and the workplace environment.

Ultimately, you have to work with either the candidate or the people interviewing you for 8 hours a day, for a long time, so choose wisely.

Thursday, January 22, 2015

Leveling Up Your Testing Skills

Recently I gave a talk intended to be a quick survey of some of the core areas of testing.  I certainly didn't hit everything, but meant to give people tools to go exploring on their own.  I used a text editor for my presentation, because not everything needs power point.  I thought it might be useful to others so I am recreating it here.  I have done some minor modifications, removing things that only made sense in context of a performance.  I also added a few things based upon the discussion during the presentation.

 ----- Page 1

Survey:

Who has heard about AST?

How many of you have read or even skimmed a testing book in the last year?

How many of you have read a white paper?

How many of you have written ANY bugs outside of professional obligations (your job, school, etc.)?

Has anyone tried to formally QA an article?

How many of you have heard about the “No Tester” movement?

How many of you have heard about ISO 29119?

 ----- Page 2

Purpose:

My purpose is not to teach you facts about testing, even if some of that happens, but rather to teach you what questions you didn’t know that you should even ask and show you places you didn’t know to look.

NOTE: I know I cite myself several times, and while there are other sources, few are as narrowly focused to the strategies I am going to talk about..

 ----- Page 3

Do you know the different ‘schools’ of testing?

Four Schools of Testing*: www.testingeducation.org/conference/wtst_pettichord_FSofST2.pdf


Analytical School - Code Coverage, Unit Testing


Factory School - Metrics, Traceability


Context-Driven School: Exploratory, Multidisciplinary based upon context


Quality Assurance School: Protect user, Gatekeeper, Process-Oriented

* [Edit: Since this presentation, I have discovered an updated model including a 5th school, Agile.  See https://www.prismnet.com/~wazmo/papers/four_schools.pdf)
 ----- Page 4

I’m mostly going to speak from the CDT point of view…

(Aside: While I appreciate CDT’s philosophy, be aware that if you approach the community online, some people participating in CDT’s development tend to be passionate/challenging/aggressive and some are very interested in defining words.  Even if you are not interested in that, CDT is still worth looking into, just figure out who you find value from and whom you don't get value from.)
  
 ----- Page 5


Two of the largest “CDT“ classes:

BBST: http://bbst.info/ ; http://www.testingeducation.org/BBST/ ; http://www.associationforsoftwaretesting.org/training/courses/ ; http://altom.training/bbst-foundations/

RST: http://www.satisfice.com/rst.pdf

(Both have free portions, BBST includes all the lectures for free)
  
 ----- Page 6-8


Models and Heuristics:

What are they? Read my work: Words of the Week: Heuristic [& Algorithm]: http://about98percentdone.blogspot.com/2013/10/words-of-week-heuristic-algorithm.html

“A Heuristic is an attempt to create a reasonable solution in a reasonable amount of time.  Heuristics are always Algorithmic in that they have a set of steps, even if those steps are not formal.” 

List of Heuristic Mnemonics: http://www.qualityperspectives.ca/resources_mnemonics.html

SFDIPOT - Structure, Function, Data, Integrations, Platform, Operations, Time

HICCUPPSF - History, Image, Comparable Product, Claims, User Expectations, Product, Purpose, Standards and Statutes, Familiar Problems

Heuristic Test Strategy Model: http://www.satisfice.com/tools/htsm.pdf

How do you know when you are right? http://about98percentdone.blogspot.com/2013/11/how-do-you-know-when-you-are-right.html



Models:


Session-Based Test Management: http://www.satisfice.com/sbtm/index.shtml

Thread-Based Test Management: http://www.satisfice.com/blog/archives/503

Tours: http://www.developsense.com/blog/2009/04/of-testing-tours-and-dashboards
   
 ----- Page 9


Books (just a few):

An Introduction to General Systems Thinking: http://www.amazon.com/exec/obidos/ASIN/0932633498

Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design: http://www.amazon.com/Exploratory-Software-Testing-Tricks-Techniques/dp/0321636414

Lessons Learned in Software Testing: A Context-Driven Approach: http://www.amazon.com/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124/

Agile Testing: A Practical Guide for Testers and Agile Teams: http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468/
 
 ----- Page 10


Self-based learning

Go find a testing job for the weekends like:
http://www.utest.com/
http://sourceforge.net/p/forge/helpwanted/testers/
http://www.guru.com/d/jobs/
http://weekendtesting.com/america
   
 ----- Page 11


Where are you going?

http://blog.red-gate.com/wp-content/uploads/2014/02/Test-Engineering-Skills-v3.pdf

(Go look at this guy, it is an interesting list of skills)
   
 ----- Page 12 & 13 

Experts and active members of the community:

There are different people who have different expertise’s that are worth reading.  Not everyone does much automated testing, while other people are more interested in coaching or test design.  Look at where your strengths are and find people who will be able to supplement them.  Some of these people may in fact oppose my own views, but that too can be valuable.  Debate helps you understand your own point of view.  Here is an example or two….

James Bach* – Testing is an Intellectual Inquiry
James Christie* — Consultant, Professional Auditor and Tester, Started entire ISO 29119 discussion
Jon Bach* — Session-Based Test Management (with his brother)
Michael Bolton — Testing vs Checking
Huib Schoots — Dutch Testing Coach
Scott Barber — Load Test Guru
Rex Black — Proponent of Factory School of Testing***
Harry Robinson — Model Based Testing
Justin Rohrman* — Active in community, board member of AST
Robert Sabourin** — Author of I Am Bug (pictures by his 12 year old daughter)
Jerry Weinberg  — Systems thinking, consulting, author
Karen N. Johnson* – Professional Tester’s Manifesto
Fiona Charles* — Author, Speaker
Matt Heusser* — Founder of Miagi-Do
Cem Kaner — Originator of CDT, BBST, Legal concerns around testing
Alan Page — (Former?) Microsoft Test Architect



* I met these folks at CAST, and you too can meet these sorts of folks at CAST.
** I met Rob at WHOSE, I enjoyed his writing at WHOSE but he tends to be more academic in my experience.
*** [edit:  Since publication my understand of Rex Black's ideas has evolved. Rex specifically rejects the concept of Schools and, as best I understand would prefer I say he's a Proponent of the Strategy of Factory Style Testing in some contexts.  I leave the original work as stands for historical reasons.]

(Some of these people are accessible to talk with, some only speak through their work, some through conferences…)
    
 ----- Page 14

An Exemplar (with more details): 

Doug Hoffman

http://www.softwarequalitymethods.com/h-papers.html
(pay attention to the dates of the papers, some have updated versions)

He has written exhaustively around automation and testing.  While that isn’t the only work he’s done, you will get a good idea of the depths you can go in with automation.  On the other hand, if you want to learn to code, Doug is probably not the man to visit.  He’s interested in theory behind automation.  He was one of the minds behind the ideas High Volume Test Automation and Exploratory Automation.

I wouldn’t go to Doug to find out the latest idea behind Selenium.  I would go look at Doug’s work to understand what sort of automation techniques might make sense to apply to a problem.
    
 ----- Page 15

Questions you need to ask (that I can’t answer):

How much time am I willing to dedicate to learning?
What sort of things do I want to learn?
How varied do I like my studying?

Is this a job or a profession?

Do you want to do something that matters?

Are you okay with having 10 years of experience that really only add up to 1 year of valuable experience?

 ----- Page 15-17

Questions you need to ask (that I can give hints on):

Where can I learn?
 - Blogs
 - BBST/RST and other classes (LST is another CDT class, RBCS is from the factory school)
 - Books
 - Co-workers (particularly challenges)
 - Conferences (CAST - https://www.youtube.com/playlist?list=PLQB4l9iafcelXpJnK6IyDsoFeEb1icqrl , Code Camp, Star West, Star East, Agile testing days, GTAC - https://developers.google.com/google-test-automation-conference/2014/stream , etc. ; Often recorded on Youtube)
 - White papers: http://about98percentdone.blogspot.com/2015/01/white-papers-and-who-owns-your-education.html

What should I learn?
 - Start by glancing at the foundations class.  See how much of it you know already.
 - Read blogs about what interests you.
        - Look up the people I talked about (I suggest Googling "<Name> Testing”.  Almost all of them have blogs).
        - Look at the top blogs and see what they have to say: http://www.testbuffet.com/lists/top_114_software_testing_blogs_2014/page/1/
        - If those methods don’t work, try looking at the fire hose and see if there is an interesting topic: http://www.testingreferences.com/testingnews.php
 - Start your own blog and learn to write; here is mine: http://about98percentdone.blogspot.com
       - Feeling shy?  Why not start by writing comments.
 - Pick up one book.  Read it.  Don’t like the ones I listed?  Check out this extensive list: http://www.testingreferences.com/software_testing_bookstore.php
   - Write a review on your blog
 - QA a news article.  Write up bugs on failed assumptions.
      - http://about98percentdone.blogspot.com/2013/09/testing-babies-for-learning.html

Learn about your interests AND figure out how much you are gaining.  If your energy wanes, move to a different topic or take a break.

What else can I do?

- Figure out what matters and work on that: http://about98percentdone.blogspot.com/2014/10/noise-to-signal-attempt-to.html
- Don’t keep working in the same position for too long.  Changing jobs is healthy.
- If you aren’t much of a reader, but rather audio or video, try some of these: https://flowoftesting.wordpress.com/2014/09/02/podcasts-and-videos-for-testers/
- Learn from the history of testing: http://www.testingreferences.com/testinghistory.php
- Find some heroes and some villains and learn from them (villains will help you clarify your own views): http://about98percentdone.blogspot.com/2014/01/heroes-and-villains.html

Have fun.  If this doesn’t sound fun at all, go find something that does, even if it is a different career.