That’s Cool!

Nothing like getting some praise for a tool you built to make your day a little brighter.  During scrum this morning some folks were talking about the status of a few bugs that were found that without it likely would not have unless those particular enterprises had been selected for testing with.

The tool is very simple in concept.  Get all of our client accounts into a ready state for each enterprise and then run a service against it to see what trades are generated.  Run this in 2 different environments and compare output.  This was a manual process that was very tedious to do through the UI, since every enterprise had to be logged into individually and the process and compare done by hand.

The output still has be analyzed by a person, but the because we were able to broaden the scope of the amount of datasets to work with the test team dug up some potentially gnarly bugs that in previous iterations may very well have gone to production.

So I got a warm fuzzy feeling, we found some good bugs, and I got a nice reminder that simple things still can add a lot of value.

Revival

I am going to be doing my best over the next few months to try to write a little more often here.  Of late I have been building functional automated smoke tests for our main products (UI based ouch…).  I have been learning more about our oldest product and getting involved in testing some user stories for it.

I also delivered a tool to exercise different versions of a WCF service and compare the output. That was a satisfying project since the I was able to automate a compare activity that was previously through the UI on a per client basis and now could be done by a tool per client or for all of our clients.  This took a very tedious process and gave us the ability to  increase our coverage across client data sets significantly.  The first impressions and feedback I got from that were very positive and I am looking forward to other projects like this.

A Work in Progress

I am starting my 5th month in my new job.  The good news is that I am still really enjoying myself.  I like the people that I am working with.  It feels good to get up and come into the office and know that my contributions are valued.

I have had two main responsibilities that have taken up most of my time lately.  One is continuing to understand our products.  The other is to help come to a recommendation on a test tool/framework that can be used going forward for test automation efforts.

Our initial automation efforts are going to focus on doing web UI automation to build a regression test suit.  Yep, that means UI automation with all of the challenges that represents.  I go into this well aware of the challenges that this presents.  One of the reasons that we are working from this approach is that there is not a particularly accessible API and the presentation layer and business layer are rather somewhat intertwined.

I was given the requirements of needing to support record and play back with an underlying framework that would allow us to code tests as well.  I was not looking to do code generation from the tool but to be able to either write tests and reusable page elements against tests and use the Record and Playback capabilities to have other members of the test team engaged in the test automation process.

I looked at a number of tools and we finally settled on Telerik’s Test Studio product.  For the time being we settled on a single license.  We went this route for a couple reasons.  The cost of entry was pretty low (not free but low).  The record and playback capabilities are very robust and in functions on top of a well constructed test framework (WebAii which is free) that can be extended.  There are also some very cool performance tools built into the tool that hopefully will prove to be useful going forward.

One of the more interesting capabilities of the tool that I hope to be able to make use of as I am laying down a foundation is the ability to reuse other tests inside of larger test tests.  I am currently planning on seeing how robust the record and playback tool is since I am able to lay down tests much quicker this way than even writing a bunch of pages classes with all of the controls and actions.  My goal is to make the test in step chunks small enough and reusable enough that it becomes a fairly simple matter of putting together the individual steps into a larger test block and be able to use those as building blocks for the rest of the team.

I am also hoping to be able to use the record and playback tool for some record and dispose type of automation that might be used for functional acceptance tests that can be developed in conjunction with out SMEs and used by the developers to figure out if their work meets the minimum level of functionality to turn over to the test team.

The real question then becomes what does the maintenance of that collection look like.  Will this be a stop gap as I am rolling my own automation using the WebAii framework?  Time will tell on that one.

The Indispensable Individual

There is always that person that seems to knows how every things works.  They are the go to person for questions about how things work.  Things always seem to be easier for everyone around when that person is there and can help to uncover the hidden nuggets.  It may be because that individual has been around for an extended period of time and just learned everything, or perhaps they are the original author.    It also may be simply this person is so good you can just able to do more or some combination of all those items noted.  This can be great WHEN THE PERSON IS THERE.  I find this a dangerous habit that many teams seem to fall into.

I was reminded of this again just recently when a developer took several weeks of in the middle of developing a new module for one of my companies products.  Vacation – no problem everyone should take one.  The really problem was he was the only developer working on this module.  It was a challenging module and he was doing a great job of juggling all the different rules and parts tat went into it.  This meant that in the time he was gone no progress was made towards completing it.  We continued to test but the bits got rather stale after a while.  When there were questions about why features were implemented in a particular manner the questions simply were tabled for when so and so returned. 

This sort of situation bothers me for several reasons.  The first is that I hate the idea of the bulk of the knowledge every being locked up in anyone persons head.  It makes the team and not to mention the company far to dependent on that individual.  There is also the problem of developing the habit of “just ask Joe..” instead of really understanding why a system works.  It can make other people lazy about their approach to solving problems.

