Software Quality Assurance: Identifying Features

It's been a while since my last Software QA post when we talked a little bit about equivalence classes. In this post, I'll be discussing how to properly identify features within a program.

During the software development lifecycle, normally early during specification and development, test planning occurs. This is where all of the identification of the program falls into scope and frameworks are built to support the application for a certain level of resiliance and sustenance. It is best practice to plan this out before you finish specifications or code. During our test planning stage we may identify the following paths for testing:

• Bug tracking database features
  - Used across disciplines (development, testing, etc)
  - Agree of severity, priority, feature are, and other fields
• Test tracking framework
  - Record results of tests across different test builds
  - Allows for manual and automated tests
  - Generally used exclusively by test team
• Test automation framework
  - Testing requires development, too
  - Plan with development early on to schedule testing hooks
• Feature Identification
  - We'll look at this one today.

What exactly is a feature?

When identifying features the following categories will come up with each feature identified. You must be careful to properly place the feature in the appropriate area so you can handle how to test for it throughout the testing stage.

1. Is it something you could market to the customer?
       - This is generally very broad (i.e. built in code generation)
2. Is it a specific UI element?
       - 3D Window Manager (Window + Tab)
       - Aero glass interfaces
3. Implements an algorithm?
       - Spell-checking
       - Matrix inversion
       - Model consistency checks
4. Piece of code in the product?
       - Public classes and methods
       - Extensibility points
       - Internal classes

Classify your features

In order to properly classify the features of a program, a lot of questions need to be asked. Some questions provide natural dependency information between components. Since all features naturally nest (i.e. the what of one feature is part of the how of another) the question-based approach works for all feature types:

• Box, UI, Algorithm, Implementation.

Here's what you can ask:

1. What is the task that needs to be performed?
• Box: built-in code generation
• UI: choose the Generate Code menu item
• Algorithm: Perform object-mapping to group objects
• Implementation: Save temporary file and apply transform to generate code
2. Who is expected to perform the task?
• Identify customer roles (example, extensibility programmer)
• Box: Full extensibility
• UI: Add plug-in dialog
• Algorithm: Service-oriented architecture for external use
• Implementation: Requires extra testing at public API level
3. Why do they want to perform the task?
• Usually the best question for large functional grouping
• This is why the customer buys the product.
4. How do they do perform the task?
• An answer to how will often identify sub features.
• Box: Rarely mentioned (beyond the vague 'automatic')
• UI: Focus on UI elements (menus, tool windows, dialogs, etc)
5. When is the task available?
• Identify the context of the task
• UI: Properties Windows items populate when a control is selected
• Provides a natural grouping for test design

Identify Context

As expected, all features run in a given context. This means, that there is a given state in the program where the feature exists. This context is usually static (yes or no, true or false) but can indeed be dynamic given any number of constraints to the feature. You will find that dynamic context occurs in ongoing actions such as playing a video, generating code, or analyzing live data feeds.

However there are plenty of cases, and this works well with test design, where features require more than one context. In other words, code generation isn't available unless I have valid XML. If feature B is code generation, and xml validation is feature A, we know that feature B is available within the context of feature A. You can almost always test B along with A, but not vice-versa.

Proper Plans

In the early stages you will need to do the following:

• Identify large why areas
• Areas correspond to single or multi stage user actions
• The how should be left until last
• A feature test should use a utility layer to do the how

Examples:

- Delete the BlogPostComment is an appropriate action for test planning.
- Click the Delete Comment link (one of the many How features) is not appropriate for functional test planning.

- Add a Video is appropriate
- Open the 'Compose Page', click the 'videos' button, tab to next page, click last video link... etc is not

• Your test should be able to say 'Add a video'
• The automation layer (later on) will do the rest.

Risks and Side-Effects

Every action of a test will have its risks and side-effects. Although, the manifestation of the side-effects is not important in early stages, it is increasingly important to note the risks involved and any possible consequences to occur when running a given test.

• Good examples
• Renaming your username should fail if the name is in use by another user.
• Deleting a user group should throw {x,y,z} errors.
• Bad examples (the how should be hidden from high-level feature tests)
• Renaming a blogger's username to a used name will display a message box.
• The task list will change when an error is added.

I hope this has helped identify features a little easier for those of you who seek quality assurance in your software. In my next post I'll talk about how we can make the testing part of development a little less hectic with creating proper problem reports.