It’s only a job title… right?

I have recently been putting quite a bit of thought into job titles and have come to somewhat of an impasse. Recently I said I would help revamp a job posting for the test coop position, and one of the road blocks that I have hit is what to put in the title. The posting is for the waterloo coop system and it would be an understatement to say that the system is less than ideal. There are two things about it that make a title so important:

1. The time window that a job posting is up is about 3 days and there are LOTS of jobs, enough that you cannot see them all in that short time period, thus the job title has to catch a potential coops attention if you want lots of applicants.
2. The only real way to do a search on the jobs is by job title; it is not possible to search what the actual posting says, thus the only way to try and pinpoint jobs you might want is by title

Well it’s just a title right? It shouldn’t be that hard to make one that is appealing; in most cases that might be true, but because this is a test position it is a little more difficult; unfortunately, especially in the coop program, Test (or QA) has a very bad rep, and rightfully so in some cases. I personally have worked a terrible Test coop job, we were glorified typing monkeys, I was given a very rigid test plan to go through that consisted of about 200 tests, and by the end I had done some of them up to 30-40 times! Furthermore creativity was also pretty much discouraged, going outside of our area was frowned upon and to top it off developers didn’t think much of testers, that basically saw us as a walking, typing monkey. So because of this experience I can sympathize with those who fear that testing job, because it is difficult to know if it will be good or not.

In getting back to the job title, I was considering if there was a way to put less emphasis on test in the title, so that people will actually look further into the job, and not disregard it simply based on the fact that the word test is in the title. I thought about it for a while, and decided that there would be no real way to represent this job properly without having test in the title, but I did come up with an idea that would actually represent the job better and might appeal to more people,

Software Testing and Development Specialist

Now the specialist might not be in the final rendition, but I think the development is actually an important thing to put in the title. The job definitely has room for development, and it something that seems to interest a lot of people and it demonstrates that the job is multi faceted.

I was contemplating putting this up or not, simply because it’s a very specific problem for me, but I figured heh why not!

An annoying problem can often be seen as an interesting challenge, as with many things in life, it’s all about perception.

Giving and Accepting Advice… it shouldn’t be this hard, should it?

I have had thoughts on this topic for a while, and have had them surface recently because I have been reading the book “The Secrets of Consulting” by Gerald Weinberg and am about 50 pages into it. The book, as the title suggests is about consulting, which is in effect giving advice to people who say that they want. The reason I highlight say, is because the book discusses that even if someone says that they want your advice they rarely actually want it. I am going to go into my thoughts on firstly receiving advice, then I will go into actually giving it.

Receiving Advice
I have two questions to pose first, think about these two questions for a bit:

How often have you reacted adversely to someone trying to help you?
How often have you reacted adversely to someone giving advice?

From my personal experience I would rarely have an adverse reaction if someone is trying to help me, but as soon as someone offers advice, of any kind, I sometimes become defensive, discredit what they are saying or simply ask myself ‘why should they know better than I do?’. It is an interesting occurrence since the difference between the two is very minor. When someone gives advice, are they not trying to help you?

Maybe the difference is that if someone offers to help you, thats all it is help. But when someone gives you advice, perhaps you are admitting to yourself that someone else knows more than you, that they know better than you. I think that that is exactly where the problem lies, just because someone gives you advice on something, it does not mean that they necessarily know better.

Since I have had these feelings of defensive towards receiving advice, I have actively tried to be receptive to all advice, because it can never hurt to hear someone’s advice, the worst case scenario, it is not good advice and you choose to ignore it. I really feel that your attitude to receiving advice is what really matters, so to try to be more receptive to advice, I actively try to listen and be open to any advice people are willing to offer, and then if it does turn out that I feel it is not pertinent or good advice, I simply file it away and do not act on it, as stated above hearing the advice cannot hurt.

