Showing posts with label Test Education. Show all posts
Showing posts with label Test Education. Show all posts

29 November 2016

Learning about learning by teaching

I've undergone a tough education in software testing:
  • 15 months long
  • Tests 3 times a week, 7 hours each and in front of a crowd
  • If you skip a test you'll have to do it again, typically within 5 days.
  • The expected level of competence is: "Good enough to teach others"
  • Little or no chance of "redo:s", you better do it right the first time, every time
In other words: I've been teaching a class in software testing.
The intense experience of teaching testing like this has of course taught me tons of things and with this post I want to share the positive effects this particular job had on my own learning. Each benefit (of teaching) comes with a "why I find it useful" and "how you can apply this knowledge in a more everyday context".

Benefit: Curriculum

Why?

I'm not a fan of committing to a plan, especially not when it comes to my learning. However, the education's curriculum did force me to look into many topics/material I would otherwise had skipped due to laziness, lack of interest or lack of understanding (not thinking it was useful to me). Some of these have definitely made me a more complete/skilled tester such as test framing, deeper understanding of test techniques and a better understanding of bias.

How?

Benefit: Go deep

Why?

I've read tons of articles, watched hundreds of hours of presentations/videos and spent a lot of time practically practicing testing. However, I often end up looking at topics in a quite shallow way especially when I find the topic a bit boring (may still be very useful). When you are to talk about a specific topic for just a couple of hours, you're okey, there's little "need" to go deep. When you have to prepare several weeks of study material though, that's a whole different beast! Being forced to go deep into topics has enables me to better question, improve, explain and argue for the various choices I make (for example why I chose to place my testing mission at the top in a certain status report).

How?

  • Dig deep into fundamental questions e.g. what is testing, why do we test, what is an oracle etc.
  • Look into related topics. Say you want to improve your written reporting skills then look into e.g. rhetoric, design, how people read printed and digital documents, how people interpret colors or tutorials for your word processor/mind mapping tool/whatever. The point is: don't limit yourself to articles specifically about test reporting.
  • Set a "topic of the month" and try to become as skilled as you can in this topic. Don't stop because you feel "done", continue beyond that.

Benefit: Giving feedback

Why?

An important part of my job is helping students understand what they do well and what they might need to improve. To do this I have to observe and analyze what they've done, what they think they've accomplished, what actually made them accomplish what they've accomplished etc., all this I have to do rather thorough in order to be able to explain it to them. This helps me create an understanding that is beyond "do this or do that because it works better".
An example of this is when grading various assignments and projects as students, at least on a general level, need to understand what they did good and what they would had to do to get a better grade. If they get the highest grade they need to know why, so they both know what to continue doing and what to improve. As testers we need these kinds of observation and communication skills all the time when working with developers, project managers etc.

How?

  • Study your own testing and try to explain why it was good and how it could be improved.
  • One area where I've found this pretty easy to practice (can't prove that the practice translates to other parts of testing but I think it does) is watching presentations (e.g. YouTube) and try to give feedback to the presenter. What specifically did she/he do good and bad?
  • Study other testers and try to figure out why you find them good/bad testers. Be as specific as you can.
  • When testing, try to find positive and negative patterns: "The log entries are (almost) always relevant and well described making my work so much easier" or "The UI components often have poor vertical alignment".

Benefit: Teaching

Why?

Teaching in itself is a great technique for learning. You have to rephrase the content to match your own language, you hear yourself speak about the topic and you get questions pinpointing gaps in your understanding and/or explanation.

How?

  • Do teach colleagues and friends about the various topics you've practiced.
  • Write an educational article/blog post about what you've learned (you don't need to publish it to anyone to still get many of the benefits).
  • Talk at a local test meetup and if there isn't one, arrange one.

Benefit: Peer

Why?

Working with Maria Kedemo and Martin Nilsson have allowed me to get feedback on the ideas I'm about to share, feedback on my interpretation of various topics and someone to speak with when I feel stuck. It has also allowed me to learn from their knowledge and experience of testing.

