Posts Tagged ‘QA’

The Proof is in the Pudding- Stating the Obvious III

January 31, 2009

Contrary to what many programmers think, QA role is not to do the dirty work for them. QA’s role is to validate, independently, that the code actually works.

The reason I put the responsibility on the coder is simple. The coder is the one who writes the code, the one that understands it and the one that can change it. Why should anyone else be the owner ?

QA has a lot less options for proving the code works and reducing the risk than the developer, they can only test the functionality from a black box perspective.

Smart Software Developer using Virtual Lab Automation

Smart Software Developer using Virtual Lab Automation

The developer, on the other hand, has multiple options , beyond the ones already listed in part II.

  • Rewrite the code in a more modular fashion so it is easier to have unit tests
  • Move from c# to Python to make it easier to write mocks and do sub system testing
  • Add logs, alerts and assertions so he knows that edge conditions are safely handled
  • Refactor the code so User Interface validations and server validations use the same mechanism
  • Add new code with a separate flag\object\screen so it has less chance to have regression on other functionality
  • Shout at the product manager that the requirements are too complex and there is not way to implement them In SQL with proper testing
  • Move from simple ASP.NET mode to MVC model so more parts of the UI can be tested separately
  • Ask QA to help with extensive PRE-COMMIT manual testing as part of the development stage
  • Ask QA to help with running the automatic testing on development branches
  • Help the  Automated QA team  to make sure new features are tested during the development stage and not post deployment

The manager role is:

  • Iterate over and over the concept of ownership, proof and responsibility
  • Back the theory with resources – buy machines for testing, software for code checking etc
    • For example, buying two servers for the clustering team so they can test their code actually runs on a cluster
  • Help to manage trade-offs and real world considerations
    • For example, which functionality is used a lot and which is hardly used
  • Pay the “price” for making higher quality code
    • For example, Pay $50,000 for a new automated testing project
  • Avoid being dogmatic in the specific methodology
    • For example, unit testing might not be effective in certain places and forcing everyone to do them will just create resentment
  • Introduce and promote new technologies such as Virtualization and lab automation
  • Help apply the right methods in the right context
    • The JavaScript testing framework is great, but should we implement it right now ?

To summarize, like any other professional, the developer is the one responsible for the quality of his or her work.Allowing them to push unproven code to customers is what gave us bad reputation as an industry.However, the best ones are able not just to code, but also to analyze the risk, check for validity ,rewrite and design to create bullet proof products.

And if you read so far, here is a reminder to a lovely 80’s song.

Product Management in the Real World -“The Divider” Case Study, Part II

February 22, 2008

There are scratches all around the coin slot
Like a heartbeat, baby trying to wake up,
But this machine can only swallow money.
You cant lay a patch by computer design.
Its just a lot of stupid, stupid signs.
 

Two weeks later Ron sent an initial version to QA. The testers vigorously began opening bugs with hilarious titles: “Nothing Works!”, “GUI Crashes Every 46 Seconds” ,”Spelling Mistakes in Non Existent Help Screens”. The coders raged about QA’s inability to overcome transitory hiccups, and silently ran to fix the problems.  

An improved version with most of new features was deployed to QA after a two month delay. Surprisingly, it turned out the old, “existing” features the divider was supposed to expose are hardly working. Since they had no user interface the testers “forgot” to check them.  It seemed customers were not using the protections either.

The default setting for the innovative protections was set to off, as it raised too many false alarms.  Since there was no visible way to turn them on, only the most advanced and innovative, paranoid customers implemented the protections.

To make things worse, no support tickets were open as well, and the CMO was convinced the product is top notch.

Sigourney shouted at Ron:”How can you provide a product that’s not working? Did you ever test it yourself before deploying to QA? “Ron, who wasn’t the quiet type, responded: “I own the SQL Guardian” that works smoothly. The “Data Crusher” was written by the company founder five years ago and you can talk to him about it. I did not join this company to be a code monkey. You are throwing undefined tasks at me, stealing Mark for other projects and then wonder why things break.  I will not stand this hypocrisy”.

team-problem.jpg

Rumors of the problems reached Oberon, the director. He moved three additional developers to help the project. Although Ron felt the project is running out of control, bugs were fixed at a much higher rate. The director ran a daily status meeting to monitor the development and reprioritize trivial bugs. He kept the team confident :”Microsoft ships with many bugs and they still rule the world”,” In a 1.0 version  customers are forgiving for minor problems”.

The marketing department published a passionate release note regarding the innovative new concept TASP security will present in. The stock rose and the sales team was energized. The entire R&D helped and people worked around the clock. Following three months of intense work, a Go-No-Go dissuasion was held with QA, R&D and product management.

QA felt the product is not mature enough, but the rest of the team ignored them. There wasn’t a single product they ever approved, not even the successful “Knowledge keeper” .The exhausted Sigourney felt the product is ready and people got tired of the repeating delays. Five months later than the original plan, the pressure was mounting to go ahead and release.  Ron was the only opposition, and refused to be responsible for the results. Oberon considered all the options and decided to ship. To comfort Ron all the limitations will be listed in a ten page long release notes paper.

Stay tuned for Part III – The Customers.


Follow

Get every new post delivered to your Inbox.

Join 137 other followers