RSS

Author Archives: Kim Engel

About Kim Engel

Software Quality Specialist

As a software tester, do I need to learn about automation?

24 Jul

Testers regularly ask, “Do I need to learn automation skills?”.

Let’s step back for a minute and put this another way, “Do I need to learn how to drive a car?”.

Well you could walk, or take the bus, or pay a taxi\Uber driver to drive you around. These are all valid choices. But there’s a big advantage in being able to drive, for times when driving is the best option.

So my answer is no, you don’t need to learn automation skills, but having those skills will let you make informed decisions about the most efficient way to approach each testing task, with a wider range of options available to you.

Consider for a moment, what has stopped you from learning hands-on automation skills before now?

bus.JPG

Ignore the Fear

When testers ask me whether they’ll need to learn automation skills, there’s an implied reluctance or fear behind the question. Sometimes it’s a fear of being left behind in the job market, or of being replaced by testers with stronger technical skills. In a few cases the testers asking seemed reluctant to invest time in learning new skills unnecessarily. I have a lot more time for the first group of people, compared to the second group.

For the testers who ask this question, are you nervous, intimidated or overwhelmed when it comes to learning automation skills to help with software testing? For now, let’s pretend that you’re not. Imagine instead that you’re completely capable of writing an automation script (because you are). How can you get started?

Avoid Analysis Paralysis

There is so much information online that we’re presented with an overwhelming number of options and learning resources. I got stuck while deciding which programming language to learn (COBOL has gone out of fashion since my development days).

I had finally decided on Python – I can’t remember why now – and had completed the first few tutorials, when others convinced me I should be learning Java. Or C#, or Ruby… So I stopped doing the Python tutorials, and unfortunately it was a while before I decided to try again.

I’ve since learned that it simply doesn’t matter. My learning experience has driven my approach for this post. The key thing to remember is that once you learn the basics of an object-oriented programming language, and an automation tool, it gets much easier to learn the next one. They all have a lot in common.

To help you stop procrastinating, and to make sense of all the options out there, the rest of this post is very straightforward. My goal is to get testers to learn some automation, to complement their existing skill sets.

laptop.JPG

Take the First Step

Learn Java, using this website to get you started: http://www.tutorialspoint.com/java/index.htm

(The time you may be tempted to spend on researching the best website\tutorial to use could be spent learning Java instead. )

You know your own preferred learning style better than I do, I just have a few words of general advice.

  1. Start from the beginning.
  2. Follow the instructions to set up your computer, and try to overcome any perceived obstacles while you’re getting started.

i.e. if you get stuck, ask for help.

  1. You won’t need to memorise anything. Yes, the maximum “int” value is 2,147,483,647. And no, you won’t need to remember that number. Once you’ve read the course information, you’ll know where to find it later if you need it again.
  2. It’s okay if some things don’t make sense right away. “Float data type is a single-precision 32-bit IEEE 754 floating point”. I don’t understand most of that sentence, yet I can write automation scripts.

 Java tutorial.JPG

You don’t need to complete all of the lessons unless you want to. You’re not trying to become a developer, you need to know ‘just enough’ to be getting on with for now. The course material will still be there when you need to deepen your knowledge of Java, down the track.

There are no stupid questions. Anything you want to ask has probably already been asked and answered on http://stackoverflow.com/. If you can’t find an answer there please feel free to post your question. You’ll be doing a huge favour to plenty of other beginners like yourself, who will benefit from reading the responses in the future.

Take the Next Step

So, what’s next?

Pick a tool, any tool.. If your test team aren’t currently using any automation tools and you’re stuck for ideas, check out Ghost Inspector https://ghostinspector.com/. There’s a free trial and you can quickly automate some website checks. Ghost Inspector is like Selenium, but it’s hosted on the cloud with a pretty good GUI, and a record and playback feature, making it easy to get started with.

ghost inspector

Start by using a non-production version of the website you’re currently testing, or use a sample website created specifically for learning to use automation tools. For example, http://phptravels.com/demo/.

