Posted by: Martijn de Vrieze | February 10, 2012

Work ethics – being professional?

No matter where I have worked I always believed, and still do, that I have a strong and sensible work ethic. I expect to have to work hard in order to learn new things and grow in my role. Sometimes working hard means traveling a lot, sometimes it involves working long hours or weekends without being paid extra for it. Quite often I have asked myself whether it is all worth it, generally speaking it always was.

I enjoy learning new things, new techniques or technologies. Learning means you need to invest in it, do something actively, like making an extra effort on top of your regular day-to-day life.

In return for making an extra effort, I generally get appreciation from my colleagues and customers and gain new insights and knowledge. On top of getting appreciation, I also get credits for wanting to go the extra mile, which results in goodwill from both customers and colleagues and strengthens my reputation as a professional.

Of course I too complain about things. Obviously there are things I would like to see done differently in my work. However I try to take the active approach to introduce the improvements and make life easier for all those involved.

I truly believe that in a professional working environment it is not a lot to ask people who complain – and rightly so – about things they consider wrong or up for improvement to be constructive and try to change these things, look for solutions rather than keep whining. Quite often however, when you ask the complaining people what are they planning to do to make things change, silence is the answer.

I understand that not everyone has the same drive for his work, some people rolled into a profession by accident and are not motivated to grow their, work related, knowledge and just work to make a living. They, hopefully, have something else that gives meaning to what they do and which motivates and inspires them everyday. Personally, I enjoy my job. I like testing, I like finding solutions and moving  software testing to the next level, I enjoy solving testing problems and get satisfaction from deep diving into software testing theories and challenges. I also really enjoy spending time with my family and friends, but that does not make them mutually exclusive in my view. Just as I invest in friendships and my relationship with my wife and family, I invest in my relationship with my employer and my customer.

In my professional life I try to address things I do not like or think could be better (at least in my opinion). This is why it still surprises me that quite often I run into people who are not happy with a lot of things, but when you ask them what do they propose to do about it you get no answer.

Example: as a consultant I do not have a lot of direct contact with my employer, ergo, communications between my employer and myself (and my colleagues) is not always as supple and swift as one (and the company) would like. Since I am generally at a customer site I have to read emails from my work in the evenings and weekend. We use quite some online, or cloud-based, tools to make sure we stay in touch, such as Dropbox and LinkedIn. So on my personal smartphone I make sure I have the LinkedIn app up and running so I can keep in touch with what is happening “back in the office”, even during weekends or when at a customer site where I have no access to anything but the systems we’re working on and with (bank-like institutions usually lock off their network so you also cannot get to the outside, and rightfully so).

To make all of this even easier we now have received a smartphone. Not exactly the one I would have preferred, but hey, who am I to complain about an iPhone? I had to configure the mail on it, install a few apps on it, but I now have a fully mobile miniature office with me. My employer pays for the bandwidth I use on the phone so no added costs to me, just added ways to communicate with the “home front” be it my employer, my colleagues, my assignment or my family and friends.

You’d think wonderful inventions like this make life easier for those who do not regularly read their company email or never participate in a discussion on LinkedIn. However instead it raises even more questions and reservations, such as “am I required to configure email on the phone?”, “why wasn’t this done for me already?”, “do you now expect me to read my email in the evenings?”.

Am I crazy to enjoy my work and wanting to go that extra step, if reading your email indeed should be considered an extra step? I think I am the normal one and those moaning and complaining are the crazies, but once you start noticing that a majority of the people around you are crazy, it makes you reconsider. At least it did for me.

I started to wonder whether it is normal that I feel connected to my work and to my employer, that I like responding to questions, statements or comments posted on forums, that I do read my email at the most improbable times, that I do not mind driving 400 km’s to go to my colleagues on the other side of the country to talk to them about software testing and things that keep my mind occupied.

I still believe I am the normal one, just a normal person part of a minority with strong work ethics.

Posted by: Martijn de Vrieze | February 9, 2012

Are we afraid of test automation?

After having spent the last 9 months working on a test automation implementation for a team I am not running myself I have started to wonder what are the main success factors for test automation, besides the obvious: achieving the goal you set out in the first place?

One of the main factors that will help test automation be a success in your organisation is to not consider test automation a goal, but use it as a means to achieve a goal. The goal should not be something like “have x% of regression automated”, your goal should be something in which test automation can be a means to achieve this goal, for example help free up time for the testers to focus on important things rather than having to spend most of their time in regression testing.

Another very important thing to keep in mind in implementing test automation is that you need to keep a sharp eye out for trying to automate everything. Technically it may be possible, but it is hardly ever a good idea to want to automate everything. Quite some things require human intervention or human interpretation and cannot be simply made into a Boolean (which is what test automation is in the end, something is either true or false).

