Добавить юзера c обычной подпиской
Стань тестировщиком сегодня
Level 3
Development and work of testing artefacts
Уважаемый студент, мобильная версия данного уровня не доступна, пожалуйста перейдите в десктопную версию.
Welcome to Level 3, my young Padawan! Here you will face dark and light forces of testing. Fight with the dark side to learn, how it works and become a real tester, which is powerful in both positive and negative forces of testing. At this level you will become familiar with the relic of testing - Test-case. And, of course, with all surrounding documentation.
Well, let's start from the main "column" of testing. Test Case is an artifact describing a set of steps, the specific conditions and parameters, necessary to verify the implementation of the test function or a part of it.
Under test case we understand the structure as: Action > Expected Result > Test Result
Test Case
Basic definitions
In accordance to processes and methodologies of the software development, during a testing, a certain number of testing artifacts are created and used (documents, models and so on). The most widespread artifacts are:
-
Test-Cases & Test-suites
-
Bug Reports / Defects
-
Testing plan (Level 7)
-
Plan of design acceptance testing (Level 8)
-
Defects description (Level 5)
-
Report on testing
-
Check-list
-
Use cases/User story
-
As you see, three of them are so important that are assigned whole level each. So they are waiting for you in levels ahead!
Test Result
passed/failed/blocked
Expected Result
Action
Open page "login"
Login page is opened
passed
A bit difficult definition you may think. But if to put into simple words, then a test-case is a record of tester actions. Recorded as tested. It is necessary for any other tester or even a beginner unfamiliar with your product to be able to perform the testing without you. Also, test cases are suitable for understanding what part of work has been or need to be done, for monitoring and documenting the work process. Heads, you know, like documents very much.
Standard atributes of a test case
Let's look at what a test case is on practice. A test case is like a soup - different for every lady, though all the ingredients used are the same. There is no 100% reference test case, so we will look at different variants of test cases, and then you will be ready for any event. Here is one example of a test case, written for a test site from the homework:
1
2
3
4
5
6
7
1. ID - a unique identifier of a test case. This is useful for a clear understanding of a kind of checking (for example, to give a link to a description of a bug on this test case).
2. Name - a brief description of a checking idea. Should fit in Twitter and be understandable! Briefly, but succinctly! Here is important to go easy on brevity - what you are talking about should be clear for everyone, not to you only.
3. PreSteps (PreConditions) - a description of actions necessary to be done, but not directly related to the checking (for instance, to register in the system to check an element creation). If there are no PreSteps, then a section is not filled.
4. Steps — a description of actions necessary for checking (for instance, creation of an element).
5. PostSteps (PostConditions) - a list of actions, translating a system in the initial state.
6. Expected result — the checking itself: what we expect to obtain after steps ("The element is created").
7. Test Result - passed/failed/blocked.
8. Test Case Priority - the importance of a test case. Can be ranged from 1 to N or with a priority: minor, major, critical, there is also blocker, but it is rarely implemented to a test case.
Types of Test Cases
Negative test case
Operates both correct and incorrect data (at least 1 incorrect parameter) and aims to check exceptional conditions (validators operations), and also checks that a function called by the application does not proceed at the validator operation.
Positive test case
Operates only with correct data and checks if the application correctly proceed the function called.
Examples
Action
Expected Result
Test Result
PreConditions
do A1
verify B1
do A2
verify B2
Test Case Description
do A3
verify B3
PostConditions
delete this user
In the given example the final check is В3. It means, that it is the key. Thus, A1 and А2 are the actions that make the system being ready for a testing. And В1 and В2 are conditions, at which the system is ready for a testing. So, what we have is:
Implementation
Action
Expected Result
Test Result
(passed/failed/blocked)
PreConditions
do A1
verify B1
passed
do A2
verify B2
failed
Test Case Description
do A3
verify B3
blocked
PostConditions
delete this user
In this example, during the passage of test cases, a tester failed to perform step A2, and as a result, the system did not come to the state suitable for testing. In this case, a tester gets a bug with the status "blocker" and append all further states as "blocked". Passage of the test cases will resume only after the correction of this error. If discovered a bug that does not block further steps, test case always goes to the end.
More examples
Depending on the requirements of the functional coverage and the rules of writing for test cases in a particular company, we can reduce the detalization of test cases:
Examination of page display
Action
Expected result
Test result
Open page "Log in"
-Page "Log in" is open
- Page name - Log in
- The company logo is in right upper corner
- On the form 2 of box - Name and Password
- The button "Log in" is available
- "Forgot password" - is available
Page name “Log in”
Bug #BG23 is opened
Test suite
Test suite – a suite, which contains a set of test cases and helps testers to organize, perform and give reports on test cases. As for test cases, test suites are assigned with: Active, In Progress, Completed.
Test cases are combined in test suites for more convenience when you perform test cases. Since, it is necessary to go through them from a module to module, from one type of testing to another, and not randomly, going from one to one leaving most part of module or functionality unchecked.
A test case can be added into several test suites or test plans. One test suite may contain any number of of cases.
Structure of test documentation
All the structure will be clear for you after this scheme. Test cases are combined into test suites for testing of certain features of your product. And test suites are determined by a test plan that contains all the strategy of the testing.
Example of test cases
Pay a very serious attention to these examples. Spend as much time for their study as necessary. Obviously, it is not like reading "Beauties of the galaxy". But you need to understand the rules of the test case creation, and it is better to do on real examples. So, for your service:
1. Classical table test case
2. Table with variants test case
3. Test case with a bank, more than 50 test cases. It is Jackpot! (Tab "Coverage with test cases")
4. Test case in the trekking bug system bug Jira
Example of a test case performed in the trekking bug system Jira
Be careful with the forces of darkness. Darkness does not sleep and is waiting for you in the most unexpected place
Test Report
Test Report is a way of communication, aimed to establish transparency in the QA team work for a day or a different time cycle (sprint) and includes information of both the defects found, and of the results of passed tests.
Test report may be in a form of:
• Sending Email/document (most often)
• Meeting/presentation. Meeting and an oral report, or the report with a presentation
• Report in a blog
• Both everyday email and everyweek meeting
Usually, a test report is for:
• Devolopers;
• Customer of a project;
• Bosses and team leaders;
• Support team of a testing area;
• Business analytic / Product manager and other members of a project team.
They are all recipients / participants of a meeting
Content of a test report
• Number of tests planned for the reporting period
• Number of tests performed during this period
• Total number of tests performed (from planned)
• Number of defects found during this period and their status
• Total number of defects found during this period and their status
• Number of opened critical defects
• Blockers - problems of the test environment (only at their presence)
• Showstoppers – all that bothers the work - for instance, a PC misbehaves
• Attachment / link on a document for tests performance
• Link to a bug report, defect, your tool of texting
Как выглядит тим лид когда слушает твой тест репорт
Practical adices from Master:
- Mark an overall state of test by color. For example: green - tested in time, orange - a bit late, red - the test is delayed or blocked.
- Include some simple indicators in your report like: percent of successfully passed tests due, density of defects in %, percent of critical defects from all; doing it you don't just give numbers, you really allow to estimate the quality of a product that you test.
- If the most part of the work is done – mention it.
- If there is a critical defect which will block some part of a future work - underline it.
- When using a presentation, do not forget to include several graphs to illustrate your material better.
- You may also mention your future plans in the TODO section.
Let's consider two examples of reports. It will be informative.
Example of a test report table
When do you definitely need to use a table? In the case, when several people work on filling. Or, if there is a large volume of data for the report. Let's look at the example in details:
1. Module -logical section in the functionality of a project. Similar to the exmple of a test case №3
2. Scenarios - name of the test scenario. Similr to an element of a check list
3. Sub levels - sub-scenario of a test
4. Complexity - how diificult a test is
5. Responsible tester - a guy responsible for testing
6. Date - date of the test performance
7. Status - passed/failed/locked/not executed. Please memorize them!
8. Defect ID and brief description - defect's identificator and it brief description
9. Severity/Priority - characteristic of a defect
10. Status - defect's status
Example of test report
Hello.
Short update about feature status.
In general Automation with 2.983 RC and backgroundperpage open - Pass QA.
But I met a problems with Image compare test (failed 116 tests), because appears scroll on screenshot from site with experiment. This don't reproduces manually.
So I've sent a letter to automation team because don't know how to handle this.
Link to investigation table
Manual QA cycle:
Founded one more critical bug - WOH-9557 - Some templates doesn't show background with experiment turned on
Plans TODO:
- Run image compare test with experiment on
- Check bug fix and perform Sanity cycle after
Blockers: 116 automation test fail due to automation bug. Autotest need be fixed.
Regards
Перевод на русский
Check-lists
Check-list - one of the fundamental test instruments. They allow you to not forget about the important tests, fix the results of your work and monitor the statistics on the status of the software product.
Check-lists are designed for experienced testers with enough knowledge about the product.
Check-list - a document containing a list of what needs to be tested. This check-list may be of an absolutely different level of details. How detailed is the check-list depends on reporting requirements, the level of product knowledge of employees and the product complexity.
It is important to remember - with all its brevity, a check-list does not allow abstraction and ambiguity. For example: "The validity of the footer" - wrong! What's right is "Check the operation of links and social networks icons in the footer of the site.".
Добрый день.
Короткое обновление статуса тестирования фичи backgroundperpage.
Цикл автоматизированного тестирования:
Автоматизированное тестирование релиз кандидата 2.983.0 и фичи backgroundperpage - Pass QA.
Но при этом возникли проблемы с тестами для сравнения скриншотов GUI (упало 116 тестов). Причина падения тестов - появление горизонтальyого scroll bar (прокрутки). Скролл не появляется при открытии сайта вручную, поэтому был сделан вывод, что баг в автотесте. Ссылка на таблицу результатов анализа автотестов.
Цикл ручного тестирования:
Был найден еще один критический баг - WOH-9557 - Некторые из шаблонов сайтов не отображают фоновое изображение.
Планы TODO:
- Запустить автотесты с выключенным экспериментом
- Проверить исправление найденной ошибки
- Провести выборочное регрессионное тестирование после исправления всех ошибок
Blockers: проблема с появлением горизонтального скролла в автотестах
С Уважением, Магистр Оби Ван Кенноби.
Advantages of Check-lists
The main principle of the check-lists is that each tester passes them individually, expanding a test kit by the expertise and personal vision.
Advantages of check-lists comparing to test-cases:
• The leveling the effect of pesticide in regression testing
• The expansion of test coverage due to differences in passing
• Reduced costs for maintenance and support of tests: no need to write a lot of characters!
• Lack of routines that skilled testers do not like
• The ability to pass and combine tests in different ways, depending on the preferences of employees
Disadvantages of Check-lists
Yes-Yes. Despite the attractiveness of check-lists, do not rush to use them from the beginning of your career. They have some disadvantages:
-
Novice testers are not always effectively carry out tests without sufficiently detailed documentation
-
Check-lists cannot be used for training novice employees, as they don't have enough information required
-
The level of details that offer check-lists may not be sufficient to a customer or a management
Example of Check-list
In order to check the layout of a site it can be used next check list (it will be useful at Level 9).
To verify the layout of any web page, perform these checks:
-
Compliance with the type of page layout
-
Cross-browser compatibility, coding and DOCTYPE
-
Validity, accessibility, microformats
-
Blocks Independence in CSS: minimization stage, the use of techniques BEM / MCSS / SMACSS
-
Site should look fine in all standard resolutions from 1024 and higher, have no horizontal scrolling, and fit into the screen of mobile devices
-
Correct operation when typing in a real text, reliability of the layout
-
Testing and optimization of download speeds
-
Available Win / Mac / Linux-unique fonts
-
Availability at the switched off (downloading) pictures
-
HTML5 forms, linking, validation
-
Semantics. Lack of nonsenses in html and css, uniformity, accuracy
-
The correct structure of headings (H1, H2, ..., etc., TITLE)
-
Efficiency at the switched off JavaScriptt
-
Efficiency at the switched off Flash
-
The absence of bugs at the increased font
-
And the last point - small checks (details are given below)
And another example of a check-list. In this case desktop applications have been audited in different OS. Every time we have to perform a cross platform testing, we create a check-list in Google Doc. In it, each tester notes the status of his/her work area. More details are in the example:
Use case
Use case – description of a system behavior at interactions with the environment.
Use case describes how an acting person tries to reach a goal using a program.
Use cases are designed first of all to determine functional requirements to a system and control all the developing process. All major activities such as analysis, design, testing are carried out through use cases. During the analysis and design, use cases allow to understand how the results, that a user wants, influence on the architecture of a system and how system components must behave in order to realize the desired functionality for a user.
What use cases are used for?
-
Give an idea on a system behavior
-
Are clear for both customers and developers
-
Allow to describe many alternatives
(exceptions)
-
List of use variations is a list of the system functionality
-
Allow to describe the functional iteratively (List of Use Cases -> Brief descriptions ->
main streams -> Extensions)
-
Goal
-
Acting persons
-
Initial conditions
-
Maximum and minimum guarantees
-
Main scenario
-
Alternative scenarios
Structure of Use case
How manager views Use
Complicated? And who said it would be easy? There is no time to give up, move on!
Case: Register on a site
Description: Site should provide to a user an ability to register. For this, a user must fill a register form. After the registration, the site must send to user a confirmation e-mail.
How Use case would be written by QA
Description in a format of Use Case
UC name: Register in a site
Acting person: user
Initial conditions: a user is on the main page of the site
Main scenario:
- User clicks "Register"
- Site provides the registration form
- User fills the form and confirms registration
- Site confirms coorectness of the filling
- Site registers a user and sends a confirmation letter to his/her e-mail
Alternative scenario:
1. User registers using social account...
User story
List of functionality (user stories) is a detailed list of what a user can do in a system. All the functionality of the future product is broken down into simple features in the form of <who> <is making> <what>. Each function has priority, which determines the importance for the overall success of the product. In addition to the functions acceptance criteria are described - response to user actions, under which it is considered to be operating correctly.
List of functionality overlaps with use cases. The difference is that the first help in accurate accounting requirements, and the second - in the understanding of how functions and the system as a whole work. User stories say that you need to do, and Use cases - how it works
And User story, Use case - names are so similar, but how to understand what is what?
For testers, Use case is a perfect basis to form test scenarios - test cases, since they describe how each action of a user should be performed. Use case by default is a testing requirement, since it always contains the goal to achieve and steps need to be done for this
Wait a minute! I see, that you are going to complete the level. But i still cannot understand why do we need Use case?
I'll exmplain, my shaggy friend.
User Story - one of scenarios, when Use Case - number of scenarios
Use Case combines several scenarios and shows relations between them
Really, he will understand when see an example. Here is a use case, based on three user stories: US1, US2, US3.
Example of Use Case
Exmple of use case will give I to you. Read it nd try to find out, what does it mean. To become a Jedi tester, you need to be good in such things
Use Case Name: Place Order
Actors:
-
Registered Shopper (Has an existing account, possibly with billing and shipping information)
-
Non-registered Shopper (Does not have an existing account)
-
Fulfillment System (processes orders for delivery to customers)
-
Billing System (bills customers for orders that have been placed)
Triggers:
-
The user indicates that she wants to purchase items that she has selected.
Preconditions:
-
User has selected the items to be purchased.
Post-conditions:
-
The order will be placed in the system.
-
The user will have a tracking ID for the order.
-
The user will know the estimated delivery date for the order.
Normal Flow:
-
The user will indicate that she wants to order the items that have already been selected.
-
The system will present the billing and shipping information that the user previously stored.
-
The user will confirm that the existing billing and shipping information should be used for this order.
-
The system will present the amount that the order will cost, including applicable taxes and shipping charges.
-
The user will confirm that the order information is accurate.
-
The system will provide the user with a tracking ID for the order.
-
The system will submit the order to the fulfillment system for evaluation.
-
The fulfillment system will provide the system with an estimated delivery date.
-
The system will present the estimated delivery date to the user.
-
The user will indicate that the order should be placed.
-
The system will request that the billing system should charge the user for the order.
-
The billing system will confirm that the charge has been placed for the order.
-
The system will submit the order to the fulfillment system for processing.
-
The fulfillment system will confirm that the order is being processed.
-
The system will indicate to the user that the user has been charged for the order.
-
The system will indicate to the user that the order has been placed.
-
The user will exit the system.
Alternate Flows:
3A1: The user enters billing and shipping information for the order. The user desires to use shipping and billing information that differs from the information stored in her account. This alternate flow also applies if the user does not maintain billing and / or shipping information in their account, or if the user does not have an account.
-
The user will indicate that this order should use alternate billing or shipping information.
-
The user will enter billing and shipping information for this order.
-
The system will validate the billing and shipping information.
-
The use case continues
5A1: The user will discover an error in the billing or shipping information associated with their account, and will change it.
-
The user will indicate that the billing and shipping information is incorrect.
-
The user will edit the billing and shipping information associated with their account.
-
The system will validate the billing and shipping information.
-
The use case returns to step 2 and continues.
5A2: The user will discover an error in the billing or shipping information that is uniquely being used for this order, and will change it.
-
The user will indicate that the billing and shipping information is incorrect.
-
The user will edit the billing and shipping information for this order.
-
The use case returns to step 3A1 step 3.
10A1: The user will determine that the order is not acceptable (perhaps due to disatisfaction with the estimated delivery date) and will cancel the order.
-
The user will request that the order be cancelled.
-
The system will confirm that the order has been cancelled.
-
The use case ends.
Магия превращения требований к продукту в конкретные тест кейсы и есть работа тестировщика. Давайте посмотрим процесс создания тест кейсов на примере. Изначально приходит общее требование к продукту. Например,- "Доступ к новой фиче имеют только руководящие должности". Тогда я нахожу все роли пользователей в ПО и разделяю их на руководящие и рядовые должности. Для каждой должности создам тест кейс: если она руководящая то проверю, что доступ нет, в обратном случае доступа быть не должно. А теперь в виде схемы:
Questions and conclusion
My nation is not as developed as Jedi, but we also want to learn testing. We did not know how to work with Google-tables before, but found it on the internet video - it has helped us to learn how to work with Google-tables. Maybe, you will find this helpful too, young tester? Feel free to skip this if you are familiar with spreadsheets.
Practical task
Congratulations, you have passed a really bone-rattling theory level! And I know, that you can move mountains on practice now! Let's start in order:
1. Pass working test case from Master Kenobi
2. Write your own check list for the familiar site from the first level
3. Now, when you have become skilled on practice, it will be so easy for you to answer few theoretical questions
4. Visit MasterJoda - he has some personal task for you
When you finished - send the task to Masters Council trough the form. They have noted that you are outstanding padawan. Gladden them with a good work!
Practice of creating test cases
This is the task for two. Thus, it is worth to ask your friend Chewbacca for help.
You'll have to create a test case to test the purchase of sweets (I love sweets). The opening use case is:
User comes to the home page, looks at the gallery, pictures, clicks on links, and so on - everything should work fine. Then he goes to the page of categories by the link and choose different types of cookies or candies placing them in the cart (we do not know exactly what he chooses, so you need to cover with tests all the unique selections). Then, he goes to the cart and there still increases or decreases the amount of goods, we do not know it sure, so check all the actions.
On the basis of this scenario, you need to build a test case, performing which a tester can make sure that the site works and all scheduled functions can be performed.
You need to understand that this is the minimum, so that you are not confused in what is necessary for you to do. In addition, it is necessary to fill a test case with those inspections of the site functionality that you may think are important. For example, check the components of the main page.
Then, you have to share test cases with Chewbacca, he will check your test case, and you will pass his test case, and give to him you review - what you would like to improve / fix. In order to do this - copy the document itself and show all changes and comments there.
P.S. Take a look at his test case before you send your own.
Для перехода на уровень 4, необходимо набрать минимум 21 балла за задания уровня 3.
