How your personal understanding of “Quality” influences your way of testing

I want to offer you a hypothesis, a proposition that I don’t have proof for. But I believe I’m on the right way.

“Your personal definition  of quality influences the way you test.”

Quality is a seven-letter word. I think that’s the only statement that we can commonly agree on. Quality is a very complex matter and I don’t want to go too deep into detail on that this time.

To make my point I’ll base this post on three common defintions of quality, that your personal understanding might be more or less based on.

Q1: “Quality is conformance to requirements.” – Philip B. Crosby

Q2: “Quality is value to someone who matters at some point in time.” – Jerry Weinberg, extended by James Bach, Michael Bolton and Anne-Marie Charett

Q3: “Quality is fitness for use.” – Joseph M. Juran

I want to describe the type of testers that I see behind those definitions. This is based on my mind model, my experience of 16 years and the people I work with and talk to. I know that this number is way too small to be representative. But maybe it is helpful for some, at least it helps me to understand people and their motivations, and their way of working, how projects are set up and so on.

Type “Quality is conformance to requirements.”

Frameworks like iSTQB and PMBoK are based on variations of Q1. And this totally makes sense from their point of view. That way testing is plannable and controllable, and you might even come up with metrics to make quality measurable, based on that definition. It’s a good way to define price tags for testing, which enables schemes like outsourcing testing.
The other definitions would not be able to serve that purpose in a similar way.

Testers with an understanding of quality like Q1 might tend towards test cases and test coverage metrics based on requirements. Waterfall-like approaches (including those covered as Agile) make them feel comfortable and standard test case deduction methods are their daily tools.

Projects and general product development with very specific lists of requirements, standards to adhere to and processes to follow would need a quality understanding like this.
Also people with a background in model-based testing might feel comfortable with this definition.
For concrete implementation projects they need to rely on customers that are able to express their requirements.

Type “Quality is value to someone who matters at some point in time.”

Proper Exploratory Testing in my opinion tends to be more based on definitions similar to Q2. They explore the system under test from different angles, and exercise it based on the findings that they evaluate most important.  Test reports should inform decisions and rather tell a story than produce numbers. They are aware that they are not the customer or end user of the system, but they try to resemble them as good as possible.
I could imagine that people who see themself as context-driven testers might have a quality definition based on Q2.

They understand that context matters most and the usefulness can change over time. This type of tester in my opinion is more aware of potential risks and trying to detect potential risks is more important than covering every edge case possible. They also understand that quality is different for different stakeholders and users.

Type “Quality is fitness for use.”

Approaches like observation, monitoring, testing in production, data analytics and alike belong more to quality definitions like Q3. They want to see that the implementation works in the field. Testing before releasing to production is mostly used to minimize risks of massive failure. Carefully releasing software into the wild and rolling back in case of failure is their preferred way of checking code changes.

I’d assume a trend towards incorporating parts of definition Q2 in their understanding of quality.

Background story

I came to this hypothesis recently when I had to change teams in the same context and room from a customizing implementation team, to the product development team. I did not feel too well in the beginning after the change and I wanted to understand why. It’s not the people or the domain. It’s the way of working or rather the definition of quality you need to apply that defines the context. In my case I had to switch from a Q2-context to a Q1-context. Guess, what I prefer.

Summary

I believe that your personal definition of quality is a fundamental piece of the puzzle how you subconsciously work, how you test, how you design test strategies, how you’d set up a testing project and so forth.

Of course people can adapt to their current context and fulfill the requirements of the job, and do it good. But I assume they won’t feel as comfortable as they could. At least I do.

I need your help!

You made it this far, thanks for staying. I need your help! I would like to know if my hypothesis is worth following up on.
If you have a personal definition of quality, maybe it fits roughly to one of the three examples provided. And maybe you are aware of what kind of context you mostly enjoy working in.
Please let me know, if my generalized description above fits to your personal situation or not.
Thank you!

Advertisement

Introducing Grumplexity Theory

In close relation to Prof. Dave Snowden’s Cynefin framework I found out this week, that the model also fits very good to describe the states of grumpiness.

Being grumpy is a state of mind that I – and also other fellow testers, like my partner in grump, Del Dewar – have internalized. The reason for the grumpiness though is highly context-dependent and should at no time be underrated. The grumplexity model provides you a tool, to understand your own and others’ grumpiness a bit better.