Look & feel testing, or validating, should in most cases not be automated for example. This for the simple reason that, despite it being possible, will more often than not raise either false positives or more likely, false negatives. Since these tests often require some form of image recognition and comparison a change of screen resolution or a small CSS change (font difference for example) will make the test fail, resulting in either maintenance or tests being made redundant.

For me however, the main show of success is that the automated tests are actually used and maintained actively.

Having a test automation framework and relying on it to do its job is not good enough. Just like every other software automated tests also want some TLC or at least some attention and maintenance.

Something that is still often seen in test automation is that the tests run but with non-determinate errors, in other words errors that are not really due to the testcases but are also definitely not a bug in the system under test.

If you show some tender love and care to your automation suite, these errors will be spotted, investigated and fixed. More often however these errors will be spotted, someone will “quickly” attempt to fix it and fail, after which the “constantly failing test” will be deemed useless and switched off.
Besides non-determinate errors there is another thing I have seen happen a lot in the past.

Some automation engineers spend a lot of time and efforts building a solid framework with clean and clear reporting. They add a lot of test cases, connect the setup to a continuous integration environment and make sure that they keep all tests working and running.
They then go ahead building more and more tests, adding all kinds of nice new tests and possibilities. What gets forgotten often however, is to involve the rest of the department, they do not show and tell to the (manual?) testers, they do not share with the developers. So the developers use their own unit tests for themselves and if they do some functional testing they do it manually and sloppily. The (manual) testers go about their usual business of testing the software, as they have always done. Not considering that a lot of the test automation suite they can use and abuse to make their life easier. They will spend time on data seeding, manually. They will spend time on look and feel verification on several browsers, manually.

All this time the developers and (manual) testers could have been using the automation framework and the existing tests in it to make their life a lot easier.

While writing this down it starts sounding silly to me and unlikely that it happens, yet I have seen this happen time and time again. What is it that makes developers but especially testers afraid of hesitant to use automated tests?
I love using test automation to make my life easier when doing manual testing, despite having an very strong disliking for writing code.

Test automation should be seen as a tool, it is there to make life a hell of a lot easier. It cannot replace manual testing, but it can take all the repetitiveness and tediousness of manual testing away, it can help you get an idea of what kind of state a system is in before you even start testing, but it can also help you, a lot, in getting the system in all kinds of states!

Posted by: Martijn de Vrieze | October 27, 2011

Where are the technically inclined testers?

–Edit–

This would have been better had it been called something towards “Where are the technically curious testers” as Anna Baik pointed out. The wording is not perfect.

//Edit//

Over the years I have worked with a whole range of testers, both functional and technical, who have shown different levels of comfort with the technology under test. Some were good, some were great and others I simply never want to work with ever again. The latter ones, to me, are a problem we are currently facing in software testing. There seem to be too many software testers with a lack of understanding how software is actually built, how the internals of a program work.

I have never understood how one can be working in technology, or to be more specific in information technology and not have at least a base grip on how things you are supposed to test work? Even when you are purely focussed on functional testing, I really do not understand how you can not grasp the basics this entire industry is based on.

How come that even now, when it is becoming more and more clear that software testing is an important specialisation within the IT industry we still see a lot of testers with no technical knowledge what so ever in this industry? I realize that historically there was the idea that “anyone can be a software tester”.  I am just not convinced that statement still holds true.

Take for example a building inspector, that is also a tester of sorts, no? He verifies whether all the rules have been followed of proper architecture, the design has been implemented as promised etc. Imagine you are having your own house constructed and this building inspector comes by. You put your hopes on this person to validate that your house is what you want it to be: warm, safe and as you requested.

This building inspector, upon arriving, grabs his excel sheet with the requirements for the house and checks the ones he can verify, without needing any knowledge of architecture or constructing a house for that matter. He then gives you this checklist and tells you he has functionally covered all things of your house.

Considering that you live in an area with lots of snowfall in winter you ask this person whether the roof can manage with a load of snow on it in winter and the heating will not collapse under the strain of having to heat the entire house in a snow-storm.

He says: I don’t know, I am not an architect nor a construction worker, I am merely the building inspector. I just go through this list of things I need to check, why would I know anything about building a roof for a house or what the heating can take? You should probably ask the construction workers what they think.

Would this give you faith in his verdict that the house is indeed what you wanted?

I believe not, yet this is a practice that i see happening fairly often in software testing. So where does it still go wrong in software testing? How come there is still this tendency to believe there is no need for understanding software when you test it?

How often do you see the same bug coming by when testing an application, once you see a bug more than once, in a very similar form, you should be able to come up with the idea that there might be an underlying issue going on. Instead what I  often see is that for every occurrence a new bug is created in the bugtracker. To understand that there quite likely is one underlying problem, the tester doesn’t need to know how to program, you should however have a basic idea of how a program is (or should be) built up and if you are not certain whether it indeed might be one and the same issue in the code, how about talking to the developer?