The first test scripts you create will fall into all the traps inherent with using record and playback tools, and that’s okay! Because you’ll be automating, and you’ll be learning, and that’s an excellent start.

From here you’ll gain confidence to start\join a conversation about automation, you’ll have specific questions to ask, you’ll be able to research online independently, and continue to learn new automation skills.

 demo site.JPG

It’s Okay to Fail

They say in Silicon Valley, “Fail fast, fail often”. The same applies here.

Learn the hard way by diving in, getting started, making mistakes, and improving as you go. The worst thing you could do is read every “Lesson learned in test automation” article on the internet before learning to use a single automation tool.

Start Right Now

Get started with an online Java course right now – http://www.tutorialspoint.com/java/index.htm.

If you prefer hands-on classroom-style learning, at Engel Consulting we have Introductory Java and Selenium courses available in Auckland, with more courses coming soon. There may be also local training providers in your area, or experienced testers willing to provide training on request.

Also worth a mention is Mike Talks’ blog post series on automation: http://testsheepnz.blogspot.co.nz/2016/06/automation-1-guide.html

 
7 Comments

Posted by on July 24, 2016 in Software Testing

 

Tags:

What Are Test Oracles?

24 Jul
What Are Test Oracles?

How do you recognise that something you’ve seen may be a bug?

What do you do when your test results don’t match the expected results?

For our WeTest Meetup discussion we started with a working definition of an oracle as “a source of authoritative information”.

We rarely rely on just one source of information when determining how a product should work. For example, when working from a list of written requirements we may also check how the previous version of the product works, to further clarify our understanding.

Two authoritative sources can contradict each other. For example, written requirements may not match the design documents. In that case, how do we decide which oracle to use?

Stakeholder decisions during product development can be a compromise between desired functionality and a practical solution. How often is documentation updated to reflect these ever-changing decisions? In this situation, is ‘product team consensus’ considered to be an oracle?

An oracle can be incomplete. In fact, we struggled to think of a real-world example where an oracle would be complete and correct…

Rapid Software Testing (RST) takes a broader definition of an oracle:

“An oracle is a means by which we recognise a problem when it happens during testing” – James Bach and Michael Bolton, Rapid Software Testing.

Rasha Taher brought along this RST diagram on oracles to share with the group:

OracleQuadrants

Our authoritative oracles all fall under the Reference category in this model. They are external, explicit oracles. This model opened up a whole new perspective to the discussion. We started to brainstorm other oracles we use every day, without necessarily realising that we’re using them.

After talking through this model as a group, we felt more conscious of using our own experience and feelings as oracles while testing. Did the behaviour of a certain feature make you feel confused? You may have found a usability issue, for example. Once you’ve worked out the cause of your confusion, consider whether users may encounter the same problem, particularly new users.  Will they be provided with more or less training than you received as a tester? Is there a way for users to overcome this hurdle, without needing to personally ask the developer and product owner how the feature should work?

Conference oracles highlight the importance of communication in software testing. With open and frequent communication testers can gain a clearer picture of stakeholders’ expectations of the product. This can help guide testing, to determine how well the product meets those expectations.

While discussing Inference oracles, Ram Malapati led us to the FEW HICCUPPS heuristic. These are a whole topic by themselves, and could be the main topic for our next discussion group!

Through learning the term ‘test oracles’ and reviewing this model, we feel more empowered and in control of our test approach. While we may not use the term oracles at the office, just being aware of the oracles we use daily can improve both our approach and our confidence.

Finally, learning the term ‘test oracles’ opens up a new avenue of research on software testing methods, to learn more about oracles and how we can use them.

Further reading:
As Expected – Michael Bolton
Oracles from the Inside Out – Michael Bolton
What Testers Find – James Bach

 
Leave a comment

Posted by on July 24, 2016 in Software Testing

 

Listen to Your First Testing Podcast

02 Jul
Listen to Your First Testing Podcast

This month I’m joining many members of the online software testing community in the 30 Day Testing Challenge.

