Testing my own website

I have spent sometime recently testing my own website and fixed quality issues. Maintaining a website is not an easy task. I was checking some old pages/articles and found following issues on some.

• Links are incorrect
• Page navigation links not proper (no back link)
• Font not consistent with rest of site
• Page Title does not exist
• Page Title and Article does not match
• Color not consistent with the site

Since the site has lot of pages and links, it took me sometime to test and make changes. Now when you browse all my articles posted before I started using blog to write articles it should be consistent experience.

If you still notice any quality issues while browsing my website, do let me know. Send e-mail to cskishore at yahoo dot com

Link to all my articles

Sustainable Software Development

During my hunt for best practices in most of the things I do, I come across very good articles on various websites. Most of the time some newsletters are my sources. I had created a forum to share good articles. There are more than 150 articles posted on this forum over years and I still continue to use some ideas from the articles posted here

A recent article I found was very apt to my thinking. This was a book excerpt on Sustainable Software Development. Click here to read the article.

This article focused on continuous improvement in software development. I will try to find time to read the full book.

Quality is Free

This is the title of book by Philip Crosby that I read a long time back. My understanding of quality after reading this was: business success is mostly driven by quality. Quality of products, services determines success of any business. Paying attention to quality must be one of the primary task business should do to ensure continued success.

I have made quality as my career objective and do my best to take care of this critical aspect.
My articles on Quality at work and Quality is in details reflect my thoughts on quality.

Recently I gave a presentation on dimensions of quality in software. Following are the aspects that I think are important while evaluating software quality.

•Functionality
•Performance
•Supportability
•Maintainability
•Upgrade
•Integration
•Scalability
•Standards
•Customizability
•Security

Software testing should not just focus on functionality but take care of all the above dimensions also.

Once quality of products and services is handled well, business will take care of itself and there will not be a need to take corrective actions to keep business alive. In my opinion quality speaks for itself.

Related Links:
Take Ten Minutes newsletter . Archives of newsletter containing some insightful articles.
Articles : Articles posted on Philip Crosby Associates website.

Quality is in details

Definition of Quality is always difficult. There are many dimensions and attributes that make up quality. Whether it is quality of product, quality of service, it is difficult to quantify quality.

Of late, I have been thinking that there is one attribute that makes a big difference in quality. Quality is in details. Quality becomes apparent when you take care of details.

A few examples my experiences

I was watching a movie (Hindi) which was supposed to make it big, but apparently failed at box office. In the first scene itself there was a glaring mistake. The scene starts with a prayer room where deities are kept.  Statues of Rama, Lakshmana and Sita are to be kept in a proper order. But in this particular scene it was glaring that even this was wrongly kept. It clearly made it evident that details are not watched closely and I was not surprised that this movie failed at box office.

I liked and watched movie ‘Dil Chahta Hai’ so many times. And in this movie even minor details were taken care of very well. For example, one of the characters in the movie who is portrayed as a serious and intelligent character is shown as solving Rubik’s Cube puzzle. This is a very minor detail and some of the movie watchers might have missed noticing it. But the fact that even such minor details were taken care of reflects the quality of the movie. Of course, this was a big hit movie.

In another telugu movie I watched, Chirunavvuto, it was attention to details that made me like the movie.

Whenever you evaluate a successful product, movie or service, you will find that attention to minute details makes it successful. At same time a critical analysis of a failure may reveal that the big picture is there, but attention to details was missing.

Paying attention to details does not come easily. It requires careful planning, execution, review and validation.

Paying attention to details in every minor task we do can lead us to better quality. This will reflect professionalism. Having spent lot of time in Quality assurance, I tend to notice even minor details carefully.

I do not say, I have perfected this, because even if I sometimes end up stopping going the extra mile due to lack of time or sometimes even skill to make it perfect. For example, I have not really managed to redesign this homepage to my satisfaction. Due to this, inconsistencies in format in browsing my homepage also stand out glaringly and make one feel that the quality of the website can be improved.

When details are taken care of you, you experience a ‘WOW’ factor. You will be surprised that even such details are taken care of and you will be impressed with the same.

Summary

