Friday, 23 February 2018

Problem Solving as Software Development

TLDR; I can view Problem Solving as Problem Identification, Problem Solution Construction, Solution Evaluation and I can map that on to Software Development to help me communicate in normal language.

I was at the gym and a couple of thoughts came together in my head.

First was the notion that if I want to go meta to what I do in software development testing, then I might view what I’m really involved in as a problem-solving process.

But we know that.

Problem solving is already covered in lots of software development books as being analogous to the process of software development.

Heuristic Compiler

And this was actually covered pretty well in a Herbert A. Simon paper on a Heuristic Compiler.

Where he looked at “how can we automate the process of programming?” and he really came the conclusion that it was pretty hard.

Because what you’re trying to do is automate the process of problem solving and that’s quite hard.

Nowadays, we might try and use machine learning to do that. And people might be working on those kinds of problems.

But it’s still a hard thing to do.


I was also reading this book “Relentless - the Japanese way of marketing”.

And what I find interesting in there.. there’s a quote that said that:
“marketing is too important to leave to specialists because the customer requirements can slip through the gap between the specialisms”.
So that’s much the same as with software development.

Gaps Between Specialisms

Customer requirements slip through the gap between our specialisms as well.
  • We’ve got software testers.
  • We’ve got software programmers.
  • We’ve got a requirements analyst.
And our requirements slip through the gap.

Our needs for automated execution to determine whether the feature still works… slips through the gaps. Because testers are doing that work, but they’re too busy doing exploratory testing.

Because we’ve given it to a specialist rather than the software development process handling that problem.

If I take the notion of “software development is problem solving”.

And then chunk problem solving into:
  • identifying a problem,
  • coming up with a solution for the problem,
  • evaluating whether that solution is effective.
Then we have a pretty good analogous model for how we pursue software development as a set of specialisms.
  • Problem identification == all the requirements analysis.
  • Problem solution == the actual development of a product or buying in a product.
  • Solution evaluation == checking to see whether it meets the users needs. Whether we’ve done the feature right. All of that activity which we might call Testing.
And so the notion of problem solving encompassing es these internal activities.

I find that useful because the problem identification, solution, and evaluation, happens at every step in our problem solving process.

And our problem identification problem:
  • is this the right problem?
  • Are we trying to solve the right problem?
  • Are we solving it in the right order?
  • Is this the right solution?
  • What alternatives do we have?
  • How do we know?
For the software evaluation:
  • have we evaluated this in the right way?
  • Is that it?
  • Do we need to do more evaluation?
  • Have we evaluated it for things that we haven’t thought about yet?
All of that provides me with a useful set of chunking down models.

Describe your own models

What I encourage you to do is try and create your own models for software development, and testing.

Using normal everyday language.

Because then we’re avoiding the notion of specialisms and we can start communicating to other people.

And if we communicated software testing as a solution evaluation. e.g. Have we built the right solution?

That might help people explain what we do.

We could possibly use it as a questioning process where we ask questions of the system to see…
  • Does it do what we think it does?
  • Does it do things that we don’t think it does?
The more that we can drop down into normal language. The more we avoid the problem with specialization.

Specialization provides us with a unique domain language that we have to understand, and might aid ambiguous communication.

Hopefully using natural language helps us think about our work in different ways.

And that’s really important if you’re going get on top of it and take responsibility for your process.

Live Stream

This was originally a live stream that I presented as an Instagram Story so I could get the idea out of my head before I forgot. And then live on YouTube as I tried to get used to YouTube live streaming. The recording was not actually the YouTube recording because I was on the wrong wireless network with a poorer upload speed, but I was recording locally via XSplit, and I released an edited recording to YouTube.

Wednesday, 21 February 2018

Considering a Career in Software Testing?

TLDR; A career in Software Testing is not an ‘easy’ ride, if you are not careful then you can get stuck. But if you work at it then you can make a difference to your company and the community at large.

Are you considering a career in Software Testing? Have you watched videos describing your future job opportunities and the training or roles you have to consider?

Well, this blog post and associated video might help. I’ve distilled my 20+ years of Software Testing and Development experience into some Software Testing Career advice notes.

And this isn’t just for beginners and people at the start of their career. I hope this advice will help you even if you have been a Software Tester for a few years.