The challenge for Day 3 is “Listen to a testing podcast”.

Testers know that rules are made to be broken… I was planning to watch a testing talk on YouTube instead. When my colleague Ram insisted that I should actually listen to a podcast, I had to confess that I’ve never listened to a podcast before.

Here’s what I’ve learned about how to get started. Unsurprisingly really, it’s easy!

I’ve included 3 testing podcast channels below. If you know of other great channels please add them in the comments section.

  1. Search for\open the Podcasts app (see links below for app recommendations)
  2. Search for testing podcast e.g. Ministry of Testing, Testing in the Pub, Test Talks…
  3. Subscribe to the channel
  4. View the channel feed
  5. Download an episode that looks interesting
  6. Listen at any time

This slideshow requires JavaScript.

Podcast Terminology

Podcast – term used to refer to either a channel or an episode (confusing hey..)
Channel – a collection of podcast episodes, which users can subscribe to
Episode – an individual mp3 file, which can be downloaded or streamed
Feed – an updated list of episodes for a podcast channel

Apps

There’s lots of other podcast apps available for iOS and Android, with extra features.

 
2 Comments

Posted by on July 2, 2016 in Software Testing

 

“7 Testing Principles” – Meetup takeaways

29 Apr
“7 Testing Principles” – Meetup takeaways

Over lunch time today our WeTest meetup group discussion topic was the ‘7 Testing Principles‘.

Our aim was not to dissect and review the principles.. We only had 50 minutes – less the time it takes to order and pay for lunch! Instead we used the principles as a focus point to discuss relevant aspects of our current project contexts and our past experiences.

From principle 3 ‘Early testing’ – my takeaway was that testing involvement is more useful before and after architectural design rather than during architectural design. I think this could be a whole separate topic for discussion\debate, depending on other testers’ experiences and context.

There were also real-world stories of what can go wrong when testing is not done early e.g. finding issues with requirements during UAT, on an “Agile” project!

From principle 6 ‘Testing is context dependent’ – We had fun explaining different aspects of context and how they affect our current projects. My key takeaway is that context can change even within the same team and project. Eg, one company grew from 5 to 150 people, causing a major context shift.

The question was raised, “Can automation be context-driven? “. Again, that will be a good topic for a future discussion. I’d like to discuss this in more depth.

Principle 2 “Exhaustive testing is impossible” – This came up briefly, and basically we all nodded 🙂

At that point we were out of time, and we finished by unexpectedly giving Elena (a Neighbourly developer) some direct user-feedback.

This meetup was interesting, easy to organise through our existing Meetup group, and fun to attend. I encourage you to consider hosting a similar discussion group.

 
Leave a comment

Posted by on April 29, 2016 in Software Testing

 

Rapid Software Testing – Reading Recommendations

14 Aug

Having just completed Rapid Software Testing twice in two weeks with James Bach, I’m feeling motivated and inspired to continue learning.

Here’s a list of books recommended by James during the course. These will enhance your skills and change the way you look at testing.

RSTReading

The first book may be the most important, and the most difficult to read. I’m still getting through my copy. The content is excellent, and there’s a lot to take in.
The next 4 books are real page-turners, explaining important and complex information is a way that’s enjoyable to read.
I haven’t yet read the last book on this list.

An Introduction to General Systems Thinking by Gerald Weinberg
Thinking, Fast and Slow by Daniel Kahneman
Tacit and Explicit Knowledge by Harry Collins
Lessons Learned in Software Testing: A Context-Driven Approach by Cem Kaner, James Bach, Bret Pettichord
The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully by Gerald Weinberg
Discussion of the Method: Conducting the Engineer’s Approach to Problem Solving by Billy Koen

If you’ve already read these books, I’m interested to hear your thoughts. For example, what was the biggest takeaway you got from each book, and how has that helped you with software testing?

 
7 Comments

Posted by on August 14, 2015 in Learning, Software Testing

 

Tags: , , , ,