When it comes to quality doing our best is not enough. To give a perfect touch of quality, we need to go beyond the best. Take care of details before we admit that it is complete. Let others experience quality of your work. Remember that this can be achieved only by meticulous planning of minor details and execution without compromise. Quality takes time and it cannot be rushed.

Are you paying attention to details in your job?
Have you recently received any appreciation for taking care of details in your recent work?
Do you take pride in professional quality of your work in every deliverable you do?

Importance of Standards

Have you ever wondered why standards are needed? What if there are no standards available? Either in personal life or work, standards are important. Standards make it easy for us to operate. It gives us predictability and reduces chances of accidents and mishaps.

We live by standards and cannot do without them. But when an attempt is made to implement new standard we resist change.

Imagine life without standards

1. Imagine countries do not have time standards. Then everyone will have a different time on their watch and you can imagine what will happen.

2. Imagine no two streets in a city look the same. Can you travel on road?

3. Imagine one junction uses red for STOP and another junction uses green for STOP. what will happen?

4. Imagine no two cars operate the same way. Can you drive?
5. Imagine each tap operates differently. Turning one way opens in one room, other opens in another room. What would happen?

and so on..Think crazy and imagine what will happen if some of the things you notice are not standardized. Look around and see where standards have been implemented.

I am a cautious driver and despite my cautious driving, I almost had accidents on two occasions. When I analyzed both occasions, I realized that these incidents were due to ‘non-standard’ design of those roads.

Work place Standards

At work places also standards make a big difference. Our expectations will not be met if no standards are followed and everyone operates in their own way.Most of times the standards may be enforced by making it mandatory. In some cases it may be set a guideline.

Forms, Templates, Checklists, Processes etc evolve as organizations mature and try to achieve a standard.

Some people resist introduction of standards as they feel ‘bound’ and ‘restricted’. Some people find chaos when are no standards set and each one operates in a different manner.

It is necessary to define ‘good enough’ processes and standards so that some predictability can be achieved. We can introduce standards for ‘deliverables’ but not how they are delivered.

Standards are most often derived best practices in organizations that are found to give best results and eliminate mistakes.

Next time you are filling a form or asked to fill a checklist, do not dismiss it as ‘useless’ practice. There is a reason why a standard has been established and respect that.

Summary

Whether in day to day personal life or work life, it is good to have a standard way of doing things which reduces risks of errors and failures. Sometimes we may not be able to understand why a particular standard has been set up, but try to follow standard in spirit instead of dismissing them.

I give lot of importance to standards and try to design and put standards in place wherever possible which reduces risks of mistakes and improves ‘professional’ nature of team.

Measuring Software product Quality

Judging software quality is very difficult task. Experience shows tendency to associate the quality of the software with the number of defects encountered during testing and after release is high. This approach is flawed because:

Any problem in the software gets recorded as a defect ranging from GUI Error to application failure.

If we continue to measure software quality just by the number of defects there will never be able to make any software release. Any software is bound to have defects. The business of the company need not depend on the number of defects in the software. A new perspective of looking at the quality of the software is by Assessing the risks associated with the software release. When a user uses the system, what are the likely risks associated with it and what it means to the user.

Thinking in a practical manner you would not visit a hotel if you are sure that by eating there will spoil your health. Even if the hotel happens to be a 5-star hotel you wouldn’t risk it. Right? The name and hype do not matter when it comes to quality. It is the RISK that matters to you.

A list of risks is given in Box below in deploying a computer system [1]:

Computer system strategic risks •Incorrect results will be produced •Unauthorized transactions will be accepted by the system •Computer file integrity will be lost •Processing cannot be reconstructed •Continuity of processing will be lost •Service provided to the user will degrade to an unacceptable level •Security of the system will be compromised •Processing will not comply with organizational policy or governmental regulation •Results of the system will be unreliable •System will be difficult to use •Programs will be unmaintainable •System will not be portable to other hardware and software •System will not be able to interconnect with other computer systems •Performance level will be unacceptable •System will be difficult to operate Testers must understand that their business is to evaluate the business risk and to report those results to management. Viewed from this perspective, testers must first ensure they understand the business risk, and then develop test strategies focused on those risks. The highest business risk should receive the most test resources.

