Feeds:
Posts
Comments

Albert Einstein “Anyone who has never made a mistake has never tried anything new.”

William Shakespeare “Love all, trust a few, do wrong to none.”

Thomas A. Edison “I have not failed. I’ve just found 10,000 ways that won’t work.”

This post is a little off track from my usual QA posts but I thought was interesting to think of how you can actually bring your work home, but in a good way!  We should be every bit as careful in dealing with our family as we are with our work colleagues and too often, we ask them to take a back seat.   Team building skills are every bit as relevant at home as they are in the office.

I have a wonderful co-worker and friend who I think is great because she always challenges me to consider new ways of looking at things.   Every chat we have leaves me richer in ideas and motivation.  She came to my rescue today after I was feeling down and discouraged with my parenting skills with teenagers.   As we are both professionals, it was only natural to put this in business terms.   “Have you told them what your requirements are?” she asked, “if this was work, you would define your expectations for them and find out what are their expectations of you”. 

I had not considered it this way!  Why wouldn’t I consider them to be my team, the same way I view my co-workers?   While I had told them from time to time what I expected from them, it was pretty hit and miss (and to be honest, mostly after they missed picking up after themselves!).  Sometimes parenting is very much “by the seat of your pants” as you are always on the job but maybe it needs a more formal approach. 

So how do I define my expectations?  Previously I would get caught up in the details – how many chores, how much homework.  But do I really want to define it along those terms or should I go for the bigger picture.  What what did it all really mean?  What was the philosophy behind the chores and the homework that I wanted them to learn? 

So this is my list for my team:

1. Take responsibility to carry your fair share

2. Learn something new every week

3. Don’t be afraid of your mistakes, be afraid of not making any because this means you playing it too safe and are unwilling to take a risk.  Better to have tried and failed than to have never tried.

4. Find something to be passionate about, be engaged what you are doing.  Have an opinion!

5. Recognize your potential and find challenges to help you to reach it

6. Be self-aware of how you impact others and how you react to them

7. Realize how resourceful you can be, don’t be afraid to ask for help but demonstrate first that you made an effort

8. Take ownership of your happiness and your needs, be vocal about them.  Don’t expect people to read your mind or blame them for not knowing you better.  It is up to you to make yourself known.

9.  Learn how to manage conflict but be prepared, it’s a life long process!  Take a stand but be prepared to compromise where you can.

10. Set standards for yourself and your behaviour that are constant regardless of who you are with or what is done to you.

Now I wonder what they will come up with for my list of requirements! 

What do they consider their needs to be?   Just because I gave birth to them, did not necessarily mean that I still always knew what was best for them.  I just assumed that I was meeting their needs but this was a big assumption on my part.  If I expected them to start being adults, I also had to grow up and release my authority as their expert. 

The same thing applies to your work team.  You might have foster and implemented a project from Day 1.  Just because it was your creation, once you build your team to support it, you can’t always be the authority.  You have to be open to the fact that they might have become experts as well and might have even exceeded your knowledge!

This famous quote by George Santayana is the basic philosophy behind Total Quality Management (TQM).  It seems like a pretty simple concept, to learn from your mistakes so that you don’t repeat them but the reality is that it is often very difficult to do. 

Even the steps are pretty simple:

  1. Identify and describe the problem or issue
  2. Determine the cause
  3. Resolve the problem
  4. Follow up and monitoring

So why is this so hard?  This is my take on what gets in our way:

“We don’t have time”

Software projects and releases are notorious for being time sensitive and often are behind schedule.  Teams are working overtime and often reacting to unexpected and unscheduled delays so the focus is often to just get it done.   When people are in a time crunch, this is when teams look for short cuts and want to deviate from the improved process to go back to their old ways.  It is difficult to stick to your guns and push for the new process.

