By and large software
development projects proceed as per the following team structure
1) Team of Feature
Owners: It is a top-level team in the hierarchy, which directly interacts with
the prospective customers. It is responsible to minutely understand the
customer requirements and groups them into several features. Various members in
such a team may become the owners of some of such features. The team members
take due initiative and actively interact with various teams become
instrumental in providing necessary directions in developing the features owned
by them.
2) User Interface Team:
The User Interface called UI in short is extremely significant for the product.
Even if a software product has series of excellent features, but its User
Interface is not effective & convenient, the product is destined to fail.
Hence independent User
Interface team is created. The members of a User Interface team are specialists
in designing the User Interface for the software products and understand the
difference among a good User Interface and a poor one. The sole objective of
such User Interface team is to do extensive research in the User Interface.
The UI team designs UI
for the product or its features. In the next step the UI team interacts with
Feature Owners team to give a practical shape to the UI jointly. Such meeting
may result into may be "Page designs" or some "Mockups"
containing all elements of the UI as required in the page. The mockups are
helpful in presenting the desired appearance or looks of the page. Actual
navigation between various pages is also checked during such cross-functional
meetings.
3) Development Team: Is
entrusted the task of development of the Product.
4) Testing Team: Is
entrusted the task of testing the product.
FLOW OF THE PROCESS:
1) Project Kick Start:
The members of feature owners team kick start the process with the development
of a design document at High level applicable for every feature & the same
is released to all concerned.
2) Release of High Level
Design Document: Apart from the High level design document prepared by features
owners, the designs of the pages or the User Interface Mockups are released to
all concerned for reference by the UI teams.
3) Software Development:
Coding of the desired features is started by the development team as per the
released documents.
4) Software Testing: The
testing team kick starts the testing related activities in the following
manner:
($) Preparation of a
Document with Test Outline: This document describes details of flows of the
test or Multiple-Test Scenarios projected at high level. Test outline shall
have brief information as to what needs to be checked at which point during the
flow.
In addition to the
details of flows, this test outline document contains detailed matrix
describing all the requirements from the High Level Design Document (HLD) down
to the test flows. In HLD a unique ID can distinctly identify each requirement.
The purpose of this matrix is to make sure that all requirements have been
carefully checked for any deficiency.
($) Preparation of Test
Cases: Every test scenario is further converted to an individual test case,
which contains all the detailed information. It specifies exact steps for
navigation, desired data and detailed information as to what needs to be
checked. Detailed explanation in Test Cases is helpful especially when the
persons writing the test case are other than the persons going to execute them.
($) Test Automation:
Although not compulsory, test automation is optional step. This involves
automation of the designed test cases with the help of some automation tool,
best suited to the requirements of the company.
($) Concurrent
Activities: Development & testing work is carried concurrently. The
development team gets engaged in the main task of coding of the desired
features. Development team sometimes does some sort of testing at their end as
well. In the meantime the testing team prepares the test cases for manual
testing and automation scripts for automating the test execution with the help
of some automation tool.
($) Product Testing: The
cycle of testing begins when the testing teams actively start the testing of
the product and start logging the bugs in the defined bug repository system.
Concurrently the developers are engaged in fixes of the bugs.
As a best practice, two
separate instances of the application are maintained. One instance is earmarked
for the testing team and the second one is meant for the team of developers or
bug fixing team. However both the teams operate on the same code level.
($) Logging of Bugs:
Prior to logging a bug in bug repository system, it is verified as to whether
we can reproduce it in the instance meant for the developers or not. If the bug
is reproducible, it is assigned to the concerned developer for necessary
fixing. When the bug is fixed, then the code fix is applied on developer's
instance, thoroughly verified and then it is applied to the testing team's
instance for regression testing.
However if the bug can
not be reproduced on developer's instance, it may be inferred that it can be a
problem related to some type of application setup. In such case the developer
interacts with the testing team to ascertain if it is a genuine bug requiring
changes in the code or it is some kind of application setting issue. Such
application setting issues are quite common during testing of software suites
of tightly integrated products.
($) Regression Testing:
Code patching is done & the testers repeat the testing from the beginning.
In order to fix the bugs, frequent patching of the system is avoided. As per
the best policy for patching the bugs, involving for multiple rounds of
testing, patching of all bugs accumulated between two testing rounds is done
once only, The bugs are fixed and kept ready for patching together. This also
does not have a hard & fast rule. Exceptions are there for bugs, which are
considered to be critical & which can severely hamper the testing can be
patched immediately.
($) Sanity Testing:
After the patching is done, the application instance is subjected to sanity
testing by the development team. Then it is released for the next testing round
involving execution of all the test cases again. This includes execution of the
test cases which happen to pass in the previous round.
($) Stopping the Testing
Operation: In a scenario of multiple testing rounds, an important decision
needs to be taken as to whether to proceed to the next round of testing or halt
there itself. The vital decision to a large extent depends upon the number of
bugs which had been logged during the previous round of testing. Two factors can
help take such a decision are:
1) Further testing can
be stopped when no fresh critical bugs are detected & when there is no
further need felt for regression testing.
2) Further testing can
be stopped when very less number of minor issues are left. The term
"Less" is highly subjective and depends largely upon the application
under test.
Article Source: http://EzineArticles.com/?expert=Yogindernath_Gupta
Article Source: http://EzineArticles.com/1717647
No comments:
Post a Comment