What’s Your Context? – Workshop with Fiona Charles

10 Nov

How do you discover the differences in context between clients and projects, and whether those differences matter? While intuition is important, unconscious analysis and choices lead to unconscious assumptions – Fiona Charles

Ask a tester which approach is the best way to test software. The typical response will be “It depends”. But what does it depend on, and why? How will those facors affect testing?

Fiona presented her “What’s Your Context?” workshop to the Auckland WeTest meetup group. We split into 6 groups to brainstorm the elements of context that affect our approach to testing. It’s difficult to report on the value gained from attending a workshop, as the learning comes from being involved in the discussion. Here I’ve recorded my brief notes on the “Aha!” moments described by others at the end of the workshop.

Me: I’ll be doing this exercise regularly for projects I work on. More aware how much context can change during the course of the project.

Natalia: It was very useful to learn about other tester’s contexts.

Pete: Two favourite sayings are ‘It depends’ and ‘Why?’. For example, ‘Why are we doing this?’.

Morris: We say ‘team’ a lot. Testing is a team sport.

Vikas: Highlights the importance of thinking about context deliberately, instead of repeating past processes.

Shaheem: Maintain a risk focus, which things can derail or negatively impact the project.

Chris: The definition of Minimum Viable Product is heavily context-dependent.

Georgia: Focus on the problem being solved. Take history into account. Appreciate the benefit of informal communications (this arose in the context of working with offsite teams).

Vincent: Like the experience of working with his team, learning from their experiences, and the way they grouped elements of context together into personal, product, team and development methodology.

John: So many sources of information beyond just requirements. Stop and consider context first before you get started.

I encourage other testers to take Fiona‘s workshop. Her questions, insights and stories brought the exercise to the next level.
In the meantime consider pairing up with one or more testers and asking yourselves, “Which elements of your context affect your testing? Why, and how? How can you use this information to improve your testing approach for your current project?”

 
1 Comment

Posted by on November 10, 2014 in Software Testing

 

Tags: , , ,

Let’s Test Oz – Closing Keynote from Fiona Charles

10 Oct

The closing keynote speech of Let’s Test Oz 2014 was “The Battle for Our Hearts and Minds” by Fiona Charles.

This was the first time I’ve attended one of Fiona’s talks in person. My impressions of Fiona after this conference are that she is honest, practical, a strategic thinker and that she doesn’t mince words.

“I have seen 50-page test strategies without an ounce of strategic thinking”

Fiona Charles

“I’m not going to do bad work” Fiona Charles

The theme of this keynote was that attempts to standardise testing are stifling creativity and value, and that it’s time for testers to take back our craft. Fiona spoke of the need for testers to have the courage and tenacity to speak up about important issues when others remain quiet. This included being willing to ‘blow the whistle‘ where necessary to expose important issues which could affect people’s lives.

“We need to be able to say things that nobody wants to hear, because that’s our job”

The topic of testing standards came up more than once, as a primary cause of the long-term de-skilling of the testing workforce and the current overall state of testing processes and documentation. Using the example of a 25-page IEEE 829 compliant Test Plan, Fiona saw no project-specific content until page 12. The time taken to produce these documents is costing companies money, and contributes to testing being viewed as ‘too expensive’. The focus of testing should be on adding value to the project and to the company.

“The Master Test Plan is probably the most useless document since printing was invented”

Most of the people behind the creation of ISO 29119 stand to profit if the standard is introduced. Interestingly, Fiona’s opposition to ISO 29119 comes despite her anticipation that she’ll profit from the standard if it’s introduced. Fiona described how she has seen first-hand the damage caused by compliance to the IEEE 829 test documentation standard. She has been called in to multiple organisations to mop up the damage which that standard leaves in its wake, and she has every reason to believe that ISO 29119 would create more of the same damage.

“The quest for certainty collides with the reality of software development”

Fiona introduced the concept of “healthy uncertainty vs unhealthy certainty” while debunking the notion that popular test metrics are useful. She covered some key attributes of great testers, and they’re not the ones you see listed in jobs ads: Integrity, Independence of Mind, Courage, Engagement…