When you enter a situation, you know the person is grumpy, but you have no idea why. You don’t know yet, how to deal with the situation, and if you should at all.

Sometimes the reason is quite obvious. The train didn’t come, it’s raining and there’s no cover. After the trigger has been removed, solved or vanished into thin air, the chances are good, that a piece of chocolate might help.
I call this the grumpvious mood. The half life is usually not very long, once the trigger and most consequences are gone or solved. The train finally came, you found shelter, your clothes start to dry again. A piece of chocolate could help.

Then we come to the situation where it’s not that simple. The trigger might be a bit in the past, the initial situation is already forgotten, so it seems. But real grumpsters don’t forget.
Let’s take a work example. Someone broke the build process, because they forgot to build it locally before checking in; for like the hundredth time. Then a few days after the last time that person broke the build chain, you see them check in again, without building it locally. You get grumpy, because you know of the apparent risk, and can’t believe that this person still hasn’t learnt from the past hundred times.
Nothing happened – yet – but you are grumpy already. I call this a grumplicated situation. Not directly apparent, but easy to explain. A whole bar of chocolate might help in that situation.

Now it get’s tricky. It’s for example about triggers that don’t seem to be qualified to make you grumpy in the first place or multiple triggers that seem independent and suddenly become dependent. For observers it’s even harder to understand what has happened to trigger that mood.
Let me give you two examples. When I come home tonight, I’ll have to help my wife bake some cake. Nothing bad about that, but actually I have to do the baking, because she broke her hand a few weeks back, and the reason for baking the cake is not for self-consumption, but for a promise my wife gave before her accident. And I’d rather go into my workshop to continue the reconstruction I started weeks ago, before my wife had her accident, and that didn’t make much progress. Yet, I’ll of course help her with the cake and get up early on a Saturday to deliver it. That is a grumplex situation, as multiple triggers come together. And it might leave the colleagues in wonder, why I’m going home grumpy on a Friday afternoon.
The other example for a grumplex situation, and the trigger that started this whole grumplexity idea, was an email I received recently with an actual positive content. The problem was the way that lead to the situation and my involvement in the process, and all the strings attached to this, that instantly made me heavily grumpy and brought up the urge to reply in a very unpolite manner. Grumpsters don’t forget easily. Now imagine the perplexity of the sender of the email, if they would have received the unpolite reply.
You better bring some more chocolate and a nice bottle (or two) of Spezi (my favorite drink), if you want to have a proper conversation with me in that situation.

And last but not least, there are the days where you are just batshit angry, just because. It takes some energy and lots of chocolate and Spezi to calm down and find the energy to analyze the situation to unscramble everything that goes wrong at the same time. That is when a bunch of triggers made an appointment to come up on the same day. Individually it might be able to handle them, but coming at you all together. Holy shit, you better duck.

Update: David Högberg sent me this link that describes how easy it is to reach batshit angry mode. hyperboleandahalf.blogspot.se/2010/05/sneaky…

And then there is special situation that I call the cliff of fake happiness. You try to keep your grumpiness to a minimum, and it seems nearly like you are smiling. But you should better wear a helmet near a grumpster, when they smile. Never feel safe in such a situation, the next moment, you don’t even know what hit you; an empty bottle of Spezi, a wrong meowing of the cat, push message on the smart phone. Boom!!!

This article is supposed to be fun to read in the first place, but it also could help you a bit with understanding the different domains of the original Cynefin model, and it helps you to understand why a grumpster is grumpy and that often a piece of chocolate is not enough and might not last long.

I want to thank Zeger Van Hese for adding the term grumplicated and giving me the spark to this.

State of Testing Survey 2018 is live

Yes, it’s this time of the year again. The new state of testing survey is online. And here is your chance to support it by submitting your input.

Just go to http://qablog.practitest.com/state-of-testing/ and fill out the survey. It doesn’t take long, and helps with additional information on the state of testing.

You want to know, how the outcome will look like? Well, there is always a lovely crafted report on the results, interpreting the input, analyzing trends and providing valuable feedback to the industry. Example: http://qablog.practitest.com/state-of-testing-2017-report/

