The NVP BUG Report Logo
The NVP BUG Report
April 2009
In This Issue
The Bug's Last Words
Welcome Message
How Not to Run a Testing Project
Traditional vs. Milestone






































Tulip2

The Bug's Last Words


Going Agile?  Here is a quick tip!

Integrate the testers in the development teams.

Teams are responsible for delivering software that meets expected requirements and quality. However, if we want teams to test the software, we must give them the knowledge to do it right. Testers have that knowledge. By integrating testers into the development teams, teams obtain the skills they need to test their software. When you try this, make sure you choose the right mix: one tester on three programmers is a fair but minimal number.



Source: Software Development is Fun Blogspot


 
Welcome,  !
We hope you're doing well.  Spring is near, bringing with it new growth and a renewed sense of direction.  Here at NVP we've been planting seeds and growing them.  We have new programs to offer such as our Targeted Quality Mentoring Program. Check it out!  It might be just what your QA team needs to spruce things up.

We hope you enjoy this month's Bug Report.  If you have any questions or comments, please email nicole.borsoi@nvp-inc.com or reply to this email.

Until next time...
Your QA Advisors at NVP Software Testing

How Not to Run a Testing Project
Real-World Experiences

Written by: Neil Price-Jones, CSTE - NVP Software Testing


Developers always have my sympathy (and that is usually a surprising statement from a tester!).  The final client user starts with an idea and then embellishes it.  They see what they have and start figuring out what they could have.  The end result is that they identify new requirements on the fly.  Development tries to accommodate the changes that were not considered in the original design and requirements.  There is a limit to how much can be anticipated going into a design phase.  There is also a limit as to what will be funded at the start.  And we are all too prone to accommodate changes.  After all the business has reasons for what they want.  Sometimes the changes are easy to accommodate; other times they are not and they require either an unfunded redesign or a patch which automatically makes the code less stable.
 
Once this situation is well advanced we arrive to deal with the testing.  The documentation has not been maintained. The code does not reflect the original design.
 
In this particular case the group was aware that the situation was fluid so we were treated to the dog and pony whiteboard show of the current situation and expected to hit the ground running.  It was grueling to say the least - someone likened it to drinking from a fire hose.  We worked from the existing documentation where possible with the understanding that it was out of date.  Since there was internal audit and an external demanding client there was a need for testing, process and testing process. 
 
One thing we learned very early on was that there was only one development/testing environment.  So any time we tried to test, the ground under our feet shifted with development changes and developers changing.  A couple of the developers were notorious for making changes and then telling us after the fact.
 
We resolved our issue by requesting and building a couple more environments to be used for testing.  However, our attempt to restrict development access to the later environments and control entry of code was said to be too restrictive and too much effort.  So development continued to have access to the later environments with deleterious results.  We tried to implement Change Control but found it was circumvented. 
 
Suffice to say we are still chasing a moving target. Instead of just playing in one environment we now have four environments in which Development is playing.  Various products are at various stages of update.  Changes are lost between environments.  Environments go backwards overnight. Chasing the configuration is a lost cause.
 
This is an ongoing situation at this stage which is rapidly reaching a crisis.  On the testing and QA side, we are making sure our processes are in order and enforcing what we can on development.  We continue to encounter crises caused by the lack of process in the other sides. 
 
We are actively managing each problem as it shows up and implementing the testing and QA as much as time allows to address each situation.
 
The next Bug Report will report on the outcome.
 
If you have experienced a similar situation or have any comments / suggestions / questions, please reply to this email and your response may be chosen for the next Bug Report.
Traditional vs. Milestone

Written by Philip Simon for Software Test and Performance Magazine - www.stpmag.com

Organizations might recognize the need for consultants but remain unsure about how to use them. In a traditional consulting arrangement, a firm might deploy a team of individuals full-time at a client site for
forty hours a week, typically four days at ten hours per day per consultant. Under milestone consulting, a client engages the firm to check in with them on a regular basis, ensuring that the project is meeting its goals. Then there's the hybrid consultant-offering equal parts project manager, techie, and application expert-with on-site visits every two weeks or so.