Giving Advice
I wrote a little more than expected on receiving advice, so I will only state the most important thing I have learned about giving advice, something that my dad actually taught me: Always ask if someone wants your advice before giving it. I always ask someone, “would you like advice” before giving any, and will actually not proceed to give them any if they say no. That is actually the most difficult part, not giving advice when you want to, but it is important to know unwanted advice will usually have a neutral or negative impact. Furthermore if someone refuses your advice, it feels a bit like a personal insult, like they think you do not know what you are talking about; that is another thing that is difficult to get over, but is still very important, often times someone not wanting advice has very little to do with you specifically, often people want to work through things on their own.

There you have it, a few thoughts on receiving and giving advice. This is definitely a topic I am looking to expand on and these are just some first thoughts.

Advice, good or bad, should always be heard but need not be acted on.
–Steve Swanson

Bugs in the Wild: WordPress Total Views

There was a bug that I noticed today (as well as in the past few months) right here in wordpress. There seems to be an issue with the ‘Best Day’ and ‘Total view’ count on the blog stats page.

As can be seen in the attached picture, it says that my best day was ‘ Saturday September 23rd 2006′. This is impossible since I did not start this blog until September 2007. Furthermore the Total view count is terribly low, it is marked as 35, when I know for a fact I have many times received 35 views in a single day.

I find it odd that this bug has been present for about 2 months or so now. The problem is intermittent though. I have seen days were it actually has been fixed and does display the correct numbers. I also am very curious as to how they calculate those numbers, because all of the information is available from different sources. There is a graph that displays page views per day and there is also a section where an actual count is given per post that you have made. It seems odd to me that these functions work properly but the one mentioned above does not. It just shows that because one similar feature works does not necessarily mean that all the related others will.

–Steve

PS: I have done a little research and it appears tickets have been opened to let wordpress know of the issue.

The Search for Perfection and the Fear That Motivates it.

It has been a while since my last post. This was a combination of two things, firstly I had a busy few weeks in my personal life, but secondly because of the recent increase in traffic I have been feeling like I want to make a really good post, something really insightful, therefore when I would get ideas for posts, I would question them… ‘is this really good enough to put up’, and I would often answer no. In this situation the search for perfection, was holding me back; so I began to consider where else this may apply to life, and realized it occurs in many areas.

I began to look at the reasons behind why I wanted a perfect post and came to the realization that the real root motivation was fear; fear of posting something that would have people say ‘wow that was a waste of my time, why did I read that?’, or that it would be ‘worse’ then my other posts; thus I was somewhat unable to act because of these feelings of fear. I began to think how the fear was a fear of not being good enough, that the next post I made would be inadequate. This lead me to think of where specific examples when fear has held me back in the past and the present. Here are a few quick examples:

In the fall I played a few indoor soccer games with my two friends, I wasnt officially on the team, but I filled in whenever they knew they were going to be shorthanded. It was a fairly skilled team, so I felt nervous about my own skill level because I didnt want to disappoint my friends or let down the team. This nervousness lead to fear of making mistakes and being inadequate. Once this fear was in place I never made any risky plays, over thought my moves, and was generally nervous. All these things led to me playing worse then I usually would, I was acting reserved, holding back, which when playing a quick game like indoor soccer is detrimental to over all play. So it was the fear of inadequacy that held me back, if I had been confident in my abilities and not worried I would have played much better.

Another example is from my classroom experiences at University. There are many times when I will know the answer to questions, or at least be 90% sure of the answer, and yet not answer it, because of the fear of being wrong.

I got a little off topic, but its an interesting area to explore, all of the things that we are missing out on because we fear doing them. Maybe its that project at work that you are not sure you can tackle, or that girl in your book club that you’ve had your eye on for a while, it could really be anything. The longer we let fear hold us back, the longer we will be thinking of what could be, instead of living in that reality. I am getting a little philosophical here, but my point is that if something is really worth pursuing, there is most likely a chance that failure will ensue. These chances have to be taken, its the life experience (whether it is a success or a failure) that we get out of these events that really make a difference, and help to shape our futures.

If it is worth doing, it most certainly is worth failing at. I try not to think of the failures that might happen, but instead think of the lessons taht I’ll learn (even in failure), I also think of the the rewards I’ll receive in success.

–Steve

Failure is but another vessel where knowledge can flow.

Trouble with compatability…