When exchanging ideas and thoughts with other testers on twitter and forums etc I quite often see an amazing lack of knowledge in this area. To make things even worse, a fair share of testers seems to have a degree (bachelor or master) in computer science yet have no clue what, for example, a regular expression is. Is it just me, or is this indeed a worrying thing? When reading through the Computer Science curriculum of an average university here in the Netherlands, I do see all kinds of interesting subjects and descriptions that would lead me to believe basic programming is part of what you get taught, however when talking to the graduates that end up in software testing I see nothing of that knowledge.

Where are the technically strong testers? The ones that can have a discussion with developers about how the structure of a program was setup, who can tell a developer that the SQL query he wrote is extremely inefficient? I know I see some of them online, these are the testers I enjoy following on twitter and on blogs, but there must be more than these happy and noisy few. Where are they hiding? In my experience there are not enough of them, at least not in the Netherlands.

– Edit–

There is a nice article dealing with similar questions and frustrations on testnieuws.nl: http://www.testnieuws.nl/2011/06/06/tester-praat-ook-eens-met-een-ontwikkelaar/ (sorry, it is in Dutch, if you do want to attempt have a look at the google-translated version)

 

–Edit 03/11/2011 –

Really nice to read Elisabeth Hendrikson’s article on a similar subject, but from a different point of view: http://testobsessed.com/blog/2010/10/20/testers-code/

