Defect Life Cycle

Hi Friends,

In last few post, we discussed @ SDLC, STLC & Software testing types. Here, we will talk about Defect life cycle, that is - the process followed once the we got the defect.

The bug or defect should go through the life cycle.  The bug attains different states in the life cycle. Any bug to get fixed needs to pass from various phases of life cycle. The life cycle of the bug can be shown diagrammatically as follows,

Life cycle of Bug:

1) Log new defect
When the bug is posted for the first time, its state will be “NEW”. This means that the bug is not yet approved and assigned.
            When tester logs any new bug the mandatory fields are:
Build version, Submit On, Product, Module, Severity, Synopsis and Description to Reproduce
In above list you can add some optional fields if you are using manual Bug submission template:
These Optional Fields are: Customer name, Browser, Operating system, File Attachments or screenshots.

2. Open

After a QA Engineer or tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as “OPEN”.

3. Assign

Once the lead engineer changes the state as “OPEN”, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to “ASSIGN”.

4. Test

Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to “TEST”. It specifies that the bug has been fixed and is released to testing team for next round of testing.

5. Deferred

The bug, changed to deferred state means the bug is expected to be fixed in next releases instead of in the current candidate build. The reasons for changing the bug to Deferred state have many factors like priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.

6. Rejected

If the developer feels that the bug is not valid or genuine, he rejects the bug. Then the state of the bug is changed to “REJECTED”.

7. Duplicate

If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “DUPLICATE”.

8. Verified

Once the bug is fixed and the status is changed to “TEST”, the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “VERIFIED”.

9. Reopened

If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “REOPENED”. The bug traverses the life cycle once again.

10. Closed

Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “CLOSED”. This state means that the bug is fixed, tested and approved.
That’s it. It really easy to remember all above phases of the Bug life cycle or Defect Life Cycle.
  Share your views with us.

How to get started with project & Project management

                   At the start of any project, there will be a variety of ideas and opinions about the purpose and scope of the project, what the final product of the project will be, and how the project will be carried out.  The Project Initiation Stage is concerned with taking these ideas and intentions and developing them into a formal, planned, resourced and funded project.

                  It is also necessary to develop a process by which the project objectives can be achieved. This process will typically involve carrying out a number of tasks and producing a number of products during the course of the project. The tasks produce the products. For clarity of purpose and for control reasons it is useful to arrange these tasks in a top down structure, which progressively specify the required work in more detail.

As a first step, it is important to identify the stakeholders in your project. It is not always easy to identify the stakeholders of a project, particularly those impacted indirectly. Examples of stakeholders are:

• The project sponsor.
• The customer who receives the deliverables.
• The users of the project outputs.
• The project manager and project team.

Once you understand who the stakeholders are, the next step is to find out their needs. The best way to do this is by conducting stakeholder interviews. Take time during the interviews to draw out the true needs that create real benefits. Often stakeholders will talk about needs that aren't relevant and don't deliver benefits. These can be recorded and set as a low priority.
The Project management will run as per following diag-

Step 1: Project Kick Off

             The main aim of project kick off is to produce a plan which defines how to perform the Project Initiation Stage itself. Project Kick Off is therefore concerned with producing a plan of the work required to produce a plan for the whole project.

               So, after finishing Project Kick off meetings, we should have Project Initiation Kick Off Plan listing deliverables, techniques, committed resources and timescales for the Project Initiation Stage.

So simply Project Kick off is nothing but the successful discussion with BA (Business Analyst) who representing the client.

You should be more flexible here, because as you know, lot many compotators are there, offering the same service. So this is your main exam, where you have to stand.

Step 2: Project Goals

After getting deal from client, you should have to be very happy, but also have to work lot. Now your project kickoff meetings will start in order to discuss on following tasks-

ü      Business Requirement

ü      Timeline

ü      Cost

ü      Buffer management & few more

       Once this discussion gone over, Project manager & BA (Who is representing the client here) will seat together & they will work on Business requirement Document (BRD).
