Showing posts with label History. Show all posts
Showing posts with label History. Show all posts

Sunday, March 25, 2018

Code Camp Presentations

I present two hours at code camp earlier this month on the topics of blackbox and whitebox software testing.  The two topic were broken out in a way that anyone could attend one session or the other and get value out of them, but both was better.  Blackbox Testing was the first hour and Whitebox Testing was the second hour.  For those who did not attend my presentation, I should note you maybe missing some context that I gave during my talk but was not recorded in the slides.

One important aspect not in my slides but I told the audience was my blackbox talk was heavily influenced by the BBST courses developed by Cem Kaner and the book Lessons Learned in Software Testing.  So if you have questions, please feel free to bring them up in the comments below.

Blackbox Testing Abstract

Blackbox Testing involves testing software without knowing the internals of the code. This is a survey presentation, covering a broad set of topics meant to expand your interests and provide self-study opportunities. We will cover: 
* Schools of Thought: Where we have been, why testing has changed
* Testing Missions: How to know what you should test 
* Testing Strategies: How to make your testing organized 
* Testing Tactics: How to make your testing better

This will include practical examples as well as theory. You do not need to attend the whitebox session to gain value from this talk. However, these presentations are meant as a pair and will not cover the same material.

Whitebox Testing Abstract

Whitebox Testing involves testing software with deep knowledge of the internals of the code. This is a survey presentation, covering a broad set of topics meant to expand your interests and provide self-study opportunities. We will cover: 
* Schools of Thought: Where we have been, why testing has changed. 
* Limits: Why you need both the light and dark sides. 
* Techniques: Static Analysis, Security Analysis, Unit, Integration and System Testing 
* Tooling to make that blackbox system more white. 
* Automation techniques, including both white and blackbox techniques.

Almost none of the content here will be a repeat of the Blackbox Testing presentation. While it is not required, it is recommended that you attend the Blackbox Testing presentation.

Monday, April 4, 2016

Taking Stock of your QA Career and Retirement

I have talked with several coworkers over the years and all of us have felt at times like it is unclear how to invest for retirement.  Before I go on, I want to assure you that this will not be an advertisement for a particular stock nor will it be US centric with advice on 401k and IRA plans.  Anything I say here is not financial advice, so please do see a professional. To be clear, believe nothing said in this post but rather that you should test all this out yourself.  Use your skills in testing to analyze the data, create mind maps, and don't trust just one source.  I will point out some common heuristics we use in testing that you can apply to the problem.  Your own future is at stake, and at the very least you should approach this problem with equal fervor as you approach your day-to-day testing challenges.

My Experience With Fees


When I started my career in QA at 18 I knew people said I should invest in the stock market, but I was only making a little over minimum wage for 30 hours a week.  I had no money to invest.  By 24 I had changed jobs and was making a better wage, but I had no time to look into how to invest in stocks.  So I used my company’s small compensation, which invested an additional dollar for every dollar I invested, up to 3% of my salary.   Then the housing crisis hit and my very small sum dwindled down to approximately 1,000 dollars.  The investment company was charging me 60 dollars a year in fees, and I felt my money was better off in my pocket than having it spent away on losing stocks and fees.

Now, let’s look at this from a QA perspective, using tools like system’s thinking and the scientific method.  I have since examined a lot of historical stock market data and it’s clear there is money to be made.  Hiring out the investing process to someone else can cost a lot of fees.  So let’s develop a test to see if the fees are worth it.   Since the stock market is easier to measure, let’s use that.  Per Wikipedia, the S&P 500 index fund averaged a return of 12%.  I was being charged 6% in fees.  Since that seems high, let’s also see what 1% and 2% fees would look like.  Here is how that would play out in a 10-year period of compound interest:

FeesInterest After FeesStarting Value10 Year End Value
6%6%10,00017,908.48
2%10%10,00025,937.42
1%11%10,00028,394.21
0%12%10,00031,058.48
(See this calculator if you want to run your own tests)