I am sad to see though that there are people commenting on her article and are calling QTP and especially Selenium basically record/playback tools. If you have ever used either you know that QTP is a hell of a lot more than just record playback and Selenium is clearly NOT a record playback tool (unless you mean the Selenium IDE rather than the entire toolset of Selenium.

 

 

 

Over the last 3 years I have continually been amazed when watching our son learn new skills. It seems to come so natural to kids, learning. They go about it with extreme ease and are absolutely not dissuaded by initial failure, or even by repeated failure, in stead, they change their approach and try again, but now from a different angle or point of view (usually literally a different angle or point of view).

This has kept me thinking,  why is it so difficult for adults to learn something new?

Experiential learning

Experiential Learning Model

Kids have a big advantage when trying to learn things, they (often) look at them for the very first time. This helps them to not worry about what it is supposed to do, but to instead figure out what it does do. Whether it is the intended function or not, the child learns what the object can and cannot do in a rapid and fun way.

Whenever us adults encounter something new we always will try to draw from the past, look for something that may have been similar and go forward based on assumptions rather than intuition. In quite a few things it helps, but in as many things I also believes it hampers us. Most adults have a form of built-in “best practices” which they will use when they encounter something new (as described in the concept of experiential learning).

So how can we, as software testers try to not use our default boxed-in thinking? Is there a way to break through the barriers experience builds and look at something as if you see this truly for the first time?

One way I try to ensure I do not get blocked by my knowledge when starting on a new piece of software is by exploring it as I believe my child would do it. Rather than guess what it is supposed to do I try to figure out what I can do with it.

Fairly soon however, I tend to run into the feeling I have seen something like it before, or the feeling of recognizing a pattern which then triggers all kinds of things I have learned in the past. So, how do you get past this? Or should you want to get past it?

The fact that our mind works based on boxes seems a limiting factor, but apparently these boxes do come fairly natural for the human mind. One way I try to use for the so called “thinking outside of the box” is to expand the boxes in my head to contain several different boxes.

In the example above, where I start recognizing a pattern or have the feeling I know what I am looking at, I try to combine the two feelings, or hunches, and through that push my mind into a whole new trail of thought, thus breaking out of the original boxes, and shoving all of that into a bigger one. On top of that I try to change the context in which I know these patterns, transplant the feeling to my current situation and see how this could apply here, since I have to deal with a different situation, with different circumstances; different data, different programming language, different developers and designers, quite likely a totally different objective of the software I am looking at etc.

There have been all kinds of studies and theories that should help one think outside of the box, but what seems to work for me is a combination of things:

  • try to apply knowledge I gain from reading books (and I read a fair amount) into a practical situation
  • try to combine the new experience and the “learned” responses into its own, separate context of the here and now (e.g. the context in which I am currently working)
  • try to find several points of recognition or deja-vu if you will, and mash these ideas together into a whole new thing, within the current context
  • and to top this all of: I try to think of what my son would do to figure out what this object (or software) can do for him.
This approach may not always be the most efficient or for that matter the most effective, but it does ensure that whenever I try to learn something new, new software when testing it for example, that I expand my horizons yet a bit more beyond just this object under investigation. I quite often even get new insights into how I could have tackled a previous problem more effectively as well. Which then gets stored in memory and at some point gets reused yet again.
The vicious circle of learning is great, and finding new ways to expand your knowledge and the ways of learning new things is even greater!
Posted by: Martijn de Vrieze | October 12, 2011

Getting a junior up to speed on test automation with FitNesse

Last week we had the privilege of having a junior test engineer working with us for a few days to see what it would take to get him fully up and running with test automation as we have implemented it at our customer.

Our intern, as I introduced him at our client, has a solid eduction in Civil Engineering and lacked any kind of knowledge of test automation or writing software. He has just finished his first project as a junior tester, which was testing a data warehouse migration.

Motivation

What drove us to try this was simple: curiosity and questioning of my personal coaching and explaining skills. Thus far I have had the feeling that I somewhat failed in showing how easy the setup of FitNesse with our custom fixture is to anyone who is not part of a management group. With this engineer I wanted to confirm whether this was me not explaining things clearly or people not following what I explained properly (e.g. me explaining things in the wrong wording).

Starting point

Our “intern”, as said, has little or no hard IT knowledge. He is one of the junior test engineers that came out of the group of trainees Polteq Test Services hired at the beginning of the year. With his degree in civil engineering he is for sure a smart guy, but considering he has never been on the construction side of software, he had some ways to go.

Considering that he had no prior knowledge of either the FitNesse/WebDriver setup nor the environment we are working on, we started with a morning session of explaining and overflowing him with information by answering the following questions.

  • What do the applications under test do?
  • What is the service oriented architecture underneath?
  • How does this all tie together into what you see when you start using the applications?
  • What is FitNesse?
  • What is WebDriver?
  • How do these two work together?
  • What is the architecture of the Fixture?
  • What is a fixture and how does that relate to WebDriver and FitNesse?

After this session he was set to work with FitNesse. The main thing that slowed him down somewhat was the getting used to the syntax as we force it through the use of our custom Slim fixture. At this point he still had only a minor base knowledge of what the application under test does or is supposed to do. Based on the existing functional testcases he managed to fairly rapidly automate a set of testcases, or more specifically, transform them from base functional descriptions into Slim tables which will run successfully as a test.

The result

Writing the testcases was easy work for him, he picked up the base syntax really fast and managed to pump out some 15 working tests in a very short period. It was time for a bit of a challenge.

Considering he had never written a line of code in his life I thought we might as well check to see how fast he would pick up writing a simple wrapper in C# around an Advanced Search page, which includes a set of dropdowns, textfields, radiobuttons and checkboxes which can be manipulated along with a submit and reset button.

The first two methods we wrote out together, him typing while I was explaining what is what. Why do you want the method to be public, why does it need to be a bool, what are arguments and how do you deal with that in FitNesse.  Where do you find the Identifier of the object you are trying to get the wrapper around, what do you do when there is no ID, how do you extract the xpath and make that work well. Once we got through the first few methods I set him at work to figure it out for himself.

The first question I received after a while was: ok, so now I’m done writing these things out in code, then what? How can I now see this working in FitNesse? After making an extremely feeble attempt at explaining what compiling is and deciding to just show where the compile button is, he then set to work to verify in FitNesse that his code indeed is capable of reaching and manipulating every element on the search page and getting to a sensible search result.

Take away

What did I learn in this week? For starters that when coached close enough it is very simple to get someone without experience up and running with FitNesse the way we set it up, which is good to have confirmed again, since that was the aim.

Another thing we have seen proven is that adding new methods to the fixture is dead-simple, changing the ID’s of objects on the pages should not lead to too much hassle maintaining the fixture. For the Base class quite some developer knowledge is still required, but once that part is standing expanding the testable part can be done with some of coaching. So technically we would need to start handing over maintenance of our Base classes to someone within Development and hand off maintaining the rest of the fixture to someone within the test teams here.

One of the things we might consider in making maintenance easier could be to split the leaf-nodes, e.g. the page level, off from the base and helper classes in order for these two to be complete independent of one another, which means that the developer can add and refactor in the base, without breaking the current functionality, once done refactoring or adding stuff, the new DLL can be used to talk to.

Maybe I am getting carried away with making things modular now though…

Overall, good to see our idea of making things easy to transfer indeed seem to work well, although I do not want to say that this one week was enough to hand over everything of course!

Based on this week I have started to explain things to the test team internally, which does seem to indeed be an improvement. I do believe that having this week gave me a chance to play around with the ways in which I explain stuff, especially on a non-technical level.

Erwin, thanks for being here and listening to my explanations, following instructions and asking questions! It was a joy working with you this week.

Older Posts »

Categories

Follow

Get every new post delivered to your Inbox.

Join 200 other followers