Consultancies typically prefer the traditional consulting arrangement, primarily because it maximizes billable time and revenue. Second, consultants on the ground can better steer clients in the right direction throughout the project, manage issues and ensure an overall smoother implementation. On the downside, traditional consulting tends to be the most expensive option for clients.

Also, many organizations face end-user availability issues. Client end-users are often overworked and too busy to spend time with consultants. Remember, endusers on implementation teams have day jobs while consultants are there to implement the new system exclusively.

Consultants on site are billing regardless of whether r not their skills are being used efficiently or not. In the rare event that a project is ahead of schedule, rare is the consulting company that attempts to move dates up or suggests that its consultants do not need to be on site for several weeks.

Among the most obvious of benefits of the milestone consulting approach is minimal cost. To the extent that the consultant's arrival is known well in advance, end-users can focus on their day jobs during the week knowing that they will devote certain days to the new system, coinciding with the arrival of the consultant. In theory, this can be more efficient.

But the milestone method should be used judiciously; it is rife with potential disadvantages. For example, there may be no one keeping an eye on the implementation on a daily basis, allowing goals and dates to fall by the wayside. Issues may not be broached in time to address them without impacting a go-live date. Also, the implementation's flow may suffer. Projects that constantly start and stop often lose momentum. Projects with more interruptions have a greater chance of failure and milestone-based approaches tend to have this limitation.

Given the cost of consultants, many clients might question the need to have a team of three or more highly paid hourly resources on staff for forty hours per week. As a general rule, the quality and number of required external resources varies indirectly with the quality and number of available and  experienced internal end-users. In other words, an organization with extensive internal resources and expertise needs fewer external consultants. Organizations cannot expect to successfully implement major systems exclusively with either consultants or end-users. Almost always, a combination of each is required. Another consideration is end-user availability. Regular employees still have to do their day jobs in order for the organization to conduct business. For example, a payroll manager cannot set up, test, and document a new payroll system at the expense of paying current employees. If an organization wants to minimize the number of external consultants on an implementation, it must ensure that the end-users on its implementation team. It must ensure that the end-users on its implementation team are significantly devoted to, and have sufficient expertise in that system. A project's timeframe, complexity and scope are also critical factors. All else being equal, consultants called in to solve a discrete task with no particular due date may not need to show up for months at a time.

Assuming an organization's documentation is sufficient, a consulting firm may be able to perform the work required using the milestone approach. Conversely, consider a client with a bevy of complex issues, poor internal documentation, and a "drop-dead" date of two months to resolve an issue. It's very unlikely that the client will be able to use consultants in a limited capacity. Minimal consultant input and resources does not mean zero. On just about every new system implementation or upgrade,  organizations must use external application experts, technical resources adept at installing the application and seasoned project managers who have dealt with many of the issues likely to face the client.

Many organizations lack the expertise that consultancies provide. As such, organizations benefit from having knowledgeable, on-site consultants who ensure that the project stays on course, issues are reported and resolved and that individual objectives are met. Before hiring external consultants, senior management should consider budget, the state of its internal documentation, end-user availability and the timeframe, scope, and complexity of the issue or project. A complex but poorly-documented issue that needs to be resolved yesterday cannot be accomplished under a milestone approach. At the other extreme, a simple but less urgent issue probably doesn't require a full-time team of consultants to solve it. Most real-world scenarios fall somewhere in between.

Upcoming Events
Do you have a suggestion for a seminar topic?

We are currently deciding on our 2009 seminar lineup.  We want to talk about things that interest you and that affect you in your QA / Software Testing careers.

Please send any topic suggestions to nicole.borsoi@nvp-inc.com.

Save 10%
Our new Targeted Quality Mentoring Program was designed for Quality Professionals by Quality Professionals.  By signing up today you can receive a 10% discount for yourself and anyone else in your company who signs up for the program.  CLICK HERE to find out more.