I really enjoyed this talk. It was motivational, inspirational and a call to action for all testers.

Recommended reading\viewing:
The slides from this keynote are available from the Let’s Test Oz website.
Breaking the Tyranny of Form blog post – Fiona Charles
Delivering Unwelcome Messages EuroSTAR webinar – Fiona Charles
Slides from We are the 99% – Anne-Marie Charrett

All quotes in this post are from Fiona Charles’ keynote.

 
2 Comments

Posted by on October 10, 2014 in Software Testing

 

Tags: , , , ,

Equality at IT conferences

10 Oct

At the Let’s Test Oz conference I actually forgot about gender inequality in IT for three days.

I don’t complain about gender inequality in the workplace per se, for the usual reasons which I try not to complain in general. It’s not efficient, it’s not effective, and no-one listens anyway… I prefer to act. For example:
– Supporting and advocating for my team members who’ve escalated issues of harassment (albeit to no avail).
– Working to ensure that team members can return to work part-time after a career break if required.
– Championing pay rises for team members who are comparatively underpaid (and usually aren’t aware that they’re underpaid).

At most IT events I can’t help but notice that I’m in the minority. At CITCON 2014 approximately 10% of attendees were female. At a recent Splunk seminar in Auckland less than 5% of us were female, and that was confronting. On the other hand I’ve gotten used to management meetings with predominately male co-workers, because that’s the norm today.

The Let’s Test Oz 2014 conference was an exception. During the conference wrap-up Anne-Marie Charrett observed an almost equal number of men and women at the conference, both speakers and attendees. I looked around and saw that she was right, and then I allowed this to really sink in… The gender distribution at the conference matched the real world closely enough that I’d gotten through an entire IT conference without noticing the percentage of women attending. That’s progress!

While writing this I realised that I’ve never noticed gender at the Auckland Testers Meetups either, again because attendance is representative of the real-world. I think it’s great to notice and celebrate these examples of progress.

I’ve written for the Women Testers magazine and attended the Women in Tech meetup to support both initiatives, to further my learning, and to build my professional network and industry profile. I was silently cheering for the few men at the last Women in Tech meetup because they genuinely came to listen and learn about the issues women face. We could do with more of that in tech.

 
Leave a comment

Posted by on October 10, 2014 in Equality

 

Tags: , , ,

ER: Learning exercise on the Implicit Principles of CDT

07 Oct

This is a detailed experience report on a learning exercise I completed recently, following my post about James Bach‘s opening keynote at Let’s Test Oz (LTO) 2014:

…There was one slide in particular which I could’ve questioned James on for another hour, called Implicit principles of the Context-Driven School of Testing. This slide contains ideas which could fill a book, if James had time to write another book.. I think I need to read some more books before I can fully fathom the concepts presented! The beauty of this conference is that I have many opportunities to find James in the hotel and ask about this slide in more detail…

On day 3 of LTO I tracked down James and we spent the better part of an hour walking through these principles. Please click on the image below and take a moment to review them in detail.

Implicit Principles of CDT - Slide from James Bach's Keynote at Let's Test Oz 2014

Presented by James Bach at Let’s Test Oz 2014

At first glance I found these Implicit principles intimidating. In hindsight, I’ve attributed this to 3 main reasons:

1. My immediate impression was that the principles are based on a lot of assumed knowledge. I’ve since concluded that these ideas stand alone, and the impression of assumed knowledge was due to the number of unfamiliar terms. In fact the only assumed knowledge is a basic understanding of software testing and an above average English vocabulary.

2. The principles include words which I couldn’t define, such as primacy, non-linearity, cybernetic and authorship. I’ll define these simply here, in my own words:
Primacy – Most important
Non-linearity – Unpredictability
Cybernetic – React to observations
Authorship – Creation

