Тестировщик программного обеспечения

1.

ТЕСТИРОВЩИК ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
КУРС «РУЧНОЕ ТЕСТИРОВАНИЕ»

2.

2. РОЛЬ ТЕСТИРОВЩИКА В РАЗРАБОТКЕ ПО
Кто такой тестировщик
Роль тестировщика
Обязанности тестировщика ПО
Личные качества тестировщика ПО
Почему это важно

3.

4.

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

5.

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

6.

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

7.

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

8.

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

9.

О ВЗАИМООТНОШЕНИЯХ И СПЕЦИФИЧЕСКИХ ПРОТИВОРЕЧИЯХ
ТЕСТИРОВЩИКОВ И РАЗРАБОТЧИКОВ СЕГОДНЯ СЛОЖЕНО НЕМАЛО
АНЕКДОТОВ

10.

О ВЗАИМООТНОШЕНИЯХ И СПЕЦИФИЧЕСКИХ ПРОТИВОРЕЧИЯХ
ТЕСТИРОВЩИКОВ И РАЗРАБОТЧИКОВ СЕГОДНЯ СЛОЖЕНО НЕМАЛО
АНЕКДОТОВ
Если бы разработчики и тестировщики работали в МЧС:
— Алло! Приезжайте, здесь жёлтая двенадцатиэтажка горит!
— Ну, не знаю, у меня напротив такая же жёлтая двенадцатиэтажка, и она не
горит.

11.

ОБЯЗАННОСТИ РАЗРАБОТЧИКА
1. Разработка программной архитектуры
2. Корректировка разработанной программы
3. Проверка обнаруженных проблем
4. Устранение обнаруженных ошибок
5. Разработка инструкций по работе с программами
6. Сопровождение внедренных программ

12.

ЧТО ОЖИДАЕТ ТЕСТИРОВЩИК ОТ РАЗРАБОТЧИКА
Своевременность сборки продукта
Исправление дефектов
Помощь в решении возникших вопросов
Уважение по отношению к тестировщику

13.

ЧТО ОЖИДАЕТ РАЗРАБОТЧИК ОТ ТЕСТИРОВЩИКА
Тестовая документация актуальна и верна
Полное и корректное описание дефекта
Корректный приоритет дефекта
Уважение по отношению к разработчику

14.

КАК УЛУЧШИТЬ ПРОЦЕСС МЕЖДУ РАЗРАБОТКОЙ И ТЕСТИРОВАНИЕМ?
Постановка целей тестирования
Тестирование с первых дней разработки
Обмен имеющейся информацией
Выработка общего подхода к дефектам

15.

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

16.

ОБЯЗАННОСТИ АНАЛИТИКА
Выявление и анализ требований
Интервью и анкетирование
Согласование и проверка обоснованности требований
Координация процесса тестирования
Контроль за реализацией требований
Управление процессом изменений требований

17.

ЧТО ОЖИДАЕТ ТЕСТИРОВЩИК ОТ АНАЛИТИКА
Описание требований в полном объеме
Своевременность внесения изменений
Помощь в решении возникших вопросов
Консультация относительно целей проекта
Помощь в решении разногласий с разработчиком

18.

ЧТО ОЖИДАЕТ АНАЛИТИК ОТ ТЕСТИРОВЩИКА
Помощь с проверкой спецификацией
Помощь в подготовке обучающих материалов пользователя
Уведомление о недостаточности или неясности требования

19.

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

20.

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

21.

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

22.

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

23.

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

24.

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

25.

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

26.

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

27.

СТОИМОСТЬ ИСПРАВЛЕНИЯ ОШИБКИ В ЗАВИСИМОСТИ ОТ МОМЕНТА ЕЕ
ОБНАРУЖЕНИЯ (ИЗ КНИГИ КУЛИКОВА С. «ТЕСТИРОВАНИЕ ПО. БАЗОВЫЙ КУРС»)

28.

СПАСИБО ЗА
ВНИМАНИЕ!
ДОМАШНЕЕ ЗАДАНИЕ
ОЗНАКОМИТЬСЯ С КНИГАМИ
1.
КУЛИКОВ СВЯТОСЛАВ
«ТЕСТИРОВАНИЕ ПО.
БАЗОВЫЙ КУРС»
2.
САВИН РОМАН
«ТЕСТИРОВАНИЕ ДОТКОМ»

29.

ТЕСТИРОВЩИК ПРОГРАММНОГО
ОБЕСПЕЧЕНИЯ
КУРС «РУЧНОЕ ТЕСТИРОВАНИЕ»

30.

2. ПРАКТИЧЕСКОЕ ЗАНЯТИЕ
Мифы о работе тестировщика
Разбор вопросов, встречающихся на
собеседоании
Работа с требованиями

31.

обязательно надо
хорошо
разбираться в
программировании
не надо
разбираться в
компьютерах
Пропущенный баг
— вина
тестировщика
в тестировании все
просто
В IT проще всего
попасть через
тестирование, а вообще
я разработчиком хочу
быть
куча рутины и скуки
Каждый
тестировщик
становится
автоматизатором
тестировщика
должны всемувсему научить
тестировщику
некуда расти
тестировщик — это
программист, у
которого не
получилось

