Добавить юзера c обычной подпиской
Стань тестировщиком сегодня
Level 8 Work with requirements
At this level you will learn
work with requirements while we destroy the imperial troops in the Dagobah system.
Hurry up, we need your help!
Roles in creating a test plan
The following will list the main roles that you will have to try on yourself when creating a test plan. This does not mean that at your workplace you will perform them all (although most likely it will be so). It is clear that you need to be prepared for everything. After all, you can’t tell the employer - I somehow didn’t really like to administer the database, ask Vasya to do this. We list all the roles that come in handy, but do not focus on them a lot, since this information has already been given at the 4th level. Recall the roles we considered.
Main roles:
-
Test Manager, Test Project Manager
-
Test Analyst
-
Test Designer
-
Tester, Test Engineer
-
Supporting roles:
-
Administrator of the test system and applications supporting the testing life cycle
-
Database Administrator, Database Manager
-
Test developer
After you have learned all the roles in testing, I suggest analyzing each in more detail. And at this time, the Imperial Army retreated and went about their business.
Test manager, Test Project Manager
Produces management control (management oversight)
Responsibility:
-
Provides technical direction
Example: Distributes test execution and design responsibilities among other testers. Gives an instruction to create a test plan in our case.
-
Gets the necessary resources
Example: Finds out how many resources you will need (servers, smartphones, computers, etc.), and requests them in the technical support department before starting work.
-
Provides management reporting
Example: Draws up the necessary documentation for the previous two points. Usually these are the responsibilities of the team leader testers. If you are one tester in the department, then you are in luck; only you will have to do all this.
Test Analyst
Defines, prioritizes, and provides test case development
Responsibility:
-
Test Plan Development
This is the primary responsibility for coordinating the creation of a test plan.
-
Develops a testing model
Example: selects the types of testing, the number and duration of test cycles
-
Evaluates Testing Efficiency
It is carried out by calculating the project coverage with tests, creating a project map, calculating the level of software quality in percent
Test Designer
Sets and defines the operations, attributes, and relationships of test classes
Responsibility:
-
Installs and defines test classes
-
Installs and defines test suites (packages)
Example: creates tasks for writing test cases, test scripts. Combines all tests into test suites
Tester, Test Engineer
Run test cases
Responsibility:
-
Performs tests
-
Captures the results
-
Restores tests and system after failures
-
Documents change requests (detected defects, suggestions for improvement)
How complicated it is! Let's try to explain everything in simple words in Klingon.
Horrible! You do not understand Klingon ?!
Okay, I’ll explain it this way:
1. A test plan begins with a test manager or team lead. He sets the task of testing and creating test documentation and is obliged to issue technical documentation on a feature, or to make clear where it can be found. By documentation we mean: testing requirements, mockups, design, and more. We’ll talk about requirements right after this section.
2. The test analyst is primarily concerned with the test plan. Prescribes the strategy, selects the types of testing, decides what types of testing are needed, creates a testing schedule, divides everything into test sections (by areas covered by test cases), in general - fills all the points of the test plan.
3. Then comes the turn of the test designer. For each test section, he creates test cases or check lists or autotests. Then, after creating the test coverage, it will be responsible to give a report on the test coverage. He is also responsible for supporting all tests.
4. Time to test! At the end, testers pass all test cases, create a bug report on them, and testing ends with a noisy victory over bugs and release.
Work with requirements
An example of a non-testable software performance requirement
What did we miss in requirement?
What is the response time? At what bandwidth congestion? Should not exceed 1 second, under what conditions? Finally, the runtime of what ?!
-
System response time should be within acceptable limits.
-
The response time (Response to what operation?) Of the system (what is the system in this requirement: UI, DB, client + server + network?) Should be (Conditions? Load?) In an acceptable framework (What are these acceptable limits in numbers?)
What about the resources? What should they be?
An example of a testable requirement:
-
The response time of the system from the point of view of the end user (end-to-end) during a productive load (50 user sessions in the manager mode / 15 user sessions in the analytic mode) when the bandwidth from the client system to the application server is loaded 50% for a network of 100 Mb / sec, must not exceed one second for recording operations and three seconds for recording operations.
-
The execution time of analytical reports is determined separately for each sample.
-
The amount of RAM used should remain stable.
Practical tips:
-
Changes in requirements should clearly reflect changes in the functionality of the system and the covering test suite
-
The analysis of requirements coverage is recommended at the test design stage, provided that the process guarantees fixed requirements within the iteration
-
Under the condition of “floating” requirements, coverage analysis is performed upon delivery of a version of the system, which includes a set of relevant requirements. This approach increases the total time allotted for testing due to technological downtime.
-
Each requirement must be tested (have a test)
-
Each test must relate to a requirement.
-
Requirements can be generated by tests (when using agile methodologies)
-
Requirements must be under version control.
Before the master checks your knowledge, look at what the forces of evil are doing now,
for they do not sleep!
Test yourself before moving on!
Overview of roles testing artifacts
You need to understand that test documentation is created for all roles in testing. Moreover, it is necessary for the testing process as a whole, as well as for programmers, products and other specialties with which you will work. The following are the roles that most commonly relate to this type of test document.
Tester
Test Analyst
Test Designer
Test Manager
-
Test script
-
Test log
-
Test Case
-
Test-Ideas List
-
Workload Analysis Model
-
Test Data
-
Test results
-
Test Strategy
-
Test Automation Architecture
-
Test Environment Configuration
-
Test Suite
-
Test Plan
-
Test Evaluation Summary
All this is a graph of the structure of testing artifacts proposed by the IEEE 829 standard
Testing artifacts are documents stored in the version control system or filled out forms in the testing management system and the output reports generated by them.
A further review of the testing artifacts is provided in the context of the previously defined roles in the testing group.
Tester
Test script – a step-by-step description of the actions that must be taken to complete one test scenario. The test script should describe the actions for manual execution, suitable for transfer to the testing automation group.
Test log – the script execution protocol in the system, the result of the test script execution entered in the test report or the mark on the normal passage of the test set in the checklist.
Test Analyst
Workload Analysis Model – a working load model that defines the conditions and configuration of the system during testing.
Test Data – formal description of test data that will be used for testing or algorithms for obtaining test sets, if they cannot be described and presented due to size or complexity.
Test results – summary report compiled on the basis of test logs and information about defects recorded for the current state of the system.
Test Case – a formal specification of the state of the system before the test suite is completed, a description of the input conditions, the actions of the test script (possibly a set of links to test scripts) and the expected result (most often in the form of a description of the state of the system after the test script).
Test-Ideas List – a numbered list of ideas that can be implemented as test scripts. Serves for preliminary approval of the direction and approaches to testing.
Test Designer
Test Strategy – a document that defines the strategy (a set of actions, types of tests performed, required resources, etc.) of testing the system in testing. RUP offers a testing strategy as the main part of the Test Plan of the testing project.
Test Automation Architecture – a document fixing approaches to test automation, as well as test specifications that are subject to automation and a description of instrumental solutions for software testing automation.
Test Environment Configuration – description of the software and hardware configuration of the test bench, as well as features of the configuration and administration of application software.
Test Suite – a document describing a set of test scenarios covering business transactions and showing the possibilities of analyzing the state of a system under a test by analyzing test logs and messages about recorded errors.
Probably tired, the forces of darkness are also resting. Listen to the joke:
"What green I was then ..." thought Yoda after watching the first episode.
Test Manager
Test Plan – a document describing the goals and objectives of testing an application or system under a test, including a description of the general approach to testing, a testing strategy, a list of supplied artifacts and a plan for using resources.
Test Evaluation Summary – a document representing a summary analysis of the test results in the context of the resources expended and the results achieved, the system’s readiness for release and forecasts for improving the cost / result ratio for further stages of the project.
Testing purpose
The purpose of testing the project is to check all its functionality on different versions of browsers, at different monitor resolutions, as well as conduct a series of stress tests to identify bottlenecks and vulnerabilities of the project. The final documents of the testing process will be: a report on the results of the test, which includes a description of the test environments and the found defects and shortcomings. The conclusion of testers about the general condition of the project, which is a graph of the ratio of critical defects to their total number. Testing is supposed to be carried out in manual mode, without the use of automated systems.
Strategy
The testing process strategy is planned in three stages. Consider the stages of the testing process:
The first stage is to analyze the technical specifications, compile a critical checklist, draw up a test plan, as well as a partial run of functional tests.
The second stage will be devoted to detailing the functional checklist and a detailed run of functional tests with the identification and description of defects.
In the third stage, stress testing and stress testing will be performed with a description of the defects found or demonstration of compliance with system requirements.
Thus, the maximum detailing of the testing depth is achieved, which, in turn, allows you to more accurately determine the resources spent, and also allows project developers to start fixing defects at the earliest stages.
Due to the refusal to maintain defects in the bugtracker, all detected defects will be transmitted to the project managers in writing via bug lists.
At the first stage, smoke testing will be applied, in which the requirements will be clarified, test environments will be defined and configured.
By the beginning of the second stage, a critical checklist will be generated, as well as a functional test checklist and user story.
At the second stage, detailed testing of the project functionality is performed, defects are collected and described. Each checklist is run for each browser.
The third stage completes the testing work. It conducts an established set of tests to identify vulnerabilities. This type of testing is quite time-consuming, so the necessary set of test cases is being developed together with the developers of the project.
Definitions
Project - The bla bla project serves to create .......
Functional testing - testing application functions for compliance
Stress testing is an assessment of the reliability and stability of a system when exceeding the limits of normal functioning. Test environment - a set of software for reproducing user actions as close as possible to real ones.
Terms of Reference - a document describing a set of technical and functional requirements for a software product. User story - a step-by-step instruction that reproduces the user's actions.
Purpose
Purpose of the document (purpose):
The purpose of this test plan is to describe the testing process of the bla-bla.ru website (full address http://bla-bla.ru). This document allows you to get an idea of the planned work, timing and testing strategies. This document does not intend to describe test cases, links to found defects, or their analysis.
Hooray! Now you know what a test plan is and you can easily write it! You think a joke?
No, not a joke! Most likely, you have already begun to create a test plan and looked at all the documentation transferred in the previous level. It's time to open your test plan template and start filling it out. And where to start? Further, all the points ...
The master will explain everything to you in detail.
Has it always been a mystery to me how attack aircraft go to the toilet in their spacesuit?
Oh yes, I'm sorry, I was distracted, let's start with the definitions ...
Smoke testing
Purpose: Sketch skeleton of checklists for functional testing and stress testing. This method is used with a minimum set of tests and a minimum technical task. The purpose of this testing is not to identify errors, although if obvious defects are found at this stage, they will be recorded by the tester.
Functional testing
Purpose: Identification of functional errors, inconsistencies with the technical specifications and user expectations by implementing standard as well as non-trivial test scripts.
Testing in a specific environment
Purpose: To verify the correct operation and design of the project in various browsers and at different monitor resolutions.
Description of configurations:
Browser / Resolution
1680 * 1050 / Internet Explorer 11
Моя совсем ничего не понимать! Тест план большой и страшный. Там все на англиском. Ужжассс!! Брррр! Магистр помоги моя!
My understand absolutely nothing! The test plan is big and scary. Everything is in English there. Horror !! Brrrr! Master, help me!
What kind of voice is in my head? Master Yoda seems to have begun a telepathic transmission to explain the meaning of the test plan to us. May the Force be with us!
My young padawan. We will never leave you in the dark. Let me remind you that you can always turn to the masters in social services for help. networks or through a form. I hope my explanation helped you. But this is not all help - here's an example of a test plan that my best wrote on a different feature. Use it wisely, do not copy everything, and may the Force come with you!
The results of the theoretical part of the course,
all that we have learned to this level
This result so that you look at each item and remember everything you know about it is a small retrospective. Before that, it was about the theory of testing and test documentation. Theory ... Theory ... it is so boring, but still necessary before we begin to test and study practical aspects on specific types of testing. This is a necessary base, you can’t get into the testing space without it. You can fix the base by writing a test plan. Recall that we learned:
-
Definition of software testing and information system quality
-
Place of testing in the software development process
-
Testing Process Requirements
-
Goals and objectives of testing
-
Test levels
-
Testing steps
-
Types of tests
-
Testing Roles
-
Defect Management
-
Overview of test artifacts and test documentation
Level 9
You need to get at least 28,2 points for tasks of
level 8 to go to level 9.