
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 TestingDevelopers
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.
|
|
|