I believe in evolving…

It’s been more than four and half years since I am involved in QA activity and have executed quite a lot number of projects varying from 6 months duration to 2 months. Most of those project execution was based on Waterfall model and Iterative model. One question which keeps coming to my mind is why different companies follow different software development models? Does it really matter to the end users or Client or Stake holders, if you have followed typical waterfall or a fashionable agile model? Why would they even bother about that as long as you are giving them what they want (Quality Software) and on time (satisfying their “Time to Market” clause)? They might be interested in the success rate of the projects which followed “A” methodology or surprised by the “X” amount of overhead some company is charging which follows “B” methodology (which is based on some of the best engineering practices for rapid and high Quality Software Development).

Software is an evolving field and so should be the processes. We need to continuously improve and refine the processes for delivering better and high quality software. One distinctive feature of Agile methodology is regular adaptation to changing circumstances. To improve we should look back, analyse, find out the short coming and rectify it going forward. In the way I understand, nothing is hard coded in so called agile methodology, we adapt good practices, drop  out some unproductive practices and take some time out to see where we stand and how to improve.

So the question is still at it’s own place, why do different companies follows different methodologies? It might be something which is wired into the DNA of the company when it is founded, it might depend on client to client (whatever we can sell) or sometime it’s just like “let’s ride the wave”.*

* Conditions Apply  :)

Comments

  1. prakhar jainApril 07, 2010

    I think now a days all companies want is that resource utilization should be maximum and all decisions should be made by TEAM,not by an individual.
    Now if you can achieve above, what process you follow doesnot matter.

    ReplyDelete
  2. Nishant VermaApril 07, 2010

    I believe that maximizing resource utilization can never guarantee a quality software deliverable. One should focus on quality more than the quantity of hours logged in the time sheet of an individual.

    Thanks,
    Nishant Verma

    ReplyDelete
  3. prakhar jainApril 07, 2010

    Yeah man , resource utilization means every team member is committed and utilize is ability optimally.
    Logging time in time entry tool will not guarntee the resource utilization optimally.

    So if every team member is comitted to his work and delivering results your resource is utlilized optimally.

    ReplyDelete
  4. Zakk WyldeApril 23, 2010

    I believe the words 'maximize' and 'optimize' are not interchangeable here. Maximizing would mean hitting an efficiency of 100% - that would surely fall into the realm of NP hard problems. Nishant, if you hit upon a heuristic to do that - even computationally then you should let the world know.

    Of course everything falls flat when 'humans' come into the picture. Controlled environments are only moving windows completely dependent on the mental makeup of the evaluator.

    ReplyDelete
  5. Nishant VermaApril 23, 2010

    Yes Zakk Wylde , those words are not interchangeable. Well if you see the blog it's a question on why companies follow a different methodology. My views are maximizing the resource utilization will not guarantee you a quality software !!!
    Let me know if I have mistaken you !

    ReplyDelete
  6. Zakk WyldeApril 23, 2010

    Yes, you are right. My post was in reference to the earlier comments. I'm not much of a software guy anyway but I enjoy reading your blog. Keep up the good work!

    ReplyDelete

Post a Comment

Your comments will be reviewed and then published !

Popular posts from this blog

Defect Tracking System – Wastage of Money & Time ???

Image
As a QA I have been logging bugs since 5 years. But what do we do with that ? A typical flow: If this is the only thing we need to do then why taking so much of pain to have a defect tracking system . To log a standard bug (Standard Bug= Broken Functionality), we need to write steps to reproduce, pre-requisites (if any), expected result, actual result, priority, severity, snapshot (if any), Test environment details and finally save it. This takes around roughly 3-5 minutes to log a bug. To say truth, I have never seen any report coming out of defect tracking system which is of use in analyzing the pattern of bug or finding out any trend in them. All I have seen apart from tracking usage, is the summary of bugs with count based on Priority and Severity. Is that the only purpose of Defect Tracking System? If that is the case then why not use a Google spreadsheet rather then investing money of the company and time of QA in a bug logging system. I am sure if we mine the data which i
Read More »

The 3 qualities that will always help you become better at almost anything…

Image
Have we ever noticed how excited we are when we start anything? But it’s a sad fact that 70% of people abandon what they have started with so much energy and love. It could be as small as building a hobby or starting a pet project or even an activity or a side learning we started. “ Well begun is half done .” Aristotle did say this but we are judged for how we have finished something. You separate yourself fro m  the masses when you choose to give that task a finish.  The first quality is finishing off what you started and it helps develop mental stamina or willpower.   It builds confidence and inculcates as a habit in a long run. You don’t need to sign up for the mammoth activity to build this habit, even finishing mundane day-to-day routine tasks will help. Diligence — the quality of working carefully and with a lot of effort Diligence is a quality that almost never will get unnoticed. It’s one of the underlying traits of great works or success. The key to mediocrity on the o
Read More »

Test Case Paths : Happy, Sad & Bad

Image
I came back from the background of writing test cases which were categorized in either Positive or Negative test cases. Positive test cases were business flows which may or may not give any result but they will certainly not give any exception or error. Negative test cases are those test cases which were bound to result into some exception or better expressed as error causing scenarios.  Then those positive test cases were prioritized as High/Medium/Low . Finally it used to result in quite a comprehensive test case document. Then it will go through the process of review and few more updates or change of priority etc. Certainly it is a tedious process. Here in ThoughtWorks I got introduced to different way of categorizing test cases called “ Happy/Sad/Bad ”. A test case which results you in a positive result is a Happy path , for e.g. entering proper username and password on login page. A test case which yields no result like entering invalid username and invalid password on a logi
Read More »