Here is your chance to participate: http://qablog.practitest.com/state-of-testing/

Thank you for helping,

Patrick

Time to give something back…

It’s been a tough year for me with highs and lows. And to keep it short for a change, I’m coming right to the point.

With the amazing support of a great group of people, Kristine and I were able to launch the first TestBash Germany. And at the end, who would have thought in the beginning, we were also making some profit for the Ministry.

Apart from some TestBash tickets for myself and finally a Pro Dojo account, I gave most of my share to the scholarship program of the Ministry of Testing to do more great stuff and support the future generation of badass testers.

I won’t know who will benefit from this donation, and this is fine for me, as I prefer to stay in the background anyway. But I want to make one donation that is in my control. I got myself one ticket to give away for the Mother of all TestBashes in Brighton on March 16th 2018.

Please use the comments on this blog to apply yourself or suggest somebody else for the conference day ticket. Please give a good reason, why you or the person you suggest would deserve to visit TestBash Brighton 2018.

You can apply or suggest someone for the ticket until January, 7th 2018. I will decide who will get the ticket by January, 13th 2018.

What I want in return? Nothing. It would be great to see a blog post from that person’s TestBash experience, but you don’t have to. All I expect is that the person shows up and has a great day at TestBash Brighton.

Disclaimer: This is only the admission for the conference day of TestBash 2018 on March 16th in Brighton, UK. No travel or accommodation included. I decide who gets the free ticket.

If you don’t want to publicly share your story, why you think you deserve the ticket, you can share it with me at info (at) testpappy (dot) com.

UPDATE: Thanks to the amazing Danny Dainton and Matthew Parker who throw in an additional £150 to cover a good part of travel and accommodation costs.

Update: WE HAVE A WINNER

And the winner is… Samantha Flaherty.

A new hope…

Boy, that sounds like a pathetic title. But this is a personal story of being thankful, so yes, the title has a right to be pathetic.

When I joined QualityMinds last year I made the conscious decision to enter a consulting position. I knew that it’ll be part of my job to change projects from time to time, do different kinds of workshops, talk with potential clients, and so on.

Now it’s about time to change project for the first time. And I want to use that chance and look back at the last nine months, something I won’t probably do for the next changes, but my first assignment was in several ways special to me. And it’s is also a way to say “Thank you!” to the project team.

As some of you might know, I left a place last year that would not immediately come into mind when you would try to describe “a great place to work”. So you might get a feeling why that project was so special to me, even if others might say, where’s the big deal, that’s business as usual for me. Oh lucky you!

Early September 2016 I joined the team responsible for the content management system behind a large telecommunication company’s online platform. I was the first “professional” tester to join the team, before me usually interns and team newbies did most of the testing. I was the only full-time tester together with two part-time interns, who already started shifting towards developer positions, in a SCRUM team with 12 developers. Bad ratio? Not at all, not in that team.

“Everybody can test!” was one of the team’s mottos, and it still is. Two special moments are attached to that motto. The first one was when taking over a work package that was new for the whole team and that blocked nearly all my capacity in the beginning. I got immediate help from three developers until the backlog was down to near zero. I was astonished and impressed.
After about half a year I was worried that the team got a bit too dependent on me, as when the word “testing” was mentioned usually all eyes were on me. So when going on vacation for one and a half weeks, I was worried how the SCRUM board would look like after my return. Well, the board was pretty empty, except the tasks that were currently in development. All stories that were finished during my absence were tested. My stomach feeling was gladly totally wrong.

When I arrived the automation suite with only about a hundred simple test cases was based on Protractor, despite the fact that the portal was not an AngularJS application. The tests were written around the actual Protractor features to simply use the provided webdriver. It was a nightmare to use and debug. When I asked if it would be possible to replace “that thing” with something in Java, that would be better to debug, and written in a language the whole team understood, I was only asked to put all pros and cons in a story for the next estimation meeting. I was running against open doors. Once it was a bit quieter again, the story was up for implementation and I was the architect behind my second test automation framework, this time even seeing it to become reality. And the first time in years the UI automation suite status went to green.