I also think there is a danger of letting this happen to yourself in a larger organization.  It may make it difficult for a person who is considered indispensible in their current role to be promoted or have the ability to move into a different sort of role.  A different sort of pigeon holing happens because you as a person are to valuable to allow to move on.

So how do you try to avoid this?  Here is what I try to do for myself.  Share information.  As much as possible make sure tat your  team members know what you are doing and why.  Share responsibility for tasks.  This can be done verbally, in a written format etc.  Try to ensure that you have overlap in knowledge and responsibility with folks who might be building your products.   Really it comes down t effective communication.  Easier said than done.

Healing up

I had neck surgery several weeks ago, which limited my keyboard time.  I unfortunately had no buffer of blog posts.  I have a few in progress so more random thoughts soon.

 

The Tester Make Up

Within the first few days of the new Software Testing site on stackexchange being opened to a public beta a question was posted as to what makes up a great test team member.  I snapped off a couple top of the head thoughts on what I thought make up a quality tester and came up with the following.

• Testing aptitude
• Willingness to ask questions
• Ability to negotiate
• Technical ability (reading and writing code)
• Strong communication skills.
• Curiosity
• A bit of a stubborn streak.

Overall the post seemed to generate some interesting comments and a number of up votes.  I thought I might take some time and go into detail on each of the points.

Testing aptitude – This is the ability to break down an application into is discrete parts understand how to test it.  This includes the and understanding of testing techniques such as boundary conditions, state conditions, the happy path and other techniques.  This includes knowing how to apply those techniques to a variety of situations and applications.  To me this also encompasses what I would call a nose for bugs.  There have  been a number of people that I have worked with in my career who I can put in front of nearly any app and given a bit of time they will find an issue.

Willingness to ask questions – I want a tester that will ask a question.  It is often in the process of asking questions that logic holes are uncovered and a shared understanding can be reached.  Some of my best work has been done simple having a dialogue with a developer about why they chose to do things a particular way and to find out if they had kept particular conditions in mind.

Ability to negotiate – It is important that you know how to negotiate.  To be able to argue for some things and know when you are better off when to just let them go.

Technical Ability – More and more I think this is an important skill for a tester to have.  I am not saying they need to be a rock star programmer.  If they are more to the good.  I do think that a decent understanding of programming concepts such as data types, data structures, and logic controls can help make a tester more effective.  For any testing working on data driven applications a good grasp of SQL is necessary  as well.

Communications Skills – This is the ability to communicate through speech and writing.  Testers need to be able to write good bug reports, test plans and other documentation.  They also need to be able to clearly articulate points in meetings and in discussions with developers.

Curiosity -  I want a tester that asks “What would happen if?”  This is going to also be reflected often in a person who is interested in continuously learning.    These are the folks who are going to be pushing to improve their skills and gaining a full and deep understanding

A Bit of a Stubborn Streak – This was the one line that generated the most comments on the post.  The one that struck me was Joe Strazzere.   He commented: “Am I the only one who sees “stubborn” as not necessarily a positive thing?”   What I am looking for in this case is the willingness to fight for those important issues.  When there are problems and things are not going well the willingness to stick it out and see it through.  This sort of stubbornness may also be see as persistence and perseverance.  Stubbornness can be taken too far when you are not willing to move and adjust as needed.  The inability to change and adapt can be detrimental.   It is something of a balancing act.

That’s my take…what’s yours?

Here are a few other folks thoughs on what makes a tester:

• Alan Page – Tester DNA
• Catherine Powell – What Makes a good Tester

Digging In

I am a little over two weeks into my new role.  Like any new job at this point I have learned a lot of the basics about my new company.  Some of it is very mundane things like how long does it take to get into the office one the bus, where the bathrooms are and my coworkers names.   I am also starting to get a sense for what some the aspects of the job are REALLY going to be.

The test team has two groups each focused on part of our product line,  I am going to be a floater between both groups, though initially I am focused on learning one aspect of the product. I have jumped in to help get some testing done for a release that will be going on in the next week or so.  For me this means digging into any existing user documentation, reviewing the user stories and defects for the current release and getting up to speed fast enough on specific areas that I can tell if they are behaving the way they are supposed to.  To me the interesting thing that I bring to the table as an experienced tester is that I have been able to find several issues that are related to behaviors in various controls that interact with each other.  I also have the advantage of bringing fresh eyes to the product.

I am also beginning to identify different opportunities for automation.  This is going to be the other aspect of my role.  Scary as it may be I have more coding experience than a good chunk of the folks on the team, though it seems like there my be a more robust skill set there than I was lead to believe.

All in all lots to learn and plenty of opportunity to make some impact.