3 posts tagged “features”

    How many times have you suddenly "discovered" a feature about a certain software that could of possibly saved you hours of time had you known that feature before? It's all too typical to find hidden features in software these days. The problem isn't that designers intend to keep you from using such a feature, it's that the design limits them from "trying to put everything in front of the user". There's the first mistake - don't.

    There are some products that will put everything in front of the user while other products will only put a few things while hiding the rest from perspective. Users will either find themselves searching and searching for something that they need to get to or slow down the confusion and filter through all the unnecessary, even still - distracting - garbage in front of them.

    To avoid this scenario, designers can equip themselves with learning about what tasks are important to their users in addition to creating workflows. Most users can only get one thing done at a time. It's usually best to follow this idea of presenting things one at a time - wherever appropriate. For instance, instead of providing the textbox to post a new blog post, there is a Create button at the top of the page. I can see that when I need to accomplish that task, it's right there in front of me to get to it - without distractions.

    As a user we can be prone to wanting everything in front of us at every possible moment, but what we tend to forget is that we don't always need to get everything - everywhere - done at the same time. So, in supplement we complete tasks according to the context or point of focus we are in. At the same time, with respect to the designer, we need to understand that users need to be able to get out of context quickly - without seeking it out, which can lead to frustration. Simple things like - "I'm done", "Save", "Ready", "Back", "Previous" help users understand that they can navigate to other points of focus not only fast but very simply.

    The web is full of applications that have a way of giving the user the ability to perform tasks according to their needs. But sometimes those needs expand outside the realm of what's available in whatever the tool allows. A common scenario for a user is to simply not get what they want, move to a different tool that does do what the user wants it to do, or provide a feature request to the developers. But let's get to the basics of what applications are initially intended for.

    Applications, which are apart of a business model that envelops the ideologies and processes that make up information technology and the people it involves, are intended to serve. Services are created so that the audiences and primary customers are satisfied with the end-product. The primary objective of the business is to ensure that the customer is happy and is being served the content in a way that is pleasing. This of course is contingent upon the fact that the user never changes his/her mind with the product. So what happens when an audience of the business wants feature X, we'll say they want the ability to share the content with their favorite social networks. So what happens?

Sharethis

   Well, here are your choices for sites in which you can share your content with (among others not listed here). Quite a few sites will have links to share said content to YouTube, MySpace, Facebook, Digg, Twitter, Live, Slashdott, StumbleUpon. This list just keeps going. This creates a very typical and dawning problem for application developers. Given that each site will post shared content in different ways, the business chooses which sites to share with, downloads the apis and develops according to said networks.

    Not only does this create a problem for developers, it creates an even larger issue for users. My site isn't listed! Well, once sites ABC are supported the business has successfully gone outside the scope of their core business processes. The important part is the ability to create a service to manipulate, aggregate and navigate content. Networks provide a nice area of sharing content, services provide a great mashup for providing content. When services can be successfully aggregated and served as tools to users - in this example sharing content will be seemless.

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.