Nov13

QA, Tester, What’s in a title

by Lyndon Vrooman on November 13, 2012 at 8:00 am
Posted In: Uncategorized

I find titles incredibly useful and useless at the same time.  This becomes even more apparent when looking in IT shops, especially the testers.

I find titles useful for classifying things and groups of things.  In regards to the workplace, and positions, the title helps to identify what job function the person (in theory) specializes in.  For example, when needing an application developed, my first though wouldn’t necessarily be the sales rep down the hall, but instead, a developer.  If I wanted to know what kinds of features our customers wanted, I would then probably visit the sales rep.

Now, in theory, this gets even more muddled when it comes to people who specialize in testing.  QA, Tester, SDET.  I’ve seen the three titles used interchangeably a number of times.  For the purpose of this post, I’m only going to be using QA and Tester however.

When I first started in testing, it seemed to be that most of the testers around were given the title QA.  As time went on, there was a push to have the QA’s re-titled to be testers.  I can remember having a discussion while in line for coffee with my lead about a years ago when he asked me where I stood on this discussion.  This was due to the fact that the newer IT divisions within our company were only hiring testers, not QA’s.  I had stated of course that I preferred tester, as it more accurately described what it was that I was doing in my role.

How times change.  Over the past couple of weeks, I’ve been taking a much closer look at what it is that I actually do at work.  One thing that really surprised me, is that I don’t seem to do a whole lot of testing any more.  I think that it would be safe to say that lately, I’ve been actually hands on keyboard testing for maybe 6-8 hours per week.  Some days, I spend my time writing test automation.  Ok, that’s a test activity.  Some days I spend my time participating in code reviews or doing a root cause analysis to find the source of a fault in the code. I guess that’s somewhat, maybe kind of related to testing.  There’s also days where I spend my entire day showing teams how systems integrate and working on solutions to these bugs.  Of course, it’s just scratching the surface, but, you get the idea.

When we look at these types of activities, they don’t outwardly have much to do with testing.  Instead, they seem to have much more to do with the whole quality process over all.

Do you find yourself in a similar situation?  Are you still passionate and dead set about what your title should be?  Does it really matter if you’re a Tester or a QA?  If my title was changed to Tester tomorrow and I was going to continue performing the same types of activities, I really wouldn’t mind.  For the moment however, I’ve realized that I’m happy with QA, and whatever each individual person happens to think that each letter stands for.

 Comment 
Mar07

My first experience with paired testing

by Lyndon Vrooman on March 7, 2012 at 6:55 pm
Posted In: Agile, exploratory testing, pairing, Testing, Testing with the team

Today I had my first experience with paired testing.  An old application had been transitioned to my team a little while ago, and a change was needed to it.  Unfortunately, the testing SME for this application is currently at home with her new expansion to the family.

As I’ve said before, at the moment, there are 2 testers on my team.  When we were first asked who would like to take this change, we were both rather apprehensive.  Neither of us had ever seen the application before, and the story cards made it seem rather daunting.  We decided then (a few weeks ago) that we would try pairing for it.  Neither of us had any experience with paired testing, so it would be a learning experience on multiple fronts.

Our real start was about a week ago when we met with the Business stakeholder.  (This change has actually been ready for quite some time, but not deployed due to other circumstances.  Due to compliance reasons that I won’t go into here, it also needed to be retested.  The application has been tested by IT as well as spent a number of months with UAT, the 2 users of the application.)  The stakeholder went over all of the changes with us in great detail and we both felt a sigh of relief that this wouldn’t be anywhere near as difficult as we had both had thought.

Today, we both had a little bit of time and decided that we would finally tackle this.  There were only 8 story cards, so we felt that half the day was acceptable.  Were we ever wrong!

The other tester decided to drive, while I played an observer role.  We would start off by going over the card, and then start looking into it.  We were able to bounce idea’s off of each other as to how to test it as well as how to interpret the results.  While she was driving, she would explain everything that she was doing, and I could chime in at any time.  Sometimes I would walk her through what I would like her to try and we could change what we were planning on doing on the fly.

After 2 hours, we had accumulated 4 bugs, and one question for further information.  We printed off the issues section of our session sheet and started to discuss if there was anything else that we could do.  Unfortunately, I had a meeting right after this, so she went to speak with our stakeholder about the bugs that we had found.

When I got back, I was in for a shock.  The stakeholder had answered our 1 question, saying that we got everything right, that 3 of our issues were minor and they weren’t concerned about them, but that one was an absolute show-stopper!

After the experience, we went back to our lead, and expressed our concern over the show stopper and the timeline that we had in hoping that this could make it production.  We also expressed how we felt about our first paired session.

 

What we learned from this:

1) Although we thought that this way would take longer, it actually took us less time that it would have if one of us was doing it alone.

2) This is a great creative process.  Being able to bounce idea’s off of people while losing zero ‘productivity’ is great.

3) This is a great way to learn how to compliment your current skillset as a tester.  You can quickly describe a technique to someone who is not familiar with it.

4) This is an amazing way to learn an application that you’ve never seen/tested before.

 

This was our first session doing this together, and as I said, we hope to experiment with this further in the future.  We both realize that this isn’t necessarily suited to every day testing (for the moment) in a sustainment environment, but now see value that we didn’t realize before.  I’m hoping to learn more in the near future.

If you’ve never tried paired testing before, I ask that you try, at least once.

 Comment 
Feb24

But my manager said no…

by Lyndon Vrooman on February 24, 2012 at 8:06 am
Posted In: Initiating change, Teamwork

How many times have you attempted to introduce change to your organization and failed.  If you care about the work that you do, it’s probably been quite a few times.  Unfortunately, it all comes down to how you present your case.