So in 10 years, 6% in fees cost 43% of the possible income.  2% costs 16% of your possible income.  When calculated out to 50 years, 2% of fees from 7% interest will cost you 60% of your income!  So fees do matter, due to the magic of compound interest.  Don’t believe me?  Test it yourself!

 As an important aside, please be aware that while the S&P 500 has seen a 12% rate of return, this does not factor in inflation.  Most inflation adjusted numbers I see show 2-3% of the earnings lost to inflation.

Requirements, Stocks and Bonds


In my story, fees were only one factor.  Another big factor was that I didn’t want to take up a lot of time, time I want to invest in testing career and home life. So, one of the clear requirements is that a retirement system for me must be fast and easy to calculate.  Speculation is a form of gambling with high risk and high reward while investing is an effort to decrease risk and while moderately increasing reward.  In testing we are use to trying to find high-risk areas to investigate and we can use that skill to decide what to invest in and avoid speculation.

With these two requirements, me personally playing the stock market as a day trader is out.  Investigating, buying individual stock and holding it breaks my time requirement.  Housing is so variable to location and many other complex variables, that I think it's too difficult to go into in a short post, but the NY Times calculator was helpful for me.  While buying up gold, oil or other commodities is possible; it tends to be a little more complicated than stock.  This too feels more risky and time consuming, which clearly violates my personal requirements.  So, there are only three big possibilities left within the stock market.  There are actively trade funds, index funds and bonds and of course, one non-market option of retaining cash.

Bonds are effectively agreements to pay back loans from large institutions, like governments, so they can build bridges now, and pay back the loan on low interest later.  They tend to not pay much in interest, but are also generally safer than stocks as governments don’t collapse that often.

Stocks are in fact businesses, which mean you actually own a piece of a business; you might own a brick in the building of your favorite restaurant.  So even when the stock goes down, keep in mind the building is not gone, it just means that someone decided that that the building or the brand or whatever was worth a little less.  On average, if the heuristic of history is a guide, the market goes up in the long run.

Then there are index funds, “algorithmic funds”, often meant to represent all or part of the market.  The S&P 500 and even the Dow Jones fall into this category, both picking the largest companies in the market in an effort to represent the market as a whole.  There are even funds that hold every stock in the market.  In effect, these give you the ‘average’ of the market or some subsection of the market.

The last stock market option is an actively traded funds.  These funds hire experts to gauge the market and invest in what they think are the best companies.  Since you are hiring experts, it costs more and thus you have higher fees.  The question is, are they worth the cost?  Can they outperform average?  Or perhaps, flipping it on its head, can you pick a fund manager who can out perform the index fund?  Keep in mind, Warren Buffet from 1994-2014 made about 12.5% interest compare to the S&P’s 9%.

Of course you could choose to not invest at all.  Keep in mind that not investing is not actually a 100% foolproof way of protecting you.  Inaction is still an action.  First of all, you are being taxed on your income, where as in some countries investing is tax deductible.  Furthermore, cash can be hurt by inflation.  Even if all you did was save cash and could save enough, when you retire, your cash will spend down faster due to a lack of interest, putting you at risk of running out of retirement.

In my opinion, unless you have the time, talent and interest, index funds make things much simpler.  Unless your stock manager is the next Buffet, 1-2% fees will be more expensive than the potentially better outcome they might provide.  However, if you’re a numbers expert or you think you know which mangers will make great investments, go for it! Ultimately you should test these assumptions.

How Much Do I Need?


The final piece to this puzzle is how much do you need to save for retirement?  Earlier I said stocks were a good long-term investment, but how long is long term?  Long term is from the day you retire to the end of your life or beyond.   So, will your money last your lifetime?  More interestingly, can you make your money self-sustaining, using the history heuristic as a reasonable guide on returns?  It turns out the second question is actually reasonably easy to test.  Using the several studies on withdrawal rates show that approximately 4% is a safe withdrawal rate assuming the past is a reasonable guide.  And while I admit that nothing is guaranteed, it's a useful starting place. 