Suggested Remedies

  1. Awareness – the team has to realize that although the short cut saves them time in the short-term, in the long run, it will always catch up with you.  It takes discipline to stay on the correct path, especially when it is something new and unproven.  It is human nature to stick to old habits.  Have past examples in mind when these discussions come up and remind the team why these changes were needed. 
  2. Take Responsibility – it is incredibly frustrating for teams when they are pressured to find short cuts and then blamed when the short cut comes back to bite them.  Managers need to take responsiblity to either allow the team to take the extra time to do it right or take the responsibility of taking the short cut.  This builds trust within the team and keeps their faith with management.  It is impossible to work on continuous improvement if your team doesn’t trust you.
  3. Plan and schedule your improvements   The time to have improvement discussions is not in the middle of a high pressure release as you are not going to find a receptive audience.  The time to analyse and review past mistakes should never be when people are under pressure and stressed.   Designate someone to take action items when ideas are raised that can’t be implemented right away and host post-mortem reviews after the release is out the door.   Make sure that new changes to the methodology are factored into the next project schedule.  People need time to adjust to a new way of doing things.  Don’t overload team members with too many new changes all at once or there will be confusion and possibly a revolt!

“It wasn’t me!”

Lets face it, no one likes to realize that they made a mistake, let alone have the mistake aired publicly and dissected by the team.  The more pride a team member takes in their work, the more defensive they will be when problems are found.  You don’t want to discourage this sense of pride in their workmanship but you cannot allow people to get territorial and resistant to change.   I am Canadian and Canadians are notoriously polite and hate making a scene.  Team members are often reluctant to air problems for fear of being rude or impolite to a fellow team member.  We would rather smolder and steam than risk causing a scene but this means problems go unresolved and good team members get fed up and leave for better projects.

Suggested Remedies

  1. Set an example – if you are leading up the improvement process, find an example of something you might have done wrong and ask for suggestions for improvements.   Demonstrate that you don’t expect people to be perfect but you do expect a willingness to improve and grow but you must lead the way by your own actions.
  2. Avoid making it personal – try to keep the focus on what is best for the project and that the purpose is to find out what doesn’t work for the team, NOT to identify weak team members.  If a weak team member is a problem, this not the place for this discussion and the manager needs to take this offline as it distracts from the focus of improving the process.  Ensure that your language uses nouns of  the tasks and issues and not a person’s name – for example “the web API” rather than “John’s API”.
  3. Keep it light and find humor in the situation.  We once had an awards ceremony for the post-mortem review and the awards were home-made silly statues that gently poked fun at some of the hurdles that we had to overcome.  One developer got a stitched up rag doll as the “Patches Award” for the most number of hot fixes.  She wasn’t responsible for the number of hot fixes but she had to bear the brunt of managing all of them and it was a way of recognizing her hard work while at the same time recognizing that maybe we didn’t need so many!  Another team had a “Bad Ass Wizard” award for any developer that broke the automated nightly build.  If you came in to find the wizard on your desk, you knew you had work to do right away.  The wizard had to live on your desk until someone else broke the build.  No one wanted that ugly thing on their desk for long but it did make the rounds from time to time! 

“It’s no use, we will never get better”

Sadly, there is a pessimist in every crowd and it can make the job of encouraging and promoting change extremely challenging.  They will point out every flaw and reason why it won’t work or it shouldn’t be considered while offering little as an alternative.  I have come to realize that there are people who actually enjoy working in chaos and feel that this gives them their stage to shine on.  For some, this is their job security because they have convinced the team that the project won’t survive without them to save the day when things get crazy.   Successful projects should never depend on heroics and sooner or later, people will be exhausted with the high stress stakes and you will lose your best people.  So how do you win over the doom and gloom crowd?

