Software process

Real_Time_Bug_Tracking_Procedure

 Real_Time_Bug_Tracking_Procedure

Test Standards

Standards and Acronyms

A large number of standards are mentioned in this paper, normally by reference to the originating standards body and standard number only, such as “BS 7925-1”.  This list gives the name for each of them, along with any acronyms used.

DO-178B Software Considerations in Airborne Systems and Equipment Certification
IEEE The Institute of Electrical and Electronics Engineers
IEEE 610 Standard Computer Dictionary
IEEE 610.12 Software Engineering Terminology
IEEE 730 Standard for Software Quality Assurance Plans
IEEE 829 Standard for Software Test Documentation
IEEE 1008 Standard for Software Unit Testing
IEEE 1012 Standard for Software Verification and Validation
IEEE 1028 Standard for Software Reviews
IEEE 1044 Standard Classification for Software Anomalies
IEEE 1044.1 Guide to Classification for Software Anomalies
ISO The International Organization for Standardization
ISO 9000 Quality management and quality assurance standards
ISO 9001 Model for quality assurance in design, development, production, installation
ISO 12207 Software life cycle processes
ISO 15026 System and software integrity levels
ISO 15288 System Life Cycle Processes
ISO 15504 Software process assessment
NIST The National Institute of Standards and Technology
NIST 500-234 Reference Information for the Software Verification and Validation Process
PSS Procedures, Specifications and Standards
PSS-05-0 ESA Software Engineering Standards
SEI The Software Engineering Institute
SE CMM Systems Engineering Capability Maturity Model
SW CMM Capability Maturity Model for Software

Software Bug / Defect Life Cycle

       Let’s look into it. Suppose a tester finds a defect .The defect is assigned a status, new.

       The defect is assigned to development project manager who will analyze the defect. He will check whether it is a valid defect.

       If not , next the defect is checked whether it is in scope. Suppose you find a problem with the email functionality. But it is not part of the current release .Such defects are postponed

       Next, manager checks whether a similar defect was raised earlier . If yes defect is assigned a status duplicate

       If no the defect is assigned to developer who starts fixing the code. During this stage defect is assigned a statusin- progress.

       Once code is fixed. Defect is assigned a status fixed

       Next the tester will re-test the code. In case the test case passes the defect is closed.

       If the test cases fails again the defect is re-opened and assigned to the developer

       Consider a situation where during the 1st release of Flight Reservation a defect was found in Fax order which was fixed and assigned a status closed

       During the second upgrade release the same defect again re-surfaced. In such cases, a closed defect will be re-opened. That’s all to Bug Life Cycle

Download the sample Defect sheet

http://www.4shared.com/office/J4-C9pDP/Defect_Report_Template_V10.html

Web Application Testing

Web Application Testing

Web application is tested in 3 phase





Web tier testing—Browser compatibility.
Middle tier testing—Functionality, security.
Data base tier testing—Database integrity, contents.
Types
1) Functionality Testing
2) Usability testing
3) Interface testing
4) Compatibility testing
5) Performance testing
6) Security testing
1) Functionality Testing
This is used to check of your product is as per the specifications you intended for it as well as the functional requirements you charted out for it in your developmental documentation.Testing Activities Included
Test all links in your webpages are working correctly and make sure there are no broken links.
Outgoing links
Internal links
Anchor Links
Mail To Links
Test Forms are working as expected :Forms are the integral part of any web site. Forms are used to get information from users and to keep interaction with them. So what should be checked on these forms?
First check all the validations on each field.
Check for the default values of fields.
Wrong inputs to the fields in the forms.
Options to create forms if any, form delete, view or modify the forms
Database testing:
Data consistency is very important in web application. Check for data integrity and errors while you edit, delete, modify the forms or do any DB related functionality.
Check if all the database queries are executing correctly, data is retrieved correctly and also updated correctly. More on database testing could be load on DB, we will address this in web load or performance testing below
Test Cookies are working as expected. Cookies are small files used by websites to primarily remember active user sessions so you do not to log in every time you visit a website. Cookie Testing will include Testing cookies (sessions) are deleted either when cache is cleared or when they reach their expiry. Delete cookies (sessions) and test that login credentials are asked for when you next visit the site.
2) Usability Testing:
Test for navigation:
Navigation means how the user surfs the web pages, different controls like buttons, boxes or how user using the links on the pages to surf different pages.
Usability testing includes:
Web site should be easy to use. Instructions should be provided clearly. Check if the provided instructions are correct means whether they satisfy purpose.
Main menu should be provided on each page. It should be consistent.
Content checking:
Content should be logical and easy to understand. Check for spelling errors. Use of dark colors annoys users and should not be used in site theme. You can follow some standards that are used for web page and content building. These are common accepted standards like as I mentioned above about annoying colors, fonts, frames etc.
Content should be meaningful. All the anchor text links should be working properly. Images should be placed properly with proper sizes.
These are some basic standards that should be followed in web development. Your task is to validate all for UI testing
3) Interface Testing:
The main interfaces are:
Web server and application server interface
Application server and Database server interface.
Check if all the interactions between these servers are executed properly. Errors are handled properly. If database or web server returns any error message for any query by application server then application server should catch and display these error messages appropriately to users. Check what happens if user interrupts any transaction in-between? Check what happens if connection to web server is reset in between
4) Compatibility Testing:
Compatibility of your web site is very important testing aspect. See which compatibility test to be executed:
Browser compatibility
Operating system compatibility
Mobile browsing
Printing options
Browser compatibility:
In my web-testing career I have experienced this as most influencing part on web site testing.
Some applications are very dependent on browsers. Different browsers have different configurations and settings that your web page should be compatible with. Your web site coding should be cross browser platform compatible. If you are using java scripts or AJAX calls for UI functionality, performing security checks or validations then give more stress on browser compatibility testing of your web application.
Test web application on different browsers like Internet explorer, Firefox, Netscape navigator, AOL, Safari, Opera browsers with different versions.
OS compatibility:
Some functionality in your web application is may not be compatible with all operating systems. All new technologies used in web development like graphics designs, interface calls like different API’s may not be available in all Operating Systems.
Test your web application on different operating systems like Windows, Unix, MAC, Linux, Solaris with different OS flavors.
Mobile browsing:
This is new technology age. So in future Mobile browsing will rock. Test your web pages on mobile browsers. Compatibility issues may be there on mobile.
Printing options:
If you are giving page-printing options then make sure fonts, page alignment, page graphics getting printed properly. Pages should be fit to paper size or as per the size mentioned in printing option.
5) Performance testing:
Web application should sustain to heavy load. Web performance testing should include:
Web Load Testing
Web Stress Testing
Test application performance on different internet connection speed.
In web load testing test if many users are accessing or requesting the same page. Can system sustain in peak load times? Site should handle many simultaneous user requests, large input data from users, Simultaneous connection to DB, heavy load on specific pages etc.
Stress testing: Generally stress means stretching the system beyond its specification limits. Web stress testing is performed to break the site by giving stress and checked how system reacts to stress and how system recovers from crashes.
Stress is generally given on input fields, login and sign up areas.
In web performance testing web site functionality on different operating systems, different hardware platforms is checked for software, hardware memory leakage errors,
6) Security Testing:
Following are some test cases for web security testing:
Test by pasting internal URL directly into browser address bar without login. Internal pages should not open.

CMM(Capability Maturity Model)

The Capability Maturity Model (CMM), also known as the Software CMM (SW-CMM), was first described by Watts Humphrey in his book Managing the Software Process. The CMM is a process model based on software best-practises effective in large-scale, multi-person projects.
The CMM has been retired and not been updated in over 10 years. CMM has been superseded by CMMI (Capability Maturity Model Integration).
The CMM has been used to assess the maturity levels of organisation areas as diverse as software engineering, system engineering, project management, risk management, system acquisition, information technology (IT) or personnel management, against a scale of five key processes, namely: Initial, Repeatable, Defined, Managed and Optimised.
CMM was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University in Pittsburgh. It has been used extensively for avionics software and government projects around the world.
Currently, some government departments require software development contract organisations to achieve and operate at a level-3 standard Maturity model
The Capability Maturity Model (CMM) is a way to develop and refine an organization's processes. The first CMM was for the purpose of developing and refining software development processes. A maturity model is a structured collection of elements that describe characteristics of effective processes. A maturity model provides:

1. a place to start the benefit of a community’s prior experiences 
2. a common language and a shared vision 
3. a framework for prioritising actions 
4. a way to define what improvement means for your organization. 
5. A maturity model can be used as a benchmark for assessing different organizations for equivalent comparison. The model describes the maturity of the company based upon the project the company is handling and the related clients
6. Levels of the CMM

Level 1 - Initial
At maturity level 1, processes are usually ad hoc, and the organization usually does not provide a stable environment. Success in these organizations depends on the competence and heroics of the people in the organization, and not on the use of proven processes. In spite of this ad hoc, chaotic environment, maturity level 1 organizations often produce products and services that work; however, they frequently exceed the budget and schedule of their projects.
Maturity level 1 organizations are characterised by a tendency to over commit, abandon processes in the time of crisis, and not be able to repeat their past successes again.
Level 1 software project success depends on having high quality people
Level 2 - Repeatable [Managed]
At maturity level 2, software development successes are repeatable. The processes may not repeat for all the projects in the organization. The organization may use some basic project management to track cost and schedule.
Process discipline helps ensure that existing practises are retained during times of stress. When these practises are in place, projects are performed and managed according to their documented plans.
Project status and the delivery of services are visible to management at defined points (for example, at major milestones and at the completion of major tasks).
Basic project management processes are established to track cost, schedule, and functionality. The minimum process discipline is in place to repeat earlier successes on projects with similar applications and scope. There is still a significant risk of exceeding cost and time estimates
Level 3 - Defined
The organization’s set of standard processes, which are the basis for level 3, are established and improved over time. These standard processes are used to establish consistency across the organization. Projects establish their defined processes by applying the organization’s set of standard processes, tailored, if necessary, within similarly standardised guidelines.
The organization’s management establishes process objectives for the organization’s set of standard processes, and ensures that these objectives are appropriately addressed.
A critical distinction between level 2 and level 3 is the scope of standards, process descriptions, and procedures. At level 2, the standards, process descriptions, and procedures may be quite different in each specific instance of the process (for example, on each particular project). At level 3, the standards, process descriptions, and procedures for a project are tailored from the organization’s set of standard processes to suit a particular project or organisational unit
Level 4 - Quantitatively Managed
Using precise measurements, management can effectively control the software development effort. In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Organisations at this level set quantitative quality goals for both software process and software maintenance. Sub processes are selected that significantly contribute to overall process performance. These selected sub processes are controlled using statistical and other quantitative techniques. A critical distinction between maturity level 3 and maturity level 4 is the predictability of process performance. At maturity level 4, the performance of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable. At maturity level 3, processes are only qualitatively predictable
Level 5 - Optimising
Maturity level 5 focuses on continually improving process performance through both incremental and innovative technological improvements. Quantitative process-improvement objectives for the organization are established, continually revised to reflect changing business objectives, and used as criteria in managing process improvement. The effects of deployed process improvements are measured and evaluated against the quantitative process-improvement objectives. Both the defined processes and the organization’s set of standard processes are targets of measurable improvement activities.
Process improvements to address common causes of process variation and measurably improve the organization’s processes are identified, evaluated, and deployed
Six Sigma
Six Sigma is a disciplined, data-driven approach and methodology for eliminating defects (driving towards six standard deviations between the mean and the nearest specification limit) in any process -- from manufacturing to transactional and from product to service.
The fundamental objective of the Six Sigma methodology is the implementation of a measurement-based strategy that focuses on process improvement and variation reduction through the application of Six Sigma improvement projects. This is accomplished through the use of two Six Sigma sub-methodologies:
DMAIC
The Six Sigma DMAIC process (define, measure, analyse
DMADV
The Six Sigma DMADV process (define, measure, analyse, design, verify) is an improvement system used to develop new processes or products at Six Sigma quality levels. It can also be employed if a current process requires more than just incremental improvement.

THE KEY TO PRODUCTIVE QA TESTING

It is crucial to recognise that all testing will be conducted by comparing the final product to the product’s set requirements; therefore, product requirements must state all functionality of the software and must be updated as changes are made. Any functionality that does not meet the requirements will be recorded as a defect until resolution is delivered.
Twelve Types of QA Testing
1. Unit testing (conducted by Development)
Unit test case design begins after a technical review approves the high level design. The unit test cases shall be designed to test the validity of the program's correctness. White box testing is used to test the modules and procedures that support the modules. The white box testing technique ignores the function of the program under test and focuses only on its code and the structure of that code. To accomplish this, a statement and condition technique shall be used. Test case designers shall generate cases that not only cause each condition to take on all possible values at least once, but that cause each such condition to be executed at least once. In other words:
Each decision statement in the program shall take on a true value and a false value at least once during testing.
Each condition shall take on each possible outcome at least once during testing.
2. Configuration Management
The configuration management team prepares the testing environment
3. Build Verification
When a build has met completion criteria and is ready to be tested, the QA team runs an initial battery of basic tests to verify the build.
If the build is not testable at all, then the QA team will reject the build
If portions of the website are testable and some portions are not yet available, the project manager, technical lead and QA team will reassign the build schedule and deliverable dates.
If all portions of the build pass for testing, the QA team will proceed with testing.
4. Integration Testing
Integration testing proves that all areas of the system interface with each other correctly and that there are no gaps in the data flow. The final integration test proves that the system works as an integrated unit when all the fixes are complete.
5. Functional Testing
Functional testing assures that each element of the application meets the functional requirements of the business as outlined in the requirements document/functional brief, system design specification, and other functional documents produced during the course of the project (such as records of change requests, feedback, and resolution of issues).
6. Non-functional Testing (Performance Testing)
Non-functional testing proves that the documented performance standards or requirements are met. Examples of testable standards include response time and compatibility with specified browsers and operating systems.
If the system hardware specifications state that the system can handle a specific amount of traffic or data volume, then the system will be tested for those levels as well.
7. Defect Fix Validation
If any known defects or issues existed during development, QA tests specifically in those areas to validate the fixes.
8. Ad Hoc Testing
This type of testing is conducted to simulate actual user scenarios. QA engineers simulate a user conducting a set of intended actions and behaving as a user would in case of slow response, such as clicking ahead before the page is done loading, etc.
9. Regression Testing
Regression testing is performed after the release of each phase to ensure that there is no impact on previously released software. Regression testing cannot be conducted on the initial build because the test cases are taken from defects found in previous builds.
Regression testing ensures that there is an continual increase in the functionality and stability of the software.
10. Error Management
During the QA testing work flow, all defects will be reported using the error management work flow.
Regular meetings will take place between QA, system development, interface development and project management to discuss defects, priority of defects, and fixes.
11. QA Reporting
QA states the results of testing, reports outstanding defects/known issues, and makes a recommendation for release into production.
12. Release into production
If the project team decides that the build is acceptable for production, the configuration management team will migrate the build into production.

Final Release Report for QA Testing

Test Deliverables

Testing will provide specific deliverables during the project.  These deliverables fall into three basic categories: Documents, Test Cases / Bug Write-ups, and Reports.  Here is a diagram indicating the dependencies of the various deliverables:

Workflow diagram: quality assurance testing lifecycle

QA Testing
Software testing verifies that the software meets its requirements and that it is complete and ready for delivery.
Objectives of QA Testing

1. Assure the quality of client deliverable. 
2. Design, assemble, and execute a full testing life cycle. 
3. Confirm the full functional capabilities of the final product. 
4. Confirm stability and performance (response time, etc.) of the final product. 
5. Confirm that deliverable meet client expectations/requirements. 
6. Report, document and verify code and design defects.

Preparing for QA Testing
Prior to conducting formal software testing, QA develops testing documentation (including test plans, test specifications, and test procedures) and reviews the documentation for completeness and adherence to standards. QA confirms that:

1. The test cases are testing the software requirements in accordance with test plans. 
2. The test cases are verifiable. 
3. The correct or "advertised" version of the software is being tested (by QA monitoring of the Configuration Management activity).

QA then conducts the testing in accordance with procedure, documents and reports defects, and reviews the test reports.
The Key to Productive QA Testing
It is crucial to recognize that all testing will be conducted by comparing the final product to the product’s set requirements; therefore, product requirements must state all functionality of the software and must be updated as changes are made. Any functionality that does not meet the requirements will be recorded as a defect until resolution is delivered.
Twelve Types of QA Testing
1. Unit testing (conducted by Development)
Unit test case design begins after a technical review approves the high level design. The unit test cases shall be designed to test the validity of the program's correctness. White box testing is used to test the modules and procedures that support the modules. The white box testing technique ignores the function of the program under test and focuses only on its code and the structure of that code. To accomplish this, a statement and condition technique shall be used. Test case designers shall generate cases that not only cause each condition to take on all possible values at least once, but that cause each such condition to be executed at least once. In other words:

1. Each decision statement in the program shall take on a true value and a false value at least once during testing. 
2. Each condition shall take on each possible outcome at least once during testing. 

2. Configuration Management

1. The configuration management team prepares the testing environment

3. Build Verification
When a build has met completion criteria and is ready to be tested, the QA team runs an initial battery of basic tests to verify the build.

1. If the build is not testable at all, then the QA team will reject the build 
2. If portions of the website are testable and some portions are not yet available, the project manager, technical lead and QA team will reassign the build schedule and deliverable dates. 
3. If all portions of the build pass for testing, the QA team will proceed with testing 

4. Integration Testing

1. Integration testing proves that all areas of the system interface with each other correctly and that there are no gaps in the data flow. The final integration test proves that the system works as an integrated unit when all the fixes are complete.

5. Functional Testing

1. Functional testing assures that each element of the application meets the functional requirements of the business as outlined in the requirements document/functional brief, system design specification, and other functional documents produced during the course of the project (such as records of change requests, feedback, and resolution of issues).

6. Non-functional Testing (Performance Testing)

1. Non-functional testing proves that the documented performance standards or requirements are met. Examples of testable standards include response time and compatibility with specified browsers and operating systems.
2. If the system hardware specifications state that the system can handle a specific amount of traffic or data volume, then the system will be tested for those levels as well. 

7. Defect Fix Validation

1. If any known defects or issues existed during development, QA tests specifically in those areas to validate the fixes.

8. Ad Hoc Testing

1. This type of testing is conducted to simulate actual user scenarios. QA engineers simulate a user conducting a set of intended actions and behaving as a user would in case of slow response, such as clicking ahead before the page is done loading, etc.

9. Regression Testing

1. Regression testing is performed after the release of each phase to ensure that there is no impact on previously released software. Regression testing cannot be conducted on the initial build because the test cases are taken from defects found in previous builds.
2. Regression testing ensures that there is an continual increase in the functionality and stability of the software. 

10. Error Management

1. During the QA testing workflow, all defects will be reported using the error management workflow.
2. Regular meetings will take place between QA, system development, interface development and project management to discuss defects, priority of defects, and fixes.

11. QA Reporting

1. QA states the results of testing, reports outstanding defects/known issues, and makes a recommendation for release into production.

12. Release into production

1. If the project team decides that the build is acceptable for production, the configuration management team will migrate the build into production.

CONFIGURATION MANAGEMENT

The configuration management (CM) team is responsible for maintaining the validity of code as it moved from one environment to the next. The CM team takes part in the development workflow every time there is a change of code status. For example, when a software build phase is completed and ready to be tested, the code must be moved from the development environment to testing environment. This task belongs to the CM team.
CM follows a controlled workflow to promote and deploy all code. Additionally, CM is responsible for maintaining all source control databases (SCD) and the standards and processes related to SCD.
Objectives and Benefits

1. Improve the complete software development and maintenance cycle. 
2. Make QA testing easier, reliable, and effective. 
3. Remove error-prone steps from product release management. 
4. Support and ease the challenges of change management and defect tracking. 
5. Improve the quality and validity of code through version control. 
6. Provide code roll-back if necessary, or trace related code components. 
7. Maintain a history of code changes (who, what, when and why). 

CM Responsibilities
The CM team provides the following services throughout the course of product development and deployment:

1. Implement and maintain version control in development and testing environments. 
2. Prepare and configure QA servers per the specifications provided by system designers. 
3. Move code into the testing environment (servers and SCD) and establish the initial (or “baseline”) code base. 
4. Give the go-ahead to QA to commence testing after the code is moved. 
5. Simplified CM Workflow
6. CM’s role in software development and deployment may be summarized as follows:
7. In preparation for QA testing, CM moves all labeled files from the development SCD to the QA servers and the QA SCD, where they are labeled again. 
8. During QA testing, CM moves all new builds and defect fixes to the QA SCD and QA servers and labels them. 
9. When the files are approved, CM labels and moves them from the QA SCD into the production staging servers. 
10. Upon approval from project management and QA, CM promotes the final code base to production servers for deployment. 
11. Any defect fixes or enhancements after the initial build will also be deployed following the above steps. 

QA and Configuration Management

1. QA audits all CM functions for adherence to CM plans and procedures and prepares reports of its findings. QA reviews the CM plans for compliance with software CM policies and verifies that the plans include follow-up for defects. 
2. The CM functions monitored and audited by QA include baseline control, configuration identification, and configuration control. QA assures that:
3. Baselines are established and consistently maintained for use in subsequent baseline development and control. 
4. Approved changes to baseline software are made properly and consistently in all products, and no unauthorized changes are made.

Testing Roles and Responsibilities -Senior Test Leads,Test Leads,Software Testing Specialists

Senior Test Leads’ roles include the following:
Senior Test Leads

1. Lead a team of test leads on multiple projects including:
2. Supervise test leads and assist with test lead tasks as appropriate. 
3. Verify all projects are smoke, build, and regression tested on release build. 
4. Verify all projects have undergone at least two complete cycles of testing (all test cases executed) for the alpha and final release testing milestones. 
5. Verify test plans and other test documentation is prepared. 
6. Act as Test Lead on larger projects. 
7. Monitor releases and builds going out to production and track production bugs over time. 
8. Provide test documentation and reports to test and project management as required. 
9. Train and Mentor test leads. Verify all appropriate testing deliverable are met including: 
10. Weekly Roll-up Status Reports 
11. Test Schedules and requirements for test staffing. 
12. Test Environment prepared & maintained. 
13. Risk and Quality Assessments in conjunction with project test lead 
14. Final Release “Certification” Report 
15. Post Mortem Reports in conjunction with project test lead 
16. CD’s and Testing Manual of the project in conjunction with project test lead Provide the following services to Project Management 
17. Non team based sanity check for all software going out to production. 
18. Provide all above documentation 
19. Training, hiring, and mentoring for all contract test staff. 
20. Quality feedback for use in go/no go meetings and roll outs 
21. Make sure testing is on schedule and identify and work with project management to fix test issues that are delaying implementation Test Leads 

Test Leads’ roles include the following:
Lead a team of testers on a project including:

1. Supervise testers and allocate testing tasks to appropriate testers. 
2. Verify all test cases assigned to testers are executed. 
3. Verify all test cases assigned to testers are designed properly. 
4. Verify all bugs are put into bug tracking system. 
5. Verify all bugs marked resolved are regressed by the proper testers. 

Assist with testing.Verify all appropriate testing deliverable are met including:
Weekly Status Reports

1. Test Plans 
2. Test Schedules 
3. Bug tracking & TCM are setup 
4. Requirements for staffing, back end testing, and automation testing are identified. 
5. Test Cases 
6. Test Environment prepared & Maintained 
7. Bug Tracking & TCM Reports 
8. Build Acceptance Reports or Certification Reports 
9. Risk and Quality Assessments in conjunction with Senior test lead 

Release Checklists

1. Post Implementation Reports in conjunction with Senior test lead 
2. CD’s and Testing Manual of the project in conjunction with Senior test lead 
3. Act as member of core project team 
4. Provide the following services to Project Management 
5. Setup and run Bug Triages (Bug Review Meetings, minimum of weekly meeting once in development) 
6. Provide all above documentation 
7. Maintain bug tracking system, TCM, and the Test Environment 
8. Provide quality feedback for go/no go meetings and rollouts 

Software Testing Specialists
Test Specialists roles include the following:

1. Execute all assigned test cases. 
2. Design and prioritize test cases. 
3. Put bugs into bug tracking system. 
4. Retest resolved bugs on each release. 
5. Regresses existing bugs on previous software builds or alternate database/server configurations. 
6. Assist the test lead with test lead duties as needed. 
7. Provide feedback in Bug triages. 
8. Assist with preparation of test plans. 

In addition Test Specialists may be called to perform any of these tasks:
Automate test cases.

1. Test SQL Interfaces and have a working knowledge of SQL. 
2. Run Smoke tests. 
3. Build code from Source Safe or other Version Control utility. 
4. Run Build Acceptance tests on any code. 

Difference between Priority and Severity

Sr.	Priority	Severity
1	It is associated with schedule to resolve e.g. out of many issues to be tackled, which one should be addressed first by the order of its importance or urgency.	It is associated with benchmark quality or adherence to standard. It reflects harshness of a quality expectation.
2	Is largely related to Business or Marketing aspect. It is a pointer towards the importance of the bug.	Is related to technical aspect of the product. It reflects on how bad the bug is for the system.
3	Priority refers to how soon the bug should be fixed.	Severity refers to the seriousness of the bug on the functionality of the product. Higher effect on the functionality will lead to assignment of higher severity to the bug.
4	Priority to fix a bug is decided in consultation with the client.	The Quality Assurance Engineer decides the severity level. It is decided as per the risk assessment of the customer.
5	Product fixes are based on 'Project Priorities.	Product fixes are based on Bug Severity.

1) Generally speaking, a "High Severity" bug would also carry a "High Priority" tag along with it. However this is not a hard & fast rule. There can be many exceptions to this rule depending on the nature of the application and its schedule of release.