With 4% as our “typical” case, we can start with the assumption that 25 times the current expenses will yield you a safe amount of income.  That is to say, if you take out your current expenses from your stocks/bonds, you will take out 4% of the total fund.  These studies often found people would grow multiple times the wealth they start with, but 4% was for the worst year to start retirement and not run out of money.  Keep in mind your taxes, health care, driving and childcare expenses may change when you retire, but in most cases expenses will go down.  So if you use your current expenses, you're likely to have a reasonable safety net.  Obviously this is critical to your retirement, so you’ll want to test this piece carefully with a lot of what if scenarios.  Tour through your retirement with costs of new hobbies or traveling and with some stress tests, such as you have lots of expense for a few years in the beginning, middle and end of your life.

Have you tested your retirement plan lately?

Post Scripts


In writing this post, I did a lot of research, not all of which fit the nice format of an article.  So, in a mostly unformatted way, here are some additional thoughts to consider:

  • Testers often make a higher salary than the average US household income (and often that is a two person working household).
  • The data seems clear, at best only a few people can actively beat the market long term. However, that is a theory that can be put to the test.   Even active fund managers claim that there is a better than 50% chance that a index fund will outperform an active fund, and it is unclear if that includes fees.
  • This is a nice simple explanation of the business cycle and why it exists.
  • The S&P 500 is more an American index.  While I was not researching how Europeans invest, I did run into an interesting article with different investment methods for Europeans, including investing in the US market.  I have no opinion on the validity nor usefulness of this, as this is not a problem I have faced.
One final thing I wish to make clear is I'm not making any profit from this blog post.  I make no endorsement of any particular investment strategy, I simply suggest you do the research now, when it is easier to plan for retirement rather than waiting until it's too late.

For anyone who has made it this far, I do have a query.  I'd like to know, is this content useful?  Is it too far from testing to be of value or does it still feel connected to testing?  Please tell me by writing a comment below.

Thursday, September 10, 2015

Belief: Absolute Conviction or Probability?

I have long been thinking about the nature of the world, the nature of belief, knowledge, faith, etc. I have come to a conclusion that is both obvious and perhaps to some, scary.  This is one of those personal adventures, and it will take a little bit to explain.  It's also rather abstractly connected to testing, so if you are looking for how-to articles on testing,  I'd go looking here or even here instead.  You've been warned.

By modifying the definition of belief ever so slightly, my language in fact sounds completely reasonable, and I suspect that my version of belief is much closer to the reality of what a belief really is in a psychological sense.  In particular, I can say I have observed it with people who do scientific-like work.  Let's first start with dictionary definition of belief.

According to Merriam-Webster, a belief is:

1. a state or habit of mind in which trust or confidence is placed in some person or thing
2. something believed; especially : a tenet or body of tenets held by a group
3. conviction of the truth of some statement or the reality of some being or phenomenon especially when based on examination of evidence

Knowledge in epistemology is well known to be a "True Justified Belief."  Effectively, the difference between belief and knowledge is that a belief may not be true and it might not be justified. You can only claim to know something when it is true and justified (although how much justification is still in question).  I have also done some informal consideration of justification, which can be valuable in justifying a bug.

In a World...


Imagine, if you will, a world where beliefs were held so tightly that they were in fact the way you ran your life with exact and precise calculations.  You might be like some of the Vulcans who dedicate themselves to pure logic, as described in Star Trek, except your dedicate would be to your own beliefs, not logic per-se.  If, for example, you believed in a set of development principles, you would never break any of these principles.  Assuming your principles were designed correctly to never have functional bugs, a functional bug would not exist in a code base you exclusively created because your beliefs would be personal law, with you never straying. The only possible remaining set of functional bugs are those which are not covered by your beliefs or areas where your personal mental model of your belief was not exactly in congruity with the actual statements of the guiding principle, which is just a form of misunderstanding.