Then This BRD will get finalized once got final approval from client, normally lot many changes will be their in the drafted version. Make sure that all this changes should be tracked by using word tracker & should be saved with different version names so that in feature we may use those if any requirement got cancel.
       A project is successful when the needs of the stakeholders have been met. A stakeholder is anybody directly or indirectly impacted by the project.
This is the most difficult part of the planning process completed. It's time to move on and look at the project deliverables.

Step 3: Project Deliverables

Now the hectic work for project manger will start, that is to design SRS along with BA.
Usually BRD is the reference for SRS (System Requirements Specification).  Again same as BRD, project manager & BA have to work together for getting done with requirements. Once all requirements are documented, it should be first got signed off by BA, then few managers from client side. After getting final approval on SRS, have to start this step No: 2 that is WHAT WOULD BE OUR PROJECT DELIEVERABLES?
        Using the goals you have defined in step 2, create a list of things the project needs to deliver in order to meet those goals. Specify when and how each item must be delivered.       Add the deliverables to the project plan with an estimated delivery date. More accurate delivery dates will be established during the scheduling phase, which is next.

Step 4: Project Schedule

Create a list of tasks that need to be carried out for each deliverable identified in step 2. For each task identify the following:

• The amount of effort (hours or days) required to complete the task.
• The resource who will carryout the task.

Once you have established the amount of effort for each task, you can workout the effort required for each deliverable, and an accurate delivery date. Update your deliverables section with the more accurate delivery dates.
      At this point in the planning, you could choose to use a software package such as Microsoft Project to create your project schedule. Alternatively, use one of the many free templates available. Input all of the deliverables, tasks, durations and the resources who will complete each task.
        A common problem discovered at this point, is when a project has an imposed delivery deadline from the sponsor that is not realistic based on your estimates. If you discover this is the case, you must contact the sponsor immediately. The options you have in this situation are:

• Renegotiate the deadline (project delay).
• Employ additional resources (increased cost).
• Reduce the scope of the project (less delivered).

Use the project schedule to justify pursuing one of these options.

Step 5: Supporting Plans

This section deals with plans you should create as part of the planning process. These can be included directly in the plan.

Human Resource Plan

Identify by name, the individuals and organizations with a leading role in the project. For each, describe their roles and responsibilities on the project.
Next, describe the number and type of people needed to carryout the project. For each resource detail start dates, estimated duration and the method you will use for obtaining them.
Create a single sheet containing this information.

Communications Plan

Create a document showing who needs to be kept informed about the project and how they will receive the information. The most common mechanism is a weekly or monthly progress report, describing how the project is performing, milestones achieved and work planned for the next period.

Risk Management Plan

Risk management is an important part of project management. Although often overlooked, it is important to identify as many risks to your project as possible, and be prepared if something bad happens.
Here are some examples of common project risks:

• Time and cost estimates too optimistic.
• Customer review and feedback cycle too slow.
• Unexpected budget cuts.
• Unclear roles and responsibilities.
• Stakeholder input is not sought, or their needs are not properly understood.
• Stakeholders changing requirements after the project has started.
• Stakeholders adding new requirements after the project has started.
• Poor communication resulting in misunderstandings, quality problems and rework.
• Lack of resource commitment.

Risks can be tracked using a simple risk log. Add each risk you have identified to your risk log; write down what you will do in the event it occurs, and what you will do to prevent it from occurring. Review your risk log on a regular basis, adding new risks as they occur during the life of the project. Remember, when risks are ignored they don't go away.

All above discussion, can be simply summarized by using following process –

Please Share your views about project management with us via comments below.

Software Testing Types

Hi Guys,

           I am very much new to software testing, but still i have gone through some websites & some books to learn this topic, Software testing types. In this post i am going to discuss about Software Testing Types (Just Small Introduction) , So Lets go -

ACCEPTANCE TESTING

Testing to verify a product meets customer specified requirements. A customer usually does this type of testing on a product that is developed externally.

BLACK BOX TESTING

Testing without knowledge of the internal workings of the item being tested. Tests are usually functional.

COMPATIBILITY TESTING

Testing to ensure compatibility of an application or Web site with different browsers, OSs, and hardware platforms. Compatibility testing can be performed manually or can be driven by an automated functional or regression test suite.