2) High Priority & Low Severity: A spelling mistake in the name of the company on the home page of the company’s web site is certainly a High Priority issue. But it can be awarded a Low Severity just because it is not going to affect the functionality of the Web site / application.

3) High Severity & Low Priority: System crashes encountered during a roundabout scenario, whose likelihood of detection by the client is minimal, will have HIGH severity. In spite of its major affect on the functionality of the product, it may be awarded a Low Priority by the project manager since many other important bugs are likely to gain more priority over it simply because they are more visible to the client.

Some important manual testing process

Click Here-manual testing process

Software Testing Concepts

Click Here-High level process

Manual-Testing-Real-Time

      1.differentiate between QA and QC?

It is process orientedit envolve in entire process of software developement.Preventin oriented.QC:It is product oriented.work to examin the quality of product.Dedection orientd.

      2.what is a bug?

Computer bug is an error, flaw, mistake, failure, or fault in a computer program thatprevents it from working correctly or produces an incorrect result.

      3.what is a test case?

Testcase is set of input values, execution preconditions,expected results and executionpostconditions, developed for a particular objective or test conditons, such as to exercise apaticular program path or to verify compliance with a specific requiremnt.

     4.What is the purpose of test plan in your project?

test plan document is prepared by the test lead,it contains the contents likeintroduction,objectives,test stratergy,scope,test items,program modules userprocedures,features to be tested features not to tested approach,pass or fail criteria,testingprocess,test deliverables,testing,tasks,responsibilities,resources,schedule,environmental requirements,risks & contingencies,change management procedures,planapprovals,etc all these things help a test manager undersatnd the testing he should do & what he should follow for testing that particular project.

      5.When the relationship occur between tester and developer?