3. I couldn’t understand the reasons behind the creation of these principles. If James covered this in his talk then I missed it. I was wondering what was wrong with the original list of seven basic principles (shown below). I wanted to understand not just the new principles themselves, but also the need for them, and the thought processes that went into creating them. As an aspiring CDT practitioner, understanding this process of articulating the CDT approach is important to me.

Original CDT Principles by Cem Kaner and James Bach

Original CDT Principles by Cem Kaner and James Bach


The Learning Exercise

While discussing these principles with Anna Royzman over dinner, I mentioned that the new list seemed unapproachable for the masses. Anna agreed with the need for a shorter and more simplistic version, which I’ve called the marketing version. Anyone reading the marketing version and looking for more information could read the full version of these principles to find out more context and detail.

I approached James about this on Skype and offered to create a first draft for review, to get the ball rolling. James disagreed with the need for a marketing version of the principles, but he did agree to support me in the process of creating it. I was quite confident in the need for a new version…

Draft 1 of my marketing version

I have to remind myself now that I was proud of this version when I initially created it, while the ink was still wet. I felt that I’d captured the key points from James’ 10 Implicit principles and presented them in a user-friendly way. Here’s what I came up with:

  1. We constantly adapt test processes to changes in our real-world environment (covers point 1 from updated list)
  2. We learn through investigation and present facts based on evidence (covers points 2 & 4)
  3. Due to systems complexity, we observe and react to uncertainty (point 3)
  4. Systems are developed by people, for people (point 5)
  5. Testers have a duty to add value and behave ethically (point 6)
  6. Testers work with the team and share responsibility for quality (point 7)
  7. Testers must continue to learn a variety of skills and practices, in order to adapt processes to suit each project (covers points 8, 9 and 10)

I sent this list to James for review, and we started to review point 1 together. Based on James’ questions and comments, I had a basis to further review my own work. These are my brief notes from that review.

Self-review 1:
1.
2. ‘Facts based on evidence’ doesn’t seem to tie in with heuristics.
3. No longer sure that this sentence makes my point clear
4. Therefore… what?
5. I want\need to do this, it’s not just a duty. This sentence [as written] currently applies to everyone in the company…
6. Sounds like I’m describing Agile testers. “The team” – which team?
7. This point isn’t terrible.

This version is vacuous. I’ve abstracted too far, it could almost be describing procedure-driven testing. Start again…

Taking a Step Back

During Skype coaching James posed the question, “If you had to tell someone a few things that would get across to them the *gist* of CDT what would that be?” This expanded the learning exercise for me, as I’d have the freedom to create a whole new list, rather than devising a simplified version of the 10 implicit principles.

I decided to first work out which concepts were lacking in the 7 Basic CDT Principles, in order to understand the need for the 10 Implicit CDT Principles. I came up with a working list of the differences (shown in the image below, initially without the information in italics).

Comparison of CDT Concepts

Comparison of CDT Concepts

While reviewing both lists so closely, I gained a greater appreciation for the initial list of principles. I really started to doubt the need for a new short version, and I also doubted whether my creation could come anywhere close to the original.

When reviewing some of the differences I’d identified with James, he said something very interesting. His updated list of 10 principles was not intended to replace the original list! Therefore the original list still stands, and my marketing version is redundant. The new list was designed to clarify the implicit concepts which were behind the creation of the original principles.

The implicit principles were created by the main principles…
… I wrote the ten by asking myself what did I mean by the seven and what must necessarily be true to achieve them.

This was my aha moment. Now I understood that there was no need for a new short list. The original list was not being replaced at all, only expanded upon in more detail.

Conclusion

Although I’d started out on a fool’s errand due to a misunderstanding, this turned out to be a productive learning exercise. I can now speak confidently about the principles of context-driven testing and will continue to champion them. I’ve suggested two changes to James which he has agreed with. The first was the re-introduction of the concept of software solving a problem. The second is that community status was not implicit in the original principles and has been added in this new version.

This exercise has prompted me to finish reading Thinking, Fast and Slow by Daniel Kahneman, analysing my own thought processes.
And finally, it helped me to “keep my brain sharp” between contract roles.

