Test the theory

Common English words 1

Words you often encounter at work:

Bug Percent release test UAT build code List Deploy status login logout Log out mail URL account password leader not found fail error success edit Product system admin/administrator (administrator) keyword Keyword) case User /username IP address host Host port port submit Firefox Firefox Chrome Google Ie Microsoft Web app Mobile phone PC PC BAT Baidu, Teng Xu, Ali

Install software common words:

Next step back, Previous Step Cancel Cancel install Install Uninstall Uninstall Finish Agree OK Finish Download

Database common words:

Database use select(query) from (select) Show show table where (conditions) or(or)and like (like) In (in… Between limit Top ORDER by DISTINCT desc (descending order) ASC sum AVG Max min count group By having null not is Yes INSERT into VALUES Update set CREATE primary Primary key Key key Int char delete view drop Delete TRUNCate Empty JOIN Join inner outer outer left right Right Alter Column add modify change Rename rename to index Boolean Boolean

Linux operating system:

Copy Copy move Move grep Filter kill Kill find Search tail Tail head Head type

English Word 2

Python programming language: Print Numbers (int, Num String STR List Tuple Dictionary dict delete delete del Append add remove delete reverse reverse Reverse if if else otherwise range While break breaks, Pause continue Continue pass Pass default Default class Definition Definition (def) return Return file open Open input Row Row column read Read Write Write Close Close Import Import from Where to find Max Max Min Minimum Type Type Try Except Exception Exception Length (len) True True false False bool Boolean UI automation words: Driver driver get; Click click Send Send keys s Elector window window time Sleep sleep back Return Forward refresh refresh quit Exit attribute display Display size size location location clear Clear waite wait implicitly It was not obvious until… So far lambda anonymous function title Title current Current double double switch to frame form default Default content Handle Alert Accept Dismiss Eliminate Confirm Confirm prompt prompt system execute script script document set Scroll visible value Image Image Width Width Height Height Save Crop crop cut cut connect Connect CURSOR pointer Random Random number Assert Assert equal equal suit set Run run add add year year month month day day hour hour minute minute second report input enter object object page page model login login Logout Main Main function data Data Common Case expect Expect

The first chapter introduces the basic knowledge of software testing

** is a collection of computer data and instructions organized in a specific order. It’s the non-physical part of the computer; The physical part of the computer is called the hardware, which consists of the computer shell and various parts and circuits. Computer software needs hardware to function, and vice versa. Neither software nor hardware can actually function without working together. A computer program is a group of computers, usually written in a programming language and running on a target architecture, that perform actions or make decisions. QC quality control: Quality contrl QA: Quality assurance QA is to provide enough trust to show externally that the material can meet the quality requirements. Software testing terms: product (requirements), architecture, development, testing, operations. ** Testing: ** is tested against requirements, but software testing is not only tested against requirements, but also checks for common sense errors. ** Test outline: ** To prevent inspection omissions, each checkpoint is recorded in a file, the test outline. ** Test cases: ** Record how each item was checked in a file (Excel) called a test case. **Bug Sheet (defect report) : ** Problems during testing are recorded in a file for development to fix. The file to record problems is called Bug sheet. ** First, the product manager puts forward requirements, develops, tests and reviews the products. Then, the development architect designs architecture design documents according to the requirements documents. After that, the developer distributes their modules and produces detailed documents according to the architecture documents. Development while developers are developing, test and write test cases. After writing, development, testing and products are also reviewed. Once the development is complete, the tests execute the tests according to the test cases. Find bugs and let development solve them. When all problems are solved, conduct regression testing, and then let operation and maintenance release to the pre-release environment, and then conduct regression testing, and then release to the production environment, and then see if there are any problems. If there are no problems, it means that the launch is complete.

Iv. Definition of software: ** The process of running or testing a system using manual and automatic means; The purpose is to verify that it meets specified requirements or to understand the difference between expected and actual results.

Five, the software test check content

  1. Ensure that procedures are in accordance with the corresponding specifications
  2. Find defects in software
  3. Make sure the software doesn’t do anything unnecessary
  4. Ensure proper implementation of the system
  5. Determine how far you can run your system before it fails
  6. Identify the risks associated with the system being released to users

General content of software testing

  1. Develop a test plan
  2. Design test cases
  3. Conduct software testing
  4. Submit defect sheets (defect reports or bug sheets)
  5. Test summary

Vii. Software Testing Purpose From the perspective of users, software testing is expected to expose hidden errors and defects of the software, so as to consider whether to accept the product. From the perspective of software developers, we hope to show that software products do not have errors and defects, verify that software can correctly realize the needs of users, establish people’s confidence in software quality. From the perspective of software managers, they want to spend limited resources to meet the quality requirements of the software, and the cost and schedule are their primary concerns.

  1. An example of successful software testing is the discovery of a hitherto undiscovered error
  2. A successful software test detects a bug test that has yet to be discovered
  3. Testing is not just about finding errors
  4. Testing without finding bugs is also valuable, and complete testing is a way to assess software quality

** The fundamental purpose of software testing: ** is to deliver the product to the user to meet the needs of the user, is the product before the user to find as many problems as possible, and correct the problems, and finally give a high-quality software system to the user to use.

Testing and debugging

  1. Software testing is to find errors in software that already exist, while debugging is to locate errors and modify the program to correct them.
  2. The object for testing can be documentation and code, while the object for debugging can only be code.
  3. Debugging is random, done by the programmer, in order for the program to run.
  4. Testing is purposeful, done by testers, in order for the program to perform specified functions.

Ix. The necessary qualities of software testers

  1. The sense of responsibility

  2. Team player

  3. Ability to understand and express

  4. Always be skeptical and have a sense of prevention

  5. Have some programming experience

Chapter two is the definition and classification of bugs

I. What are the causes of software defects?

  1. There is insufficient person-to-person communication, misunderstanding or no communication at all
  2. The program itself has errors
  3. Software complexity
  4. Demand is constantly changing
  5. Short construction period, heavy task, time pressure
  6. Overconfidence of the people involved
  7. Imperfections in documentation

2, defect =bug, software bug is not only refers to the error of the system bug definition: in the use of software in the process of any problem (or causes the software does not meet the design requirements or does not meet the needs of consumers can be a bug)

Defects are classified according to the severity level: problems affecting the test progress: crash, functional problems, interface problems, optimization and suggestions are classified according to the priority: problems that should be fixed immediately, problems that must be fixed before the product release, problems that should be fixed if time permits, and problems that can exist in the version. A serious problem is not necessarily a high priority problem, because some problems will be resolved later, but a problem that affects progress is definitely a high priority problem.

4. Experience in finding bugs

  1. You can use the documentation (requirements specification) used in your work as a standard for identification and judgment.
  2. By communicating with developers, we can learn the logical process of software design and analyze potential problems that may exist.
  3. Understand the industry background knowledge of software products and the operation habits of common users in the industry to find problems.
  4. Use mobile phones with kindness, learn and share other people’s methods and experiences in judging defects.

How to ensure the recurrence of defects in software

  1. Don’t take any assumptions for granted, and be good at documenting your steps
  2. Be good at finding recurrently defections and whether or not they appear at a particular moment
  3. Be aware of hardware failures, which may not work as intended
  4. Pay attention to software failure issues, the modification of defects, may create new defects

For defects that cannot be reproduced, a detailed record of such defects should be made and submitted to the developer as soon as possible. For defects that are difficult to reproduce, a reasonable arrangement of time should not be penny wise and penny foolish.

7. How to record bugs effectively

  1. Ensure recurrence of defects
  2. Analyze faults and reproduce defects in a minimum of steps
  3. Contains all necessary steps to redefect
  4. Easy to read, as simple as possible, one defect at a time report
  5. Watch your tone

Bug single content

  1. Their products

  2. Owning module

  3. Affects version

  4. Bug type

  5. The title of the Bug

  6. Severity of the Bug

  7. Bug priority [high, medium, low]

  8. The reproduction step consists of three aspects: operation steps, expected results, and actual results.

  9. Bug reappearance Upload corresponding files (such as screenshots found during operation)

There are three severity levels: Major: The system cannot be operated. General: basic functions mentioned in requirements analysis are not achieved, basic functions are not implemented as required, etc. Minor: inconvenient operation, interface error, error word and other errors. Priority: (Note: urgent is equivalent to the preparatory work before implementation, important is equivalent to the follow-up work.) Important and Urgent: The items that must be done are of the highest priority and are important but not urgent: The items that must be done are important and not urgent. The items that must be done are not important and can be prepared and not urgent and not important. Unmodified: An unmodified error. Unmodified: An error that has not been modified

The third chapter is the process and status of bug

First, the process of Bug handling: first, the test submits the defect report to the development manager, and then the development manager allocates the defect report to the corresponding developer, and the developer processes the defect report. After the processing, the test carries out the reverse test. If the reverse test fails, the test directly calls back, and the reverse test passes, and the defect report is closed. In general, the tester submits defect reports directly to the corresponding developer. ** Reverse test: ** After a defect in a feature is modified, the tester retests to see if the problem exists. ** Regression test: ** refers to that after the completion of the development and modification of the bug, not only to verify the bug but also to see if it affects other functions, regression test the bug-related functions. Regression testing of all features and impact points is typically done before going live. ** How the impact points are arrived at: ** Development and testing typically conduct an impact point analysis session prior to testing, where development details the scope of the update.

2. Classification of defect reports shall be in accordance with the handling status: New submitted, assigned, to be confirmed, unresolved, resolved, to be retested, closed, to be filed, and filed according to handling suggestions: Bug status: ** refers to the progress of a defect through a tracking repair process. These include New, Open, Reopen, Fixed closed, and Rejected. New: Status marked by the tester submitting a New problem. Open: The task allocator (development lead/manager) is ready to make changes to the problem and assigns the status marked by the allocator to the problem. Status in Bug resolution, changed by task allocator. For bugs that do not enter this state, the programmer does not care.

The scene is one of Reopen: the tester does not pass the marked state after verifying the modified problem, or an error occurs again when the modified problem is correct. Changed by the tester. Fixed: Indicates the status marked by the developer after the problem has been modified and has not been tested. Closed: indicates the status that is marked when a modified problem is validated by a tester. Changed by the tester. Rejected: a problem that is not a bug (it is not described clearly, it is repeated, it cannot be repeated, it is not a bug (it is a mistake but it is not Rejected) Set by the bug distributor or developer.

Third, almost all bugs can be turned into unsolved bugs

Chapter 4 – Software testing related models

1. Waterfall model of software testing life cycle: documents generated at each stage

  1. Planning stage: project planning, development planning, test planning
  2. Requirement analysis: requirement document, (requirement specification), product model
  3. Design stage: architecture documents (architecture design specification), detailed design documents, interface documents are generally written by developers
  4. Coding: develop proposed code files, system deployment documents
  5. Test phase: Test outline (generally written by the leader), test plan, test case, defect report and test summary

Each iteration (update) of the Gleason spiral model includes the following six steps:

  1. Identify target alternatives
  2. Identify and resolve project risks
  3. Evaluate technical options and alternative solutions
  4. Develop the deliverables for this iteration and validate the correctness of the iteration
  5. Plan the next iteration
  6. Submit steps and plans for the next iteration

Spiral model is also called iteration. Spiral model is a standard development specification in the software industry. If a project cannot be completed at one time, it is completed in batches, and each iteration must follow the spiral plan.

Second, the life cycle of software testing

  1. Develop a test plan
  2. Test design and development
  3. Conduct software testing
  4. Write test reports
  5. release
  6. Test summary

[image: 3 aac7037 b60 F9CB – 4 – A629 d441f5242e9 A33814EE80BC – 275-00014 / picture 10. PNG]

When we get the requirements, the product, development, testing and product managers will review the requirements together. After passing the review, we will list the test outline according to the requirements document, and then write test cases. At the same time, developers will also conduct code development. Of course, after the test case is written, there will be an in-group review, an out-of-group review, and after the review is passed. Development after the completion of the submitted test version (2), we according to the test cases to test, test found a Bug, the Bug is submitted to the corresponding development, development of modified reverse measurement, verification is OK to close the Bug, otherwise continue to change, when all issues carried out after completion of repair regression testing, operational published to the pre-release environment, in regression testing, Then operation and maintenance in the release to the production environment, after regression testing, and finally after the launch of no problems to write a test summary.

Contents of the test plan

  1. Project background
  2. Test purposes
  3. Test start and end time
  4. Test participants
  5. Test range
  6. Test Environment Requirements
  7. Task allocation
  8. Test milestone
  9. The test strategy

The test report is generally sent by email at the end of work every day during the execution of the test, and sent by the test leader to the test, development and product, and copied to the relevant leaders, mainly including the test scope, tester, test execution time (after several rounds of testing, after several days of testing). Problems found in the testing process (how many fatal, how many serious, how many general, how many minor, how many suggestions, delayed processing problems, etc.), also need to attach the Bug list (the list of bugs) Note: blocking problems, must be reflected in the daily work, there is a risk of delay!!

Content of test Summary Test summary is generally sent by email after the launch. Mainly includes the test project, background, purpose, test environment (software and hardware environment), test cases, several different stages of testing, test results, test coverage, found that the number of bugs, and the distribution of the bugs (how many Bug is serious, general, tiny, deadly, and so on), legacy problems, conclusion, Suggestions, and the analysis of the causes of typical bugs.

Vii. Common Testing Strategies (Testing methods)

  1. Database testing: testing the database structure, data tables and the data call relationship between software systems according to database design specifications.
  2. Functional testing: The testing of the functions in the software requirements specification, item by item, to verify whether the functions meet the requirements (for the high peak type, the internal software generally does not need).
  3. Performance testing: The testing of the functionality in the software requirements specification to verify that the functionality meets the requirements.
  4. Stress testing: The performance of a software system with low system resources. The purpose is to find out where and how the system fails.
  5. Load test: if the system runs in an overloaded environment, the program can bear it.

(3-4-5 are performance tests.) 6. Interface test: Tests the interface requirements in the software specification item by item. 7. Interface test: test the operation and display interfaces provided by all human-computer interaction interfaces to check whether they meet user needs. 8. Compatibility test: test whether the software can run normally on different operating systems, different system versions and different carriers. 9. Reliability testing: Functional testing of software in a real or simulated environment in order to make an estimate of software reliability. 10. Usability test: it refers to whether the user feels convenient during the use of the software. For example, it can reach the user’s purpose after operating the mouse for three times. 11. Configuration test: adjust the software and hardware of the system under test to understand the impact of different environments on system performance, so as to find the optimal allocation principle of system resources. 12. Security test: check whether the existing security and security confidentiality measures in the software are effective [(professional) hacker]. 13. Installation test: The test of whether the installation process is in accordance with the installation procedures to release errors during installation. 14. Encryption test: for example, some sensitive information. 15. Cross-test: Switch the modules tested by the tester. 16. Document test: test related design reports and user instructions. Design report main test program and the design of the design ideas are consistent, and testing of the user instructions is to validate the user instructions for application in the description of the operation method is correct, the key to the operation of the user using notes example test, to ensure the operation method can correctly in the process to complete the operation.

Agile Testing Agile development

  1. Agile development is characterized by rapid iteration, periodicity, and timely response to frequent customer feedback.

Agile testing features:

  1. Daily station meeting (Meeting)
  2. Extreme programming (xp)
  3. Test-driven development

Differences between Agile testing and traditional testing:

  1. Development goes hand in hand with testing
  2. Tasks are clearly divided
  3. Issues that are time-consuming or difficult to resolve will be resolved in future releases
  4. Testing occurs throughout the software lifecycle

Chapter 5 – Software testing process 1. Testing environment requirements

  1. Meets the minimum requirements for software operation
  2. Create a relatively simple and independent test environment
  3. Non-toxic test environment

Second, the model of software testing

[image: ECFCD377 – f58 – BA51 B71E – 4-7 c68b4ad62b4 d327c4ef00e – 275-00014 / picture 9. PNG]

The process from left to right in the V model, which describes the basic development process and testing behavior. The value of V model is that it clearly indicates the different levels of testing process, and clearly describes the corresponding relationship between the testing phase and the development process. Limitations: Test as the last activity after coding, requirements analysis and other early errors can not be found until later acceptance testing. [image: DcafdBEC-2576-4B7B-9112-4B51173492B3-275-00014d2DE28b8CD4 / image 8.png]

The W model is an evolution of the V model, emphasizing that testing goes along with the entire software development cycle, and that testing objects are not only programs, but also requirements, functions, and designs. Testing is done simultaneously with development, which facilitates early detection of problems. Limitations of W model: Both W model and V model regard software development as a series of serial activities such as requirements, design and coding, which cannot support iteration, spontaneity and change adjustment.

[image: 1 b9cb3f5 – ad3 C7CB – 4 – BDE0 d277552fb93 EAB549E837EF – 275-00014 / picture 7. PNG]

In the GleASon H model, the software testing process is completely independent throughout the whole product cycle and is carried out concurrently with other processes. When a test point is ready, it can be carried out from the test preparation stage to the test execution stage. Software testing can be done early and stratified according to what is being tested.

Unit test: mainly tests the program code, in order to ensure the normal function of each unit module. There are module-specific tests, there are class-specific, function-specific tests, and so on. ———— is usually done by development during development. Integration test (joint test) : on the basis of unit test, the unit is composed into a complete system to test whether the interface between software units is accurate and whether the data can be transmitted normally. ————— such as registration and recharge these two functions are unicom. System test (ST test) : it is to assemble tested subsystems into a complete system for testing. It is an effective way to verify that the system can provide the functionality specified in the requirements. The purpose of system testing is to comprehensively test the final software system to ensure that the final software system meets the product requirements and complies with the system design. Acceptance test (UAT test) : it is a user-oriented test, usually attended by product, development and test managers. Its purpose is to prove to customers that the product is reliable and meets the demand, and user representatives (or demander) must participate in it. (Integration test, system test and acceptance test are the general work content of test engineers.) Acceptance test is classified into α test, β α test, α test. It is the early stage of acceptance test, which simulates the real environment of users. Β test: is late acceptance (online), running in the user environment, part of the tester and the user participation, the development is not in the scene, and later found that the problem is solved. The difference between unit tests, integration tests, and system tests is sentence – paragraph – article. Operation and maintenance (O&M) : It is the longest phase in the software life cycle. To prolong the service life of software and meet users’ requirements, software must be maintained. Including error correction maintenance and improvement maintenance.

Static testing: the process of not running the program under test, but looking for possible errors in the program or evaluating the program code by visually reviewing the code. Dynamic testing: Actually run the program itself under test, enter the corresponding test cases, and check the difference between the expected results and the actual results. Black box testing (functional testing) : data-driven testing or requirements specification based testing (manual testing); In the test process, the program under test is regarded as a black box, regardless of the internal structure of the program, only the relationship between the input and output of the program. White box testing (structural testing) : logic-driven testing or testing based on the program itself. During testing, the program under test is treated as a white box, and test cases are written according to the content design of the program. Gray box test: it is a test between white box test and black box test. It is mainly used in the integration test phase. It not only focuses on the correctness of input and output, but also needs to pay attention to the internal condition of the program under test. Random test: a test in which all data is randomly generated to simulate the real operation of users and to detect marginal errors. Common white box test methods:

  1. Statement coverage
  2. Branch coverage or judgment coverage
  3. Condition covering
  4. Judgment/conditional coverage
  5. Path coverage

＊＊＊＊＊ Smoke test (version confirmation test) : Smoke test accounts for 10% of test cases and is the first step in each stage. It mainly tests the main and key functions of the software. Before software testing, both development and testing will smoke test the version submitted for testing to ensure that there are no problems with the main functions of the program to ensure that the testing work can be carried out normally. Manual testing: A traditional testing method in which testers execute test cases and compare expected results with actual results. Automated testing: tests carried out on the basis of manual testing, using automated testing tools to execute test cases.

Unit test → Interface test → Joint test → System test → Acceptance test Interface test is a test that tests each module to call each other. It is mainly used to examine the interaction between external systems and internal subsystems. It focuses on checking the exchange of data and mutual logical dependence between systems. (Interface tests come after unit tests and before integration tests)

Chapter 6 Understanding of Software Testing i. Principles of software testing

  1. Software should be implemented early and tested throughout the software lifecycle
  2. Software testing should trace requirements
  3. Testing should be done by a third party
  4. Do not under-test, do not over-test, because bugs are not exhaustive
  5. Every test result must be thoroughly checked
  6. Be aware of Bug clustering

In the analysis, design, implementation phase of the review and testing work can find and avoid 80% of the defects, and system testing can find the rest of the 80% defects, the last 4% defects may only be exposed in a large range of users, long time after use. 2-5-10 Principle of response time:

  1. That is, the user gets a response within 2 seconds, and will feel that the system responds quickly
  2. When the user gets a response in 2-5 seconds, it feels like the system is responding just fine
  3. When the user gets a response within 5-10 seconds, the response is perceived as slow, but acceptable
  4. When the user doesn’t get a response after more than 10 seconds, he or she feels bad about the system, thinks it’s unresponsive, and leaves the Web site or makes a second request

C/S architecture and B/S architecture C/S architecture: Software that can be used only after the client is installed. Each update requires updating both the server and the client. Such as: supermarket cashier system, every update every computer must reinstall the client, branch is more troublesome, and its consumption of manpower, material resources, financial resources. B/S architecture :(website nature) only need a browser to access the service, only need to update the server, do not need to update the browser, user initiative is high. Such as: Tmall, JINGdong. Review purpose: Whether there are inaccuracies, conflicts, ambiguities or omissions such as: Review of requirements documents (development, test, product manager) Review of test cases (Development, test, product manager) There is no omission in the test point, and the documents generated in any link of the test specification project need to be reviewed

  1. The quality of software is not measured, it is only a means to effectively improve the quality of software
  2. Software testing is no easier than development
  3. Software testing requires both development and testing
  4. Software testing is not a late stage of software development

Four, if there are no requirements document how to execute the test Any requirements documents, will surely there is demand, should first instead of determining the demand, with the development and the analysis of the product manager, through discussing some branch of demand and detail, the development will explain how they implement demand, as well as the testing is should pay attention to the point, on the basis of the above information to make a mind map, Write test cases according to mind maps, and finally execute tests. Five, if the test time is not enough, how to do first apply to the test manager to arrange colleagues to support, urgent test; If not, report back to the project manager to see if time can be increased; If it is not enough, we first ensure that the test of core business and main functions is OK to ensure that there is no problem in the normal process. Meanwhile, we urge the development of self-test and unit test in the development stage. As well as listed test points, tests should be carried out according to the priority of each function, daily test tasks should be refined, tests should be carried out overtime, daily test reports should be produced, project personnel should be sent, risks should be assessed and so on. Six, before the launch of the discovery of a Bug, the first to analyze the severity of the Bug, not serious is the development of overtime modification, and then online; If it is serious, first check whether the development overtime can be modified. If not, it is like whether the project manager can apply for an extension of the online. Normally, after a few rounds of testing, we don’t have this problem before we go live. If a Bug is found online (in the production environment), check the severity of the Bug first. If the Bug is serious, roll back to the previous version and modify the Bug. If there is no problem, go online. If it’s not serious, we need to do an emergency “test” and ask developers to patch it. Testing is still done in a test environment first, in a pre-release environment, and finally in production. Under normal circumstances, our test will go through several rounds of unit, integration, system and pre-release testing, and this problem will not occur after the launch. 8. When a Bug is found in the test, how to deal with it? When a Bug is found, the first step is to save the screenshot, and then submit the formal Bug sheet to the corresponding developer, and then the developer will deal with it. Nine, found a Bug, developers think it is not a Bug how to do? First, find evidence from the requirements document to persuade the development; If the requirements document is not clear or does not describe, go to the product manager or the requirements person and have them determine if it is a Bug. Unit test Auxiliary test module Driver module: used to simulate the functions of the superior module of the module to be tested: receiving test data in the integration test, transmitting relevant data to the module to be tested, starting the module to be tested and printing out corresponding results. Pile module: it is used to simulate the function of the module called during the working process of the module to be tested: the module to be tested is called, which generally only carries out little data processing, in order to check the interface between the module to be tested and its subordinate modules. Integration test method

  1. Incremental integration method: top-down integration, bottom-up integration
  2. Non-additive integration method, also known as global integration method

How do software testers ensure version quality

  1. Self-test and smoke test are performed before development submission for testing
  2. During the testing process, the quality is guaranteed by integration testing, system testing and acceptance testing
  3. Test cases are reviewed
  4. Cross testing and regression testing are usually done before going live

Xiii. Standards for system release and online

  1. The system meets the function and performance requirements specified by users
  2. Close and fix all bugs
  3. Pass user acceptance tests
  4. Execute all test cases

The CMMI model

Capability Maturity Model Integration

CMMI Model: Capability Maturity Model integration (also known as: Integration of software capability maturity model), it is an idea, by the department of defense in 1994 under the U.S. department of defense and Carnegie Mellon university’s software engineering research center, and the defense industry association, joint development and research of the they plan to all existing now and about to be developed on the implementation of all kinds of capability maturity model (CMM), integrated into a frame, The condition for applying for this certification is that the enterprise has a valid software enterprise certification certificate.

  1. The initial stage

Software processes are disordered and sometimes chaotic, with little definition of process, success dependent on individual effort, and management reactive. 2. The manageable level establishes basic project management processes to track cost, schedule, and features. The necessary process discipline has been developed to replicate the success of earlier similar application projects. 3. The defined level has documented, standardized and integrated the processes of software management and engineering into the software process of the software organization. All projects use approved, tailored, standard software processes to develop and maintain software, and the production of software products is visible throughout the software process. 4. Quantitative management level analyzes detailed measurement data of software process and product quality, and has quantitative understanding and control of software process and product. Management has an objective basis for making conclusions and can predict performance on a quantitative scale. 5. Optimize the quantitative feedback of the management-level process and promote the continuous improvement of the process with advanced new ideas and technologies.

The Google Way of Software Testing. PDF

Blog Source: Blog of rainy Night