For example, if you stated your belief was "No text box I create will have an injection attack possible.", but your mental model was only based upon SQL injection and did not consider command injections.  Then if you had a vulnerability to a command injection attack in your text box, is it the fault of your beliefs that no text box should be vulnerable to injection attacks?  I think not, because you either had a limit to your understanding of your philosophy (what you believe an injection attack to be) or the world (what injection attacks are known to the world).  However, a more subtle question and interesting question is, did you really hold the belief?  I think the answer is complicated.  Internally, the answer is yes, of course you believed.  However, from an external view did you hold the true belief?  Yes, you held the belief in your own way, however, it might not meet some external evaluator's view of how that belief should be held.  This is a communication problem people run into all the time when they define words differently.

Thus, your personal reality would appear to succumb to your beliefs, or your beliefs would say nothing about reality. That is to say you would ignore your own senses when you observed the natural world contradict your beliefs. This occasionally happens at a developer's desk when they say, "That isn't possible." as I demonstrate a bug to them.  Do they see the world shifting out from under them or are they ignoring it?  Do they see their belief ruined and their world is crashing down?  For some people, this Vulcan-like demand for the perfect belief, the idea of the world crashing down might come close to their view of life.  Then there are others who choose to doubt only the facts they don't like, so that their belief is maintained.  But do these groups go from the point where they say “I believe” and run their life exactly according to their proclaimed beliefs?

Perhaps a few do run their life exactly according to their beliefs, but I suspect that it is more likely most have a journey where you slowly reform both themselves and their beliefs.  Even with all the defenses around their beliefs, and all the denial for the facts contradicting, I think given time to consider, people can migrate beliefs.  Like the developer who claims the bug is not possible, they adjust their beliefs over time. So, either most of us are able to hold two opposing beliefs at the same time ("That isn't possible" and "That just happened") as we reform our beliefs, or are able to ignore those former beliefs somehow, thus truth in the mind and actions are not strongly related.  The latter option is sometimes referred to as rationalization.

For the sake of argument, I am going to assume that in fact people can hold two opposing beliefs at the same time. The reasoning I am assuming this is that if belief of a truth and how one acts have limited relations, then we are creatures whose entire rationale does not matter and thus the entire nature of belief doesn’t matter in this context. Another reason for my assumption is that in working with software testers, I have observed this ability to weight two opposing beliefs.  In my observations, it wasn't that they had ignored their belief and just done something else but rather taken context into consideration.

50% Chance of Opposite Day


If we can in fact hold two opposing “beliefs” then those are not beliefs in the traditional sense.  One is not in fact completely confident in their belief.  Instead, what they almost become is an internal struggle for which belief is more accurate in the modeling of the world.  Since different people model the world differently, a realization occurs that multiple models can both be correct.  In a real sense, the person with said beliefs is weighing non-mathematical probabilities.  Now, if that is what we are doing, trying to decide which version of belief is more likely, and we have the ability to replace one belief with another based upon this evaluation, beliefs are just things we attach a probability on.  Another way of saying this is that they are context driven.  The probability that a particular belief will satisfice is determined through life-experienced context and those probabilities are constantly being re-evaluated as more of life is experienced.

I try very hard to avoid politics in this blog, but I wanted to address a good example of differences in mental models where it is not clear what the meaning or intent is.  Recently, a woman claimed that she is black when her parents disagree with her and claim she is white.  The interesting question here is, what is it to be "black"?  Is it a life style?  Is it a social upbringing?  Is it a description of particular genes?  Is it a color?  At what time and under what conditions?  Is it an origin?  How many generations back?  Is it a description of being disadvantaged? Is it an artificial classification?  How many of these checkboxes do you have to have to be considered black and which oracle(s) do you listen to?  Is this another true Scotsman problem?

