About testing web applications
Software testing is a process involved in all life cycles of its development, which is engaged in verifying and planning product requirements, preparing and implementing changes in the developed system. As a result, there are inconsistencies with the requirements and errors, the tools that are used are evaluated.
And if you digress and consider it systematically, the role of the tester actually lies in every person. If you look at the project as a person, the role
Quality Assurance is often considered a synonym for testing, but in fact it is a technique to prevent errors, and not to find and correct them. Quality in this sense is a characteristic of the product made.
Formally speaking, the tester should check even the technical task, project plan and analysis for consistency and clarity, and not just the program code and interface. Testing as an independent discipline in the general flow of software development appeared in the early nineties, when the audience (customers), quality and development time became more important.
The importance of software testing is especially important in critical systems. For example, the Therac radiotherapy unit (1985) irradiated a lethal dose of radiation to 6 people due to the lack of verification of the state of the unit in the code and validation. Or the rover in 1999 brought a loss of $ 125 million because of the lack of thought in a single measurement system between the development teams. And even in Estonia, there were problems with electronic elections due to poor load testing .
The basic principles of testing are embodied in a small ISTQB document and in the book “Foundations of software testing”.
The whole "charm" of a tester specialty is that, as a rule, this does not require a great deal of knowledge in programming and people far from web-building can try themselves in this role.
Testing as part of the company's work on the project can take place either in the waterfall approach, where the tester is pulled only at the end of the project, or according to the agile methodology, where the finished version rolls out with each iteration.
The test iteration consists of the following items.
The tests have their own levels, hierarchy and classes (hello RPG players!). You can check both different parts of the application (that is, by area, by pages), and different properties of this area (that is, in depth, degrees of quality). Here, by the size of the sites, tests can be divided into categories ...
Now, in fact, essentially testing ..
Testers, like “technical assignment writers” for self-control, should always remember the abbreviation SMART, so that more practical people would understand them correctly.
Ad-hoc (monkey) - random testing with no defined strategy.
Exploratory testing (exploratory testing) - examining the product if documentation is largely absent
Error grouping by equivalent classes ( equivalence partitioning ). The most popular technique. Each input is checked for requirements (by character length, possible values). In tests for minimizing their number, classes of different inputs are combined to make the maximum error coverage.
Another technique exists primarily for integer values. Errors usually occur in boundary values , so the technique is called ( boundary value analysis ). Two or three values ​​are selected near the border. For example, if the maximum header length is 250 characters, how will the error be generated at 249, 250 and 251 values?
More close to dynamic systems is the state transition testing method. The state depends on the input and on the previous state. States and transitions are described by graphs ( finite state machine ).
The decision table (decision table testing) itself comes to mind when the business rules in the application are very complex and need large mathematical calculations. Using tables, you can minimize the number of unique combinations.
Testing of scenarios (use-case based) takes place according to the scenarios created in the analysis, taking into account the different roles, alternative flows.
Intuitive-experimental testing (experience-based) as it is already clear comes to a person over time and allows you to find systematic design errors, programmers, data flow, taking into account changes in the code.
The goal of structural techniques is to maximize code coverage with tests, and since the white box is used as an addition to scripting techniques, it is logical that there is a maximum coverage of scenarios or, more precisely, their branches (statement & decision coverage).
Mathematically coverage percentage = 100% * number of units covered / number of all units. This does not mean that everything will be tested, only selected units of testing ( coverage item ). Testing units for each role look differently - for developers, these are database tables, functions in code, a request to an external component, while for a tester and analyst these are actions in a script, equivalence classes.
Rising above the units of testing, you can see the proposals and accordingly cover them ( statement coverage ). Good testing with black box techniques can cover up to 60-75% of sentences. In terms of code, this is a specific line.
The coverage of the branches ( decision coverage ) is already a higher level, it includes all types of hierarchy (if-else, switch, method calls, and so on). Black box methods can cover 40-60%. Cyclic complexity (cyclomatic complexity) is a test of the algorithm known to all computer scientists for quadratic, exponential and logarithmic complexity.
The next level of coverage includes possible paths that can be walked along branches. Theoretically, these paths are infinitely many if we take into account all the cycles.
The most familiar tools by the programmer are of course bug tracking systems (bug / issue tracking) - Mantis , Bugzilla and Trac . Some IDEs can integrate with them in such a way that commit actions into the repository of the versioned system (SVN / CVS / Git / Mercurial) can be updated without working in the browser.
There are more general, industrial products including requirements writing, scenario grouping - HP (Mercury) Quality Center and IBM Rational Quality Manager
Automated interface testing is currently the most popular using Selenium , SilkTest , HP QuickTest Pro , QF-Test, Rational Robot , TestComplete , Watir , TestPartner. There are more exotic tests like soapUI .
Load testing is a bit more complicated, because additional machines are needed (for example, one machine simulates 300 user connections) - it is usually impossible to start 3000 connections on one machine. Instruments:
Original article
And if you digress and consider it systematically, the role of the tester actually lies in every person. If you look at the project as a person, the role
- project manager is the spine and the autonomic nervous system
- programmers are skeleton and motility
- analysts are the senses
- testers are conscience
Quality Assurance is often considered a synonym for testing, but in fact it is a technique to prevent errors, and not to find and correct them. Quality in this sense is a characteristic of the product made.
Formally speaking, the tester should check even the technical task, project plan and analysis for consistency and clarity, and not just the program code and interface. Testing as an independent discipline in the general flow of software development appeared in the early nineties, when the audience (customers), quality and development time became more important.
The importance of software testing is especially important in critical systems. For example, the Therac radiotherapy unit (1985) irradiated a lethal dose of radiation to 6 people due to the lack of verification of the state of the unit in the code and validation. Or the rover in 1999 brought a loss of $ 125 million because of the lack of thought in a single measurement system between the development teams. And even in Estonia, there were problems with electronic elections due to poor load testing .
The basic principles of testing are embodied in a small ISTQB document and in the book “Foundations of software testing”.
The whole "charm" of a tester specialty is that, as a rule, this does not require a great deal of knowledge in programming and people far from web-building can try themselves in this role.
Organizational process
Testing as part of the company's work on the project can take place either in the waterfall approach, where the tester is pulled only at the end of the project, or according to the agile methodology, where the finished version rolls out with each iteration.
The test iteration consists of the following items.
- Planning. Determined goals, tools, time, order. The most psychologically difficult part is to understand and remember how the system should work, especially when there is no technical task, documentation, and a sane project manager (see exploratory testing below)
')
Therefore, the tester has at least an internal one, but the analysis consists of ...- Conditions
- Interaction Stories (cases)
- Implementation in the form of a document (basis) with reference to the specification, architecture and other documents (if they are)
- Checks. In case of inaccessibility and incomprehensibility - when and with whom to contact something, the task would not be forgotten.
- Prioritization of test cases (usually 1 case = 1 requirement = 1 web page). What are the most critical scenarios? Which are the most risky in development?
- Grouping tests into suites (suite) by common modules
- Check and compare with the requirements (the actual search for errors)
- Writing a report (both bugs and the overall picture - percentage of coverage)
- Rechecking the modified part (confirmation, retesting) or the effect on unchanged parts ( regression testing )
- Completion. Archiving tests, saving lessons learned.
Test levels
The tests have their own levels, hierarchy and classes (hello RPG players!). You can check both different parts of the application (that is, by area, by pages), and different properties of this area (that is, in depth, degrees of quality). Here, by the size of the sites, tests can be divided into categories ...
- Modular ( unit-testing ). Semi-automatic testing, in the sense that the tests have to be written by the programmer in very close contact with the code of the classes that the unit test has to check. It is not necessary to follow TDD, you can write at least for the most critical parts (financial transactions, etc.)
- Integration ( integration testing ) check connections between different modules. You can do both before the general integration of the system (module by module), and after (we write, we write, we add up - we will test it before the final acceptance test). Here again, close work with code and programmers.
- System - to go through the entire system and find inconsistencies with general standards and specifications in general. As a rule, at the end, when the system is basically ready.
- Acceptance- test passes as a rule already with the client during the transfer of the project and shows the willingness to work with clients. It is at this stage that alpha versions appear (everything is still probably on the developer’s machine, third-party testers are involved) and beta versions (everything is already on the client side, potential clients are attracted)
Types of tests
Now, in fact, essentially testing ..
- Functional answers to the question " what " should the application do
- Non-functional requirements / tests answer the question “ how ”. Non-functional features include interface usability, reliability, data security, scalability, cross-platform, and even economic viability (see ISO / IEC 9126)
- External (black box) / Internal (structural, white box). Structural testing verifies the internal structure of the application as it is implemented, but needs an understanding of the code. The “black box” approach is based on the fact that the software has not yet been implemented, or we do not know its exact work, but there is a specification of how everything should work. Structural ( white box ) approaches test the application from bottom to top, concentrating on maximum code coverage (rather than input-output combinations in the interface). Usually white box approaches are used in addition to the black box (as it should work).
- Regression testing - hasn't something broken due to this change? As a rule, this is what should be associated with unit-testing for greater automation.
- Test support ( maintenance testing ) - the system is already working and we are just updating it (deploy & migration). Migrations in recent times, too, are usually automated.
- Dynamic / static testing. Dynamic involves interactive, working with a ready system or code. This is not always necessary and possible. Theoretically, you can test the documentation or check the consistency of the analysis, find errors from the logs and so on.
Testers, like “technical assignment writers” for self-control, should always remember the abbreviation SMART, so that more practical people would understand them correctly.
- Specific - an exact description of the requirement, without copy-paste correspondence with the client, chat, data dump and one-step sentences
- Measureable - the measured value of numbers, time, probability, users, location.
- Attainable - technically achievable requirements. Not everything is still possible technically, you will not steal forward progress
- Realizeable - human-achievable human demands for time, quality, knowledge, price
- Traceable - compliance with the original idea and goal, the consistency of compliance with several requirements.
Black box technology
Ad-hoc (monkey) - random testing with no defined strategy.
Exploratory testing (exploratory testing) - examining the product if documentation is largely absent
Error grouping by equivalent classes ( equivalence partitioning ). The most popular technique. Each input is checked for requirements (by character length, possible values). In tests for minimizing their number, classes of different inputs are combined to make the maximum error coverage.
Another technique exists primarily for integer values. Errors usually occur in boundary values , so the technique is called ( boundary value analysis ). Two or three values ​​are selected near the border. For example, if the maximum header length is 250 characters, how will the error be generated at 249, 250 and 251 values?
More close to dynamic systems is the state transition testing method. The state depends on the input and on the previous state. States and transitions are described by graphs ( finite state machine ).
The decision table (decision table testing) itself comes to mind when the business rules in the application are very complex and need large mathematical calculations. Using tables, you can minimize the number of unique combinations.
Testing of scenarios (use-case based) takes place according to the scenarios created in the analysis, taking into account the different roles, alternative flows.
Intuitive-experimental testing (experience-based) as it is already clear comes to a person over time and allows you to find systematic design errors, programmers, data flow, taking into account changes in the code.
White box (structural) technology
The goal of structural techniques is to maximize code coverage with tests, and since the white box is used as an addition to scripting techniques, it is logical that there is a maximum coverage of scenarios or, more precisely, their branches (statement & decision coverage).
Mathematically coverage percentage = 100% * number of units covered / number of all units. This does not mean that everything will be tested, only selected units of testing ( coverage item ). Testing units for each role look differently - for developers, these are database tables, functions in code, a request to an external component, while for a tester and analyst these are actions in a script, equivalence classes.
Rising above the units of testing, you can see the proposals and accordingly cover them ( statement coverage ). Good testing with black box techniques can cover up to 60-75% of sentences. In terms of code, this is a specific line.
The coverage of the branches ( decision coverage ) is already a higher level, it includes all types of hierarchy (if-else, switch, method calls, and so on). Black box methods can cover 40-60%. Cyclic complexity (cyclomatic complexity) is a test of the algorithm known to all computer scientists for quadratic, exponential and logarithmic complexity.
The next level of coverage includes possible paths that can be walked along branches. Theoretically, these paths are infinitely many if we take into account all the cycles.
Instruments
The most familiar tools by the programmer are of course bug tracking systems (bug / issue tracking) - Mantis , Bugzilla and Trac . Some IDEs can integrate with them in such a way that commit actions into the repository of the versioned system (SVN / CVS / Git / Mercurial) can be updated without working in the browser.
There are more general, industrial products including requirements writing, scenario grouping - HP (Mercury) Quality Center and IBM Rational Quality Manager
Automated interface testing is currently the most popular using Selenium , SilkTest , HP QuickTest Pro , QF-Test, Rational Robot , TestComplete , Watir , TestPartner. There are more exotic tests like soapUI .
Load testing is a bit more complicated, because additional machines are needed (for example, one machine simulates 300 user connections) - it is usually impossible to start 3000 connections on one machine. Instruments:
- Small - Apache ab, httpperf , openload , Neoload , hammerora
- Large - Apache JMeter , IBM Rational Performance Tester , HP LoadRunner (Mercury), Oracle Application Quality Management (Empirix e-Load)
Original article
Source: https://habr.com/ru/post/73060/
All Articles