Friday, June 21, 2013

Difference between Google and Microsoft approach....using 80/20 rule

 Microsoft’s own research found that the average user of Word uses only *8%* of the functionality, we can come up with the questions that :

If Microsoft had developed only the important 8% of Word, maybe they could still have captured the same market share? 

On the other hand, It’s also worth considering the impact on user experience. Google has shown us that users often prefer apps that do just what you want. That’s *just* what you want. And no more. The rest is arguably clutter and actually interferes with the user experience for only a limited benefit to a limited set of users.

- See more at:

Why we need Agile Practices

The use of the word agile in this context derives from the agile manifesto.  

A small group of people got together in 2001 to discuss their feelings that the traditional approach to managing software development projects was failing far too often, and there had to be a better way.  They came up with the agile manifesto, which describes 4 important values that are as relevant today as they were then.  

It says, “we value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  •  Customer collaboration over contract negotiation
  •  Responding to change over following a plan

These are characteristics that are common to all agile methods, and the things that make agile fundamentally different to a more traditional waterfall approach to software development.  They are:

1. Active user involvement is imperative  
2. The team must be empowered to make decisions  
3. Requirements evolve but the timescale is fixed  
4. Capture requirements at a high level; lightweight and visual  
5. Develop small, incremental releases and iterate 6. Focus on frequent delivery of products  
7. Complete each feature before moving on to the next  
8. Apply the 80/20 rule  
9. Testing is integrated throughout the project lifecycle – test early and often 10. A collaborative & cooperative approach between all stakeholders is essential

See more at:

Thursday, June 20, 2013

Relationship between Agile and Lightweight process

Few days back, I came across quite good article by "Glen B. Alleman- Agile Methodologies", I found quite reasonable brief explanation of lightweight and measuring "agility" of the project.

Lightweight and Agile are not interchangeable words how-ever. This distinction is not well understood by many agile proponents,you can find the distinction below:

Lightweight describes the weightiness of the process and its artifacts. The amount of potentially non–value added artifacts produced by a specific process. 

This weightiness can be attributed to the undesirable consequences of the process – artifacts that don’t provide benefit to the out-come. This weightiness can also be attributed to the application of a specific process. 
"Agility" describes the behavior of the participants and their ability to move or adjust in new and possibly unforeseen situations.

Much like an overweight boat, airplane or athlete, the undesirable weight needs to be removed in order to increase the efficiency of the vehicle. This is a standard best practice in many engineering disciplines. 


Friday, February 15, 2013

10 useful tips for Software Testers

  1. When testing, never tamper with the testing environment that you have set up.
  2. Set up goals for yourself. Start each testing day with the aim of reporting maximum Bugs. Make the day worthwhile and try to add maximum value
  3. Apart from following the test cases, allocate some extra time for exploratory testing of the application. Chose a section of the application and make sure that by the end of the day you have not left any part of it untested.
  4.  Devise practical life scenarios that can aid in testing the application from different angles.                                                               
  5.  No bug in application is small enough not to be reported. Be it application crashing or a minor issue of text alignment, report them all.
  6. Bug reporting should be more efficient. Try not to merge too many issues in one JIRA. This way there is a chance that few important points can get overlooked.
  7. Make sure the steps to reproduce for an issue are detailed and easy to follow. Do not miss out any detail so that the issue is easily reproduced at the other end, and minimal questions are asked from you during the workaround.
  8. Review the Bugs reported periodically as it would help in making the test case updates process more efficient for future version.
  9. Write all important observations during testing on a word document. It would help to save a lot of time while reporting bugs or creating new scenarios for testing
  10. Most importantly, stay focused. The time you spend testing, keep your attention on the task at hand only as I believe testing is all about “Focus” and “intent of finding errors”.