Suggested Remedies

  1. Allow everyone to contribute feedback and solutions.  So many times I have seen post-mortem reviews where only the management team attends.  It is the team members in the trenches that really know what happened day-to-day and often managers might have their own agenda to promote.  If you really want to know what happened with a project, don’t exclude the people who are directly impacted and  bore the brunt of the problems.  Allow them a chance to express themselves and offer ideas and you will find that the quality of the solutions improve and the team will adopt new changes more readily.
  2. Monitor the changes and provide metrics to the team.  Team members need to feel that they are making a difference.  Too often reports on the project status are circulated to upper management but the team also needs to see how they are doing.  They need to know if the improvement plans are working and what is still broken.  I had a Manager of Development who objected to my tracking the reopen rate of defects because he felt this looked badly for his team.   My argument was that a reopened defect was not necessarily a reflection of the development but a reflection of the project.  Defects could reopened because the requirement was not written properly and therefore not fully understood or that the original defect wasn’t properly documented by QA.  Regardless of the reason, it reflects churn in the project that could be eliminated or reduced.  By tracking these metrics and putting corrective action in place, the team could see if their efforts produced the results they were hoping for.  If improving the process requires more effort or work, people need to see that the results are worth the effort.
  3. Celebrate!  No one can stand a steady diet of issues and problems.   If we want teams to be open and honest about what isn’t working and where their problems are, we have to give equal time to what is working and celebrate our successes.  Team members that are excelling should be appreciated and recognized.   One company I worked for had a bank of Starbucks gift cards and team members could request one to send  thanks to team members who went the extra mile to help them out.   People are more open to change if they feel appreciated.

SQA was not my first career. 

I actually started as a Mechanical Designer (tool & die) in the manufacturing sector.  When I was in college, everything we did was on a drafting board.  Within one year of when I graduated, AutoCAD was launched for PC computers and within 5 years, it was hard to find a drafting board anywhere.   This was my first clue that I better learn fast or I would never be able to keep up.  Within 10 years, manufacturing had dramatically changed and it seemed like every machine had a digital interface.   I learned how to program CNC machines and PLC controllers all from manuals and trial and error.   The machines were arriving faster in the plants than there was courses available to teach anyone.  I would arrive in the morning to find a manual on my desk and my boss asking “Can you figure that thing out?”  Luckily I learn better on the job than sitting in a class so it worked well for me but my resume is oddly lacking in the education department. 

When I started in the SQA field, it was a 3 month contract to test some new software and it ended up being a 3 year gig and a new career I stumbled into.  In 1995, there weren’t many courses or degrees in SQA and most of the training was on the job.  If I don’t learn at least one new skill each year, I start to panic that I am falling behind.  This blog has been a great way for me to remind myself to keep current and keep searching for what is up and coming in the field. 

When I am interviewing candidates, I am always looking for clues in their resume or their answers that they enjoy learning and are actively involved in picking up new skills.  If their learning stopped after they got their degree, they aren’t for me!

This presentation really brought the point home to me and is a MUST SEE for all teenagers.  For all the benefits that our generation has had over past generations, we have huge challenges ahead.  It is becoming increasingly critical for the next generation to learn on their feet and not look to school as their primary source of education.  As much as I loved this presentation, I must admit that it made my head hurt to just take in all the implications!

What is cloud computing?

According to the definition in Wikipedia .. “Cloud computing refers to the provision of computational resources on demand via a computer network. 

Cloud computing can be compared to the supply of electricity and gas, or the provision of telephone, television and postal services. All of these services are presented to the users in a simple way that is easy to understand without the users needing to know how the services are provided. This simplified view is called an abstraction. Similarly, cloud computing offers computer application developers and users an abstract view of services that simplifies and ignores much of the details and inner workings. A provider’s offering of abstracted Internet services is often called “The Cloud”.

For the purpose of this post, I am going to focus on the Software as a Service (SaaS) type of cloud computing which delivers a single application through the browser to thousands of customers using a multitenant architecture.     Salesforce.com is by far the best-known example among enterprise applications, along with Flickr, Google Apps like Blogger and Zoho Office.

What does this mean for Quality Assurance planning of a SaaS cloud application?

Similar to a hosted environment, the cloud computing now takes on the role of the customer’s IT infrastructure that was previously managed in-house.  The cloud application provider must inform and commit to customer a high standard of quality in the following areas:

  1. Release Management
  2. Compliance and Security Certification (i.e. PCI, Sarbanes-Oxley)
  3.  Performance / SLA monitoring

Release Management in a Cloud Environment