developer is the one who sends the application to the tester by doing all the necessary code inthe application and sends the marshal id to the tester.The tester is the one who gives all theinput/output and checks whether he is getting reqd output or not.A developer is the one whoworks on inside interfacing where as the tester is the one who works on outside interfacing

      6.when testing will starts in a project?

the testing is not getting started after the coding.after release the build the testers performthe smoke test.smoke test is the first test which is done by the testing team.this is accordingto the testing team.but, before the releasing of a build the developers will perform the unittesting.

      7.If a bug has high severity then usually that is treated as high priority,then why dopriority given by testengineers/project managers and severity given by testers?

High severity bugs affects the end users ....testers tests an application with the users point of view, hence it is given as high severity.High priority is given to the bugs which affects theproduction.Project managers assign a high priority based on production point of view.

      8.what is the difference between functional testing and regresion testing

functional testing is a testing process where we test the functionality/behaviour of eachfunctional component of the application...i.e.minimize button,transfer button,links etc.i.e wecheck what is each component doing in that application...regression testing is the testing the behaviour of the application of the unchanged areas whenthere is a change in the build.i.e we chk whether the changed requirement has altered thebehaviour of the unchanged areas.the impacted area may be the whole of the application orsome part of the application...

      10.do u know abt integration testing,how do u intregate diff modules?