Notes on Complex Language

I remain concerned that the complex language used in these principles will hinder the widespread communication and adoption of the concepts.

My concerns are valid, according to this paper by Daniel M. Oppenheimer – “Consequences of Erudite Vernacular Utilized Irrespective of Necessity: Problems with Using Long Words Needlessly”. Essentially, as the level of complexity increases the text becomes harder to understand and less likely to be accepted by the reader.

Oppenheimer’s emphasis here is on ‘needlessly’ complex words.

…there are many times when a long word is appropriate, because it is more precise or concise…
…select the most appropriate word for a given argument such that decreases in fluency are overridden by increases by other positive attributes…

What are your thoughts?

Are precision and brevity (conciseness) more important than first impressions in this case?
Does the original set of principles serve the needs of newcomers adequately, lessening the need for the new version to be approachable?

 
4 Comments

Posted by on October 7, 2014 in Software Testing

 

Tags: , ,

Let’s Test Oz 2014 – Day 1

15 Sep

It’s 11PM and day 1 hasn’t finished yet, there are activities still happening around the hotel. This is really a different style of conference than I’m used to. All participants stay at the same hotel where the keynotes, breakout sessions and test lab take place, so the conference doesn’t actually end at a specific time each night.

I arrived this morning in the picturesque Blue Mountains outside of Sydney. I was excited, nervous, intimidated, keen, and relieved to have made it here. There was a contingent of testers already here and the conferring had begun before the conference’s opening keynote. About 5 minutes after entering the hotel, most thoughts of intimidation and nervousness were gone. This is where I was meant to be. I mingled and promoted twitter as a means for learning more about the context-driven testing community.

The opening keynote was delivered by James Bach:

How do I know I am context-driven?

What followed was a wealth of information based on years of research, hands-on experience and debates, condensed into a one-hour talk. This was an excellent summary of what it means to be context-driven, from one of the founders of the context-driven testing community. There was one slide in particular which I could’ve questioned James on for another hour, called Implicit principles of the Context-Driven School of Testing. This slide contains ideas which could fill a book, if James had time to write another book.. I think I need to read some more books before I can fully fathom the concepts presented! The beauty of this conference is that I have many opportunities to find James in the hotel and ask about this slide in more detail, ask for advice on recommended further reading, and discuss testing in depth.

As usual, I found James’ talk personally motivating and compelling. Specifically, the categorisation of levels of involvement in the context-driven community felt to me like a call to action and I’ve treated it as such. I will be actively ensuring that I fall into the Committed Practitioner category, and probably also Committed Student as I love to keep learning.

These are some of my favourite quotes from James‘ keynote speech:

“A professional society of people trying to be the best they can be” – Yes! This is a growing crowd which I’m proud to be a part of.

“Respect and nurture people who are learning” – James noted the Greeting vs. Challenging methods of introducing testers to the context-driven community, and his tendency towards the latter. There are other leaders in the test community who patiently introduce those who are newly discovering professional testing approaches.

“The product is a solution. If the problem isn’t solved, the product doesn’t work”. Hallelujah!

“Testing has parallels with martial arts, you need to practise, and EARN respect” – I’m paraphrasing here.

“Context-driven testers must be able to answer the question ‘What’s your approach to testing?'” – Oops. I have some homework to do.

“Instead of best-practice, say a practice. For example, we use a practice for defect management.” That’s a huge improvement! This would make the software world a better place 🙂

“You don’t need to promise, quantify or lie. See Keith Klain for more information.” I’m paraphrasing again. This was another call to action for me.

In conclusion…

This is what I got from the FIRST HOUR of this 3 day conference. I’m glad I made the effort to attend, I’d have deeply regretted missing out.

Stay tuned, more to come. But not tonight 🙂

 
3 Comments

Posted by on September 15, 2014 in Software Testing

 

Tags: , ,

← Older posts
Newer posts →
 
%d bloggers like this: