1. Каким должен быть (на)
стоящий тестировщик
или
Тестировщик как система
повесть в 2 главах

2. Требования к системе
● Функциональные требования - что тестировщик
должен уметь делать
● Нефункциональные требования - как тестировщик
должен делать то, что должен

3. Functional requirements
Глава 1
все тестировщики делают это

4. Пользователи системы
● Project Manager
● Разработчик
могут быть и другие...

6. Время
● Сколько времени нужно на
проверку?
○ Вход - объем работ
○ Выход - оценка по времени
● Что ты проверишь за это
время?
○ Вход - время
○ Выход - перечень функций,
которые реально
проверить за указанное
время
Тестировщик должен уметь делать оценку трудоемкости
своей работы

7. Состояние работ
● Что ты уже успел проверить?
○ Выход - перечень функций,
которые уже прошли
проверку
Тестировщик должен уметь четко формулировать ответ
на вопрос о состоянии работ по тестированию

8. Состояние продукта
● Сколько у нас багов?
○ Вход - функция/система,
состояние которой хотелось бы
узнать
○ Выход - количество багов, в
идеале - с разбивкой по
критичности
● Работает?
○ Вход - тот же
○ Выход:
■ Кратко - да/нет
■ Детально - да, но...
Тестировщик должен уметь описывать состояние
системы с разными уровнями детализации.

9. Описание дефекта
● В чем состоит этот баг?
○ Вход - "идентификатор" бага
○ Выход - четкое описание
дефекта, включая:
■ последовательность
действий для
воспроизведения
■ окружение
■ дополнительную
информацию
Тестировщик должен уметь четко описывать дефект

10. Экспертиза и интуиция
● Какие тесты ты порекомендуешь?
○ Выход - рекомендации по
необходимым типам тестов с
объяснением зачем они нужны
● Ты поставил бы систему в таком
состоянии?
○ Выход:
■ да/нет
■ почему
Тестировщик должен:
● Быть знатоком своего дела, а не простым
исполнителем
● Ставить себя на место PM-а, брать на себя
ответственность, аргументировать свою точку зрения

11. Non functional requirements
Глава 2
не все тестировщики одинаково полезны

12. Тонкая настройка тестировщика
В поисках золотого сечения
Тестировщик может
назвать багом отсутствие
возможности закрытия окна
с Esc... а может и не
назвать.
Следует определить "порог
срабатывания".

13. Повышаем КПД
В природе круговорот перекладывания
ответственности играет значительную роль
Hamlet, the QA of Denmark:
The bug or not the bug... that's no
longer a question if asked to PO.
His father, the PO of Denmark:
That's not a question, that's a trouble
if asked every time.
Шикспир, неизданное

14. Тестирование вхолостую
или "на малом газу"
Социальная реклама
Ваш тестировщик недостаточно
думает о создании продвинутых
тест кейсов?
Он не задумывается как
пользователь будет
использовать функционал?
Безинициативность - зло.
Смените его.
(парам-пам-пам-пам)

15. Тестировать нужно прагматично
Следует ли до посинения
тестировать удобство
кресла, если двигатель
работает с перебоями?
А если оно из кожи?

16. Контроль и посадка бага
Мы в ответе за тех кого приручили
Если тестировщик поставил
девелопера в известность о
наличии дефекта, и баг не
низкоприоритетный, то
тестировщику хорошо бы
проследить за статусом и
закрытием бага.
(древняя мудрость)

17. Слишком много хорошо...
Чрезмерная въедливость
иногда бывает вредна так
как смещает фокус на
малозначимые вещи.
Да тестировщик хочет как
лучше, а получается

18. Плох тестировщик что не держит
курсор на пульсе программы!
Хороший тестировщик - это командный игрок,
"болеющий" за своё дело и стремящийся к новым
вершинам

19. Контакты
Alexander Kryuchkov George Khubua
PM, Ciklum Team Lead, GlobalLogic
alexander.kryuchkov@gmail. khubua@gmail.com
com
Skype:
Alex.Kryuchkov