Red Earth QA of Central Oklahoma

Wednesday, May 20, 2009

Free e-book (until May 27th) - Defect Prevention

A colleague of mine told me about this book. It is a free download (though requires a signup to Microsoft's training site). Here is an overview and link.

Body:

The Practical Guide to Defect Prevention

This practical, hands-on guide captures, categorizes, and builds a process of best practices to help avoid creating defects during the development process—rather than fixing them after extensive analysis.

The Practical Guide to Defect Prevention

Part I Introduction to Defect Prevention
1 Defect Prevention
2 Defect Prevention Frameworks
3 The Economics of Defect Prevention

Part II Defect Detection Techniques
4 Quality and the Development Process
5 Using Productivity Games to Prevent Defects
6 Improving the Testability of Software

Part III Defect Analysis Techniques
7 Software Measurement and Metrics
8 Risk Analysis
9 Using Simulation and Modeling for Organizational Innovation
10 Defect Taxonomies
11 Root Cause Analysis

Part IV Defect Prevention Techniques
12 Adopting Processes
13 FMEA, FTA, and Failure Modeling
14 Prevention Tab.

Part V A Culture of Prevention
15 Scenario Voting
16 Creating a Quality Culture
17 Moving Quality Upstream
18 Rewards, Motivation, and Incentives
19 Knowledge Management and Communication
20 Pulling It All Together

Tuesday, May 19, 2009

Meeting Announcement - May 28th

NEWS
- We've moved our meeting to the 4th Thursday this month. (It may be permanent)

Time and Location

The Red Earth QA's meeting will be held on the 3rd floor of 100 N. Broadway from 11:30am-1pm on Thursday, May 28th. Look for the signs to direct you to the correct room.

Topic

Michael Penny from Tek Systems will provide some insight into the local job market.

We have some unconfirmed additions as well. So come and be surprised!

Directions

You can park in Main Street Parking on Main or you can find street parking.
From I-40, take the Robinson Exit. Go North on Robinson to Main. Right on Main. You can either go to Main Street Parking or continue to Santa Fe Parking. You will see 100 N Broadway on your left across Broadway. The building says 'Chase' at the top.

Monday, May 18, 2009

Creating User Interfaces - Design Patterns

Do your users complain about your application, even though it gets the job done?

Are you asked to 'spice it up' or make it 'Web 2.0-ish'?

Well Design Patterns are for you! Here are some helpful links (though you can find your own easily) to inspire design of User Interfaces.

http://developer.yahoo.com/ypatterns/

http://ui-patterns.com/

http://www.uidesignpatterns.org/designPatterns

http://uipatternfactory.com/

For example, UI-Patterns.com lists these patterns among many.

Inline Input Adder
Minimize the amount of input fields by allowing the user to add more input fields if he needs them.

Undo
Give the user an option to easily undo an action.

Edit-In-Place
Use a dynamic text editor to allow the user to edit text

directly “in-place”.

Primary & Secondary Actions
Match the visual presentation of actions to their importance to get users through a form as quickly as possible.

Inline Suggestions
Help the users to give an answer by suggesting valid answers from which to pick from.

Carousel
Show thumbnail images of items on a scrolling menu, which allows users to browse through them.

Wednesday, May 13, 2009

Starting With Root Cause Analysis (and mitigation)

Root cause analysis doesn't have its roots in Software. It was originaly applied to manufacturing processes and has been adapted to Software defects.

One approach is to list known causes (defect in requirements, defect in design, defect in coding, defect in testing, defect in environment, etc.) and associate each defect with that cause. That is not what I'll be doing here.

I'll be discussing going through a thought experiment for some subset of failures to determine what is likely a series of root causes and how to manage that long-term to make your product better by learning from your team's mistakes.

First, it's likely that you only have the bandwidth to do this for a relatively few items and it's important to pick those items well. One excellent candidate is user-reported bugs that are deemed 'critical' (Hopefully, you have some reasonable way to do this). In all cases, it's helpful for the bug being analyzed to be fixed and be verified as fixed.

Then for each defect, record the following: (This is my list, and can be suited to your needs)

ID / title - This comes from your bug tracking system and is used to clearly identify what issue is being discussed
Function - This is the actual system capability that failed and it may be part of a formal list of system capabilities or may be some general statement such as 'Detailed Data Display'
Effect - This is the impact to the user or some discoverable impact to the system. It may or may not be the same as your title, depending on your defect report standards. A good example would be 'User unable to log in after changing to a long password'
Failure - This is a description of the behavior or design where what was implemented differs from the expectations. It may or may not be the same as your title, depending on your defect report standards. Often, it is more detailed than the Effect and may require some code or environment analysis to clarify. A good example of this is 'Users are able to create new passwords that are more than 45 characters long, but any password longer than that will not be validated successfully'
Notes - This is you can discuss any historical / contextual information that doesn't fit elsewhere, but that would be helpful if reviewed in the future. An example could be "This appears to be an issue that has existed since the product's first release, before we did formalized testing"
Cause(s) - This is where you apply one of several techniques. Rather than go into them here, you can read about Ishikawa Diagrams and make a Pareto Chart to fill out the next steps. There are other related topics you can apply to fill out this section if you find they suit your needs better.
Recommended Actions - If you created a Pareto chart, you have the highest contributors to the cause at the top of your list of causes. You work your way down the list to address items insofar as they are helpful. It's likely that some of the causes will need to be left as continued exposure to risk if the cost to implement is not acceptable.
Responsibility - Not only do you identify actions, but you need to assign them to someone. If you have other methods of assigning work, you can simply refer to that here. For now, we'll assume that this spreadsheet is used to track these items.
Target Completion Date - The person that is responsible for completing this action should come up with some acceptable date to complete this. Record that date here.
Action Taken - In the end, it's possible that the action isn't exactly what was targeted. If different, record here.
Date Action Taken - Record the date that the action was completed so that you can focus only on the items that are not completed.

There is an implied workflow here. On some schedule, you will need to update this list (unless you are doing this as a one-time exercise). Once you have assigned actions, you will need to follow up with people to ensure they are complete or that if any changes need to be made, that those changes are made and that the mitigation is complete.

In addition to online resources regarding root cause analysis, you can also look for classroom training.

Friday, May 01, 2009

Fun Bugs

Have you ever found a bug that you had to say "Hey! Lookit!"? Most of the ones like this I find are only of interest to my team. However, here is a link to bugs found (and fixed) along with a discussion of each.

18 Embarrassing Game AI Bugs

Thursday, April 30, 2009

Old-school programming techniques you probably don't miss

Computer World has an article on techniques you rarely need to consider for so-called 'modern' computer systems.

Among those listed are
- hand-coded sorting algorithms
- GUI elements
- self-modifying code (this is particularly interesting for anyone under 40)
- punch cards
- pointer math
- and much more...

The article is well-written and a fun read. From a QA perspective, the 'other shoe' aspect is that these no longer need to be tested. Whew!

Monday, April 27, 2009

Call for Bloggers

If you are interested in blogging on this site, please send us an email at redearthqa@sbcglobal.net.

If selected, we will ask that you commit to a regular schedule and be subject to editorial approval for a short trial period.

Testing Without a QA Team

Yikes! That sounds like heresy! Regardless, it's the position that many developers find themselves in. Typically, this is for internal applications or small-ish products. There is no easy justification to hire a dedicated person (let alone a whole team) to do the QA. That doesn't mean that testing can't be done.

Here are some tips from a book "Beta Testing for Better Software" by Michael R. Fine on approaching the testing effort when there are no full-time QA assigned to the product.

Start with a usable test product
Even if you have a list of known issues, if you can describe them clearly you can avoid unnecessary churn.
Target actual users
Find people that not only know the domain for which the product is intended for, but also someone that is able to think clearly and provide good feedback.
Be sure you are mentally ready for the feedback
You may have to ask for clarification for bugs that are reported. Users are not experienced in writing bug reports and likely cannot do any sort of analysis on what the root cause is.
Be sure your schedule is ready for the feedback
The users that are helping with the feedback will be more likely to provide feedback if they feel that their issues are addressed quickly. If there is a server portion that is offline for several hours, users may loose confidence in the product. Knowing that it's down and reacting to that quickly is good. If there is a simple fix you can provide, be ready to send that out as appropriate. Even better, plan on updates to the software as a result of the beta testing so that the users can see the improvement (and have some pride knowing that they contributed to this)
Have a clear plan
Knowing how many users is one thing. Clearly guiding them on what new features they should be focusing on or bug fixes to verify is important. You should also have a clear timeframe in which to ask for this feedback.
Identify what success looks like
How do you know if the beta test was successful? How do you know that the new features have been sufficiently exercised? How do you know that your participants provided some value? How do you plan on addressing these issues before you leave 'Beta'? How does this beta compare to previous betas?

The book goes into more details and I encourage you to read it. Even if you have a full-time QA staff, this book provides some insight into how Beta testing can be used effectively within your current processes.

Monday, April 13, 2009

Meeting Announcement - April 16th, 2009

Time and Location
The Red Earth QA's meeting will be held on the 3rd floor of 100 N. Broadway from 11:30am-1pm on Thursday, April 16th. Look for the signs to direct you to the correct room.

Topic

Sky IT Group will be presenting Quality Center 10 new features.

Requirements Management Only License – enables business analyst & owners to leverage QC to create a central location for requirements management, versioning and reuse.
Versioning - Manage project chaos by versioning requirements, tests and components.
Integrated dashboard module.
New Baseline Functionality - Capture project assets at critical stages with new baselining functionality.
Risk Based Quality Management - Enhanced Risk Based Quality Management with testing effort.
Quality Center Premier Edition.
a Reuse of Requirement / Tests across Projects.
b Defect sharing across Projects.
c Integrated dashboard module across Projects.

The presenter, Sky IT Group will be providing Subway for lunch.
We need a response by Wednesday 8:00 am only if you plan to attend for lunch at 11:30.

Can't attend in Person?

phone dial-in (877) 848-7030

code 8218181

Join the meeting

Computer Audio
To use computer audio, you need speakers and a microphone, or a headset.

First-Time Users
Make sure the Office Live Meeting client is installed before the meeting:

Troubleshooting
Unable to join the meeting? Launch the Office Live Meeting client and join the meeting with the following information:
Meeting ID: 253cc236575a4d95b7662f69832764d9
Entry Code: sYj1ys9uweq
Location: meet:sip:Bill.Rice@dvn.com;gruu;opaque=app:conf:focus:id:253cc236575a4d95b7662f69832764d9%3Fconf-key=sYj1ys9uweq

Notice
Office Live Meeting can be used to record meetings. By participating in this meeting, you agree that your communications may be monitored or recorded at any time during the meeting.

Directions

You can park in Main Street Parking on Main or you can find street parking.
From I-40, take the Robinson Exit. Go North on Robinson to Main. Right on Main. You can either go to Main Street Parking or continue to Santa Fe Parking. You will see 100 N Broadway on your left across Broadway. The building says 'Chase' at the top.

Tuesday, March 17, 2009

Meeting Announcement - March 19th

Time and Location
The Red Earth QA's meeting will be held on the 3rd floor of 100 N. Broadway from 11:30am-1pm on Thursday, March19th. Look for the signs to direct you to the correct room.

Topic
Randy Rice will be giving us a preview of his StarEast presentation on Dashboards. Randy is local to the Oklahoma City area and travels internationally to consult with companies regarding their development and testing processes and provide training in many areas including Quality Assurance.

http://riceconsulting.com/home/

Can't attend in Person?

dial-in number: 877 848- 7030
passcode: 8218181

Directions

You can park in Main Street Parking on Main or you can find street parking.
From I-40, take the Robinson Exit. Go North on Robinson to Main. Right on Main. You can either go to Main Street Parking or continue to Santa Fe Parking. You will see 100 N Broadway on your left across Broadway. The building says 'Chase' at the top.

Monday, February 16, 2009

Meeting Announcement - February 19th

Time and Location
The Red Earth QA's meeting will be held on the 3rd floor of 100 N. Broadway from 11:30am-1pm on Thursday, February 19th. Look for the signs to direct you to the correct room.

Topic
Sonata will be doing an online meeting showing their automation framework that ties into Quick Test Pro.

Can't attend in Person?

Here are the details for online access.

When: Thursday, Feb 19, 2009 12:00 Noon (CST)

Duration: 1:00

https://www.livemeeting.com/cc/sonata/join?id=CCM7DP&role=attend&pw=4%7C%3AtT%5Bf%262

Meeting time: Feb 19, 2009 12:00 Noon (CST)

Add to my Outlook Calendar:

https://www.livemeeting.com/cc/sonata/meetingICS?id=CCM7DP&role=attend&pw=4%7C%3AtT%5Bf%262&i=i.ics

AUDIO INFORMATION

-Telephone conferencing

Use the information below to connect:

Toll: +1 (218) 486-3850

Participant code: 331404#

FIRST-TIME USERS

To save time before the meeting, check your system to make sure it is

ready to use Microsoft Office Live Meeting.

http://go.microsoft.com/fwlink/?LinkId=90703

TROUBLESHOOTING

Unable to join the meeting? Follow these steps:

1. Copy this address and paste it into your web browser:

https://www.livemeeting.com/cc/sonata/join

2. Copy and paste the required information:

Meeting ID: CCM7DP

Entry Code: 4|:tT[f&2

Location: https://www.livemeeting.com/cc/sonata

If you still cannot enter the meeting, contact support:

http://r.office.microsoft.com/r/rlidLiveMeeting?p1=12&p2=en_US&p3=LMInfo&p4=support

NOTICE

Microsoft Office Live Meeting can be used to record meetings.

By participating in this meeting, you agree that your communications

may be monitored or recorded at any time during the meeting.

Directions

You can park in Main Street Parking on Main or you can find street parking.
From I-40, take the Robinson Exit. Go North on Robinson to Main. Right on Main. You can either go to Main Street Parking or continue to Santa Fe Parking. You will see 100 N Broadway on your left across Broadway. The building says 'Chase' at the top.

Monday, January 12, 2009

Meeting Announcement - January 15th

Time and Location
The Red Earth QA's meeting will be held on the 3rd floor of 100 N. Broadway from 11:30am-1pm on Thursday, January 15th. Look for the signs to direct you to the correct room.

Topic
Software Development Technologies will be discussing their offerings.