The SQA role in Release Management in any hosted environment does not stop once the software has been approved for release.  The full deployment cycle needs to be carefully managed to have a seamless experience for the customer with little downtime or outages.  

1. Multi-platform Support – because browser applications are the point of access for the client to the cloud application, browser and operating system compatibility  issues are a critical concern.  Given the wide range of customers to be supported, there is demand to support a wider range of platforms and a greater business risk if defects are found in this area.

  • Supported browsers should be determined based on their compliance compatibility.  Eliminate any older browser or operating system versions that will cause issues with compliance or coding due to non-standard web support (see http://www.webdevout.net/browser-support-summary) and/or security issues.  This will make QA and support much more manageable.  This list should be reviewed and updated regularly.
  • Customers should be clearly informed of the browsers that will be supported as well as any browser configuration requirements.  It amazes me how many clients stay with ancient browser versions and expect them to be supported!  This sounds like an obvious point but it often is overlooked by application providers and causes a great deal frustration for customer support when it isn’t clearly understood. 
  • Constantly monitor browser and operating system security alerts, hot fixes and new releases to ensure that the cloud application is always compliant and defect free.  Always check the major platform release schedules when determining the cloud application release schedule. 
  • Block unsupported browsers where ever possible.  If the application can detect and block unsupported browser versions, this will go a long way to reduce the potential of unexpected errors and corrupted data .
  • Automate cross browser testing.  There are several excellent tools in the market now to ease the burden of cross browser testing.   (see http://freelancefolder.com/7-fresh-and-simple-ways-to-test-cross-browser-compatibility/ ) Automated API tests are more economical for testing the business logic layer of the application and the cross browser testing should focus primarily on the GUI issues of the application. 

2. Customizations

  • As much as we want to always meet our customer’s needs, customized release versions can throw a real monkey wrench into release deployments and the cost of software support.   Customizations complicate the version control management of  the source code and each release must be tested against every customization and customization hot fix.  Giving a customer a quick customization might sound like an easy fix from a development perspective but it quickly becomes a release management and QA nightmare to maintain and support. Where ever possible, a better solution would be to deliver customizations as a configuration option in the core product. 

3. User Acceptance Testing and Training

  • Prior to deploying a major release of the cloud application, the customer should have access to the new version in order to assess how any changes might impact their business workflow and processes.  It also gives customers an opportunity to participate in the user acceptance testing (UAT) efforts and an environment to provide early training for their teams prior to the deployment.

4. Data Migration

  • Many cloud applications offer migration scripts to assist new customers in migrating their data from a legacy system to the cloud application which enables new customers to have a quicker conversion and ramp up time.  Sometimes these migration scripts are a standard component of the product and thus, part of the QA scope for testing.  However in some instances, these migrations scripts could be a customization requiring only one time testing.
  • If a new release requires data migration for existing customer upgrades, it would be ideal to offer the customer a beta environment with their own migrated data to better assess any data issues or impacts.  This also allow the IT team a chance to test out the migration on customer data prior to the release. 

5. Deployment Planning

  • Customers will not necessarily want to accept a new release according to the cloud application’s release schedule.  Therefore the cloud application should provide a process for the customer to remain on their current release and to choose when to upgrade according to their business demands.  This also eases the burden on the cloud application IT team to not have to migrate every tenant in the application at once.
  • Many cloud applications have service level agreements (SLAs)  for 7-24 availability.   In one company I managed the staged deployment to a clustered server arrangement where we brough one side off-line for deployment for a short period of time while the other half remained online.   Deployments were planned for off-peak hours to limit the risk of performance issues.  Once one half of the cluster was deployed and tested, it went back online and the second side was taken off-line, deployed and tested.   It was critical to have a detailed deployment plan complete with milestone checkpoints and rollback scripts for each checkpoint, if needed.  We never had to use these rollbacks but they were as well thought out and tested as the successful deployment plan.  Each deployment script had a dress rehearsal in the QA staging environment prior to the deployment date so all team members were familiar with their tasks for the actual deployment.

For more information, see these great blogs on Cloud Computing http://cloudtp.com/thought-leadership/top-25-cloud-bloggers