So recently I found a bug in windows. So I thought ‘cool, I’ll take some screen capture of it and then upload it to youtube and write a blog post about it.’ So I get two of these three things done properly; and based on the title a bet you can assume which one I couldn’t get to function!

Firstly I’ll describe the bug. The bug occurs when editing the details of a music file. If you select one of the text boxes and scroll the mouse wheel the text box floats as you scroll. THis clearly is not designed functionality.

So my first step was to get the screen capture and export it into a .avi file. I use software meant for screen capture (I am avoiding the name because I don’t want to bring negative attention to a product that in general I really enjoy) to get a nice 30 second video of the bug. When exporting to a .avi I fiddle with the settings slightly so the file is a reasonable 2 Mb size (instead of the original 170 Mbs!). I view the video file everything seems to be fine, the video looks ok and the framerate seems good as well.

From here I start writing a post on this blog to let the world know of this grievous error (heh heh)! I get my post all set and save it before posting it and surf over to youTube to upload my video (as this blog does not accept video uploads).

Here is where the trouble begins. I try to upload my screen captured .avi file, and everything seems to be going fine but when I watch the video it is only one second long! It was like watching the bug in fast motion, all of the 30 seconds where compressed into one.

I have a theory of why this happened; I am ‘fairly’ confident that it was because the frame rate I chose to take the video in was different then from what youTube desired. What I found odd about this whole thing was that the video plays fine in Winamp, windows media player and VLC player but once its uploaded to youTube it ends up being one second long!

My contemplation here lies with the following question: ‘Is this user error, or a bug in the youTube software?’.

Frankly I am not sure. I feel that I am pretty computer savvy but I have had no end of trouble with this youtube upload. I could, with reasonable certainty, identify what the issue was, but for some reason I could not seem to fix it (I tried a few times). Am I at fault and should be more aware of the .avi I exported or should youTube’s software be able to rectify the disparities between the video I am giving and what it expects.

Just something to think about while I get some new video capturing software and see if I can get that bug uploaded!
–Steve

Discussions and arguments are not about who is right or wrong; they are about having new ideas, thoughts and expanding the mind.

What’s in a Name?

Why does there need to be a name for all different kinds of testing. Why do you need to identify if one case is a boundary case and another is not. There are clearly a class of test areas that could be considered ‘boundary tests’ but why need the name? I it as a convention that just exists for the sake of cross communication between people. IE so when you say boundary testing, I know what you are talking about, just as in we can identify that a shoe is a shoe and communicate that to someone else.

Other then for that reason I do not see much use for it; what’s the point of having names for things? To me having a name limits what you see and limits creativity. If you feel that certain things are not to be considered boundary tests, then maybe you won’t do them. Maybe you are pigeon holing yourself into constraints that do not need to be there. Furthermore it seems that everyone has a different idea of what a ‘boundary’ test is. IF that is the case then why even have a name for it? I looked online to see if I could get some definitions and here is what I hit:
“Boundary testing has definition A testing strategy based on testing at the boundaries of equivalence classes - since this is where most errors occur.”

So from that you need to look up equivalence classes:
“Equivalence Class: A testing strategy based on determining the possible equivalence classes and creating a test case for each”

Again this begs the question of what they define as an equivalence class. Found another website that defines things as such:
• Case #1: domain of data is an interval
– Class(es) of valid values
– Class of invalid values (out of boundary, inf. and sup.)
– Class of non member (for numerical values, characters are non members)

So from this it is a little clearer as to what a formal definition of what a ‘boundary’ test can be considered. Its a way to test such that elements that ‘would’ have the same outcome are not retested, thereby identifying equivalence classes and tests the elements that would yield only different results Here is an example to illustrate a simple case of equivalence cases and boundary conditions.

Example: There is a field that is only suppose to be able to take in Unsigned short ints (programmed in c++ MIN: 0 Max: 65535).
In this case I see the equivalence class here to be {1 - 65534}. It would be expected that these values would yield ok results. This would leave the ‘boundary’ cases to test, in this case {0, 65535} I see those as the working boundaries… and then there are the non working boundaries {-1, 65536, ‘A’, ü}. That class covers the min, the max, a letter and a symbol. All of the rest of the possible entries could be lumped into another equivalence case of improper values {The Rest}