How?

  • Speak with a colleague
  • Join a local tester meetup
  • Go to a test conference
  • Join the active community on Twitter
  • Try your own version of Transpection Tuesday (my post, Helena's post: 1, 2)
  • More ideas...

Benefit: Observe testing

Why?

I've spent a significant amount of time both observing testers test (as a group), observed testers test (the actual testing done by an individual) and listened to testers speak about their testing. All three exposed me to new ideas and made me question my own approach. It's also interesting because you get to see a specific problem solved in many different ways which helps you understand what actually impacts the result; e.g. "what is the common denominator in these solutions, is there anything I can learn from that?" or "they all had different ways to setup but all ended up with the same solution, which setup worked best/most efficient and can I learn something from that?".

How?

  • Pair testing
  • Look at other testers' notes, reports etc.
  • Do call for and attend debriefs no matter if you use the concept of test sessions or not
  • Offer to review things
  • Volunteer to mentor/coach another tester; this will enable you to observe another tester as well as get several of the other benefits mentioned in this post

Benefit: Consistency

Why?

To sit down and learn about various topics every day for over a year has definitely added some welcomed consistency to my self-education.

How?

Benefit: Questioning basic assumptions

Why?

Explaining fundamental concepts is incredibly hard but rewarding! As an experienced tester I take quite a few things for granted and explaining concepts built on these assumptions to someone without experience lead to wonderful questions like "but why do we need testing at all", "what does it actually mean to test something", "why can testers find bugs if developers who know the code can't (as in why do bugs happen at all)?". Answering these questions without being able to rely on "experience based assumptions" has led to more than a few epiphanies (and a lot of frustration of course).

How?

  • Talk testing with people having a different frame of reference (developers, management etc.)
  • Talk testing with people who don't work in the industry; for instance try to explain what you do to a relative.
  • Teach new testers at the company or teach e.g. developers in testing
  • Talk testing with new, inexperienced testers

Benefit: Ask yourself "how do you train this skill"

Why?

Reading and listening is nice but sometimes you need to actually practice skills to be able to learn them. When teaching I've spent a fair amount of time trying to figure out exercises pinpointing a specific skill I want the students to practice or just exercises/projects in general helping students practice relevant testing skills. This experience help me now both when less experienced testers want help learning a skill, when I try to explain/teach something and when I try to teach myself something.

How?

  • After e.g. a blog post, YouTube video or book; think about how you can incorporate the new concepts you've just learned about into your own work.
  • Try various exercises and try to replicate various experiments yourself; such as: 1, 2, 3, 4; to help kickstart your brain.
  • Whenever you're asked to explain something; try to come up with an exercise or experiment that helps demonstrating whatever you are to explain.

Benefit: Getting questions

Why?

I've already touched upon this but getting questions from the students on anything that's not clear to them is incredibly challenging but rewarding. It has helped me realize flaws in my own understanding, forced me to question my own assumptions and challenged me to find new ways to explain certain concepts in.

How?

  • Explain concepts to others
  • Ask for feedback
  • Ask questions yourself; this both inspires others and help you ask questions "to yourself"
  • When reading/watching e.g. a book, presentation (video) or article; pause periodically and ask yourself: "what did I just read/watch and what of that is unclear/seems strange to me?"

Benefit: Having the time and expectation to learn

Why?

When in the middle of deadlines, huge backlogs and conflicting priorities it's easy to forget learning. Having the explicit expectation to learn new things has been an interesting experience and I feel confident saying I leave the teacher assignment as a much more competent tester. Spending as much time as I did on learning is not possible in most working contexts but I think "expectation to learn" is the key concept here as it helps making it happen at all.

How?

  • Ask your boss: "How much time am I expected (or at least allowed) to spend on education?"
  • When doing backlog grooming (if you do this); add learning stories as dependencies e.g. "before we implement the new video player we need to learn a bit about streaming, video formats and performance testing related to streaming". If you end up never having time for these learning dependencies, try timeboxing them to make the expected time invested in learning more explicit.
  • Remember learning is a fundamental part of testing.
  • Differentiate between the learning that's necessary to solve your current task and learning with more long term, strategic value (e.g. learning more about testing in general, about web security, about test planning etc.). The "strategic learning" is often important to keep you and the company progressing but can easily be forgotten if put in the same "budget" as the task solving learning.

Final word

I removed several additional benefits I had initially included just to finally get this blog post published (it's been stuck in "draft" for over a year) so just to be clear: You can learn so much more about learning by teaching; this is just a mere introduction.
Etiketter: , , ,

24 August 2016

How to come up with test ideas

Update Summer 2022

Some links have been moved, hidden behind memberships/payment (for good reasons because they're awesome, just to be clear!) or even become obsolete due to technology shifts. If someone who's more active within testing these days would like to take over this endeavour; just go ahead and pick the contents here; no need for attribution etc.

With that said, the vast majority below is still available, relevant, helpful and valuable to testers, it's just that's it's not updated with the latest and greatest anymore.

Intro

This post is an attempt to gather the various tools, tips and sources I've found useful to improve my ability to generate test ideas.

Notice that the various concepts described are huge and I will only briefly describe them in this post, it's up to you to learn more and put them into practice. A good start would be to check out the many articles I've linked to.

To developers
Important! The techniques and sources I will describe are just as useful when developing, example:

"This will create a separate log file, what do I need to take into consideration when that file is created..."

If you want to develop high quality software, learn the fundamentals of test design!

Common product risks

Risk catalogs
Risk catalogs are lists of generic risks (things to test) in common components/functions.

You will of course need to judge what's relevant in your context and risk catalogs aren't flexible the way actual thinking techniques are but they are still incredibly useful:

Quality characteristics
Quality characteristics, also known as quality criteria or quality attributes, are an attempt to break down quality into meaningful/helpful categories. When generating test ideas these categories help us see the product from different angles.

Generic risks
Some aspects are (almost) always worth taking into consideration when assessing risk e.g. "is this new functionality?" or "does this module have a history of being buggy?". I can't say this information helps me generate new and creative test ideas but it helps me focus my effort on risky areas thus still relevant.

Test techniques

Test techniques are sort of "compressed tester mindset". The set of 9 techniques defined in the heuristic test strategy model is my personal favorite but there are many different sets out there.

Notice that each technique is way too broad to cover in this blog post but if you want to "learn to think like a tester" I urge you to learn more about and practice them!


Function Testing
Identify and test each function individually.

I prefer to begin with creating a list or mind map of all functions I can identify in whatever I'm about to test. A function in this case is anything the application can do e.g. save a log message, identify that a new version is available or show an error message. To do this, touring is a useful practice described in the links below.

When you've identified the functions, focus on each one individually, example:
"How can delete entry be tested? Successful delete, try to delete an already deleted entry, try to delete when lacking access, stack deletes of the same entry, lose connection to data source when deleting, modified delete request (e.g. SQL injection), potential timing issues, delete different entries in rapid succession, ..."

Domain Testing
Identify the input and output data in the application then look at which of the possible values/combinations of values you should test.

After identifying the variable (input or output) to test, you first group the possible values into equivalence classes. The idea is any of the values within each equivalence class should in theory behave the same. The next step is to select one or more values from each class to test. To do this you for instance look at boundary values, high risk values or realistic values. Finally when several variables need to be combined (such as in a typical form) there are various combinatorial techniques to help you find an efficient way (as few tests as possible) to actually combine these values into individual tests with the level of coverage you're aiming for.

Notice! When reading about domain testing you might get intimidated by all the paper work involved: "I don't have time to do all that for a simple form...". For me the detailed analysis on paper is sometimes useful, especially to practice my domain testing skills, but generally I just keep the various techniques related to partitioning (creating and grouping values into equivalence classes) and value selection in my head and apply them "on the fly". Still: I do urge you to sit down and create e.g. a detailed boundary/equivalence table at least a few times because it's key to actually understand domain testing.

For the combinatorial analysis: Remember there are excellent tools!

Stress Testing
Identify various bottlenecks, input that can be sent in huge volumes or that require more computing power than usual, dependencies, communication to external systems etc. and ask yourself how these could become a problem for the application (e.g. flooding of  requests, dependencies lacking, slow connections/timeouts/lost packages). Also look into the system's ability to restore itself after collapsing (e.g. will the system come back up after a database crash).

Do notice that stress testing often refers to testing the behavior when actually going beyond a system's breaking point. This is important since if you search for "stress testing" you'll mostly find just a subset of what the test technique "stress testing" is suppose to cover. Try also searching for e.g. "robustness testing", "load testing" and "performance testing".

Flow Testing
Testers often reset environments between tests, especially if using test cases, by e.g. closing the application or only focusing on one step in a long flow. The problem: Users don't. The test technique flow testing is thus about focusing on what will happen when a continuous chain of events occur. One way is to actually identify a long, realistic flow (e.g. a "buy, cancel, refund" cycle in a web shop) and test this, another is to not reset between tests (e.g. not close the application or reset data for several days while testing).

Scenario Testing
Scenario testing is, unsurprisingly, about creating a scenario and test this scenario. One important benefit with scenario testing is it can identify gaps in the implementation that other techniques generally don't, as they focus on what has actually been implemented.

Claims Testing
Also known as "specification-based testing". The idea is to identify the claims made about the product and check if they are actually true. Claims can come from a variety of sources e.g. specifications, requirements, manuals, various in-app help sources, public statements or the EULA.

User Testing
User testing is about asking yourself "how can I use users to improve my testing":
  • A user attempts to complete various tasks in the application and walks you (the tester) through how she/he is reasoning. The tester's job is to identify problems the user runs into e.g. not understanding certain parts of the navigation.
     
  • Use user data to drive the testing e.g. "the most items a user has ever ordered is 104 and in our tests we never order more than 20, we should increase that amount".
     
  • Personas and other tools helping you "simulate" a user can be used when testing, example:
    "Looking at this from the perspective of 'Nancy, the power user', I realize we lack keyboard shortcuts in much of our application"
Do notice that user testing often refers only to the first bullet above. This is important since if you search for "user testing" you'll mostly find just a subset of what the test technique "user testing" is suppose to cover. Try also searching for e.g. "personas", "ux testing" and "usability testing".

Risk Testing
Identify risks and design tests to cover each one of them.

These risks can either be identified:

... inside-out (ask: what could go wrong here?), example:
"We now allow users to delete their private messages, how could that be a problem? Well what if a user could potentially delete another user's messages? How can we test if that's possible to do?"

... or outside-in (apply common risks to the product), example:
By using Michael Hunter's "You're not done yet" I realize saving the configuration to a read-only folder could be a problem.

The chapter "Common product risks" includes tons of sources useful when applying the outside-in approach to identify risks.

Notice that "risk-based testing" (prioritize testing that's considered the greatest risk first) is not the same as the test technique "risk testing", but will be your most common result in a web search. However, articles about risk-based testing typically covers tools and techniques to identify and prioritize risks making them useful anyhow; just be aware of the difference.

Automatic Checking
How can you use tools you know about to improve your testing?

Do not confuse this with "automation", "automatic checking", "automated testing" or whichever term you prefer, which is a way to actually execute the ideas identified and not a test technique itself; even though unfortunately sometimes used as some sort of technique.

Other useful resources about test techniques
  • What is a good test case, by Cem Kaner
    More information about some of the test techniques above as well as some additional techniques.
  • Lessons learned in software testing (book), by Pettichord, Kaner, and Bach
    The chapter about test techniques is available online as PDF as part of the BBST course. I very much recommend you to get the rest of the book as well.
     
  • BBST Test design, by Cem Kaner and Rebecca L. Fiedler
    BBST presents a broad set of test techniques. Highly recommended reading in general and for test design in particular.

Critical and lateral thinking

Everything else in this article is more or less applications of critical thinking and supported by lateral thinking. They're thus the most abstract but generally applicable concepts I will describe.

Critical thinking
Definition:
"The objective analysis and evaluation of an issue in order to form a judgement"
Oxford Dictionaries

Compare this to e.g. James Bach's definitions of software testing:
"Questioning a product in order to evaluate it"
... any similarities?

A more in depth definition of critical thinking has been made by The Critical Thinking Community.

When developing software we make massive amounts of assumptions, simply to save time, example:
This framework will prevent..., this is what users want, this is the simplest way to...
Critical thinking is essentially the skill needed to identify these assumptions.

Learning:
I also designed a critical thinking exercise for testers, which might help.

I would love some more (and better) sources on critical thinking, so please drop a comment with your suggestions!

Lateral thinking
Lateral thinking is simply put the skill to think outside the box.

Definition:
"The solving of problems by an indirect and creative approach, typically through viewing the problem in a new and unusual light. Contrasted with vertical thinking."
Oxford Dictionaries

Reading material:
Exercises:

Domain knowledge

To be able to form any test you first need to, at least on a conceptual level, understand the product and its context.

I for instance like to think I'm pretty skilled with test techniques, that my critical and lateral thinking skills are decent and that I know how to get some good value out of tools such as risk catalogs. Still, when new to a product I'm not very effective until I've actually learned the product.

Stuff you can do to quicken the learning of a new application and its context:
  • Ask for a demonstration
  • Look through available documentation (start with documentation intended for customers)
  • Make a visual model of the application, enhance the model as you learn more
  • Tour the application
  • Ask for help to make a SFDIPOT analysis of the application
  • Learn about and try out the tech the application relies on
  • Speak with stakeholders to learn about e.g. the application's purpose and customers
  • Start somewhere and slowly work your way outwards, to avoid getting overwhelmed
  • Observe users, using the application
  • Pair up with developers, testers and others working with the application
  • Ask questions... lots of questions
  • Look into, and apply, various learning techniques (search for "learning techniques")
  • Learn about relevant laws, regulations, standards, certifications and business practices
  • Speak with domain experts, sales people and customer service
  • Look at test documentation available for the application

Other tools

Test framing
Test framing is about being aware of what you're testing and why, or, as Michael Bolton describes it in the link below: "link each testing activity with the testing mission". I find this useful to practice as the awareness, in my experience, improves my ability to see potential risks, better focus on relevant test design and it actively challenge my critical thinking skills.

Opposites
When you have a few ideas to test it's sometimes useful to look at those and ask:
What's the complete opposite of these ideas and could that potentially be a concern too?

Examples:
What happens when several entries fit a delete condition?
Opposite: What happens when no entries fit a delete condition?

What if the network has limited speed, delaying requests?
Opposite: What happens if the network floods the application with requests?

How will a user with limited computer skills approach this?
Opposite: How will a tech-savvy user approach this?

Great additional sources
This is a collection of great test idea articles I've used for this article and/or when generating test ideas that just didn't fit into any of the other chapters:

Please help me improve this

Initially this was intended as "just another blog post" but it sort of took a life of its own and became a pretty big reference page.  I always appreciate comments but since I expect people to assume this is "the truth" more than usual, I will appreciate corrections and suggestions even more!

Etiketter: , , , ,

25 August 2015

How to practice software testing

During open season after Erica Walker's presentation at CAST, I mentioned a few useful tools for practicing software testing or software testing related skills (rather than passively watch/read/listen). With this blog post I want to expand that a bit and share some of the applications/sources I've found useful when actually practicing to become a better software tester.

General

Bitnami provides simple installers (local install) for several well-known web applications such as Wordpress, Moodle and ExoPlatform. The installer automatically sets up a web server, database server and the application itself. This is a great sandboxed environment for you to play with and you have access to the application's code and database content allowing you to do pretty nifty stuff.

Since the applications available on Bitnami are fairly large systems you'll find opportunities to focus your testing on basically any quality characteristic or test technique no matter which one you choose. Why not try a full equivalence partitioning, value selection and variable combination testing table for the post thread as moderator form in phpBB or a usability analysis of PrestoShop?

The drawback with these big applications may be that they are a bit intimidating/take time to learn. In that case try the many software download sites like SoftPedia but be aware that some software you find this way might come with various malware.

Joining open source projects can also be a good way of practicing testing while also giving something back. Popular open source code management sites like GitHub and SourceForge are great places to look for applications in need of testers.

Database

Install XAMPP (fully preconfigured web server) and start running queries against the MySQL server. This also gives you the ability to practice writing (and running) simple scripts in e.g. PHP to manipulate/display the database content. Getting familiar with phpMyAdmin (preinstalled) is also a good idea for any web application tester.

If you want to practice online I recommend Head First Labs. You might need a MySQL reference (available online) though to solve all their exercises since they reference to pages in an O'Reilly book.

REST API

A great place to take your first few steps in API testing is predic8. They have an online REST-API available that you're free to play around with. I recommend fetching Postman and just start making simple GET requests. Use predic8's tutorial to help you progress.

Security

Tons of applications exist for the sole purpose of practicing security testing. These applications have dozens of vulnerabilities built in so that you can practice triggering and exploiting these vulnerabilities without risking to break anything. Also, many of these applications have active communities built around them where you can get help or documentation, explaining the various vulnerabilities.

WebGoat (web testing, local installation)
Have only briefly used this but from what I've understood this might be the best choice available. If you search for WebGoat on YouTube you'll find dozens of tutorials, demonstration and installation videos.

Google Gruyere (web testing, online)
I've played around in Google Gruyere quite a bit. It's a good place to start and convenient since no installation is required. Also, due to it's fame, several videos exist demonstrating vulnerabilities in Google Gruyere and explaining the thinking behind discovering them. One example is Alan Richardson's video.

bWAPP (web testing, local installation)
Only briefly used bWAPP but seemed like it had potential. bWAPP is more helpful than Google Gruyere in the sense that you're informed about what vulnerability each page has.

BodgeIt Store (web testing, local installation)
A web security practice application aimed towards beginners (if I interpreted the description correctly). Haven't tried this one myself.

Mutillidae (web testing, local installation)
One more I haven't tried myself. What I liked in the description though was it did claim to give hints which likely make it a good starting challenge to a new penetration tester.

GameOver (web testing, VirtualBox image)
I discovered GameOver as I was writing this blog post. Haven't tried it yet but it's a VirtualBox image with several penetration testing tools and web security practice applications preinstalled (such as WebGoat). Convinient!

There are also pages dedicated to learning web security by giving the visitor progressively harder challenges (puzzles) to solve. My personal favorite is HackThisSite as I think the challenges are progressing in a good pace and you can always get help if you're stuck. For a quite extensive list of practice pages, take at look at the top answer to this Stack Overflow question.

If you want to practice system level penetration testing I recommend the Metasploit Unleashed free course. Also look into Kali Linux, a Linux distribution centered around penetration testing.
(2022 addition: Got this Kali Linux Cheat Sheet recommended to me, hope it helps)

Information gathering

Information gathering is a critical skill for testers. A course I've just started that seems to have great potential is the Google's Power Searching course. The course comes with challenges making it interactive enough to fit this blog post.

Improve your skills in other common tools

You can improve your skills in many common tools by using training videos released by vendors or users and either mimic what's done in the videos or perform the challenges given. One example of a training video collection I've found useful is Microsoft's Office course.

Operating systems

I learned a lot about operating systems in general when I started playing around with Linux. It's a fun way to start and the amount of help you can get when stuck is mind-boggling. If you have some previous experience; give Arch Linux a chance. If you're new something like Sabayon might be at the right level. Popular desktop releases such as Ubuntu may be a bit hard to get "under the hood" in but for a first timer just seeing a different operating system might be enough. In that case, go with OpenSuse or any of the Ubuntu derivatives (e.g. Ubuntu itself, Linux Mint or Elementary OS).

If you don't want to tinker with partitioning; use VirtualBox.

Networks and servers

Plenty of material is available online and practicing it is generally just about tinkering with your own home network, e.g. figuring out what various router configuration options do. You don't need an expensive lab to practice network administration and server setup; two devices (e.g. a computer and smartphone) and a basic network connecting them (e.g. a router with a built in wireless switch) is enough. If you feel like you don't know where to start, use for instance the course page linked to in this chapter and try the concepts described (like port forwarding, dhcp and file servers). I personally find network monitoring to be a particularly useful topic for testers.

Conclusion

The two most important messages I want you to remember:
  1. Do practice, it's important
  2. ... and not that hard
Good luck and if you have additional suggestions, just share them in the comment section below!

Etiketter: , , ,

24 March 2015

Testing Education: Curriculum

I promised a long time ago I would write about each of the subjects in the testing education in detail. I've learned that's not as straight forward as I thought. I need to be careful about what I say/imply about the students, course content, exercises etc. (law, policies, respect for the school (content ownership) etc.).

Due to that I lost the energy to do the detailed posts. But, since I receive a lot of questions about curriculum, here's a post describing the curriculum on a more general level. The subjects below are arranged in the same order as they are taught to the students but the items in each of the bullet lists are not sorted in any particular way. Also the lists are not complete in any way, they're basically what I find noteworthy among all the big and small things brought up. Finally from test design and forward it's not as detailed since those subjects haven't been finished/started yet.

Introduction to testing (4 weeks)

  • What is testing and why do we test software?
  • Note taking and Visualization (mainly mind maps)
  • Heuristics
  • Basic test design
  • Risk
  • Oracles
  • Coverage
  • Bugs and bug reports
  • When are you done?
  • Tools (e.g. Sikuli, Selenium, VirtualBox, Apache and jMeter)
We started this course by; first thing, first day; give the students a flash game to test, a basic testing mission and a bare minimum of introduction to get started, just to let them get a minimal practical idea of what testing is. The rest of this course was a combination of theory and practical testing; sometimes we started with letting them test and then explained some concept they had used (e.g. oracles) and sometimes we did the other way around; e.g. when explaining risk we first gave a lecture and then let them create a simple risk analysis of an application before they actually got to test it.

The testing in this course was (of course) very superficial and the goal was to introduce many different concepts to give them a "foundation" rather than focus on teaching them one part really well, All in all the students, in one way or another, worked with ~10 different applications including desktop (Windows/iOS depending on their laptop), web, mobile and, in some cases, Linux desktop applications using VirtualBox.

You have to remember that the students in many cases came fresh from high school and/or did not have any technical background so it was just a brief introduction to the concepts and tools mentioned.

Think like a tester (6 weeks)

  • Critical thinking
  • Lateral thinking
  • Heuristics
  • Bias and Fallacies
  • Problem solving
  • Test polarities
  • Models and mental models
  • Information gathering/learning
The general setup was similar to the one used in the introduction course however, during the "think like a tester" course we added a lot of general exercises (e.g. what can you do with a brick, the alien tour exercise and many other) to compliment the theory and practical testing.

During this course, James Bach visited the class in Malmö and my class in Örebro joined in via video. A great opportunity for the students to see one of the experts often referenced, in real life. The highlight was James testing the same application as the students had tested as part of their examination for the introduction course. Malmö had several visits from prominent testers (thanks to Öredev) but I leave it to Martin and Maria to speak about those.

Project contexts (3 weeks)

  • Lean and Agile
  • Scrum and Kanban
  • Waterfall and V/W-modell
  • Outsourcing
  • Testing in agile
  • Common challenges for testers
The most interesting part of this course was probably a pretty detailed lecture and discussion on agile testing followed up by a big exercise where students were asked to identify risk in various contexts (like isolation etc.) and what to do to mitigate these/solve the problem.

Programming (6 weeks)

  • Java
  • Automation
  • File systems
  • Programming theory (e.g. compilers, bin/hex and memory allocation)
  • TDD/unit tests
Most of this course was used by the students to program their own testing tool (tool to generate and interpret test data). I'm working on publishing some of them. This has by far been the most challenging course making students work day and night to get their examination applications ready.

Test methods (4 weeks)

  • Schools of testing
  • ISTQB
  • TMap
  • Context driven testing
  • Myths
We teach a context driven mindset and the primary objective with this course was for the students to learn about other ways of looking at testing. Most focus was spent on ISTQB since it's so common and the students got to read the syllabus in detail as well as discuss its strengths, weaknesses, goals etc. in true "critical evaluation style".

Test design (24 weeks, 50%)

  • Test approaches
  • Test techniques
  • Technology
  • Heuristics
  • Risk based testing
  • Coverage
  • Oracles
  • When to use what?
  • Security testing
  • Performance and reliability testing
  • Usability and UX testing
This course runs in parallel with the test strategy, bug reporting and test reporting courses described below and is (by far) the biggest course in the education. The goal is to make it rather practical letting the students use their newly acquired knowledge as quick and much as possible, thus the courses will kind of intertwine as it would be pretty wasteful/fabricated not to do test design, test strategy and test reporting when practicing bug reporting etc.

Test strategy (12 weeks, 50%)

  • Risk based test management
  • Heuristic test strategy model
  • Visualisation
  • Testability
  • Test framing
  • Test processes
This is the other course starting this week. The most important goal is to make students comfortable when requested to create or present their strategy.

Bug reporting (6 weeks, 50%)

  • Content
  • Different receivers/readers
  • Bug pinpointing
  • Reasons not to correct errors
  • Oracles
  • Bug trackers
  • Style and structure
  • What's a bug and what is not?

Test reporting (6 weeks, 50%)

  • Rhetoric
  • What are we reporting and why?
  • Metrics
  • How not to misguide the reader
  • Style and structure
  • Different receivers/readers/listeners

Testing tools (6 weeks)

  • Various categories of tools
  • Introduction to common tools
The main reason for this course is students in earlier vocal university software testing educations (not taught by us) felt practical testing and a basic knowledge of tools were the biggest parts lacking in their education. Apart from tools, being the last course we will have to spare some time to talk about practical tips and tricks preparing the students for the internship and working full time as testers.

Internship (8 weeks)

To finish off the education students are sent on internship at various companies. If you're interested in taking on a student, feel free to contact me in whatever way you prefer (email, Twitter, LinkedIn, as comment, buy me a beer at some conference etc,). By the way; I've not forgotten about you Karlo, students have been informed.

Learning more

You can read about the education (Swedish) on EC Education's homepage. If you have any further questions or are interested in attending the next iteration of the education (Malmö or Örebro) in September, don't hesitate to ask.
Etiketter: , ,

22 November 2014

Report from a software testing education

(written in the middle of the night so you'll have to excuse any strange language or grammar)

Background

I'm currently teaching a 1½ years software testing education. The education is situated in Örebro, Sweden, and there's a similar one in Malmö, where Martin Nilsson is the teacher. In this blog post, I just want to briefly describe the education since many have shown an interest in what Martin and I are doing. This post will not go into any depth about exercises or lectures so in case that's your only interest you'll have to wait. The plan is to cover individual subjects in separate blog posts.

The Education

The education has a clear context driven touch to it, which is no surprise considering the teachers and that the curriculum was created by Henrik Andersson. Since it's the first year its run the material is created in parallel with the education. This has turned out to be a lot of work for me and Martin but it's incredibly rewarding.

Teaching style

This is a vocational university education meaning the students are expected to acquire a high level of practical proficiency or, as I prefer to describe it: Become awesome testers. Our approach to achieve this has been to mix lectures, discussions, exercises and a lot practical testing. Exercises both include exercises closely related to testing (like the critical thinking exercise I've written about before) as well as exercises designed to teach some aspect in a more general way. I'll tell you more about the exercises in later posts.

A lot of emphasis has also been put on creating an atmosphere where students feel safe to stand up, ask questions, question material and even, at times, get cross-examined. Considering it's a class of 30 students that's quite a challenge but we're getting there and I must say students are doing their part of the job splendidly.

The Students

While on the topic; the students range from fresh high schoolers to people taking breaks from well paid jobs. So far the students have completely blown our minds! I had 1/3 of the class attending a local test meetup last week in their spare time, their school results are amazing, during the first course me and Martin had to up the tempo (compared to our plan) roughly with a factor of 4 to keep up with the students and there's no sign of anyone slowing down.

So far, just in Örebro, they've sent in test reports to two companies, reported bugs to two more and I'm planning a project with Securitas Direct where they will briefly be part of a live project (focus is on learning project contexts and improve their ability to test but showing off for a potential future employer is never bad as an added bonus). And in Malmö all students attended two days of Öredev (thanks to Maria Kedemo), but I'll leave it to Maria and Martin to talk more about that.

The Subjects

So far two courses are finished: Introduction to testing and Thinking like a tester. I will cover the content, outcome and lessons learned from those in separate posts. A third is underway: Project contexts and finally there's a Programming course before the year ends. Next semester there's Test methods, Test design and techniques, Test strategy, Bug reporting and the final semester consists of Test reporting, Tools and finally there's eight weeks of internship to round up the education.

The Content

How do you set up 20 hours of teacher-led education in 10-20 hours (sometimes in topics you have very limited experience in)? Well, first off, you don't; but together, me and Martin are slowly closing in on 40 hours a week. A few things I've learned:
  1. I created content ridiculously quick a few times and that quickly raised my general tempo (a bit like how you practice speed reading), so boring, but practice makes perfect.
  2. Since I don't have time to practice what I'm about to say I try to think about key points I want to make and never put more than one on each slide to help me stay focused,
  3. Use the community! Ask friends for help, get some coaching, copy or get inspired by other testers' exercises etc.
  4. Google image is your friend when you dislike text in slides!
  5. When designing my own exercises, I typically start with the one thing I want the students to learn (there are almost always added bonuses but I don't plan for those), From there I try to get to some context where this is very common and finally try to figure out a way to simulate this where I remove distractions or I try to find a way this can be isolated/highlighted while testing. I'll go into this in greater detail in later posts.
  6. I force myself to focus on what's important. I often get caught up in, for example, trying to find that one perfect image or real life example but I've learned if I can't find it in 1 minute I will unlikely find it in 30 so I need to (if not critical) reconsider what I'm looking for.
  7. I always strive for simple! It's tempting to show off by teaching the students unnecessary complicated things or making exercises overly delicate. They will forget a lot of what I say so time is, in my experience, better spent trying to teach them what's important, in an as clear and focused way as possible and repeating the key things over and over is typically good as long as you change approach (lectures, exercises, practical testing etc.).
  8. I often find that exercises can, after run once, be slightly tweaked to either cement what I've been trying to show/teach the students, let them use their new knowledge/test that they've learned from their mistakes or to teach another aspect. And tweaking an existing exercise is typically much less work that to find/figure out a new one!
Sources are anything from articles and books to blogs and experience (from testing, workshops etc.). Finding good, reliable sources is also an area where I've gradually improved. Stories seem to be easier to relate to so I try to use my own experiences as much as possible. To make sharing between me a Martin easier we typically create simple, elegant slides (one or a few images and avoiding text) with a lot of notes. This works well for us when presenting the other person's material as well as for students when they have to read up (speaking about the notes right now). I should say the fact I have a deaf student in my class also is a factor here. She asked me early on to write notes for the slides since she had problems looking at the slides, the interpreter and take notes at the same time. So she should have a lot of credit as well for the detailed notes.

There's no limit to what I could say about creating content but let's stop there.

Company contact

Being an education requested from companies in the area, it's pretty natural to have a close cooperation with them. So far I'm still building my testing network in Örebro (I live, and typically work, 12 kilometers away, in Linköping) but I'm getting there. The goal long term is to get students connected with various companies long before the internship starts. We'll see how that goal turns out.

Internship

If you keep reading about the education and think it sounds interesting keep the internship in mind as many students are open, or even actively seek, to work somewhere else than in Örebro. Mostly in Sweden (Gothenburg, Stockholm, Västerås, Karlskoga/Karlstad and Helsingborg) but also abroad such as Australia, Austria, USA (especially San Francisco and Columbus) and Russia, just contact me if you wanna know more or feel like you could use one of these students at your company. The internship doesn't start until October next year but never hurts to get the connection done well in advance.

Wrap up

So that's the boring part, next up is "Introduction to testing"; what, how and why we taught the students the things we did and what we (Martin and I) learned from giving this course.

By the way: The education use #YHTest on Twitter in case you want to see what the students have created (used sparsely so far).
Etiketter: ,

27 July 2014

Peers

What is a peer
Definition:
A person of the same age, status, or ability as another specified person
(The Oxford Dictionaries)

The kind of peer I will be speaking about is other people within the testing community striving for excellence in a similar fashion as I do and preferably on a somewhat similar level even though that's hard to compare.

We love to team up
Everywhere in life we team up. We get partners to share our everyday life with, we get friends to whom we share similar stuff, we get other friends to share more specific things with such as a hobby, we get close colleagues to discuss work with and so forth. All these people help us as advisers, complement our skills, support when things are shitty, support when we need to challenge ourselves, idea generators, inspiration and many other things, in their respective areas.

A peer in testing to me is the same thing but from a general career/tester perspective. They add an external perspective (or at least second when they happen to also be close colleagues), they help me develop, they help me challenge myself, they help me solve problems I have that require testing or test related knowledge and they can help me when I want to/have to change job.

Does this sound a bit abstract? Let's get more specific!

Help solving a (testing) problem
A question that has been nagging me for a while now is: "What is my role?" or rather "What do I think my role should be?". The problem is I don't really know and I feel I'm stuck when it comes to figuring it out. During Let's Test recently, among many things, I had a 2 hour discussion with Anna Royzman and Andrii about the changing role for testers. It was a great discussion where both I and Andrii had similar questions and together we came to insights like "everyone comes with their own unique mix of skills/experience/knowledge and we have to be careful not limiting our potential and usefulness to the role's description, people's general expectations of us or the role we once had/the person we're replacing". That's one example of how peers (Anna and Andrii) helped me get a better understanding of/solve a test related problem.

Challenge to improve
I'll save my self some work by just pointing at my story of how I became a speaker at CAST. It perfectly illustrates how a peer (Maria Kedemo) challenged me to do something outside my comfort zone in order to help me improve.

Outside perspective
I use my super peer (Helena Jeret-Mäe) for this all the time and even have a name for the quick, very context specific, questions I ask her: Sanity checks. "Is what we're doing, that I feel is wrong/strange, really wrong/strange in your eyes?". If it is, it tells me I'm at least not the only one feeling that way and if not I might get an explanation I've simply missed. An example would be the deployment strategies used in another peer's company and he often asks me: "Is this actually how software is built?". I do my best to explain how we work and/or simply say "no, I've seen... instead and it seems to work better at least in their context", too often though I just answer "unfortunately yes".

Generate ideas
It's easy to get stuck, either if it's when I'm testing, in my career or in some other aspect of my "professional life". This is once again something I constantly do with Helena: "I feel like my only options are..." and she replies "but what about...". Practical example: "I feel like my role is somewhat limited to...", "Have you tried speaking to your boss? To the developers?...". And those, seemingly obvious, answers just didn't occur to me in the middle of my "this shit is broken" kind of mindset.

Practice
A recent example is Software Testing World Cup, which I participated in with a couple of other peers. Another one is practical exercises we've tried in my local test community (EAST), one being us splitting up in teams and attempting to use various thinking hats while testing. And finally a third one is any workshop at a conference where you interact with other testers to figure something out together, sometimes by simulating something which is more or less impossible to do on your own.

Support
Sometimes you just need some cheering or a hug when things don't go your way. And getting that from someone who does understand your headache is very much appreciated, at least for me. Also, something Helena (once again) and I do a lot: Remind each other of how incredibly much we've improved/accomplished, which is easy to forget.

Coaching and Teaching
During a recent Peer Conference (more about those in a moment), James Bach explained his coaching model, which added a whole new dimension to the visual representation I had already seen. That's one example of how a peer explained to me his view/experience/knowledge on a topic. Also any (peer) conference talk is one tester teaching others, often followed up by an open season where "everyone can teach everyone on the topic including teaching the teacher". Finally Helena and I do a lot of coaching as part of our weekly sessions.

Second opinion
Before Let's Test I recorded what I wanted to present as a lightning talk. I sent the video to Helena and her answer was something like "that should be a lightning talk, it doesn't work as good as a video". In retrospect I definitely agree but in that moment it felt like I had to release it, simply because I had spent a lot of time recording it. Thanks to Helena, I didn't.

"Am I stupid" -check
This goes for closer peers, either as in geographically close (sitting next to you) or personally close as in someone you trust very much; preferably both of course. Sometimes I have an idea or question that just seems stupidly obvious. If I have a close peer I can quickly ask that person and (s)he either provides an answer or a "well I don't know either so I don't think it's too obvious". If I don't have that person to quickly ask, I easily go into wasting time waiting simply to either get brave or frustrated enough to ask or to slowly figure out the answer myself.

One practical example was a specific way to trigger a kind of failover in the product I was testing. I almost felt stupid asking if there was another way to trigger the failover. My close colleague (Saam Eriksson) next to me answered "I'm not sure but could be..." and after we consulted the expert it turned out there was a way that had basically never been tested. Without Saam I might had accepted that there probably was only one way to trigger the failover and the "other way" would not had been discovered for another ten years or so.

Fuel the fire
I quickly lose interest in things (my fiancé just nods right now, looking at me like "have you finally realized that"). Having peers who constantly push me, help me find the necessary spark when my motivation is low and inspire me by showing what's possible to accomplish, helps me stay motivated and curious. Also doing things with others (for me) is much more rewarding than doing them alone, so peers help me have fun.

Inspire
Related to that: when I heard Helena would help out planning a test conference it suddenly struck me "maybe I can do that to?", when I watched Alan Richardson's technical web testing webinar/course I suddenly thought "maybe I could record something like that" and the list goes on. There's an unlimited amount of possibilities but sometimes you need a confirmation something is possible/available and the combined ingenuity/bravery of peers often provide that inspiration/confirmation.

Job
There's a lot to say about jobs and peers. Some quick benefits I've experienced myself
  1. Peer review of CV/portfolio stuff
  2. Actual job offers, either from the peer or recommended by the peer
  3. Help choosing between job offers
  4. Recommendations
I've reviewed several CVs, mostly non-testers but I still add it here since knowing the context definitely helps. I've also had peers review my own CV.

My current job was an offer I received from Maria Kedemo and I've also turned down two other interesting offers received from peers... and, well, let's not get ahead of myself.

Also when I got the job I have now I had a hard time deciding between that job and another job. Luckily I know a person who happened to had been working for both companies. He could provide me with tons of valuable info helping me decide.

I've helped peers recruit as well as get recruited, by spreading job ads or recommend specific testers I know for specific jobs.

Finally, I've put in a good word for several testers (and programmers) where I've known the recruiter.

Peer conferences
Peer conferences are not for everyone as you're expected to contribute (present an experience report, speak up, share knowledge/experience) as well as be ready to get challenged on whatever you say. If you feel you're up for the challenge the reward is huge though (lessons, inspiration, network and new practical things to try)!

Being alone in your company/team
I'm the only tester in my "part of the company" (the company is basically split in two). In this situation I've found various testers (peers) outside my company to be invaluable as they help me "stay sane" and not get stuck on seemingly simple matters. My experience from being the only tester in the company, the only tester in my team, one of several testers in a mixed team and being in a pure testing team, is that if you're alone, find someone to share your tester burden with, otherwise it'll grow! Even though this person might not know your context that well, he or she can provide an invaluable second opinion or help you solve problems when stuck, especially when stuck on "simple things you 'should' know and feel embarrassed to ask just anyone about" (I envy you if you've never felt like that).

Super-peer
I call Helena Jeret-Mäe my super-peer. The difference is she knows so much more about me (as in my personality, private life, aspirations, weaknesses, everyday work headaches etc.). This saves a lot of time when explaining a problem and she can see connections between for instance my personality and certain problems, I'm not aware of myself. Most importantly though: We've built a deep trust in each other. She can question things I really don't want questioned and I will listen (things like not prioritizing family as much as I should) as well as push me much further as she knows my limits sometimes better than I do myself and vice versa of course.

Can't you do this on your own
You can do most of this on your own but much of it will be harder and/or take longer time and/or not be as fun. Since I reached out to the testing community my level as a tester has skyrocketed!

How to find peers?
Getting to know other testers seems fine and dandy but where do you start?

Twitter
Some tester once said to me, about testers, "if you're not on Twitter you don't exist". Even though that's to exaggerate it's still true you'll find most renown testers on Twitter and it's an amazing way to make that first contact. For instance, when I went to my first big test conference, I could immediately start talking to a ton of people thanks to Twitter and the conversations there. A good thing with Twitter: Everyone is entitled to add to a conversation so there's no initiation ritual, instead you listen in och when you feel you have something to say you join a conversation and voí la, followers will come (if you're nice and/or smart) and relationships will form.

(Peer) Conferences and courses
Peer conferences usually have fewer, and likely more dedicated, participants. They don't last for many days but the bonds created are, in my experience, very strong.

A larger test conference is perfect to get in touch with many new testers and broaden your network.

Courses are a bit like peer conferences in the sense that you can easily become very close to some testers in a relatively short amount of time.

If you need suggestions for (peer) conferences and courses, contact me (some info at the end).

LinkedIn
I mostly use LinkedIn to connect to my local test group after I learned about them but can work to find new testers to hang out with as well. Not, to me, as obvious to make useful though, as Twitter.

Meetups
If there is no local test meetups in your area, visit a bigger town to join one or start your very own local test community. If you need some inspiration: Check out Erik Davis' excellent post!

Blogs
Starting a blog about testing is good for many things (reflection, portfolio, getting feedback etc.) and one of them is, a good blog generates interest in you. Also reading other testers' blogs and leaving (sensible) comments on these will teach you things as well as help you connect with these people.

Software Testing Club
I don't use this community very much for some reason but every time I do I get impressed. Seems to be a great way to connect so try it out for yourself!

Colleagues
Why look far away when you've curious testers next to you? Suggest an educational activity like spending an hour watching some great testing presentation (need suggestions? just ask me!) and discuss the contents together. Who knows, maybe you'll find a colleague to keep learning with.

Summary
Don't isolate yourself, or other testers if you're in a test lead/manager position! Instead, try to reach out, ask for help, provide help, share ideas, socialize, listen, speak up and network. The field we work in is way too vast to be covered by one person alone. Team up and you'll be much more efficient... as well as have much more fun.

If you are, or feel, completely new, ask for a mentor (I can either help directly or hopefully get you in contact with someone who can help). If you know your way around but have done things in solitude so far, go to a test conference, start a blog, join Twitter or go to/start a (local) meetup for testers. Still feel stuck? Contact me! (use this blog, Twitter, LinkedIn or any other way you find... except tapping on my window in the middle of the night as it would probably freak me out).

Good luck!
Etiketter: , , ,

25 September 2013

Transpection Tuesdays

A couple of weeks ago me and Helena Jeret Mäe sent a few cryptic tweets about "Transpection Tuesday". Since then Helena has written a great summary of our first session and to add to that here are my thoughts so far.

What is Transpection
The best explanations I've found are James Bach's explanation of transpection and Michael Bolton's transcript of a transpection session. But basically it's one person asking questions to another person with the twist that the one asking has already tried to answer those questions. The result is you get two sets of answers, hopefully less biased from each other.

What is Transpection Tuesday
When I first met Helena it was during Let's Test earlier this year. She had tried to grab me a few times but sessions and other conversations had interrupted us. So suddenly during lunch she stood up and said: "You sit here!", and pointed at the chair in front of her. And so I did, which was one of the smarter decisions I've taken as a tester.

Transpection Tuesday happened in a somewhat similar fashion:

Helena: Hey. I was thinking this morning that we could have Transpection Tuesdays (because it rhymes :P) or something. if there's something each of us is trying to work through and solve, then we could try this transpection thing out. It's a bit random thought
Erik: Sounds cool... I'll take care of the kids alone tonight since my fiancé is working so suits me perfect... with the possible problem that a kid wakes up and I have to leave very suddenly and might not come back .)
Helena: I understand that and won't hold a grudge :P
Erik: In that case I'm in! Usually kids are asleep after 19:30 CET, hopefully there's no change tonight

So after some technical difficulties we started a Skype call with video. By the way, video was awesome for this since it made sharing visualization easier, body language is useful when trying to explain something and it helped, at least me, stay focused.

So to summarize:
Transpection Tuesday is simply a Skype session ~3 hours long, happening every Tuesday evening between me and Helena, dedicated to talk about testing.

Confession
Okey, so what we've done so far has been far from just transpection. Instead it has more been like a weekly dose of conferring where we discuss topics that matters to us in various forms; where form depends on mood and topic. You could argue the name thus is misleading, and it probably is... But we like it.

What did we discuss?
Helena shared our combined notes, from the first session. I won't write anything detailed about it now but if something in those notes seems interesting, feel free to leave a comment and I can try to write a future blog post about it (my guess is some of the more "community challenging" stuff would fit that criteria).

How did we discuss?
I recognized five different "styles"/formats used during our talks, plus one suggested that we haven't tried yet:
  1. Transpection
    I tried this briefly when speaking about why/if we should send people to courses and Helena did it much more extensively during the last TT when speaking about bias. When talking about these topics one of us asked questions we already had answers to but felt we wanted to improve/challenge. What makes this powerful is the person answering last get slightly less biased since he/she hasn't heard the first person's answers which gives you interesting answers to compare.

  2. Conferring
    Most of the talking was just quick questions being thrown out and then we together tried to answer and discuss them. I would say this is the style we use most (it's like our "go to" style) and for those of you who've been to Let's Test or CAST, this is very similar to the discussions you typically end up in during lunches (which is a good thing!).

  3. Challenging
    I plan to do a lot more of this going forward because it felt like an awesome way to learn. Essentially it's one of us asking the other to clarify something to a great level of detail or challenge a claim being made (similar to what happens during RST for instance). Very powerful as assumptions were uncovered and you constantly had to be on your toes.

  4. Role play
    We take opposite roles (e.g. the manager who questions the professionalism in ET versus a context driven tester considering ET a good approach in the current context) and simply fight it off with the goal to pressure each other to explain/motivate something at a deep level, as well as highlight assumptions. We have actually done this very briefly but I don't think enough to really call it role play, more quick imitations and reactions to that.

  5. Transfer
    Simply one of us telling the other something without any questioning going on; so basically a monologue about a topic. What was interesting to me was the information I received this way really seemed valuable but missing the interactive aspect hampered my ability to connect it to something else/make "lasting connections". Also I often felt the energy was lost a bit when one of us talk for long stretches.

  6. Interview
    Similar to Transfer but more driven by questions so basically the receiver "choosing" what information he/she is interested in. Better than the monologue version but still a lot less valuable than any of the more interactive ways. It was like, even with questions, I didn't get my brain into gears, so new information simply didn't stick as it was when e.g. Conferring.
Improvements
Here are a few things I've noticed:
  • Having a clear topic helps as we got fewer side tracks and thus easier could focus on going deep into the current topic. Side tracks are not evil per se, but too many and too big ones seem to make discussions rather shallow (my feeling so far).
  • Having prepared followup questions would had been helpful, we have improved this for next week, will be interesting to see the result.
  • We did get deeper into the topic during our third TT as we pressured each others to better explain what we meant and why even when agreeing. Think we can do this to much greater level though.
  • I need to try to quickly structure the information in my head, before starting long rants/monologues about something.
  • I think both of us could benefit from monitoring our own speaking trying to stop ourselves during long monologues. It's much harder for the other person to recognize a good break point.
Wrap up
So, Transpection Tuesdays are not so much about transpection but rather about weekly conferring. I already look forward to next week (preliminary topic: "Arguing for Exploratory Testing") and that's a great sign. I hope this turns into a long lasting tradition and it will definitely be the foundation for many future blog posts!
Etiketter: , ,

14 May 2013

Key testing skill: Thoughts into words

Background
During SWET 4, one thing that really struck me was how amazing the other participants were at quickly and accurately turn their thoughts into words. It was probably the most striking difference I noticed between myself and these experienced testers. Since then I've kept thinking about this skill and how to improve it. This is my thoughts so far...

Why
One of the early slides in the RST material starts with: "Testing is in your head" which I think sums up why this skill is so crucial. You need it if you want anyone to understand anything about your testing. Some examples; you need it to get:

  • Programmers to understand your bugs
  • Stakeholders to understand why these bugs are important
  • Your employer to know why (s)he needs you
  • Your colleagues to know what you're doing and how it's going
  • Anyone to understand your problems
  • Stuff on paper (strategy, results, methodologies etc.)
  • You to understand for yourself what you are doing/have done
Notice the list doesn't mainly consists of stuff only some test thinking expert needs to master, it's stuff every tester needs to master!

How can you improve this skill?
Since this skill is fundamental to testing you will practice it to some degree by just doing ordinary work but the ideas I've listed below are ways I've found more efficient either as ways to practice the skill or to get feedback on how well you're doing.

Answer the fundamental questions
For many questions the answer is far less useful than the process of getting to an answer. Some examples in testing:
  • What does it mean to test something?
  • Why do we need testers?
  • Can't programmers test themselves?
  • What's the tester's role?
  • What is a bug?
  • Do testers need education? Why? Why not?
  • Can we find all bugs? How? Why not?
  • How do you know when you're done testing?
  • How can we measure efficiency of testing?
  • How do we know what's important?
  • Why do we run extreme tests?
  • Can we on beforehand figure out what to test? How? Why not?
  • If we know the status of a product shouldn't we decide whether or not to ship?
Can you answer them? Is your answer a quote from some famous tester like "a bug is something that bugs somebody who matters"? How do you know who matters? How do you know what these people think? Is it enough if one out of a million of these are bugged? Two? Five? A hundred? If we expect someone to matter later who we expect will be bugged about this, is it a bug? If people who matter don't know about something, e.g. a missing link, but would love it, and be bugged if it was later removed, is the fact that it's missing a bug?

The questions I asked above is exactly the kind of questions I want to you ask and try to answer. It's a kind of mental gymnastics that will not only help you improve your ability to put thoughts into words but it will also help you learn a lot more about testing (which will be a common theme for the rest of this blog post).

Blog
I brought up the importance of blogging way back in my 2012 refelction posts, there you can find a bunch of motivational links and tips on why to blog.

Anyway, I get two things out of blogging relevant to the topic:
  1. Feedback on how well I present/explain my thoughts (if people read and react)
  2. An efficient way of practicing the act of putting thoughts into words
The second point depends on that I write about my own thoughts and not just reference what other people say.

Talk about test
Talk to colleagues, speak with people on Twitter, go to conferences/meetups, present. All these things force you to practice the art of putting thoughts into words, some of them also force you to do it rapidly to keep the conversations going which adds another dimension (which, for instance, blogging doesn't).

Explain what you do to non-testers
Have you ever tried explaining what you do and why it's important/interesting to someone like, say your mom? Or boss? Or best bud? Or some programmer you know? Or maybe you from before you became a tester ("hey myself, you're going to become a software tester and you'll love it, let me explain to you why!")? Try it, it's a lot harder (at least for me) than you might think. Also it really forces you to look deep into your thoughts to find out what things really mean to someone not familiar with testing (sometimes it helps you figure out what stuff really means in a more general/other context than testing).

Ask for feedback
It's important to practice but it's also important to know if your efforts are paying off. "Am I really better at explaining what I do know?". You can ask pretty much anyone how they interpreted you explanations and/or how easy they though your explanation was to understand. Here are a few quick, general example:
  • Was my last bug report clear to you? Did you miss something?
  • Was my last debrief useful? What could I've done to improve it?
  • Did you understand my explanation or what part was hard to understand?
  • Is it clear to you why I think we need to use an exploratory approach?
Question stuff
If you walk around and accept not understanding what others try to communicate to you I believe there's a great risk you do the same about your own explanations/thoughts. Try to get out of this by questioning anything you don't believe in and ask for another explanation whenever you don't understand something. I've found this to really help me question my own believes, assumption and opinions.

Good question to ask yourself after any explanation:
Would my dumbest colleague understand this and why not?

As a recommended reading on this I really love this blog post from Tommy MacWilliam.

Mentor someone
I've just done this briefly but I find it a great way to force myself to explain in detail what I'm doing and why. It also provides me with a great possibility to get feedback, both verbally and as I monitor my pupil's improvements.

Rapid Software Testing
The Rapid Software Testing course is a lot about trying to get you to think like a top notch tester. One of the key aspects practiced during this course is explaining what you do (putting thoughts into words) and build the courage to do so. I highly recommend the class for many reasons, this is definitely one!

Summary
Putting thoughts into words is key when doing any form of testing (planning, executing, bug reporting, following up etc.). Ways I've discovered that works well for me to practice this skill is:
  • Question the answers, why is this answer true? Is it really true in this context? When is it not true? Why?
  • Try to come up with your own answers and refine them using questions
  • Blog, or write about testing in some other way
  • Talk testing whenever possible
  • Ask for feedback
  • Don't accept not understanding neither your own nor others explanations
  • Become a mentor to force yourself to communicate your thoughts
  • Rapid Software Testing is a great course to help you improve this skill
Etiketter: , , , ,
Subscribe to: Posts (Atom)