We will cover topics such as:

  • Is there much to learn?
  • What opportunities are available?
  • What types of Software Testing could you do?
  • Is testing a Stepping Stone to becoming a Programmer?
  • Is testing really an entry level role?
  • How to create career opportunities?
  • Should I learn to code?
  • How do I get started?
  • What should I read?
  • How to recognise a bad job?
  • How to escape a bad job?
  • Should you start by learning to automate?
  • Should you get certification?
Some of this might only be covered in the video!

I’ve pursued Software Testing as a Career for 20+ years, so I’m going to let you in on the reality of pursuing this topic as a career.

Is there much to learn?

You have the chance, over your career, to become very technical if you want to: deep diving into the technology and manipulating the system under the covers, performance testing, security testing, automating applications.

You also have the option to focus more on the people and work more closely with users and requirements. There can be a lot of opportunities.

You can also do both.

Software Testing is a skill. It can take a long time to learn. There is a lot to learn.

Read as much as you can

Start with the free Testing Magazines (remember to search the web and see if there are any more).

Read the blogs listed on the Ministry of Testing Feeds site

Follow testers on twitter (see who they follow and then keep going)

Soon you will be overloaded with information.

Read as many books as you can. In the video I recommend:

  • Software Testing Techniques by Boris Beizer
  • Lessons Learned in Software Testing - Bach, Kaner, Pettichord
  • Testing Computer Software - Kaner, Falk, Nguyen
I spent a year working through the Beizer book (Software Testing Techniques) and applying it to my work.

Read as many as you can get your hands on.

Stepping Stone to Programmer?

Some people view Software Testing as a stepping stone role to becoming a programmer.

Rule that out now.

If you want a career as a programmer you should start by focussing on programming.

You might get lucky, If you are in the right company, working as a tester, and you want to work as a programmer, they might support that shift. But be honest with yourself. If you want to program. Program. If you want to test. Test.

If you are not sure. Try both. If you try both then you’ll probably be in a stronger position long term.

But it depends how much time you have to get ready.

Getting Started

The hard part is getting your first job.

It is very important to learn the fundamental and underlying techniques that are associated with Software Testing. A lot of people miss this out.

People at the moment seem to think that if you pursue a certification that you will learn these techniques and you are instantly a good software tester.

We have to distinguish between: the learning you need to do to get a job, and the learning you need to fulfil the role of a good software tester.

Hopefully you’ll be able to get a job by demonstrating software skill via a blog or a Github account and don’t have to pursue certification, but that is a choice you will have to make for yourself.

Software Testing is still viewed as an entry level role

That can make it easier to get a job as a software tester.

But if you do not control your career and keep learning then you might get stuck in a low level, unskilled testing role with a company that does not value your chosen path.

Once you have earned your stripes, find a company that does not view the tester as an entry level role.

It can be easier to switch to Software Testing

From Business Analyst, designer, manager, programmer it can be easier to switch to testing.

Sometimes because people undervalue and don’t understand testing.

Sometimes because they see potential in you and recognise that you have the creativity, tenacity, problem exploration, questioning mind required to be good at Software Testing.

You need to get in the right Company

Once you are in and you’ve paid your dues:

  • hands on experience
  • some tool knowledge
  • mastered at least one technology - API, Web, Mobile, Desktop
  • good grounding in the domain (terminology and techniques)
Move to a good company:

  • values testing
  • working flexibly (Agile, Contextually)
  • automating acceptance criteria
  • offers you the chance to learn more

It is possible to get stuck

Particularly with outsourcing companies

  • spending days writing lots of documents
  • writing test cases and test scripts that require a lot of rework
  • automating badly with a lot of maintenance
  • automating but not learning how to code or automate effectively - building keyword scripts but not implementing the keywords
All of that is going to keep you in the low paid dungeon of Software Testing.

To escape you can:

  • focus on testing as a problem solving activity - modelling systems, exploring systems, looking for risk, building experiments.
  • build your coding skills to automate and write tools to support your testing and work more closely with programmers
  • learn how systems are architected to understand them as a whole and identify risk and alternative ways to design systems
  • focus on testing as a questioning process - identifying ambiguity in requirements and discussions and helping remove that ambiguity
  • focus on the outcomes of testing rather than the legacy processes e.g. people want to know about the coverage of testing - find ways to track and visualise coverage but not in terms of ‘number of test cases written’ and ‘test scripts executed’
  • learn about Agile, and Lean, and take control of your own test processes to remove waste and the parts of your process that do not add value