So from this example we can see two equivalence cases and 6 entries for boundary testing:

Equivalence cases:
————————-
Valid Values {1 to 65534}
Invalid Values {-Infity to -2, 65537 to infinity, all leters (but one), all symbols(but one)}

Boundary cases:
———————
Valid Boundary Values {0},{65535}
Invalid Boundary Values {-1}, {65536}, {A}, {ü}
So from this example there is now a better definition and hopefully leads to better understanding of boundaries and equivalence cases. So not that we have a sort of loose definition for boundary cases we can look at, well maybe a ’simple definition’ is a better term for that.

Going with this example I can already see places where I could have made a mistake, maybe something happens at -65536, maybe the numbers switch back over to 1? That kind of behaviour is not unheard of, but to me does not come up as what I would consider a ‘boundary’. This is what I was bringing up before, with pigeon holing yourself into a situation where you effectively have blinders on. When you come up with a definition, it becomes more difficult to look at anything outside of that definition, therefore soon as the definition is in place, that well might be all that you look at. I think that the idea of boundary testing is very important, but having a firm definition is not. Here is what I see boundary testing as:

The testing of conditions that YOU feel will cause problems. These feelings will more then likely be based on some sort of logic, but sometimes not. For example I was inputting values into this calendar and it was not clear what the boundary input was. So I just try some random year 1656; I get an error back stating dates for SQL must be between 1753 and 9999. Therefore I found the boundary pretty quickly by just putting in a random number, something that might not be done because there are guidelines to the boundary testing that you are doing.

To wrap things up a bit, boundary testing is an important concept, and should have some methodology to how it is done, but the more rigid the methodology and the more rigidly boundary testing is seen, the more likely it is that things are going to be missed, because once methodologies, and things in general are in place it is often difficult to look outside them.

–Steve

Post Script
-I know there are a lot of things that I am trying to get across here, any questions on anything are of course welcome
-I could quickly find what websites I grabbed the boundary test/equivalence case definitions from, I’ll update that when I find them

Positive Feedback - Thoughts

Assessing the Validity of and being able to accept Positive Feedback
—————————————————–

Maybe I am alone in this, but based on my observations of others I am guessing no, but I feel that it is difficult to accept positive feedback. Personally I find it pretty easy to accept negative feedback (if I ask for it). I analyze the feedback to see if I think the comment is valid, if I deem it valid then I go about doing my best to incorporate it into whatever activities it applies to. Accepting positive feedback is another matter; what do you say when someone praises you. On one hand it appears obvious; accept the feedback and thank them for it. But for some reason I have this gut instinct not to do that, as if if I do accept and acknowledge the feedback I am boasting, or something along those lines. When I do accept/acknowledge positive feedback I feel like I am saying ‘Ya I know, I AM that good’ or ‘I know I did an amazing job, so what?’, for some reason I feel as though accepting the feedback invalidates it. Again I feel as though this is a very incorrect feeling, but from what I have observed of people, how they get very awkward when someone compliments their work, I feel I am not alone in this. Therefore I feel like its worth delving into feedback and see what makes it so difficult to receive.

So continuing on to the accepting of positive feedback. I find that there is a huge difference between accepting feedback in a one on one situation then there is when in a group of people; I find the latter to be much more difficult. I feel that this goes back to my feeling of boastfulness when accepting the positive feedback. I cannot put my finger on why, but I feel that being a showoff or boastful in group settings give off a negative impression to your coworkers (or those around you). It may stem from my observations that people do not seem to like people who are conceited and always telling everyone how great they are. But from the other side, in life you have to look out for yourself, so should you not then tell people how good you are (if its true) and they do not seem to be noticing. Being humble is supposedly a good policy, but if you are humble all the time will you not then go unnoticed?

I also want to take a quick look at what I see as the different situations in which positive feedback is given:

There is the spontaneous(or immediate feedback) that is given right after something happens ie: (and excuse the sports analogy) hitting a home run, all your team mates would give you a high five (this is pretty much instantaneous feedback). I see this to a certain degree as the most genuine kind of feedback as they have no time to really think about, they just know that you did a good job, and really want to let you know that you did.

There is prompted feedback. This is a situation where you directly ask someone to give you feedback. In this case two things go through my mind. Firstly since it is prompted, how is one to know if the feedback is truthful; this thought gets validated one way or the other based on the trust you have in the other person. Along the lines of the if the feedback is true, is whether or not the person giving feedback would have given it without you prompting. This leads into my second thought, I start to wonder if this feedback would have been given without me prompting for it. For some reason I feel that prompting someone to give you feedback invalidates some of the meaning it has; for some reason feedback that is given naturally without asking feels more genuine.

There is also scheduled feedback. Scheduled feedback manifests itself, for example, in the form of a yearly performance review; it is feedback that has to be given. I feel this as the worst feedback of all to a certain extent, since in most cases people are forced to give both positive and negative feedback no matter what. Therefore despite the fact that they may have no real opinion one way or the other on you, they are forced to come up with someone. This really brings the validity question into focus; how valid can feedback be if it has to be given? I do see some benefits for this case; it forces the giver to put some thought into the feedback they give, therefore they may be able to think about and bring up points from a few months ago that would not have come up unless they had the time to think about it. But in playing devils advocate, if they really had to think to give you feedback is that really a good thing?

Beyond the situations there is also feedback given in a group vs. one on one. Personally, receiving feedback and acknowledging it accordingly is much easier one-one. When in a group I feel like when I am given positive feedback, EVERYONE ELSE is not getting that positive pat on the back, it is almost as though I feel bad that they are not being acknowledge. I am however aware of why I feel this way when I receive the feedback, it is because when others receive positive feedback in the group setting I at times feel the ‘How come I am not being acknowledged’ feeling. That is I think one of the trickiest part of giving feedback, not pissing anyone else off. You have to give it enough so that people stay motivated, but you have to make sure its done in a manner that doesn’t piss others off, because you also want them to do work.

I think the giving feedback is a whole other topic, so I will shy away from it for now, plus I think this has gotten a tad lengthy, so I am going to cut it for now. I plan on revisiting these ideas and refining them, but for now its enough just to put them to pen (so to speak).

–Steve

Testing is everywhere…

This will just be a quick one before I rush off to the gym, but today I was noticing how testing appears in one form or another in my daily life.

 An example today was when I was plugging in my ipod and hanging it over a towel rack. I was concerened that the cable would slip on the rack and the ipod would fall to the ground. So what did I do to make sure it wouldnt happen; I let it go a little bit with my hand other hand ready to catch it. This was to see how far it would fall when I let it go; or essentially a test (if anyone’s curious it didnt fall very far, and then I got on to thinking about static/kinetic friction but we won’t go there…)

 I just found it interesting how small things in life manifest themselves into situation where testing is required (that is if you want a good outcome = P ).

 –Steve

Dealing with Bugs…

Filing Bugs / Bug Scrubs
—————————-
I have been giving thought to how bug scrubs go and it seems like there is some room for improvement. From what I have seen bug scrubs are done every day and they last about an hour, and have ~4-5 people in them. Say at an average of 40$ an hour, it wastes about 1000 dollars a week (which I guess isnt terrible) but there are bug scrubs for each product, so say 3-4 prodcuts we are up to 4000 dollars a week, which equates to about 200K a year, now we are talkin! Other then the money this wastes TIME, time that could be spent testing, developing, getting the product out the door etc… It just seems that there is a more efficient way to go through bugs. So I gave it some thought and came up with a possible algorithm.

The plan I came up with is as follows:
——————————

At the beginning of the test cycle introduce a few key things. I am going over what to introduce and what I think that would accomplish

The Testers and developers should know each other.
–> Face to face communication(encourage through a meeting with all developers and testers) can save a lot of misunderstanding and time.
–> When people know who they are working with they are more likely to work harder (because they know what they are working for).
–> Might result in more collaboration and idea sharing. Also a better team environment.

