QA Club Kiev #2 Vision of TL and PM

1,812 views

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,812
On SlideShare
0
From Embeds
0
Number of Embeds
1,045
Actions
Shares
0
Downloads
3
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

QA Club Kiev #2 Vision of TL and PM

  1. 1. Каким должен быть (на) стоящий тестировщик илиТестировщик как система повесть в 2 главах
  2. 2. Требования к системе● Функциональные требования - что тестировщик должен уметь делать● Нефункциональные требования - как тестировщик должен делать то, что должен
  3. 3. Functional requirements Глава 1 все тестировщики делают это
  4. 4. Пользователи системы● Project Manager● Разработчикмогут быть и другие...
  5. 5. Время ● Сколько времени нужно на проверку? ○ Вход - объем работ ○ Выход - оценка по времени ● Что ты проверишь за это время? ○ Вход - время ○ Выход - перечень функций, которые реально проверить за указанное времяТестировщик должен уметь делать оценку трудоемкости своей работы
  6. 6. Состояние работ ● Что ты уже успел проверить? ○ Выход - перечень функций, которые уже прошли проверку Тестировщик должен уметь четко формулировать ответ на вопрос о состоянии работ по тестированию
  7. 7. Состояние продукта ● Сколько у нас багов? ○ Вход - функция/система, состояние которой хотелось бы узнать ○ Выход - количество багов, в идеале - с разбивкой по критичности ● Работает? ○ Вход - тот же ○ Выход: ■ Кратко - да/нет ■ Детально - да, но... Тестировщик должен уметь описывать состояние системы с разными уровнями детализации.
  8. 8. Описание дефекта ● В чем состоит этот баг? ○ Вход - "идентификатор" бага ○ Выход - четкое описание дефекта, включая: ■ последовательность действий для воспроизведения ■ окружение ■ дополнительную информацию Тестировщик должен уметь четко описывать дефект
  9. 9. Экспертиза и интуиция ● Какие тесты ты порекомендуешь? ○ Выход - рекомендации по необходимым типам тестов с объяснением зачем они нужны ● Ты поставил бы систему в таком состоянии? ○ Выход: ■ да/нет ■ почемуТестировщик должен: ● Быть знатоком своего дела, а не простым исполнителем ● Ставить себя на место PM-а, брать на себя ответственность, аргументировать свою точку зрения
  10. 10. Non functional requirements Глава 2 не все тестировщики одинаково полезны
  11. 11. Тонкая настройка тестировщикаВ поисках золотого сечения Тестировщик может назвать багом отсутствие возможности закрытия окна с Esc... а может и не назвать. Следует определить "порог срабатывания".
  12. 12. Повышаем КПДВ природе круговорот перекладыванияответственности играет значительную роль Hamlet, the QA of Denmark: The bug or not the bug... thats no longer a question if asked to PO. His father, the PO of Denmark: Thats not a question, thats a trouble if asked every time. Шикспир, неизданное
  13. 13. Тестирование вхолостуюили "на малом газу" Социальная реклама Ваш тестировщик недостаточно думает о создании продвинутых тест кейсов? Он не задумывается как пользователь будет использовать функционал? Безинициативность - зло. Смените его. (парам-пам-пам-пам)
  14. 14. Тестировать нужно прагматично Следует ли до посинения тестировать удобство кресла, если двигатель работает с перебоями? А если оно из кожи?
  15. 15. Контроль и посадка багаМы в ответе за тех кого приручили Если тестировщик поставил девелопера в известность о наличии дефекта, и баг не низкоприоритетный, то тестировщику хорошо бы проследить за статусом и закрытием бага. (древняя мудрость)
  16. 16. Слишком много хорошо...Чрезмерная въедливостьиногда бывает вредна таккак смещает фокус намалозначимые вещи.Да тестировщик хочет каклучше, а получается
  17. 17. Плох тестировщик что не держит курсор на пульсе программы! Хороший тестировщик - это командный игрок,"болеющий" за своё дело и стремящийся к новым вершинам
  18. 18. КонтактыAlexander Kryuchkov George KhubuaPM, Ciklum Team Lead, GlobalLogicalexander.kryuchkov@gmail. khubua@gmail.comcomSkype:Alex.Kryuchkov

×