Browsing articles from "July, 2012"
Jul 25, 2012


First, test what’s important. Focus on the core functionality—the parts that are critical or popular—before looking at the ‘nice to have’ features. Concentrate on the application’s capabilities in common usage situations before going on to unlikely situations. For example, if the application retrieves data and performance is important, test reasonable queries with a normal load on the server before going on to unlikely ones at peak usage times. It’s worth saying again: focus on what’s important. Good business requirements will tell you what’s important.

The value of software testing is that it goes far beyond testing the underlying code. It also examines the functional behavior of the application. Behavior is a function of the code, but it doesn’t always follow that if the behavior is “bad” then the code is bad. It’s entirely possible that the code is solid but the requirements were inaccurately or incompletely collected and c mmunicated. It’s entirely possible that the application can be doing exactly what we’re telling it to do but we’re not telling it to do the right thing. A comprehensive testing regime examines all components associated with the application. Even more, testing provides an opportunity to validate and verify things like the assumptions that went into the requirements, the appropriateness of the systems that the application is to run on, and the manuals and documentation that accompany the application. More likely though, unless your organization does true “software engineering” ,the focus will be on the functionality and reliability of application itself.

Testing can involve some or all of the following factors. The more, the better.
♦ Business requirements
♦ Functional design requirements
♦ Technical design requirements
♦ Regulatory requirements
♦ Programmer code
♦ Systems administration standards and restrictions
♦ Corporate standards
♦ ♦ Hardware configuration
♦ Language differences

Jul 24, 2012

The WHY ASPECT : Why Software Testing is essential?

Software testing answers the following questions that development testing and code reviews can’t.
♦ Does the software really work as expected?
♦ Does the software meet the users’ requirements?
♦ Do the users like it or is it user friendly?
♦ Is it what the users expect?
♦ Is it compatible with our other systems?
♦ How does the application perform?
♦ How does it scale when more users are added?
♦ Is the software ready for release to production?
♦ Which areas/modules of the software need more work?

What can we do with the answers to above questions?
♦ Save time and money by identifying defects early
♦ Avoid or reduce development downtime
♦ Provide better customer service by building a better application
♦ Know that we’ve met users’ requirements
♦ Build a list of desired modifications and enhancements for later versions
♦ Identify and catalog reusable modules and components
♦ Identify areas where programmers and developers need training

Jul 18, 2012

Functionality Testing

Functional testing is typically the base-line technique for designing test cases, for a number of reasons. Functional test case design should begin as part of the requirements specification process, and continue through each level of design and interface specification; it is the only test design technique
with such wide and early applicability. Moreover, functional testing is effective in finding some classes of fault that typically elude so-called “whitebox” or “glass-box” techniques of structural or fault-based testing. Functional testing techniques can be applied to any description of application behavior, from an informal partial description to a formal specification and at any level of granularity, from module to system testing. Finally, functional test cases are typically less expensive to design and execute than white-box tests.

Testing is aimed at verification and validation — that is, at finding any discrepancies
between what a software/application does and what it is intended to do —
one must obviously refer to requirements as expressed by users and specified by software engineers. A functional specification, i.e., a description of the expected behavior of the software, is the primary source of information for test case specification.

Functional testing, also known as black-box or specification-based testing, denotes techniques that derive test cases from functional specifications.Usually functional testing techniques produce test case specifications that identify classes of test cases and be instantiated to produce individual test

Functional testing can be applied at any level of granularity where some form of specification
is available, from overall system testing to individual units, although the level of
granularity and the type of software influence the choice of the specification styles and
notations, and consequently the functional testing techniques that can be used.

The core of functional test case design is partitioning the possible behaviors of the software into a finite number of classes that can reasonably expected to consistently be correct or incorrect. In practice, the test case designer often must also complete the job of formalizing the specification far
enough to serve as the basis for identifying classes of behaviors. An important side effect of test design is highlighting weaknesses and incompleteness of program specifications.Deriving functional test cases is an analytical process which decomposes
Specifications into test cases.

Jul 13, 2012

Scrum Series I -Daily Stand-Up Meeting

Daily stand-up meetings play a vital role in the successful execution of Agile/Scrum process-based projects.Though Most of us know how to conduct “Stand-up” meetings,it is not conducted authentically most of the times.This article is about how to make Stand-up meetings effective.I expect to hear back from my readers about how they maintain the effectiveness of the daily stand-up in their scrum projects.
It’s extremely important to guide and let our teams know about the usefulness of daily stand-ups.
Beleive me, it’s worth all the efforts as successful stand-ups can guide sprints successfully throughout a Scrum-based project.

Here are tips which may prove helpful.

The need of Disciplne in stand-ups:
Explain your team the most effective ways of using time during the daily stand-up. Then ensure that the team follows them:

The daily stand-up should be time-limited.10-30mins should be enough.
The ScrumMaster/Project Manager should facilitate regular daily meeting times.
Try not to change the time of this meeting . Scrum always demands discipline.
Efforts can be made to update the sprint backlog during this meeting.
Each member of the team should participate in this meeting. In some prjects, senior members sometimes do not participate,
They should be educated on the the importance of their participation and the help they can provide to the team.
Team members should listen and understand the discussions to know how the team as a whole is performing so they can help each other to resolve pending issues.
Its mandatory that each team member remains present till the end. Sometimes members leave after updating their own work plan, but the purpose of the stand-up is to understand how well the team is doing to achieve the sprint goals .

Working with the customer :

The team should think of daily stand-ups as a way to communicate effectively to the customer, in addition to each other, about progress. No one wants any sudden surprises at the end of the sprint; these can be avoided if team members give regular and accurate updates during each daily stand-up.
The real value from the daily scrum is for the team to discover how they can best help each other to meet its sprint commitment.
To this end, it needs to feel free to discuss work, openly and without regard for external observers
The stand-up should go on even if project manager or a few team members could not join on a specific day for any reason.

Set backs faced by new teams
Scrum isn’t easy enough. It requires commitment from each team member, and new members aren’t always used to this work culture.

Below are some obstacles commonly faced by new Scrum teams:

Lack of scrum process knowledge: New Scrum teams need training about the Scrum process so they can effectively use the daily stand-up for its intended purpose. The ScrumMaster needs to provide this coaching and process knowledge to the team(s). In the same way, each team member must actively participate, to communicate how the team is doing and to fully learn the daily stand-up meeting process.

Hiding work details: It’s important that every team member is transparent in his or her work and gives accurate updates. The team needs a place where they can talk without fear of being evaluated or scrutinized by outsiders, especially by managers who might impose consequences. A team member might be less likely to admit a mistake or lack of knowledge if the person who writes her annual review is listening in. But this member’s issue could be critical information for the team to ensure sprint success.The daily stand-up needs to be a safe place for the team to discuss its work: the good, the bad and the ugly.

Comparisons with the Waterfall process
New members will mostly try to relate the Scrum-based process to Waterfall. This, however, is something which must be avoided. It’s important to follow agile process fully and correctly, and it’s the ScrumMaster’s job to make sure his or her team knows how to do this.Not only is the team culture different in Scrum but the way the team works with the customer is different as well.
Working with the customer effectively to deliver each sprint is key in Scrum based projects.


July 2012
« Jun   Aug »