And after nearly 14 years as a tester I made several experiences of automated tests finding regression bugs. I might be one of the bigger test automation skeptics, not against automation itself, but being careful to not trust automation too much. But this test framework and the test suite and the tools I wrote found several issues and prevented some nasty bugs from going to production. That is a new sight on test automation for me.

The project itself has a very technical nature. So for the first time in my career I was not testing business processes. I was testing technical features. And that was a new experience for me, as I not only needed to know as much as possible about the whole system and how it worked together, but more often than not, I was looking into Java code, checking what had been done, trying to understand the impact and evolving risks right there from the code base. This also helped me to regain some basic Java knowledge.

There was also a rather boring part of my job, checking design changes that came in via merge request. It was not the most challenging work I have done in my IT-life, but it hugely influenced the way of looking at the web portal. Issues that were not even worth entering into the bug tracking system in my old company, were being fixed usually within a few days or faster. And we are talking mostly about aesthetic changes. That is something people care for here.

The Product Owner is doing a really good job as well. Never before did I have a product owner who stood for a clean line in the product. And hell, does she know that system. When I thought I tested nearly everything that a story could impact, she would find two or three more scenarios I never even have heard of. And still I was able to test with such a good quality, that she trusted my opinion as she did with the whole team.

Blaming or finger pointing is non-existent inside this team. Even my usual self-blame for bugs that are found during PO acceptance or in production were always generalized; nobody else working on the ticket found them, too, so let’s fix it and learn from it.

This team is great, doing a really good job. They have team spirit, always helping each other, encouraging to learn, and open for sharing. They have reached a SCRUM maturity level that impressed me from the day I was interviewed for the team. All things I haven’t experienced first-hand before in my rather silo-ed endeavors.

I brought my part to the table to help this team, but I also got a big amount back in the past 9 months. I learned a whole heap from this team. I learned stuff and experienced something, that 10 months ago I thought to be strange stories, fiction, special situations, or whatever reason you might find to not believe something’s existence.

Soon it’s time for a new challenge and finding out how I can help there.
Team CMS, thank you!

Who are these ominous “testers”?

There is a huge shallow agreement in my part of the galaxy. It’s the term “tester”.

I know quite a lot of people who declare themselves as “tester”, independent of what it says on their business card, contract or signature. Test Analyst, Test Specialist, Test Lead, Test Manager, Software Engineer in Test, Test Consultant, to name just a few of the classics. Most of them simply call themselves “tester”. Yet everybody has a very different understanding of his daily business.

There is a role in many projects defined as “the tester”. And this is the description from my understanding how non-testers usually see this role.
A tester is the person responsible for creating test cases, test scripts, test charters, or whatever you call the plan of what you want or need to test. This person is then responsible for the actual performance of testing, doing regression testing and/or writing, adapting or extending test scripts. And of course reporting (providing information) on what they have done and found, be it counting entities of test artifacts, writing reports, filling dashboards, and filing bug reports in whatever way is appropriate for the project. That’s usually about it.

But hold on, reality isn’t that easy. Many of the people I know who call themselves “testers” do way more.

Consultants – Asking questions is what you could do all day long. Why are testers asking questions? To improve their understanding of the system (product, project, company, etc.) It’s to analyze risks, and sometimes – in forms the remind of Socratic Questioning – trying to help others to understand things better.

Project Management and Coordination – Testing – still way too often – is near the end of the software development life cycle. Mostly it’s about managing your own work, but too often that has influence on others. So testers end up juggling things around to improve efficiency and effectivity of a project to deliver faster or on time.

Developers – Automation in Testing is one of the terms I like most, that describes it as a whole. There are not only automated regression test suites, testers using or writing tools to monitor log files, create or maintain test data, manage deployments, and so on. Many testers might not be more skilled than the average script kiddie, but that’s okay. It helps to do the job. Others are creating test frameworks with gigantic test suites with hundreds or thousands of tests.
And also if you help with code reviews

Quality Coaches – Testers often help when there is a lack of understanding in what quality is and what aspects of quality are most important for the product at hand. Too often testers are called “quality assurance” and are responsible that a product “with high quality” will be delivered. But a tester, in his key role, is not changing anything in the product. But with this add-on task a tester can do a great deal to help build a high quality product, not only when it’s too late.