To effectively identify the business risks it is necessary to evolve risk assessment guidelines. Each defect recorded against software should be associated with a risk factor. An effective way of implementing this would be when a tester records a defect he should associate a risk factor based on the risk assessment guidelines. This risk factor should be reviewed by software development group and they should attach their own risk factor to it. A conflict in associating risk factor by a tester and developer needs careful analysis.

This risk factor can be the basis on which

1. Prioritization of defects to be fixed should be done.
2. Decisions to release the software can be made.
3. Decisions whether to fix the defect/implement a feature can also be made.

The five key process ideas (KPIs) of good enough software [2] Systems thinking feeds nicely into risk analysis. Why risk analysis? Here’s why. We are engulfed by uncertainty in every second of software development. When was the last time you were on a project that could not fail? If it really couldn’t fail, weren’t some of the resources or staff for the project more sorely needed elsewhere? In most situations, if we are on a project that can’t fail today, tomorrow our project will be expanded, or our resources will be stolen. Efficient software development necessitates risk taking: The real question is whether we take calculated risks or accidental risks. One way to avoid accidents is through a habit of integrated, structured risk management. By integrated, I mean that every strategy we use to create a positive result (e.g. adding a feature) has an associated risk management strategy (e.g. testing the feature). I’ve observed this habit in many companies but it was especially apparent in the Borland Languages division, where I worked for several years. We identified risks all through the project planning process, we reviewed them, we put risk reduction strategies in place, and we used postmortems and post-ship metrics to calibrate our judgment. We never quantified our risks, however, because we felt that such quantification would be impractical and misleading. Let’s examine a structured, non-quantitative approach to risk analysis. The structure we use at STL is: context, potential, occurrence, short-term consequences, and long-term consequences. When we analyze risk for our clients, we prepare a grid for each of the top 5-7 risk areas that examines that structure. For each element of the structure, we try to discover factors that increase or decrease the risk, and we suggest ideas for risk reduction. The risk description is framed in terms of a problem that may happen and consequences that may follow. That risk has a context in which it exists. Eliminate the context, and we eliminate the risk. For example, if we want to eliminate the risk of software failure, we can avoid developing software in the first place. This is no joke: the common ailment of creeping featurism brings with it the attendant problems of testing, maintenance, documentation, and support for those features. We can eliminate those problems if we resist features that aren’t essential to the success of the product.

Success of testing team will be the ability to identify high risk defects in software and ensure they are fixed.

References:

[1]: Effective Methods for Software Testing By William Perry

[2]: The Challenge of “Good Enough” Software by James Bach, Satisfice Inc. 

Understanding requirements

Understanding customer requirements is the first step towards customer satisfaction. Understanding user requirements is a difficult task in any Industry. More so in Software field where the field is evolving and customer expectations are changing fast. Changing technology makes the process of satisfying customers more difficult.

Understanding practical example of a restaurant can give an idea how requirements get specified and what analysis goes into the same.

Requirements need to be validated with a set criteria. Refined and translated to a more specific criteria.

A customer goes to hotel and asks for a coffee. The various statements that can come in this scenario with varying degree of specific nature of requirements:

• Get me a coffee
• Get me a black coffee
• Get me a coffee without sugar
• Get me a strong coffee without sugar
• Get me a strong coffee with lot of sugar
• Get me a coffee without sugar fast.
• Get me a Hot coffee without sugar in 5 minutes
• Get me a coffee with biscuits/snacks

The scenario where the specifications are very elaborate are easy to comply with and satisfy customer. In each of the above cases there are still some inherent specifications which is left to the supplier. The supplier has to use his own judgement/expertise and satisfy the customer.

Various methods for satisfying customer in each of above scenarios is mentioned below:

Requirement: Get me a Hot coffee without sugar in 5 minutes

Comment: Requirement very clear and elaborate. Even then qualitative aspect of Hot coffee is to be judged by supplier. Should confirm with customer whether the coffee is hot enough to ensure customer satisfaction. Check with customer whether he wants something to munch before he gets to his coffee.

Requirement: Get me a coffee without sugar fast.

Comment: Fast is not specific enough. Should confirm/judge about the time frame. 1 minute or 5 minutes

Requirement: Get me a strong coffee with lot of sugar

