Testing Team Setup
Generally the small scale software companies believe that
the processes especially testing processes are not applicable to them; and
these are rather a luxurious entity affordable only to large scale
counterparts.
Through this approach we will try to analyse why the
testing team and testing processes are important even for small scale software
companies.
Reasons
The typical reasons for not adapting the structured
testing (includes test methodology, skilled team, process and tooling) are
cost, time, lack of resources, complexity and focus.
What Happens?
What may go wrong with a typical small scale IT house
that does not follow structured testing?
-
Obviously, it is likely that the buggy product
might get delivered to the customer.
-
Without appropriate historical testing data it
may be extremely challenging to estimate the task(s) or project(s) in our
plate.
-
Generally, to overcome this - person dependent
solutions may be applied. (e.g. person X can solve this, etc).
Overall, it becomes difficult to get a person independent
view on reliability and stability of the product / release / patch or anything
that gets delivered to the stakeholder.
So, what should be done?
Building a testing team and setting up the
processes – first of all needs management support and nurturing. Following
small steps can be used just to measure ‘whether
structured testing can help organization’s needs?’; These steps should be
executed at least for the period of Six months:
1.
Identify the owner:
Identify the owner from
within the existing team who can grasp the testing skills and test management
principles or contract / hire a skilled member.
2.
Build the team:
Explore and identify –
people with testing inclination and interest from the existing group.
Candidates from non-IT
wing of your organization who aspire to be in IT may turn out to be good
candidates. Sometimes they prove to be of great advantage. (e.g. BPO candidates
working on process would bring their process knowledge and that can prove very useful
while building business scenarios)
3.
Build skill(s) sequentially:
It is recommended to start
with the low hanging fruit first. And hence the following sequential steps may
be useful:
1.
Start testing the release
without test cases (i.e. finding defects with ad-hoc and exploratory tests):
maintain defects in spreadsheet
2.
Start building checklist of
important tests
3.
Write test cases
4.
Think about test data (e.g.
this involves building separate table(s) / database, writing queries to
populate required data, etc): start maintaining defects in open source defect
management tool.
5.
Now write your testing approach
and follow it across all projects
6.
Think about using a test
automation tool (and automate 5 test cases with the simplest form of
automation)
7.
Think about conducting
load-performance test
8.
Expand your testing approach
Manual testing
4.
Identify Owners:
Each area needs internal
owners to register the hurdles and own the paths to overcome those hurdles.
E.g. owner for manual testing, owner for maintaining testing approach, owner
for automation, etc.
5.
Measure the Benefits:
Measure the benefits and
challenges observed during this pilot phase:
Sample benefits: uncovered
defects, customer feedback on quality (before and after), etc.
Sample challenges: time
spent on testing, development testing co-ordination, etc.
6.
Project benefits against the
cost and decide:
With so much of efforts
and time (minimum 6 months) spent on testing, it is the stage when
organization’s management committee should project the benefits w.r.t. the probable
cost that it may incur.
Consider the cost of
people, tools, infrastructure for the first year.
I would also recommend now
to introduce training cost for the remaining 6 months.
Based on this, project the
defects that should be uncovered in-house and try flourishing your structure
testing practice.
Every month – revisit the
testing approach, compare cost vs benefits projection.
I am sure with these little
steps, people will certainly identify “their own structured testing” – this is
crucial; as each organization has different culture and thus needs different
style of executing structured testing.