Testers should also know what area each developer works on.
–> This will allow a tester to assign a bug to a certain developer, and skip the bug scrub step for that bug
–> Less bugs in bug scrubs means less wasted time.

The Developers should know the testers
–> If a tester files a bug that they think is by design, they can face to face with the tester to find out if that is correct or not
–> If there is a disagreement, it can be placed in with other cases to be scrubbed.

How to assign Priotity of Cases should be clear
–> If the priority of cases is clear, testers can assign priority on their own.
–> If the tester is not sure they can assign it to the developer and he can assign priority based on his thoughts
–> If the developer does not know, then it can go to the unscrubbed pile

Developers should be clear on what they desire in Bug reports
–>when are diags needed, when are stack traces needed, is a video always good?, should there always be screenshots?, what level of detail is needed?
–> This will allow for greater efficiency because no information will be missed (for example, I missed a stack trace that was needed once, simply because I didnt know I needed it)

 

 

I think that putting these processes in place could help do the following

–>Build a better sense of fellowship between developers and testers

–>More efficiency in bug resolution and bug scrubs

–>Less bugs to go through in bug scrubs

 

Any comments are always welcome

 

–Steve

Test Engineers

There is something strange about the position of test engineer. I prefer to not refer to them as QA, or anything along those lines because all other terms have a negative connotation to them. Walk into a class room of 3rd year engineering students and ask them what they think of QA (Quality Assurance, just in case someone didnt know, I personally thought that it was Question/Answer the first time I heard it), and you will most likely not get the most positive of responses. The issue is that there are many companies, and I mean a good 90% of them, that don’t treat testing properly, they use testers as glorified clicking monkeys and they basically make testing suck, thusly they end up giving testing a bad rap. I have talked to some people about what they think of ‘QA’ here are a few things I have heard/seen,

-It’s boring
-I never want to have to QA ever again [someone who had done it for four months]
-the ‘oh god no’ look
-anyone can do that

Now seeing as I am in a test engineering position it might seem odd that I am bringing these statements to the forefront, but there is a purpose to this. What I am trying to get at is that there needs to be a change to how Test Engineering is seen. Being a test engineer, or sign ‘QA’ engineer as some people refer to it, can be an very interesting and challenging job, but unfortunately, as mentioned above, most companies do not handle it properly and basically turn testing into a point and click game.

I am just going to go over a few points of how QA usually is versus how Test Engineering should be (and is in rare cases).

How QA Usually is
-Scripted Tests
-Following directions from those who have a poor opinion of testing
-Being seen as inferior to developers, so suggested improvements are ignored
-Long test cycles that lead to repetition
-Tests that are Easy as F, so it requires no thought or imagination

How Test Engineering Should be (and unfortuantely rarely is):
- Allow for imagination! This will more than not result in a majority of tests being unscripted. This doesnt mean be completely random, it is necessary to have structure to ensure that everything does get covered and to allow for metrics. [This is where sessions come in, but thats for a later post as its quite a large topic mainly because I think that sessions leave room for improvement]
-Mutual respect between the developers and testers. In general it seems that developers as well as the testers, dont work as well as they could together. The relationship between the developers and testers has to be good, everyone should be on the same team, and if you want to have a good company, has to be on the same team!
- Testing need a little Flavour. What I mean by this is a little variety, something different to do every once in a while, side projects and short testing cycles, this helps to dispell boredom, and thus improve productivity.
- Milestones and Goals are essential. Testing seems like an unsurmountable task, it seems to have no end. To a certain degree this is true, you could in theory test forever. This mindset is a dangerous one because once something could be done forever, I find that there is no drive to work very hard at it. Therefore it is essential to set Goals and milestones so that there is something to work toward, someway to measure your progress.

Its unfortunate that QA has made a bad rap for Test Engineering, but reputations can be changed. This is only an introductory post, and I am fully aware of the, shall we say, lack of flow to this post. This is my first go at it, and although no one forgets the first time, its rarely the best time. So look forward to more coherent and meaningful posts to come.

–Steve