32.

Характеристики, которыми должна обладать хорошая документация:
1. Полнота
2. Однозначность
3. Непротиворечивость
4. Необходимость
5. Осуществимость
6. Тестируемость
РАБОТА С ТРЕБОВАНИЯМИ

33.

1. Полнота ТРЕБОВАНИЙ
Все ли описано? Ничего не забыли? Вдруг у нас
остался неописанный функционал или параметр APIметода?
РАБОТА С ТРЕБОВАНИЯМИ

34.

1. Полнота ТРЕБОВАНИЙ
Решение: чек-лист проверок
РАБОТА С ТРЕБОВАНИЯМИ

35.

1. Полнота ТРЕБОВАНИЙ
Решение: чек-лист проверок
РАБОТА С ТРЕБОВАНИЯМИ

36.

2. Однозначность.
Требования должны трактоваться всеми
одинаково.
РАБОТА С ТРЕБОВАНИЯМИ

37.

2. Однозначность.
Все, что можно прочитать двояко, лучше
исправить. Это не значит, что нужно
описывать каждую мелочь, но всё зависит
от читателей документа.
Если это внутренний документ, а у вас
сильная
команда
—
можно
расписывать подробно.
РАБОТА С ТРЕБОВАНИЯМИ
не

38.

3. Непротиворечивость
Требования не должны противоречить сами
себе.
Такое
требований
обычно
много.
бывает,
Аналитик
когда
просто
забывает, что уже писал про параметр и
снова придумывает его поведение. Иногда
придумывает немного по другому.
РАБОТА С ТРЕБОВАНИЯМИ

39.

4. Необходимость
Помните главный принцип: «Кратко, но емко»?
Он действует и в документации тоже.
Пишите только то, что необходимо:
В ТЗ — функционал, основной сценарий и
альтернативы, типы ошибок.
В пользовательской документации — то, как
пользоваться системой. Но не доходя до
крайностей
и
обучения
включению
компьютера.
РАБОТА С ТРЕБОВАНИЯМИ

40.

5. Осуществимость
А
можно
ли
реализовать
то,
что
тут
написано? Насколько это будет сложно и
дорого?
РАБОТА С ТРЕБОВАНИЯМИ

41.

6. Тестируемость
Можно
ли
протестировать
функционал?
РАБОТА С ТРЕБОВАНИЯМИ
этот

42.

РАБОТА С ТРЕБОВАНИЯМИ

43.

Плохое требование
«Приложение
должно быстро
запускаться»
Плохие вопросы
«Насколько быстро?» (На это вы рискуете
получить ответы в стиле «очень быстро»,
«максимально быстро», «нууу… просто
быстро»).
«А если не получится быстро?» (Этим вы
рискуете просто удивить или даже разозлить
заказчика.)
«Всегда?» («Да, всегда». Хм, а вы ожидали
другого ответа?)
«Опционально
должен
поддерживаться
экспорт
документов в
формат PDF».
«Любых документов?» (Ответы «да, любых»
или «нет, только от- крытых» вам всё равно
не помогут.)
«В PDF какой версии должен производиться
экспорт?» (Сам по себе вопрос хорош, но он не
даёт понять, что имелось в виду под
«опционально».)
«Зачем?» («Нужно!» Именно так хочется
ответить, если вопрос не раскрыт
полностью.)
РАЗБЕРЕМ ПЛОХИЕ ТРЕБОВАНИЯ
Хорошие вопросы
«Каково максимально допустимое время
запуска приложения, на каком
оборудовании и при какой загруженности
этого оборудования операционной
системой и другими приложениями?
На достижение каких целей влияет
скорость запуска приложения?
Допускается ли фоновая загрузка
отдельных компонентов приложения?
Что является критерием того, что
приложение закончило запуск?»
«Насколько возможность экспорта в PDF
важна?
Как часто, кем и с какой целью она будет
использоваться?
Является ли PDF единственным
допустимым форматом для этих целей
или есть альтернативы?
Допускается ли использование внешних
утилит (например, виртуальных PDFпринтеров) для экспорта документов в
PDF?»

44.

РАЗБЕРЕМ ПАРУ ВОПРОСОВ, ВСТРЕЧАЮЩИХСЯ НА СОБЕСЕДОВАНИИ...

45.

Требования:
Разработать форму для обратного звонка.
Форма должна содержать 9 полей: Email, ФИО, Регион,
Город/область, Район, Город, Адрес, Категория
вопроса, Ваше сообщение.
1. Поле Email: пользователь должен ввести
валидный (правильный) email.
2. Поле ФИО : пользователь вводит ФИО на русском
языке.
3. Поля: Регион, Город/область, Район, Город
выбрать из предложенных вариантов.
4. Поле Адрес: пользователь вводит свой адрес.
5. Поле Категория вопроса: пользователь должен
выбрать один из предложенных вариантов.
6. Поле Ваше сообщение: пользователь вводит
текст своего обращения и оставляет номер телефона.
ТРЕБОВАНИЯМИ
ОЦЕНИТЕ ТРЕБОВАНИЯ.
ЗАДАЙТЕ ВОПРОСЫ.
https://atlant.by/about/contacts/