Software Testing and QA Process

Overview

Customer satisfaction is a priority for any business, and we make every effort for excellence in all our obligations. Quality for us is always defined from the customer’s viewpoint. Our quality guarantee is effective in helping to manage and deliver high-quality projects that meet customer expectations.

This article describes the quality assurance. Furthermore, highlight approach to software testing, stages where tests are performed, and QA procedures adopted.

QA process is a self-determining process from the developing process which runs parallel to the entire software development life cycle. The handle of separate devotes people and resources, which include the QA team.

We have a committed team of quality control professionals to accomplish the creation of the test plan, developing scripts for automated tests, executing manual and automated test plan, stress, load and all kinds of tests.

Software Quality Assurance process is the way that people, procedures, guidelines, measurements, tools and equipment are to integrate software released to confirm our customers are of high quality.

The goal of our QA process is to ensure the delivered products meet the exact customer requirements and avoid duplication of customer bugs and achieve quality, on-time delivery and optimal productivity.

Although QA testing can continue and explore the infinite extended to testing, the test volume limited to protect the delivered product meets the customer’s specific needs and to avoid repetition of the customer’s failure to comply with the limited resources and tight schedules.

QA resources involve in the very beginning of the project and continue to the end of the project.

Life Cycle Quality Management

We started with how important quality is to the company, and now we want to explain the processes that are in place to provide quality on each version release cycles.

The following describes how and its customers acquire the efficiency gains across the software lifecycle through a quality-focused approach has been extensively used, implemented in practice been monitored and continuously improved through a feedback mechanism.

• Effort estimation and Project initiation – The project schedule and effort estimates for each task is recorded and documented in accordance with this phase.

• System study and evaluation of user requirements – During this phase of the assesment process will be carried out on the claims. There can be spotted flaws in user requirements, and measures taken to improve them in terms of clarity or goal.

• Test Plan – A software project test plan drawn which describes the objectives, scope, approach and focus of a software testing effort. The process of preparing a test plan will take into account the efforts needed to validate the acceptance of a software module, version or patch. The completed document will help members outside the test group understand the “why” and “how” product validation.

• Designing Test Cases – At this stage test document will describe an input, act or event, and an expected response to determine whether a function of an application is working correctly.

• Determine the Test Environment – The situation under this approach would be the collection of test environments that simulate possible hardware, software, network, data and performance expected production environments that will be used the software.

• Initiate testing – Accepting a build – When a build is ready for testing developers make an internal release to the QA. The release notification should be made through an email. The release email should contain following:

# The version number.

# Checklist confirming all the unit tests passed and basic functionality tests done.

# New features added in current build (QA should focus on this area and do deep testing before doing any regression testing).

# List of bugs fixed in the current build.

Series of build acceptance tests will be performed on localized builds from engineers. These tests require a certain level of quality prior to commencement of testing. These include

# Run the manual tests to check the basic functionality of the System. (Sanity Check)

If these test execution is Blocked, it should be reported to Bugzilla as a Blocker. Reject the build if a Blocker is found. QA may continue if a patch (work around) is available. Development team needs to attend this immediately and release a new build with the fix.

If product is intended to deploy on multiple platforms, QA must install the product and execute above tests in all the target platforms and environments [If the target platforms are available].

• Execute the Test cases with the Testing Techniques – The testing process will be directed in accordance with this procedure. They designed the test cases will be used to test techniques to evaluate the quality of the system. Testing techniques can vary from project to project. After identifying the areas of the application to be tested must be the type of tests is determined. The main techniques we use are:

• Sanity testing or smoke testing – Typically, a preliminary test to determine if a new software version is performing well enough to accept it for a major testing effort.

• Business User Acceptance testing – Preliminary tests based on the specifications of the end user or customer, or based on the use of end users / customers over some limited period.
• Comprehensive testing:

• Black box testing – This is not built basically by understanding the core design or its code. The testing is based on the client requirements and its functionality.

• Functional Testing – Developed each functional test will be based on customer specific documentation, and review of any existing syst Devoted QA Testers will execute these functional tests manually.

• Compatibility Testing – QA team provides for tests to be performed on multiple browsers and operating systems. The desired test combinations and process (including prioritization of test) will be determined during the demarcation process.

• Integration testing – Testing of combined parts of a program to determine if they function together correctly. The ‘parts’ can be code modules, individual applications, website booking engines etc.

• Incremental integration testing – Added to constant control of an application as new functionality; requires that various aspects of an application’s functionality be independent enough to work separately before all parts of the application is closed.

• System testing – The entire system is tested as per the client requirement. Black-box type testing that is based on overall requirements specifications, covers all combined parts of a system.

• End-to-end testing – Testing with real-world scenarios.

• Regression testing – Re-test after fixes or modifications of the software or its environment.

• Load testing – Testing a particular application with different load scenarios, using various testing tools.

• Stress & Performance testing – Measurement of throughput and response time of the system under various workloads. We use tools to assess how the site / product hold up under different loads, and we provide the customer with comprehensive data to scale site / product up to meet higher loads.

• Usability testing – Testing for ‘user-friendliness’.

• Penetration testing – Testing how well the system protects against unauthorized internal or external access.

• Reporting and Monitoring of Issues – We have a centralized web-based tracking database – Bugzilla will be accessed by our QA team and can be used by other internal teams to report and monitor progress and solving problems.

• Provide a QA report by Each QA Engineer – All QA engineers must prepare a QA report for evaluating the quality of every module/screen of the system and send the document to the quality assurance manager. In this report, time taken for testing, number of issues found, number of issues fixed, repeating bugs and the comment on the tested areas are included.

• Documentation – After releasing the tested project to the customer, the QA team must compile all documents used for testing. The documents will include Release Notes, QA certifications, Test Plan, Test Cases, Report of Issues and User Manuals.

• Feedback and Improvement – The above documents will be analyzed to understand, improve processes and testing criteria, and thereafter will be used as appropriate in future projects.

• Release procedure –

• When to release software?

It is true that QA testing can continue and explore test infinite extension. But the test range should be defined in such a way to cover best possible high-risk areas within available time frame. Series of tests must be performed on a proposed final build of the product to ensure that it has sufficient quality to release to the customer. This will be a subset of the overall test plan and technical analysis. The software can be released when all errors are corrected and verified and QA has completed all the tests defined in the test plan / UAT etc. and they all pass or are minor bugs that have little or no impact to the system and the customer can be convinced.

Under no circumstances software should not be released:

• Without QA testing.
• When software has BLOCKER, CRITICAL bugs.

• Releasing a software

Once the above criteria’s are passed QA should prepare the installation image for release. Before that a sanity check must be done using the new release tag. The installation image should be in compressed format (rar/zip) and should be able to extract at a customer site. This will be copied to a place like share/releases/{customer name}/{version}.

A copy of this will be sent to the customer. This will ensure that software released is tested and QA is responsible against the agreed test coverage documented in the test plan.

Software archived for the shipping need to be checked for Virus using the latest Virus guard.

Bugzilla must be queried for any outstanding Blocker, Critical and Major bugs. All bugs of the status Unconfirmed, New, Assigned and Reopened in the bug database should be queried.

Send the Release e-mail to development and management team in the project.

Sample Shipping request email:

To : {project-manager}@{domain}

CC : {The relevant people}

Sub: {Customer-Name}_{Version No} is ready for shipping

Hi <Project-manager’s name>,

{Customer-Name}, {Version No} is ready for shipping (With limitation).

Please refer to the software release for more details. Herewith attached the QA Certificate and the Release Note.

Installation image {and other require files} available at {Location of the software archived}.

Thanks.

Best Regards,