Process Optimization – I know many testers who don’t like inefficient processes, and in the average software development project there are many processes and many need adaption and tuning. Often it’s the testers who take over that job to achieve better processes. Why? Because a good tester is involved somehow in nearly every process there is in a software development project, that’s why.

System Thinkers – Testers often play a central role, don’t have split responsibilities, but need to know everything about a product, they are involved in many aspects of product design, requirements engineering, and running the product on test environments. All that comes with improved knowledge about motivations, actors, flows and stocks. Used wisely it will help in many of the other “jobs” a tester takes over.

Product Designers – Testers are often the first users of a product and play an important role influencing the product design to improve usability and user experience.

Data Analysts – Testers want to understand how the product is used in production, what errors happen in production, what typical user flows are, and so on, to improve their own testing efforts or to re-prioritize tests.

Requirements Engineers – Testers help to write and improve requirements by adding testable acceptance criteria, analyze risks, dependencies, and other influences. Or they ask questions to sharpen the understanding of requirements.

Operations and test environment coordination – Many testers are responsible for their own test environments, so they have to set up the environment, configure the tools you need accordingly, set up databases, deploy the product itself, and run it. You have to monitor your environment and take care for it. Then there are the test devices, from different browsers to huge collections of mobile devices or whatever you are working with.

Process Owner and Maintainers – very often testers own the bug tracking process, many times it doesn’t stop there. I’ve found myself more than once in the position to maintain all the process templates, and so are others. You don’t have to own a process to maintain it’s artifacts. But the influence you have when doing that is often tremendous.

Coaching – When there are new people coming into the team, I know from several places where the testers are responsible for introducing them to the product. Because they often have the best knowledge about the product and how it’s used.
Of course there are these modern approaches where testers even coach developers how to improve their testing.

Communication – Testers should be masters of communication. Testers talk with analysts, requirement engineers, developers, administrators, managers, support people, customers, and so on. And everybody uses a different language. The only one who usually adapts is the tester involved.

Decision Makers – I know that the core role of a tester is to provide information to others to make informed decisions. But all to often the testers get the role to make a decision if the product is ready for delivery or not. Might it be for blaming reasons or trust into the person who has seen the product in detail as it is now, there are many more.
In addition my point on this matter is, that a tester makes lots of decisions every day how to test the system, which bugs to report, how to prioritize things, and so on. All influence the outcome of the project. Too often we are not aware of that.

Psychologists – Testers are everywhere in a project and they speak with people. So the tester is often in there to listen to developers ranting about requirements, managers about customers, and so on. Testers just happen to be there, and when you are good in Communication, you are good in listening. So, you get that job as well.

Product Owners – I know of testers who take a mixed role of PO and tester, I know POs who are especially good at testing, I know of POs who don’t find someone else to help out on vacation, but simply assign the role to the tester, usually when there is trust involved.

And the list goes on… and this makes it so difficult to compare two testers. In the job ads you will mostly find descriptions of the core tasks a tester should do. And managers think that testers are interchangeable. Nobody speaks of the other activities I listed here, some silently expect it, some have no clue that that is what a good tester does. Oh, I could tell you some stories…

When you meet a tester, this person is all of this above to certain degrees. It’s not how testers are seen by others, nor paid. But that’s what many of the people who call themselves “tester” that I know do, and it’s what makes them get up in the morning and be the best tester they can be.

Most of the people that I know who call themselves “tester” are genuine, enthusiastic and love what they are doing, from 9-5 and often also from 5-9. No matter what others think. Often they stand in the background, take the blame, fill up empty roles, do the work nobody else wants to do, and serve the team, to make the project a better place and help to make the product a better one than in the delivery before. And in their spare time they help to improve the world of testing and make it a better place and share information and experiences.

And good testers always know where their towel is! Happy Towel Day!

PS: If you don’t believe me, look at the variety of topics at many software testing conferences. It’s usually not about writing test cases.

The 99 second talk I didn’t do – “We are all Humpty Dumpty”

At the end of every TestBash conference there are the infamous 99 second talks. A chance for everyone in the audience who wants to deliver a message to get on stage. For many it’s their first time on stage and a spark for taking the next step.

