ALM: Test Management II

15 07 2013

Test Management need not be that frightful to everyone, from the low ranking developer up to the pointy-hair manager. If you can do a proper development plan for the core product, you have already gained the skills to create a good test plan.

The moment a Project Manager set the project timeline, the test plan is already presented to him / her. The moment the Architect draft out the solution, the test cases are also created. Yes, test management goes hand-in-hand with project management.

You maybe wondering why I am stating the obvious. But if you have been involved in many different projects, you will encounter the same problem in each of them: Test development and execution at the last week or so before the project is delivered. I was once involved in a project that only cater 3 days for testing and UAT, before releasing for paying customers to use!

What I learned over the years is that

  1. User Acceptance Test should NEVER replace proper unit, functional, load and stress tests.
  2. Unit test cannot replace Functional Test.
  3. Test until it breaks.

Testing is tedious and time-consuming, but so are requirements gathering and development work. To save on overall delivery schedule by cutting away the time allocated to testing, will only create longer bug-fixing cycle. Automation is the key to make sure proper testing for the project.


ALM: Test Management

3 03 2013

Continuing on the requirements for an Application Lifecycle Management system, we will look at Test Management in this and subsequent postings.

Initially I intended to label this post as Quality Assurance Management, but Quality Assurance (QA) is more than just doing testing. QA involves mindset and behavioral changes among other things. Quality must start from the very beginning til the end of a project. Hence for this topic, it would be more appropriate to use Test Management, a checking phase within overall Quality Assurance.

The common misconception is that Unit Testing will weed out all the bugs (or at least 80%) in an application. The only thing Unit Testing ever do is to check if the “unit” or method is performing what you want it to do, but not checking if it is the right thing to do. A proper and efficient Testing involves planning the Who, What, When, How and Why.

Who lays down not just the personnel involved, but also the roles and responsibilities each person undertakes during testing.

What indicates the area to test and end result the testing should achieve (be it positive or negative).

How dictates the method of testing: Functional, Performance, Load,  and Stress testings.

When ties up all the previous factors together and execute.

Why? Do I still need to explain?

With these factors decided, the next post we will talk more about the deliverables Test Management should handle..

ALM: Requirements Management Part II

17 01 2013

In previous post, we were talking about the main features a Requirements Management System should handle. In this post, we will try to tie up the loose ends, and talk about certain good to have features the system should have.

In one the previous post’s comment, one commenter mentioned that showing UI flow for each requirement would help to improve stakeholders’ understanding of the requirement, and gather better feedback and agreement. The proposed method is using Powerpoint with each slide showing the UI in each stage of the process flow. IMHO, it is indeed a good suggestion. It is easy to use and comes with simple animation flow to illustrate interactivity. The Requirements Management System must provide file uploading mechanism and associate the uploaded files to the corresponding requirements.

Another common usage is the association of test cases to requirements. Test plans, test scenarios and test cases are designed to verify that requirements are met in the developed product. Test results are also indirectly linked to the associated requirements. Therefore a requirement has a many-to-many relationship with test plan, test scenario, test case and test result.

Another association to requirements will be from the Detailed Design Specification (DDS). Although in the DDS, requirements are mentioned in the context of the changes or design of software components. A requirement may required a series of changes to one or more software components, hence it is not practical to upload the DDS as an attachment to any requirement. In this case, we should provide a unique ID for each requirement, so that DDS can refer to the requirements through the IDs instead. If possible, system may automatically link requirements to the DDS by first parsing the file and retrieved out the requirement IDs.


Use Case Diagram of Requirements to File uploading and Test Planning association.

ALM: Requirements Management Part 1

1 11 2012

Requirements are the beginning and the end of any IT projects. Not properly managed requirements can sink a project. I like the brief introduction of Requirements Management from Wikipedia:

Requirements management is the process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform.

I like it because it not only described the processes requirements are involved in, but also about “controlling change and communicating to relevant stakeholders”. I will elaborate more on that later.

The initial set of requirements from customers, are usually in the highest form, such as “I want to have user subscriptions and monthly newsletter sent to these subscribers”. We will refer here as Business Requirements (BR). The Project Manager and Architect will have to break them down into further details and verified with the customers. Following the previous example, the finer form will be “user subscriptions” and “monthly newsletter sent to subscribers”. Let us name these as Detail Requirements (DR). These can be broken down further (if so desired). Regardless of any style of development process, it is always the best policy to break a requirement into its atomic requirements.