If beliefs are actually statements we find likely to be true, we are attaching what I will refer to as a probability. It may not be numerically calculated, but a consideration of one’s experiences, perceptions, internal mental structure, and numerous other factors. Ultimately we come to some sorts of conclusions. "I write great code", "I’m in love", "JCD writes good blog posts", ad nauseum. Can you in fact believe both “men are evil” and that “evil does not exist”? If those are just probabilities, then yes, those can in fact both be beliefs at the same time for one person. Keeping in mind that knowledge is a true justified belief; you can’t “know” both of these things at once, because only one can logically exist at once, but which one? Even with all the brains we have, this appears to be a Gordian knot of a problem. Cutting the knot using things like Occam’s razor only goes so far (It is only a razor!).  Worse yet, the question of context pops its head in here.  "In the past year JCD has written good blog posts" adds context that the first statement did not have.  A developer's defense of "No one would do that" is true in the context of "that I like and hasn't made a mistake and ...."  Perhaps with enough context one could claim knowledge, but you know the saying about building an idiot proof box... I suspect if you could build enough context, someone would just come up with new unconsidered situations.

Why not accept our nature and in fact embrace it? If someone says that “men are evil” and provides limited evidence, you can assign a probability to that (let us assign an arbitrary tag “somewhat likely” to this). Then someone else comes along with highly convincing evidence that in fact evil can’t exist. You weigh the factors you now have and change the scales, applying a “very likely” for "evil can’t exist" and downgrade the “men are evil” viewpoint to “fairly unlikely.” You need not deny either one of those items and yet you can still hold a legitimate opinion that "According to my present data, evil is unlikely to exist."  The tricky thing is, English does not make it easy to give these sorts of answers.


"Nonsense is so good only because common sense is so limited." - George Santayana


In a brief change of topic, I want to stop and address what some readers might be thinking at this point.  I am sure some people see this as non-sense.  So I want to take a brief aside to consider the possibility that this idea doesn't matter.
"In the West, we take the “law of the excluded middle” as self-evident  and  as fundamental  to  logic.  Under  this  rule,  a proposition can have two states: something “is X” or “is not X”. There is no middle ground. In contrast, several Indian logicians assumed four states, “is X”, “is not X”, “is both X and not X” and “is neither X nor not X”. I puzzled over this for many years. I am not confident that my understanding of how this could be meaningful is the same as their understanding. But in human affairs, in interpreting  people,  how  they  interact,  what  situations  they  are  in,  and  how  to negotiate  with  them,  I  came  to  view  the exclusion of the middle as a heuristic rather than a law or a rule. It is often useful to assume that “X or not X” are the only two possibilities, but when that is not productive, it is time to look for a third way." - Dr. Cem Kaner, Tea-time with Testers, June 2015, Pg 61
I could go on, as Dr. Kaner certainly has more around this.  The idea that perception is in fact reality is often skewed.  In the same magazine issue, Jerry Weinberg tells a story in which the three team members whom did all the talking were perceived as the leaders performing actions but the the one with an effective action was not the team member being defined as the leader.  The team member with the affective action was another employee whom only did one thing, silently solve the problem.  Perceiving motion for action is not an uncommon occurrence.

The point I'm trying to make is those whom see belief as a solid, absolute thing probably have a more difficult time seeing that 'reality' is more difficult to pin down.  It seems likely to me, that for most people, as they gain more experience, they too will reform their view of belief into something more generalized, such as a probability.

"The unexamined life is not worth living." - Socrates


Briefly, I want to address another sticky subject, faith.  Faith is a belief with only external sources for justification. You might be able to cite examples where the external source was previously correct, but the external source is still your only justification. Faith is often replaceable with “trust” or “hope”. You can say I have faith that login is broken because my manager is telling me it is so. The justification is based upon hope or trust in some external or internal force that your belief is true. If instead we consider faith a probability based upon your level of trust in a given oracle, you can in fact see faith is just a specialized description of a belief.

One problem with this is our language does not naturally imply that our statements are guess work, nor easily allow one to explain what the most likely evaluation you have thus far computed. People say “I know ...”, or “It must be ...”. We assert our knowledge because people are not actually comfortable with “I don’t know, but I think ...” It is in our nature to say we are right. We even prefer people in which we perceive confidence, even though it maybe a lie.  It is also convenient:

"A little inaccuracy sometimes saves a ton of explanation." - Saki
Compare "According to my present data, evil is unlikely to exist." and the shorten "evil does not exist."  In my view, these absolutes often don't represent what people really think, but I admit it's only a probability.