CONFORMANCE TESTING

Verifying implementation conformance to industry standards. Producing tests for the behavior of an implementation to be sure it provides the portability, interoperability, and/or compatibility a standard defines.

FUNCTIONAL TESTING

Validating an application or Web site conforms to its specifications and correctly performs all its required functions. This entails a series of tests which perform a feature by feature validation of behavior, using a wide range of normal and erroneous input data.
This can involve testing of the product’s user interface, APIs, database management, security, installation, networking, etcF testing can be performed on an automated or manual basis using black box or white box methodologies.

INTEGRATION TESTING

Testing in which modules are combined and tested as a group. Modules are typically code modules, individual applications, client and server applications on a network, etc. Integration Testing follows unit testing and precedes system testing.

LOAD TESTING

Load testing is a generic term covering Performance Testing and Stress Testing.

PERFORMANCE TESTING

Performance testing can be applied to understand your application or web site’s scalability, or to benchmark the performance in an environment of third party products such as servers and middleware for potential purchase.
This sort of testing is particularly useful to identify performance bottlenecks in high use applications. Performance testing generally involves an automated test suite as this allows easy simulation of a variety of normal, peak, and exceptional load conditions.

STRESS TESTING

Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. A graceful degradation under load leading to non-catastrophic failure is the desired result. Often Stress Testing is performed using the same process as Performance Testing but employing a very high level of simulated load.

REGRESSION TESTING

Similar in scope to a functional test, a regression test allows a consistent, repeatable validation of each new release of a product or Web site. Such testing ensures reported product defects have been corrected for each new release and that no new quality problems were introduced in the maintenance process.
Though regression testing can be performed manually an automated test suite is often used to reduce the time and resources needed to perform the required testing.

SMOKE TESTING

A quick-and-dirty test that the major functions of a piece of software work without bothering with finer details. Originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire.

SYSTEM TESTING

Testing conducted on a complete, integrated system to evaluate the system’s compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic.

WHITE BOX TESTING

Testing based on an analysis of internal workings and structure of a piece of software. Includes techniques such as Branch Testing and Path Testing. Also known as Structural Testing and Glass Box Testing.

UNIT TESTING

Functional and reliability testing in an Engineering environment. Producing tests for the behavior of components of a product to ensure their correct behavior prior to system integration.

Please Share your views about Software testing types with us via comments below.

  

Software Testing Life Cycle (STLC)

Hi Guys,

In my last post i explained about SDLC, that is how the softwares are developed. Developing software is not a big deal, but the challange is to develop it without any defect. So SOftware testing is very much important as like as SDLC. Lets take the look at STLC now

Software testing life cycle (STLC) model is basically develop to identify which Testing activities needs to be carry out and what’s the best time to perform them to accomplish those test activities. Even though testing differs between organizations, there is a testing life cycle.

Software Testing Life Cycle phases:
    Requirements Analysis
    Test Planning,
    Test Analysis,
    Test Design,
    Construction and verification,
    Testing Cycles
    Final Testing and Implementation and
     Post Implementation.