What I’m really talking about there is building your expertise as a Software Developer - or Software Engineer - but retaining a specialism in testing so that everything you learn you apply to the process of Software Testing.

Note: Developer does not mean Programmer - it means someone involved in the whole lifecycle of Software Development.

The more that you can expand your Domain Knowledge to cover the Software Development Discipline as a whole, the better and more valuable a tester you will become.

You will constantly learn new things and identify new approaches and tools to help you test.

That won’t happen if you stick to a very legacy view of Software Testing as: creating test conditions, writing test cases, writing test scripts and using a Test Case management system.

Choose your companies carefully and get out of those that are stuck in the past.

Should you automate?

I can’t tell you not to. Because I know how to.

I started with programming as my specialism and I kept my programming knowledge up to date.

I think the ability to code helps me because I have more options in how I approach my work.

You probably don’t need to:

  • learn to code as well as a production level programmer
    • certainly not at the start of your career (you can improve your coding skills over time)
You certainly don’t need to:

  • learn to code at the expense of learning how to test
    • you don’t need to know how to code to test, having the ability to code gives you more options, but is not required.
I would recommend you concentrate on test techniques and the actual practice of testing.

Learn to code later on. And learn in small chunks by automating your work or scripting the tools you use. Build it up over time.

I’ve been doing this for 20+ years and I’m confident with production level coding, I’m also confident with testing - take the long term view and build your skills over time.

Should you learn to develop?

I think Software Development is meta to testing and programming and analysis and management.

So learning Software Engineering: modelling, requirements, concepts, architecture.

All of that will help in the short term (and long term), much more than how to write a script in a programming language.

You should learn how to test

Find some open source software. Test it. Make notes online and share your learning.

Use your work time wisely to learn as much as you can.

There are a lot of opportunities within testing - if you can find the right company to work with.

And if you work hard, experiment, and share what you learn then you can open up new opportunities for others, as well as for yourself.

The above was the notes I used to create the video below. The video expands on the above and has additional information about Agile, Automating, Technical Testing and some other stuff.

Tuesday, 16 January 2018

Promoting Evil Tester Talks Conference Talk and Webinar Archive

TLDR; I have an archive of webinars and talks with extra material bundled as a ‘course’.

I updated my “Evil Tester Talks” Online Talk Archive and realised that I hadn’t actually promoted it through my blog. Too busy creating content and writing talks.

But since I just added two talks and one webinar to the archive, it seemed the right time to promote it.

Friday, 12 January 2018

Testability vs Automatability - in theory (Free Bonus Video Inside)

TLDR; Testability is for humans. Automatability (Automatizability) is for applications.

I was doing some research for my upcoming Eurostar webinar and I encountered a few videos and posts of people who were using ‘testability’ to refer to the ability for the application to support automated execution.

I didn’t think that was appropriate. I’d rather distinguish between Testability and Automatizability. The more popular form of Automatizability seems to be Automatability.

Thursday, 4 January 2018

The Evil Tester Show - Episode 004 - New Year 2018

TLDR; Resolutions require resolve. Goals require questioning and testing skills.

The fourth episode. It is available as audio and video covers New Year Resolutions and Asking Effective Questions.

Do you make New Year Resolutions? I set goals that I believe in, then create work plans, and adjust my expectations based on what I do, and I do change my mind based on experience. But I also, use my testing skills to do all of that.

Monday, 18 December 2017

Automating Storify and Twitter Using JavaScript From the Dev Tools

TLDR; Migrating from Storify to Twitter, semi automatically with a simple JavaScript Snippet and Bookmarklet.

In this post I provide the code for my video showing how I migrated from Storify to Twitter Moments.

Monday, 27 November 2017

What is Agile Testing? The Books List

TLDR; A list of books that was shown in shaky cam on the What is Agile Testing video.

In the What is Agile Testing? video I used shaky cam to show a subset of books which help me understand Agile Testing.

In this post I list them such that they can be researched by the diligent reader.