Another problem is that people will claim this is a flip-flop philosophy that does not in fact hold a person’s “feet to the fire”. While this is true to a certain extent, it is designed to actually be more in line with how people and our estimation of reality actually work. People are rarely able to be self-consistent in what they say, much less what they do. How often do people say “Do as I say, not as I do.”?

In recent years, people have been able to pull out long and specific quotes from others because of how our technology records everything.  We are very much able to examine other people's lives.  Yet, in looking for this consistency, we fail to examine our own lives and the changes we make.  If other people are often unable to be consistent, it's likely you too will likely fail at consistency (Consider: did you know every time you recall something, the memory is re-written and thus modified?).  Yet we like consistency.  There are still two obvious options.  Either we are really failures in consistency but pretend we are not or we are constantly evolving our understanding and are designed to evolve our thinking.  I'd give it about a 20% / 80% probability for anyone individual in circumstances similar to mine when I consider....Oh you get the idea.

Ultimately this is a small chunk of analysis attempting to describe my view of how people work.  It is hard, if not impossible, to write out a full view due to the fact no one else has experienced my life and the context that brings.  I also recognize other views exist and I think they have some probability of them being correct and am open to replacing my own view with a more probable one.  So please feel free to share any insights you have, even if they contradict my own view.  I encourage you to sit down and attempt to write out your views on how people work.  It can be a useful exercise, as it will give your opinions a more solid foundation.  But if you have done all that hard work, why not post it as a comment?

Wednesday, July 15, 2015

My Many Years in Testing and Automation Development

I have heard the question expressed in multiple different ways.  "How do I get into QA?"  "How do I progress my career?"  "How do I level up my skill?"  "You read whitepapers?!?"  "What type of automation should I write?"  I have written various articles around this broad range of topics, but I wanted to take a slightly different tact around one of the implied questions.  The implied question I'm considering is how do I continue down the path from where I am to become a better tester and what skills should I spend time working on improving?  Instead of trying to explore the topic in a general sense, I am going to go through a few interesting experiences I have had in both "Testing" and "Automation Development".  While I will be talking about automation, I do not mean to imply that is where you should spend your time learning, just that I will discuss how I made the choice.  I will try to concentrate on interesting stories and lessons learned.

I have been writing code for nearly half my life, but I started working in the development of test automation somewhere between 2004 and 2005.  I started professionally testing in 2002, although I had been writing my own code and testing it earlier.  I also did some testing for others before 2002, but I was not paid for that work.  I will try to describe the companies and context a little, but I will not use company names, to protect the innocent.  But first, a small introduction to perhaps explain how early on I was interested in QA.

When I started my life in QA, I was roughly 6 years old and curious about this clock in a video game called "The Last Ninja" for the NES.  It kept a timer of how long you had been playing the game.  It gave hours, minutes and seconds.  There was a place where no bad guys were with a stream and a park bench.  It was perfect for leaving my ninja to sit and just enjoy the scenery.  In only 99 hours 59 minutes and 59 seconds I could find out what happened when the clock ran out.  I knew Sonic would run off the screen after 3 minutes, so I conducted some smaller tests.  In my smaller tests, I discovered, unlike Sonic, The Last Ninja did not seem to mind waiting for short periods of time, so it seemed easy enough to test the longer case.  The only problem was I didn't want to lose my Nintendo for a week while I waited for the result.  So when I went on vacation, I left my system running.  When I came back, what I found was "0A" and the game was frozen up.  Now, many years later, I know 0A is hex for 10, likely meaning the clock had run over to hex and then the game had crashed.  I didn't understand the result, but I was curious about it.  I was later grounded for leaving my system on for that long.  You've been warned kids!