Software testing has its own life cycle that intersects with every stage of the SDLC. The basic requirements in software testing life cycle is to  deal with software testing methodologies like Manual, Automated and Performance testing. Let’s see each phase of STLC in details :
1. Requirements Analysis
In this phase Software testers analyze the customer requirements and work with developers during the design phase to see which requirements are testable and how they are going to test those requirements.
It is very important to start testing activities from the requirements phase itself because the cost of fixing defect is very less if it is found in requirements phase rather than in future phases.
2. Test Planning
In this phase all the planning about testing is done like what needs to be tested, how the testing will be done, test strategy to be followed, what will be the test environment, what test methodologies will be followed, hardware and software availability, resources, risks etc. A high level test plan document is created which includes all the planning inputs mentioned above and circulated to the stakeholders.
3. Test Analysis
After test planning phase is over test analysis phase starts, in this phase we need to dig deeper into project and figure out what testing needs to be carried out in each SDLC phase.
Automation activities are also decided in this phase, if automation needs to be done for software product, how will the automation be done, how much time will it take to automate and which features need to be automated. Non functional testing areas(Stress and performance testing) are also analyzed and defined in this phase.
4. Test Design
In this phase various black-box and white-box test design techniques are used to design the test cases for testing, testers start writing test cases by following those design techniques, if automation testing needs to be done then automation scripts also needs to written in this phase.
5. Test Construction and Verification
In this phase testers prepare more test cases by keeping in mind the positive and negative scenarios, end user scenarios etc. All the test cases and automation scripts need to be completed in this phase and got reviewed by the stakeholders. The test plan document should also be finalized and verified by reviewers.
6. Testing Cycles : Test Execution and Bug Reporting
Once the unit testing is done by the developers and test team gets the test build, The test cases are executed and defects are reported in bug tracking tool, after the test execution is complete and all the defects are reported. Test execution reports are created and circulated to project stakeholders.
After developers fix the bugs raised by testers they give another build with fixes to testers, testers do re-testing and regression testing to ensure that the defect has been fixed and not affected any other areas of software.
Testing is an iterative process i.e. If defect is found and fixed, testing needs to be done after every defect fix. After tester assures that defects have been fixed and no more critical defects remain in software the build is given for final testing.
7. Final Testing and Implementation
In this phase the final testing is done for the software, non functional testing like stress, load and performance testing are performed in this phase. The software is also verified in the production kind of environment. Final test execution reports and documents are prepared in this phase.
8. Post Implementation
In this phase the test environment is cleaned up and restored to default state, the process review meeting’s are done and lessons learns are documented. A document is prepared to cope up similar problems in future releases.
Share your views about Software Testing Life Cycle (STLC) with us via comments below.

What is Software Development Life Cycle (SDLC)

Hi Guys,

All softwares are developed by following some protocol, known as SDLC. Lets take a look what exactly it is-

The Software Development Life Cycle (SDLC) (also called as System Development Life Cycle) is the defines the steps or stages/phases in the building of software.
SDLC is the process of building the system or software that result in a high quality, cost-effective, within time and efficient application that is cheap to maintain, easy to enhance and that can work effectively.  It is divided in several phases and each phase comprised of multiple steps, and they are as follows:

Software Development Life Cycle (SDLC) Phases

This is also known as Classic Life Cycle Model (or) Linear Sequential Model (or) Waterfall Model. This model has the following activities.
1. Requirements and Feasibility Study
In this phase the desired system is examined and determined that whether new system is actually achievable or feasible. In this phase, the development team visits the customer and studies their system. They investigate the need for possible software automation in the given system.
At the end, the team furnishes a document (SRS) that holds the different specific recommendations for the candidate system. It also includes the assignments, costs, project schedule, target dates.
2 & 3. Analysis & Design
In this phase thorough system requirements are gathered by IT specialists, analyzing of the requirement undertaken. Also the software’s overall structure and its nuances are defined. In terms of the client/server technology, the number of tiers needed for the package architecture, the database design, all defined in this phase. In short – a software development model is thus created.
Analysis and Design are very crucial in the whole development cycle. Any glitch in the design phase could be very expensive to solve in the later stage of the software development. Much care is taken during this phase. The logical system of the product is developed in this phase.
4. Coding/ Development
In this phase the design is executed into physical system by building the database and programs. The design must be translated into a machine-readable form. The code generation step performs this task. If the design is performed in a detailed manner, code generation can be accomplished without much complication.
5. Software Testing
Once the code is generated, the software program testing begins.  In this phase a thorough testing is done on developed system. Different testing tools and methodologies are already available to test the softwares. Some companies build their own testing tools that are tailor made for their own development operations. Basically Manual and Automation testing done in this phase.
6. Acceptance ( Deployment )
In this phase the system is deployed in to actual workforce and used. The software will definitely undergo change once it is delivered to the customer.
At Capacity, we follow the SDLC to build an application so that it is of high quality, cost-effective, easy to enhance and that can work effectively. Below is the diagram that can summarize our way of working using SDLC.
                        This article will clear all your doubts about Software Development Life Cycle (SDLC). Share your views with us via comments below.