Comment: Strong and lot of sugar are subjective. An expert supplier will understand what is enough. Other option is to give the customer Coffee pot with milk and sugar cubes so that the customer can decide how much he needs.

Requirement: Get me a strong coffee without sugar

Comment: Similar to above scenario and leaving out sugar cubes is enough.

In all the above scenarios one aspect of ‘presentation’ is never stated. Whether coffee will be served in a cup or glass or flask is again dependent on the supplier. But there are hidden customer expectations on the same which will be never stated. E.g. you don’t expect a 5 star hotel to serve coffee in a steel glass. If you do so you are not satisfying the customer. In a similar way, a person taking coffee in a fast food restaurant does not expect to be served with a tray of milk, sugar cubes etc.

If a simple scenario of serving coffee has so many complications attached, software requirement specifications are much more difficult to understand.

Some critical steps towards customer satisfaction are:

1. ‘Listen’ to your customer
2. Deliberate on his demands
3. Validate the requirements against standards
4. Seek clarifications in case of doubt
5. Have the communication channel with your customer ‘open’
6. Promise delivery after proper understanding of expectations
7. Deliver on or before time
8. Check with customer how he much he is satisfied with the product
9. Make corrections if needed and possible.

Rules:

1. Do not deviate from what customer expects. If you can’t meet expectations communicate to the customer with valid reasons immediately. Users are rational.
2. The more specific the customer the better for you.
3. Always ask questions. In some cases customer can contradict his statements.
4. Never assume customer’s expectations. Have dialog with customer if possible or experts in the field.

Use tips and rules given above while evaluating requirements in future.

Quality at work

“Do to others as you would have them do to you”

Have you realized the importance of Quality in your daily life.

• Imagine the scooter/car you bought yesterday refuses to start today.
• Imagine the 250 W music system you bought last week refuses to play your favourite song when you wanted to demonstrate your new acquisition to your friends.
• Imagine the fan you installed last month refuses to operate when you came home from hot sun in summer
• Imagine the pen you bought for Rs. 50/- fails to write when you wanted to note an important address.
• Imagine finding an insect in your favourite dish at your favourite restaurant.
• Imagine the bank teller taking half an hour to encash your cheque.

What will you do when you are faced with above situations? What will happen to you?

In every situation you must have chosen the “quality” brand with faith. You choose quality in every walk of your life. Without Quality in each service you are receiving everyday you feel miserable. We demand quality. Quality is important for YOU. So is for EVERYONE. When we demand quality we have the duty to deliver quality also. As a member of society continuously striving for a “QUALITY” life we also do our part unconsciously. Imagine the satisfaction you gain by giving proper directions to a lost person. You have given a quality service. We derive tremendous satisfaction out of doing a good turn or quality work at any moment. Greater will be our satisfaction if we extend this “Quality” aspect into each moment of our life.

Quality is more important than we realize. Quality makes life what it is.

We as professionals in software are responsible for the quality of our products. Imagine yourself typing a 5 page document and the application crashes without saving your work. Imagine as a data entry operator after entering 50 fields losing the data by pressing a wrong key. What it does to you? The faith placed in the product is shaken and you will be pretty scared to repeat the job despite many reassurances. Faith once lost cannot be regained. As a software developer it may be a mere bug to you. But to the user it is more than that. The quality of software depends on putting quality at each stage of software development cycle.

Quality is not someone’s responsibility. It is everyone’s responsibility. A wrongly connected transistor in 250 W music system can make it DUMB. A loosely fitted nut in a scooter can smash the scooter. Quality at every stage of product development is essential for delivering a Quality Product.

Think Quality, Write Quality Code, deliver Quality product.

Quality belongs to none. Quality cannot be qualified or quantified. You have done some work. There will always be a better way to do it. Quality is the BEST you can do. Imagine a painter – he is never satisfied with his work. Every time he looks at the painting he will feel like adding one line here and another there. He ponders, He wonders, He beautifies his creation. If we at our professional arts of conceptualization, design, coding, testing look at our work with such an artistic eye Quality will be come naturally into our products. Continuous improvement, zeal for perfection are needed to build QUALITY AT WORK. TOGETHER we can MAKE it.

“If people knew how hard I worked to attain my mastery, it wouldn’t seem so wonderful after all” – Michelangelo.