Years later, I was looking to get a job out of High School.  I had been programming text adventures for some years, but never had a 'real' programming job.  I enjoyed programming, I enjoyed the experience of creating, but still didn't feel like I knew that much.  Still I kept at it.  I had worked at the Post Office for 3 weeks in a Christmas rush season, but had little other professional work under my belt.  I was going to school and studying Computer Science, but that was going to take years and I needed money sooner.  So I started looking for a computer job.  I interviewed once, but didn't know what I was doing and did not get the job.  College and High School don't seriously prepare you for interviewing.  In my second job interview, I took a computerized test and passed all but one question (I tried typing in a search but they expected me to use the dropdown...  No, I'm not still bitter.).

I got the job and started working as a managed contractor for a overly large company who worked on specialized hardware.  I was a tester who did everything from competitive intel to stress testing to environment testing to configuration testing.  However, I had no training and really no idea that testing was a general skill set.  I incidentally learned a few simple QA skills, but nearly all of the learning I did was around social skills in my first year.  Perhaps one the most important skills I learned was to apologize is important and doubly so when you are a manager and have made a mistake.  I moved to a more complex set of testing, but it was a script based.  I learned more about networking and security testing.  I almost got a job in a team that was inspired by James Bach's work around exploratory testing (in one of the places that James and his brother did some of the development around the idea of exploratory testing), but I missed out to someone with a lot more experience.

