Challenges

Challenges

I had to do something the other day that I've never had to do. I turned down a job offer. Some background infomration might be necessary first to fully understand.

Last fall, I was informed that I would be moving from the domestic development group to the internation development group in late Winter. In the beginning of winter, I was given an assignment from our Implementation group to help them with their backlog. They were impressed with my work and offered me a temporary position with their group to help them decrease their backlog even further.

For the last two and a half months then, I've been augmenting our implementation staff with some of the work they have. Early on, I knew the work would lead to a job offer. In the end, there wasn't really a choice.

A lot of the work is technical in nature, but not very difficult. Most of the challenges that I was faced with in this posistion were not technical challenges, but social challenges.

Technical challenges are the challenges that occur in trying to get the technology to do what is necessary to complete the job at hand. This could as simple as knowing how to operate a lawn mower for a lawn care service, to using Outlook, Office, and other computer applications, all the way up to actually designing the software that others use.

Social challenges are the challenges that occur in working with others. Examples include trying to figure out what a person has asked of you, what it is that they really want accomplished, or how to pursuade them to do what you thing is best.

Each job presents Technical and Social challenges, but I am a person who thrives on the Technical challenges. In this, I had my answer. To be satisfied with my job, I need to have a job that presents me with Technical challenges that push my skills, and not just a job which utilizes my skills.

Weekly .Net Library Review 1: TimeZoneInfo and DateTimeOffset

Weekly .Net Library Review 1: TimeZoneInfo and DateTimeOffset

While on StackOverflow (www.stackoverflow.com), I ran across a link to this poster.

I know very few of the classes listed on the poster, but it occurred to me that I should strive to learn more of them, so in the style defined by Scott Hanseleman, I plan to investigate a different class or two available in the standard .Net library. In this first installment of many, I will go over two classes that were introduced in .NET 3.0, TimeZoneInfo and DateTimeOffset. Both of these classes can be found in the System Namespace.

TimeZoneInfo

TimeZoneInfo is similar to the TimeZone class. However unlike the TimeZone class, the TimeZoneInfo class provides many static methods, including GetSystemTimeZones(), which returns a collection containing a TimeZoneInfo object for each Time Zone that is configured on the local machine.

DateTimeOffset

The DateTimeOffset class is similar to the DateTime object that has been in present in .NET since 1.0. There are two distinctions. First, the DateTime has a Property called Kind, which returns an object of type DateTimeKind. DateTimeKind is an enum with three values, Utc, Local, and unspecified. This denotes what time zone the object is based on; UTC, Local, or an Unspecified time zone. DateTimeOffset is always based on UTC time, so this property is unnecessary. DateTimeOffset also contains an Offset property, which is an object of type TimeSpan. This object contains the Offset necessary to calculate the local time from the UTC time. For example, if the local time zone is Eastern Standard Time, then the offset will be -05:00:00.

Sample Code

Above is a screenshot of the application, with notes in red.

1 is a drop down box named cbTimeZones.

2 is a label named lblUTTime

3 is a label named lblTime

4 is a label named lblOffset

During initiailization, cbTimeZones is populated with the results of TimeZoneInfo.GetSystemTimeZones(). The selected Time Zone is set to the local time zone. A function called UpdateTime is called, which sets lblUTTime to the current UT Time, lblTime is set to the time in lblUTTime plus the offset, and lblOffset is set to the offset of the current selected Time Zone.

A DispatchTimer is created and set to trigger every second. When triggered, it calls a method which in turns calls UpdateTime().

The constructor looks like this:

        public TimeZoneUtil()
 
        {
 
            InitializeComponent();
 
 
            DateTimeOffset currentTime = DateTimeOffset.Now;
 
 
            foreach(TimeZoneInfo tzi in TimeZoneInfo.GetSystemTimeZones())
 
            {
 
                cbTimeZones.Items.Add(tzi);
 
                if (tzi.Equals(TimeZoneInfo.Local))
 
                {
 
                    cbTimeZones.SelectedItem = tzi;
 
                }
 
            }
 
 
            UpdateTime();
 
 
            timer = new DispatcherTimer();
 
            timer.Interval = TimeSpan.FromMilliseconds(1000);
 
            timer.Tick += new EventHandler(Timer_Tick);
 
            timer.Start();
 
        }
 