integration testing means testing an application to verify the data flows between themodule.for example, when you are testing a bank application ,in account balence it shows the100$as the available balence.but in database it shows the 120$. main thing is "integrationdone by the developers and integration testing done by the testers"

.       do u know abt configuration management tool,what is the purpose of maintainingall the documents in configuration manage ment tool?

It is focused primarily on maintaining the file changes in the history.Documents are subjected to change For ex: consider the Test case document .Initially you draft the Test cases document and place it in Version control tool(Visual SourceSafe for ex).Then you send it for Peer Review .They will provide some comments and thatdocument will be saved in VSS again.Similary the document undergoes changes and all thechanges history will be maintained in Version control.It helps in referring to the previous version of a document.Also one person can work on a document (by checking out) at a time.Also it keeps track who has done the changes ,time and date.Generally all the Test Plan, Test cases,Automation desgin docs are placed in VSS.Proper access rights needs to be given so that the documents dont get deleted or modified.

      12.How you test database and explain the procedure?

Database Testing is purely done based on the requirements. You may generalize a fewfeatures but they won't be complete. In general we look at1. Data Correctness (Defaults)2. Data Storage/Retreival3. Database Connectivity (across multiple platforms)4. Database Indexing5. Data Integrity6. Data Security

      13.suppose if you press a link in yahooshopping site in leads to some other companywebsite?how to test if any problem in linking from one site to another site?