Then, in a sad set of events a former lead who changed shifts passed away suddenly.  I took his place, an awkward thing for sure.  I learned about this idea that you could 'automate' tests.  I began to apply my existing programming skills in order to test various UI elements.  It worked well in some cases, but we struggled to handle descriptions (a QTP phrase for describing a way of IDing elements in a UI system).  A co-worker of mine had more difficulty picking up the programming as his specialty was in hardware, not software.  He came into work more than once complaining of nightmares around programming.  My coworker did eventually get better at automation, but that was never his strength (Aside: He's now a big-wig manager, likely making way more than me!).

I bounced around from place to place, with a rough total of nine different jobs (not all jobs were title changes).  One thing looking back is how I was always trying to go meta, not just writing good automation but improving the entire process.  In a large company, that can be very difficult.  I ultimately had a conflict with one of the managers and felt the need to leave.  Before I left, I was told to quit trying to improve the organization (by providing useful tools) but instead work on personal projects!  I did and learned SQL and web development while looking for a job.  I also had multiple open source projects under my belt by this point.

If a big company didn't work, I reasoned that a smaller company would be better!  I applied to one company and studied up.  Rather than applying to many companies, I reasoned it was better to be prepared.  This from having done so poorly years ago seemed to work reasonably well.  I got a job offer. I tried to negotiate for more money, but was declined.  I declined the job but was later called back and given a slightly higher offer.  I concluded that because of the recession that a much bigger offer was not going to happen.

I took a job at a 50 person company, and within 2 weeks of me joining the QA manager had quit.  This left the QA group answering to the VP of Engineering and it remained that way for nearly 2 years.  I worked for longer hours at this company than anywhere else.  I lost another co-worker who I was training, and whom I may have been the last person he talked to.  He was hit by a bus.  I learned the 'hit by a bus' scenario is both real and the worry about how the business knowledge loss will be much less impactful than the emotional impact from the loss.  I learned what the term 'death march' meant as I worked 80+ hour work weeks.  I learned how a recession can affect you in spite of the fact that your field is in demand.  I learned the dangers of saying that you won't ship with any [known] bugs.  I learned how working more hours did not equal more productivity.  I wrote nearly 1300 automated UI tests.  I found the most bugs at the company, in part because of the automation I wrote, and because all bugs must be fixed, it must logically be concluded I found the most important ones.  (Yes, that is sarcasm.)  Yet, I was not promoted nor paid more for nearly the entire 3 years I was there.  Only after 50% turn over and the firing of upper management did things change even a little, and by then I was too tired to care.  I left.  In case you want more details, Isaac also detailed his own personal journey at this same company.

Now we are getting into more recent events.  To be perfectly honest, I don't plan on telling anything more about the various company cultures because of how it might affect me.  However, I still learned social and technical lessons.

I learned that 'manual' testers could appreciate automation and automation results.  I, for the first time, got to work with other people with equal or better coding skills than myself as we developed automation.  I got to learn how to play a technical leader, even when I was not promoted into a leadership position nor had any authority over others.  While I had dealt with databases and did a little database testing before, I got to do development in which nearly all the code was  around database usage, including communication between database systems.  For the first time I had to deal with the integration of multiple team's automation efforts which were written in different languages.  By this point in my career I had written test code in C, Java, JavaScript, SQL (various flavors), C#, J#, VB.NET and VB Script.

On the social front, I got to work with both one of the best teams and one of the most difficult teams I ever worked with.  In dealing with the difficult team, I got to see how personality clashes worked and how to work around them.  To be fair, I have my own personality quirks too, but when these hit extremes it is imperative that you figure out how to be a positive force for the team rather than yet another point of contention.  Perhaps one of the biggest lessons I learned was that it is important to have a solid social connection and understanding of an individual before giving a completely honest evaluation of someone's skill set.  In fact, I took the lesson so much to heart that I try to be more careful with my day-to-day speech as a whole.

Finally, I want to describe a little bit of my attempts at professional growth.  I spent a good amount of time embracing various avenues for learning.  I took BBST, and while I only took the class for the first BBST course, I watched all the videos and read all the material.  I have written on this blog for a few years now.  I have spent time giving talks at various venues.  I have written letters, written for other professional venues, testing non-work apps and taken serious amounts of time trying to understand the systems under which work is performed.

So to sum this all up, I think I have just two simple suggestion for you:

Learn

Making mistakes is fine.  Just learn from them.  Learn how you learn.

Don't just do work

We all are making a journey, and at some point it will stop.  Making an impact is important.  But don't make work the only impact in life.

Tuesday, July 7, 2015

Autonomation: Old is New Again; Toyota and Lean

I came upon the word Autonomation recently and felt it was interesting enough to bring it up.  The concept comes from Toyota as they were developing Lean Manufacturing in the 1990s.  The primary goal for Lean Manufacturing is to eliminate waste and thus improve production and quality. Autonomation is also referred to as jidoka in Toyota's TPS process.  Autonomation or jidoka is one of the layers in Lean Manufacturing, meant to trap failures rather than produce results.  The earliest example Toyota notes is from 1924.

In 1896, Sakichi Toyoda invented Japan's first self-powered loom called the "Toyoda Power Loom." Subsequently, he incorporated numerous revolutionary inventions into his looms, including the weft-breakage automatic stopping device (which automatically stopped the loom when a thread breakage was detected), the warp supply device and the automatic shuttle changer. Then, in 1924, Sakichi invented the world's first automatic loom, called the "Type-G Toyoda Automatic Loom (with non-stop shuttle-change motion)" which could change shuttles without stopping operation. The Toyota term "jido" is applied to a machine with a built-in device for making judgments, whereas the regular Japanese term "jido" (automation) is simply applied to a machine that moves on its own. Jidoka refers to "automation with a human touch," as opposed to a machine that simply moves under the monitoring and supervision of an operator. Since the loom stopped when a problem arose, no defective products were produced. This meant that a single operator could be put in charge of numerous looms, resulting in a tremendous improvement in productivity. - http://www.toyota-global.com/company/vision_philosophy/toyota_production_system/jidoka.html


The term Autonomation feels similar to the term I coined perviously, Manumation.  In the wiki article on Autonomation, I found it interesting that Shigeo Shingo claimed there were 23 stages between manual and fully automated processes.  Unfortunately, there is no citation for where that claim was made and while I saw others repeat the claim, no one had any citation nor data on the stages that I could find.  In my mind, Autonomation is just one form of Manumation.  However, it is also an attitude.  You don't have to try to fully automate something on your first attempt to create automation.  The idea that you set your automation up knowing it will fail, that it will need humans but don't bother the humans until it fails and that the failure is easily traceable and fixable.  Also, it means attempting to fail quickly rather than generating a bunch of waste work.

Ultimately, automation of any sort is meant to help people.  If it helps you get work done, even if it requires a human touch, it is worth considering.  What sort of autonomation have you done?