The TimerTick method is trivial and the UpdateTime method is straight forward:

        private void Timer_Tick(object sender, EventArgs e)
 
        {
 
            UpdateTime();
 
        }
 
 
        private void UpdateTime()
 
        {
 
            DateTimeOffset currentTime = DateTimeOffset.Now;
 
            TimeZoneInfo selectedTimeZone = (TimeZoneInfo)cbTimeZones.SelectedItem;
 
            TimeSpan selectedTimeZoneOffset = selectedTimeZone.GetUtcOffset(currentTime);
 
 
            lblTime.Content = currentTime.UtcDateTime.Add(selectedTimeZoneOffset).ToString();
 
            lblUTTime.Content = currentTime.UtcDateTime.ToString();
 
            lblOffset.Content = selectedTimeZone.GetUtcOffset(currentTime);
 
        }
 

The 4^th line of UpdateTime is the trickiest. Here we get the UTC time (A DateTime object) stored in the DateTimeOffset object and we add to it the offset from the currently selected TimeZoneInfo (A TimeSpan object). This gives us the current time in the selected time zone.

To get the current time, the easier approach would be to call LocalDateTime property on the DateTimeOffset object. I do not do that in this example, as I wanted to allow the user to select a time zone instead of always using the local time zone.

The right balance for a QA team

I've spent a year and a half working in QA, and I've spent about another year and a half in development. This gives me a unique perspective on QA teams. I recently realized that the manager of the QA team that is responsible for testing my teams software is operating under a dangerous assumption; that all QA engineers need to think like she does. What would happen if you had a QA team that all thought alike? You'd miss a bunch of bugs! There is no silver bullet for anything, and this applies to QA engineer traits.

I'm not the only one who feels this way. I ran across this idea first in the book Effective Software Testing: 50 specific Ways to Improve Your Testing by Elfriede Dustin. Item 14 deals directly with this. It states simply that QA team members need to complement each other.

Why is this the case? I think it is because humans working in groups work best when they complement each other. People are different and have different abilities. All of these abilities are beneficial in their own way. The same goes for a QA project.

Consider working on a large project with yourself. How do you know when you examined every angle? How hard would that be? Now consider working on a similar with someone who has a different personality than you. Might they find things that you did not initially consider? Would every angle be covered quicker? I think it would.

So, my point is, that a QA team needs to be balanced in order to achieve maximum efficiency and testing coverage. I feel different personalities complement each other, and allow QA to cover more ground. I feel the following personalities are needed on an effective QA team. However, it is possible for one person to have two hats; that would be perfectly normal.

QA veteran:

Let's face it, experience testing can be quite helpful. Veteran's understand a great deal about testing and can be a mentor to the rest of the team. Veteran's usually take a lead or guiding role on the team and are capable of testing covering a lot of tests quickly.

QA Newbie:

On the flip side of the coin, we have a Newbie. This is someone who is relatively new to testing and the product being tested. This is beneficial, as the newbie can be used to test old features and, in their testing, they may find things that others have overlooked. Newbies provide a fresh perspective and can be sculpted into one of the other types of QA engineers.

Tech Guru:

The tech Guru has a great deal of technical knowledge. A Tech Guru would be comfortable talking with IT or Development on highly technical issues. The Tech Guru is responsible for gray-box testing and thus would have a great understanding of how the product works under the hood. The Tech Guru, in addition to Development can identify areas of testing that are necessary or unnecessary.

Subject Matter Expert:

A subject matter expert is someone who may have (or did) use the product in a previous job. They understand the end user, because at some point, they either were the end user, potentially the end user, or worked very closely with the end user.

User Interface Expert:

The User Interface Expert knows how to tests user interfaces. Nearly every product that a QA team will test will have a User Interface. Since the user interface is the product to the client, ensuring that the UI meets usability standards that have been set out and is very familiar with different UIs.

Now, there are other types, but I feel that this list represents the most important QA personalities. In addition to these, you could have a Database Expert, Automated Tester, or a Performance Tester. However, I think these are simply different forms of a Tech Guru, since technical tools are required for these tasks.

I hope you agree with me that diversity should be encouraged, not stifled. Our diversity can be a great strength. While I'm applying this to a very specific target of a QA team, this principle applies to humanity as a whole. Our diversity makes us different, but working together, using our strengths appropriately allows us to move forward faster.