Immigration Financial Information Bangladesh Gateway General World Cup Entertainment Programing University and College Scholarship Job Interview Health Job

Sunday, June 20, 2010

SOFTWARE TESTING, QUALITY ASSURANCE

When ? Why?

QA is involved in the project from the beginning. This helps the teams communicate and understand the problems and concerns, also gives time to set up the testing environment and configuration. On the other hand, actual testing starts after the test plans are written, reviewed and approved based on the design documentation.

Software Testing

Software testing is oriented to "detection". It's examining a system or an application under controlled conditions. It's intentionally making things go wrong when they should not and things happen when they should not.

Software Quality

Quality software is reasonably bug free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable.

Software Verification and Validation

Verification is "whether the actual requirements are correctly implemented" and validation is code testing. Verification involves reviews, meetings, evaluating documents, plans, code, inspections, specifications etc. Validation occurs after verification and it's the actual testing to find defects against the functionality or the specifications.

Test Plan

Test Plan is a document that describes the objectives, scope, approach, and focus of a software testing effort.

Test Case

A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly. A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results.

Good Software Coding

Good code is code that works according to the requirements, bug free, readable, expandable in the future and easily maintainable.

Good Design

In good design, the overall structure is clear, understandable, easily modifiable, and maintainable. Works correctly when implemented and functionality can be traced back to customer and end user requirements.

Good Test Engineer

Good test engineer has the ability to think the unthinkable, has the test to break attitute, strong desire to quality and attention to detail.

Walkthrough

Walkthrough is quick and informal meeting for evaluation purposes.

Software Life Cycle

The Software Life Cycle begins when an application is first conceived and ends when it is no longer in use. It includes aspects such as initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, retesting, phase-out, and other aspects.

Software Inspection

The purpose of inspection is trying to find defects and problems mostly in documents such as test plans, specifications, test cases, coding etc. It helps to find the problems and report it but not to fix it. It is one of the most cost effective methods of software quality. Many people can join the inspections but normally one moderator, one reader and one note taker are mandatory.

Benefits of Automated Testing

It's very valuable for long term and on going projects. You can automize some or all of the tests which needs to be run from time to time repeatedly or diffucult to test manually. It saves time and effort, also makes testing possible out of working hours and nights. They can be used by different people and many times in the future. By this way, you also standardize the testing process and you can depend on the results.

Main problems of working in a geographically distributed team

The main problem is the communication. To know the team members, sharing as much information as possible whenever you need is very valuable to solve the problems and concerns. On the other hand, increasing the wired communication as much as possible, seting up meetings help to reduce the miscommunication problems.

Common problems in Software Development Process

Poor requirements, unrealistic schedule, inadequate testing, miscommunication and additional requirement changes after development begin.

Different Kind of Testing

• Black box testing : You don't need to know the internal design in detail or have a good knowledge about the code for this test. It's mainly based on functionality and specifications, requirements.
• White box testing : This test is based on detailed knowledged of the internal design and code. Tests are performed for specific code statements and coding styles.
• Unit testing : The most micro scale of testing to test specific functions or code modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code, may require developing test driver modules or test harnesses.
• Incremental integration testing : Continuous testing of an application as new functionality is added. Requires that various aspects of an application's functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed. Done by programmers or by testers.
• Integration testing : Testing of combined parts of an application to determine if they function together correctly. It can be any type of application which has several independent sub applications, modules.
• Functional testing : Black box type testing to test the functional requirements of an application. Typically done by software testers but software programmers should also check if their code works before releasing it.
• System testing : Black box type testing that is based on overall requirements specifications. Covers all combined parts of a system.
• End to End testing : It's similar to system testing. Involves testing of a complete application environment similar to real world use. May require interacting with a database, using network communications, or interacting with other hardware, applications, or systems.
• Sanity testing or smoke testing : An initial testing effort to determine if a new sw version is performing well enough to start for a major software testing. For example, if the new software is crashing frequently or corrupting databases then it is not a good idea to start testing before all these problems are solved first.
• Regression testing : Re-testing after software is updated to fix some problems. The challenge might be to determine what needs to be tested, and all the interactions of the functions, especially near the end of the sofware cycle. Automated testing can be useful for this type of testing.
• Acceptance testing : This is the final testing done based on the agrements with the customer.
• Load / stress / performance testing : Testing an application under heavy loads. Such as simulating a very heavy traffic condition in a voice or data network, or a web site to determine at what point the system start causing problems or fails.
• Usability testing : Testing to determine how user friendly the application is. It depends on the end user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.
• Install / Uninstall testing : Testing of full, partial, or upgrade install / uninstall processes.
• Recovery / failover testing : Testing to determine how well a system recovers from crashes, failures, or other major problems.
• Security testing : Testing to determine how well the system protects itself against unauthorized internal or external access and intentional damage. May require sophisticated testing techniques.
• Compatability testing : Testing how well software performs in different environments. Particular hardware, software, operating system, network environment etc. Like testing a web site in different browsers and browser versions.
• Exploratory testing : Often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it.
• Ad-hoc testing : Similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it.
• Context driven testing : Testing driven by an understanding of the environment, culture, and intended use of software. For example, the testing approach for life critical medical equipment software would be completely different than that for a low cost computer game.
• Comparison testing : Comparing software weaknesses and strengths to competing products.
• Alpha testing : Testing of an application when development is nearing completion. Minor design changes may still be made as a result of such testing. Typically done by end users or others, not by programmers or testers.
• Beta testing : Testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end users or others, not by programmers or testers.
• Mutation testing : A method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes (defects) and retesting with the original test data/cases to determine if the defects are detected. Proper implementation requires large computational resources.

3 comments :

  1. Nice overview of SW Testing and Quality. Based on my experience with SW Inspections, I'd like to suggest emphasizing the follow-up phase after each inspection during which the moderator ensures that all valid defects found during an inspection are corrected/resolved. With a good SW Inspection process for both detection and removal of defects, Return on Investment is in the 200% to 400% range. I have empirical proof of the outstanding performance available with SW Inspections.

    ReplyDelete
  2. Nice & effective Comments by Joe Lindley.

    ReplyDelete