As I planned for my third 99 second talk, I wanted a message that I can deliver in 60-70 seconds, so that I have time to speak slow and not hustle, like the last times. And I wanted to finish well in time to not loose my conclusion at the end to the nasty sound from Mark’s mobile. And as I’m way more nervous on stage for a 99 second talk than for a normal talk, this time I even prepared my text in advance in writing, not only in my mind. And thanks to the always amazing Damian Synadinos, who generously spent some of his time, I even got an ad-hoc review.

But as I went through it again and again, I always ended up between 90 and 95 seconds. So I decided to skip it and post it here instead. So, this is what I wanted to deliver on stage in Brighton, but didn’t have the guts to do it:

I want to talk a minute about semantics – the meaning of words.
In “Through the Looking Glass” by Lewis Carroll, Humpty Dumpty tells Alice about “glory”, but Alice is confused and doesn’t understand. Alice asks Humpty Dumpty: “I don’t know what you mean by ‘glory'”
Humpty Dumpty smiled “Of course you don’t—till I tell you. When I use a word it means just what I choose it to mean—neither more nor less.”
Sounds familiar?
Closed communication systems like software development teams tend to use words as they like. Which is okay for me, as long as you have a shared understanding in the team. But think about someone new joining the team. Is there ambiguity in your glossary? Is there room for misunderstanding or shallow agreement?

Even if you don’t like discussing about semantics, because you think it’s a waste of time. Try to do it every now and then, try it for yourself if you want. For more complex statements I like to use a technique my good friend Damian Synadinos showed me which he calls “Definition Dissection”. Just take a statement and look up every word in the dictionary. Try to continue by looking up the words that come up in the definitions you found and rearrange them. Continue until you’re happy with the precision.

In my experience, way too often, especially if English isn’t your first language, you will find out that the meaning of the words you use don’t match the intention you use them for.

So you can continue to use them, but being aware that they are imprecise or even wrong. Which will help you when you have discussions with outsiders.

Or you can start to exchange the words you use to get more precision in your everyday language.

It’s the awareness that counts!

And at this point I want to express my deep respect for all that got up on stage and delivered their message! In time or not.

State of Testing Survey 2017

It’s this time of the year again.
PractiTest and TeaTime with Testers are again collecting information about the current state of the testing industry and the trends going on and coming up. They are doing this now for the fourth time.

The survey doesn’t take long, and they are looking for feedback from all levels of the industry. From newbie to senior. And of course from all corners of the Earth.

The result is a well-crafted analysis comparing the current state with the past years to see trends in testing evolve. (see last years report) Last year the survey had over 1000 participants, and we need more to get an even better picture.

So please, take some minutes of your valuable time and participate in the State of Testing survey 2017. And if you can, please also share the link with your colleagues and friends in the industry.

Take the survey here!

Thanks for your help

Patrick

Network Console for your test scripts

As exploratory tester I love my browsers’ dev tools. Especially since I’m currently working on a CMS project, analyzing the available elements and their styles is what I’m doing every day.

When it comes to automating, Selenium Webdriver is capable of locating the elements of the DOM tree, interacting with them and even reading out there styles for verification and many other actions. But there is a tool in the toolbox that can also come in handy in automation that Selenium doesn’t cover (afaik): the network console! Selenium itself cannot capture what is going on when the browser captures its often 100+ files for one site from the web. The Webdriver “only” deals with the results.

For writing a simple check script I looked into this “problem” and found a very easy solution for Python that I want to show you. It’s by using the Browsermob Proxy. Just download and unzip the proxy to a folder reachable by your automation script and start coding.

Firing up the proxy:
# Start Proxy Server
from browsermobproxy import Server

server = Server("../browsermob-proxy-2.1.2/bin/browsermob-proxy")
server.start()
proxy = server.create_proxy()

print("Proxy-Port: {}".format(proxy.port))

# Start Webdriver
from selenium import webdriver
co = webdriver.ChromeOptions()
co.add_argument('--proxy-server={host}:{port}'.format(host='localhost', port=proxy.port))

driver = webdriver.Chrome(executable_path = "../drivers/chromedriver", chrome_options=co)

Now you have a running Webdriver that can collect information in HAR format. Let’s call a website and record the network traffic.

# Create HAR and get website
proxy.new_har("testpappy")
driver.get("https://testpappy.wordpress.com")