Hence the system we are building should handle both the BR, and respective DR. The relationship is 1 BR is to 1 or more DR.

Requirements can also arise from issues or enhancements. Issues (ISU) resulting in changes in the end product should be recorded as requirements (RISU)  as well. The recorded requirements must be able to link back to the issues that prompted them. The relationship is 1 ISU to 1 or more RISU, and possibly 1 RISU to 1 or more ISU.

The next step is to get approval by the customers or stakeholders. Stakeholders may include your own company’s internal stakeholders. For example your Chief Architect might want to ensure the products or solutions are inline of the your company’s policy. Besides handling the who, system must also provide the how and when of requirements approval.

The requirement management system should allow the stakeholders to put in comments besides plainly accept or reject a requirement. The sequence of stakeholders to seek approvals from must also aligned with the stakeholders’ roles and responsibilities. Therefore an approval workflow is needed for the requirement management system. Of course, this workflow must be configurable to suit different business process.

In conclusion, I shall use the Use Case diagram to represent all the above mentioned.

Requirement Use Case Diagram

And also an ER diagram to show the possible relationships between the different forms of requirements.

Requirements Class Diagram

Unit Testing vs QA Testing

1 11 2012

As I have also told those who cares that Unit Testing does not equals to No Bugs in the final code.

A nice small article on personal experience in finding it the hard way.

So to all overzealous TDD engineers and managers, just because your project’s Test Coverage is 100%, it does not mean that the project is bug-free!.

Stop picking on the QA team.

Application Lifecycle Management

18 10 2012

From the ever favorite Wikipedia

Application Lifecycle Management (ALM) is a continuous process of managing the life of an application through governance, development and maintenance. ALM is the marriage of business management to software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management.

Having been through many projects, I have experienced lots of ups and downs of Project Management, from the viewpoints of Project Lead, Technical Lead, Architect, and Software Engineer. There are so many variables within each Project, that it is impossible for a single Project Manager to keep track of them.

Team members may chip-in to help, but Project Manager must still maintain an overall view of the Project from start to end. Communication between customers and engineers must be captured, be it in verbal, email, document form. And that is only the peak of an iceberg. Each phase of the SDLC is made up of lots of tasks that may be related to one another within or across the phases.

I came to know about Application Lifecycle Management when I was involved in Release Management in FedEx. FedEx has a well-defined set of processes to follow for software development, accompanied by a set of tools money can buy. Working as a QA Lead and occasional Implementation lead in product deployment, I began to appreciate the intricate details that a good Project Manager must be aware of and handled properly. A good tool is needed to aid the Project Manage in this aspect.

I started researching on the tools available for ALM, especially those that are open sourced . There are lots of open source tools that offers some or most of the functions, but they were either partial in their implementations or appetizers to get you to purchase their main commercial offerings.

Some commercial offerings aren’t that good either. They are mostly made up of different applications in which you would have to purchase and configure to cover all the ALM functions. Perhaps I am too picky.

Then it occurred to me that I should try developing one myself and record down the design process involved in making them. It will be a good opportunity for me to exercise my developing brain and design muscles. So let’s see if I will have enough energy to follow through in this project and keep this blog constantly updated with its details.

An Interface too many

3 05 2012

We have been told several times to extend from interfaces, instead of inheriting from parent classes. It is the correct practice, only when you are handling various implementation of a common concept.

Best example is always the Factory pattern detailed in the GoF Design Patterns

Unfortunately, I have had encountered inappropriate usage of interfaces: Interface with no or one implementation class. Perhaps its the requirement of the framework to have interface for even one single class, or the misconception of Design Pattern usage.

If it is the framework’s requirement for an interface class, there is really nothing you can do. If it is rising from the software designer’s misconception, there is still hope for rectification.

Take for example, if there is a Factory class FactoryA that only returns a single class ClassA, which implements an interface InterfA, it would be better off to just instantiate ClassA directly. Maybe the designer planned it this way to cater for possible future extension. However if, after a few versions, it is still handling just one single class, it is just foolhardy to continue the inefficient pattern (in this case).