1)first i will check whether the mouse cusor is turning into hand icon or not?2)i will check the link is highlingting when i place the curosr on the link or not?3)the site is opening or not?4)if the site is opening then i will check is it opening in another window or the same windowthat the link itself exitst(to check userfriendly ness of the link)5)how fast that website is opening?f 6)is the correct site is opening according to the link?7)all the items in the site are opeing or not?8)all other sublinks are opening or not?

      14.what are the contents of FRS?

F → Function BehavioursR → Requirements (Outputs) of the System that is defined.S → Specification ( How, What, When, Where, and Way it behavior's.FRS → Function Requirement Specification.This is a Document which contains the Functional behaviorof the system or a feature. This document is also know as EBS External BehaviourSpecification - Document. Or EFS External Function Specification.

      15.what is meant by Priority nad severity?

Priority means "Importance of the defect w.r.t cutomer requirement"Severity means "Seriousness of the defect w.r.t functionality"

      16.what is meant by Priority nad severity?

Severity:1. This is assigned by the Test Engineer2. This is to say how badly the devation that is occuring is affecting the other modules of thebuild or release.Priority:1. This is assigned by the Developer.2. This is to say how soon the bug as to be fixed in the main code, so that it pass the basicrequirement.

Eg., The code is to generate some values with some vaild input conditions. The priority will beassigned so based on the following conditions:a> It is not accepting any valueb> It is accepting value but output is in non-defined format (say Unicode Characters).A good example i used some unicode characters to generate a left defined arrow, itdisplayed correctly but after saving changes it gave some address value from thestack of this server. For more information mail me i will let you know.

      17.give me some example for high severity and low priority defect?

if suppose the title of the particular concern is not spelled corectly,it would give a negativeimpact.eg ICICC is spelled as a tittle for the project of the concern ICICI.then it is a highseverity,low priority defect.

      18.what is basis for testcase review?

the main basis for the test case review is1.testing techniques oriented review2.requirements oriented review3.defects oriented review.

      19.what are the contents of SRS documents?

Software requirements specifications and Functional requirements specifications.

      20.What is difference between the Web application testing and Client Server testing?

Testing the application in intranet(withoutbrowser) is an example for client -server.(Thecompany firewalls for the server are not open to outside world. Outside people cannot accessthe application.)So there will be limited number of people using that application.Testing an application in internet(using browser) is called webtesting. The application which isaccessable by numerous numbers around the world(World wide web.)So testing web application, apart from the above said two testings there are many othertestings to be done depending on the type of web application we are testing.If it is a secured application (like banking site- we go for security testing etc.)If it is a ecommerce testing application we go for Usability etc.. testings.

      21.Explain your web application archtechture?

web application is tested in 3 phases1. web tier testing --> browser compatibility2. middle tier testing --> functionality, security3. data base tier testing --> database integrity, contents

Suppose the product/appication has to deliver to client at 5.00PM,At that timeyou or your team member caught a high severity defect at 3PM.(Remember defect ishigh severity)But the the client is cannot wait for long time.You should deliver theproduct at 5.00Pm exactly.then what is the procedure you follow?

the bug is high severity only so we send the application to the client and find out the severityis preyority or not. if its preyority then we ask him to wait.Here we found defects/bugs in the last minute of the deliveryor realese dateThen we have two options1.explain the situation to client and ask some more time to fix the bug.2.If the client is not ready to give some some time then analyse the impact of defect/bug andtry to find workarounds for the defect and mention these issues in the release notes asknown issues or known limitations or known bugs. Here the workaround means remeadyprocess to be followed to overcome the defect effect.3.Normally this known issues or known limitations(defects) will be fixed in next version or nextrelease of the software