Now you have all the information that usually your browser’s network console provides in this HAR entity. So let’s find out, which files get loaded, how fast that was, and how big the files are.

# Analyze traffic by e.g. URL, time and size
for ent in proxy.har['log']['entries']:
    print(ent['request']['url'])
    print("{} ms".format(ent['time']))
    print("{} kB".format(round((ent['response']['bodySize'] + ent['response']['headersSize'])/1024, 2)))

Don’t forget to clean up after you.
# Shut down Proxy and Webdriver
server.stop()
driver.quit()

The output is now a long list of entries looking something like this:

https://testpappy.wordpress.com/
1103 ms
129.46 kB

Now let your imagination run and think of what you could track and analyze for your project with that simple tool? Maybe a basic performance monitoring?

If you come up with something cool, let us all know by adding it to the comments here. Thanks!

The code used here is using Python 3.5 and the latest Chrome webdriver as of Dec. 30, 2016.

2016 – What a year…

2016 was a year with many highlights for me. And for those who know me a bit longer, the years before had way more lowlights than highlights, so 2016 really was a change for the better.

It started with the intention to finally look for a new job. And in March I had the first contact with a small test consulting company called QualityMinds in Munich, with a lot more to follow.

End of March I was speaking for the first time at a conference. And what a conference it was. TestBash Brighton! In front of nearly 300 people in the Corn Exchange was a fantastic experience.
Great thing was also that my wife and daughter joined me afterwards and we enjoyed a wonderful week in England.

In May I held my first conference workshop at Let’s Test in Runö, Sweden. Also it was the first time I volunteered as facilitator, which was a good experience as well. And like the year before it was a place where I had the chance to meet some of the folks I met online for the first time.

The day before I went to Sweden I handed in my notice. I decided I had suffered enough.

On the off-testing side of my life my artisan work in 2016 was nearly non-existent as my main focus was on re-building the interior of the attic. The final touches were made end of August, just before starting at my new place. On my birthday in September my daughter started school, which started a whole new chapter for the family as well.

Back to testing. On September 1st I started at my new company, QualityMinds, a place that hired me for being me, as I found out only later. I’m part of a great team of engaged people; to be honest, for the first time in my work life.
After 6 days I also started my first project, and in a real SCRUM environment. To the day I’m still shell-shocked that SCRUM can actually work. After experiencing lots of suffering with trying to introduce a bit more agile ways of working at my last place, I actually saw SCRUM in action. What a wonderful way of working, and finally I understood lots of blogs and tweets from people working in such an environment. It is possible. But my experience also told me that not every place is ready for such a way of working. But I love it.

Thanks to fabulous Danny Dainton I was back at a TestBash in October, this time in Manchester and as an attendee, enjoying the show for 2.5 days. That’s also where we (Kristine and me, together with our team of Vera, Marcel and Daniel (in absence)) finally laid the foundation for TestBash Germany, which was publicly announced in December!

In November I was at my first client workshop with my boss, which was an interesting experience. And I’m looking forward to more experiences of that kind.

In 2016 so much happened, and it feels so much longer than one year. By now the first 8 months of the year at my last place are nearly forgotten and so much great happened that I can honestly say, 2016 was a really good year for me!

What will 2017 bring.

Well, my crystal ball is still in the repair shop, so I assume that 2017 will be busy. As my project contract has been extended, means I stay in this project for at least a few more months.

The year starts with the Dutch double-feature TestBash NL and DEWT #7 end of January. In March I’ll be at TestBash Brighton to learn more about the organization of a TestBash hands-on.

My QualityMinds team has set a couple of interesting goals, that will keep us also pretty busy besides our project work. And thanks to our wonderful learning coach Vera I’ll be busy on the QualityLearning side as well. Both helping colleagues to improve and learning lots myself.

The most part of the rest of the year will be busy with preparing, organizing and advertising the first ever TestBash Germany in my hometown Munich on October 6th, 2017.

I also want to work on a few topics to submit for conferences later in 2017 or early 2018.

In case I have some time to spare, I also volunteered for now three friends from the testing community to help review their books in progress, which I’m very much looking forward. And I wish all three of you the best of success in your writing efforts.

And then let’s see what else might come my way. In the end I am called Agile Tester, so let’s be agile!