In this case, I’ll look at testing techniques.  Maybe you want to introduce test automation, or vulnerability scanning, or performance testing.  Many managers are thrilled at first at the thought of test automation.  It will free up their testers and maybe even free up some head count.  If done successfully, both of these assumptions are false.  Have you tried to implement test automation?  Did it fail?  Probably.

Maybe you’ve come back later on and said that you want to re-implement this.  Immediately, you get “No, we’ve tried this before and it didn’t work for us”.  Please understand, this does not mean absolutely not, it means “In the context that we understand it, we have tried, failed, and the risks of trying this again in the same context outweigh the benefits”.  You know what?  Their assumption makes perfect business sense, and I don’t blame them at all.

For starters, I hope that if you’re reading this,that you are passionate about the work that you do, and you are willing to invest some time into it.

1) Understand why they are saying no.  There’s probably reason for this.  If they’re not willing to give reasons, you may be barking up the wrong tree, or, you may be working for the wrong company.  Also start asking around to other people in your organization around this.  Start with anyone who has been involved in previous attempts, and start working up.  You will probably find people who are interested in this as well.  If you can find someone with influence within the organization with this outlook, great.  You may be able to use them to help champion the effort.

2) Start researching why other people/companies have failed at the same thing.  Was it due to lack of commitment from management?  What it implemented poorly?  Make notes of all of this, and for your own sake, write down where you found this information!!

3) Start looking at how you can address both your managers concerns, and the reasons why other people have failed.

4) Build out a proof of concept.  This doesn’t have to be full scale.  Importantly, you will probably not want to do this on company time if you do not have the blessing of your management team.  You will probably find more points of failure while doing this.  Make sure to note these as well and how you plan on compensating for them.  Also important, do occasional showcases for those who are sympathetic to your cause.  You may want to be careful with this step however.  If there are managers or influencers who are absolutely against this who know about it, they may try to stop you right where you are.

5) Build out a business case.  Why has this failed before in your organization?  Why has it failed in other organizations?  What can you do about it?  Include your proof of concept.  How do you think that you can make this work?

6) Present the business case to management.  If you found someone who was able to help you champion, or if you have influencers who are sympathetic, get them involved as well.  Be excited when you present.  If management does not hear some excitement from you, they will probably not be excited either and it will be hard to engage them.  Do not ask for this to be implemented.  Ask for an official proof of concept to be built out. 

7) Ask to be a part of this proof of concept.  With all of your research, you will probably help in this succeeding. 

8) Use it for a few months, and present your results to management.

 

I hope that this works for you.  Please understand that you may discover at any point during this process that this may not work in the context that you are attempting to propose.  That’s alright.  It let’s you know that that maybe this particular method isn’t for your organization, and allows you to think of new vectors, or, abandon the idea with the knowledge that it won’t work right now.  Keep all of your information.  These steps have worked well for me in the past.  It won’t necessarily work with managers who don’t care about how their team/department does.  I can happily say though that in the cases where I’ve made it to step 6, the number of time that I’ve been turned down is at a flat 0.

1 Comment
Feb22

But I just don’t have the time to do that…

by Lyndon Vrooman on February 22, 2012 at 7:42 am
Posted In: Automation, Testing, Time management

Yes, you will never be done testing. 

Are there techniques or tools that you would like to use in your testing but you don’t have the time?  If so (and it’s probably yes), why?

All of the testers in my department are proponents of using test automation for some of the important regression checks that would delay the deployment significantly if all done manually.  We’re all also normally asked, how long will it take you to test this/these feature(s).  Everyone seems afraid to add time to create test automation as it is normally the first thing to be cut and some in management see it as a waste of their testers’ time.  Have you given up on this too?  Why?

While on a coffee run with my lead a few months ago, we had a discussion about this.  One of the testers had said that he just didn’t have time to create any due to the amount of manual testing that he needed to do.  My lead was asking if I knew of any ways to make time for this.  My answer to him, “I always pad estimated effort for enough time to at least create happy path scenario’s and forget to mention it to you”.

He kind of laughed, said “good job”, and said that he had no problems with it as long as timelines were still being met.

Yes, there are cases when this can backfire on you if you’ve been flat out told not to do something, but, you need to learn to pick your battles, and know when not to be seen fighting them until you’ve already won. 

I’ve seen far too many people lately who are content to just sit down, do exactly what they’ve been told is expected of them, and then wonder why they aren’t happy in their current positions.

1 Comment
Feb20

Face to Face Fridays

by Lyndon Vrooman on February 20, 2012 at 11:41 am
Posted In: Initiating change, Relationships

As I’m writing this, I’m technically on vacation.  I realized today that I had forgotten to put my out of office on in Outlook.  As I was putting it on, I remembered the In Office auto-reply that a former manager used to put on every Friday.

“I am currently IN the office.  Welcome to Face to Face Fridays.  As part of my commitment to developing stronger relationships I will be returning your email with a face to face visit.”

I remember the first time that I saw this, I didn’t even read the body, only that it was an auto-response and expected to get an answer on the following Monday.  A few minutes later, the manager was sitting at my desk having a conversation with me around the email that I had sent.  The more and more I thought about it though, the more that I realized that it was a great idea.  I’ve realized this even more over the last year since taking on this role.  There are people that I talk to via email every week, in my building, and only a floor below mine that I’ve never actually met face to face.

For the people that I know, it’s fairly normal that when we send someone an email, that we walk over to the persons desk to have a conversation, or open a bridge if the person is in a different part of the city/country, unless an email is needed for compliance, etc.  But, other people that I don’t actually know, it remains as just email.

As the amount of email that I receive now is at a bearable amount, I’m thinking about trying this out for myself.  Probably starting out with one Friday a month, but, we’ll see.  Should be interesting.

Do you have any experience with this in a non-management role?  If so, let me know how it went, good or bad.

2 Comments