Документ описывает процесс тестирования программного обеспечения, включая его методы и этапы. Рассматриваются динамическое и статическое тестирование, а также причины создания команды тестирования и выбор ее участников. Упоминаются основные инструменты для тестирования и их применение в различных проектах.

1. QA Club N.Novgorod
Организация и внедрение процесса тестирования
Тестирование с нуля

2. «…Мажьтесь солнцезащитными
кремами. Выгода их использования была
доказана учеными, в то время как
остальные мои рекомендации не имеют
более надежной основы, чем собственным
путаный опыт… »

3. Что такое тестирование?
Основы основ

4. Основные определения
Тестирование программного обеспечения (ПО) — процесс исследования
программного обеспечения (ПО) с целью получения информации о
качестве продукта.
Существующие методы разработки и тестирования программного
обеспечения не могут однозначно и полностью выявить все дефекты !
Все методы тестирования
• Действуют только в рамках определенного процесса проверки
разрабатываемого или исследуемого ПО.
• Доказывают, что дефекты отсутствуют с точки зрения использования
метода

5. Виды тестирования
Динамическое тестирование — анализ программного обеспечения, выполняемый при помощи выполнения
программ на реальном или виртуальном процессоре. Утилиты динамического анализа могут требовать
загрузки специальных библиотек, перекомпиляцию программного кода. Для большей эффективности
динамического анализа требуется подача тестируемой программе достаточного количества входных данных,
чтобы получить более полное покрытие кода.
Статическое тестирование — анализ программного обеспечения, производимый без реального
выполнения исследуемых программ (К статическому тестированию относится инспекция кода).

6. Вступление
Цели фирмы, причины

7. Цели фирмы и причины для создания команды тестирования
Причины:
1. Команда разработчиков и менеджеров устали от
затянувшихся несдач проекта
2. Нужно найти того, кого будем винить в неудачах
3. У всех есть и нам можно
Цели:
1. Попытаться улучшить качество выпускаемых продуктов
2. Выделили лишние ресурсы, нужно их освоить

8. Думаем немного о руководителе
•Команда с руководителем
•Команда без руководителя
Команда без руководителя может существовать только при
хорошем менеджменте фирмы

9. Выбор руководителя команды тестирования(и тех. поддержки)
Что происходит в головах менеджеров:
1. «Свой человек»
2. Наймем со стороны самого лучшего
3. Возьмем старшего инженера и постепенно обучим
Пункт №1 чаще всего используется в стартапах на ранних
стадиях развития.
Пункты №2 и №3 используются в основном средними и
крупными фирмами

10. Команда

11. Как определить количество участников
• Ресурсы фирмы
а) Материальные
• Масштабность проекта
а) Количество продуктов
в) Сложность продуктов
б) Количество разработчиков

12. Кого брать ?
• Профессионалов?
• Юниоров?
• Простых инженеров?

13. Характер команды тестирования
В команде всегда должен быть человек ,
который:
1. Усидчивый
2. Спокойный
3. Ответственный

14. Характер команды тестирования
В команде всегда должен быть человек ,
который в будущем станет
«неформальным центром команды».
Л: — У меня есть армия. Т: — А у нас Халк!
Локи и Тони в Башне Старка /Фильм «Мстители»/

15. Inceptions
«Сделайте мне хорошо»

16. Inceptions
• В существующий и долгоиграющий проект
• В проект, где все только-только начинается
(Практически идеальный случай)
Основные риски – это человеческие взаимоотношения

17. Внедряемся в существующую команду

18. Внедряемся в существующую команду
• Все сломать, построить заново
а) Основной риск то, что не построите и просто приведете к большему
хаусу
б) Может получится басня «Лебедь, щука и рак»
в) Можете не оптимально выбрать процесс
г) Главный плюс: иногда все проходит красиво и безболезненно и
очень быстро (1-2 месяца)
• Постепенное внедрение, постепенная переработка процесса
а) Главный риск- это то, что процесс может затянуться на долгие
человекочасы
б) Главный плюс: не сломаете то, что годами выстраивалось , Это
фактически не приведет к срыву сроков

19. Внедряемся в существующую команду
• Случай «Обрушение»;
• Случай «Deadlock (Взаимная блокировка) »;
• Случаи «Растаскивания команды тестирования»;
• Случаи «Непонимания с стороны менеджмента».

20. Работаем в проекте где все только начинается

21. • Главный плюс- рисков
меньше

22. Инструменты
Все для комфортной работы

23. Основные инструменты для процесса разработки и
тестирования (1/2)
Bugtracker:
1. Bugzilla (http://www.bugzilla.org/download/)
2. Redmine (http://www.redmine.org/projects/redmine/wiki/Download)
3. Mantis (http://www.mantisbt.org/download.php)
4. QC
5. Jira
Test Management System:
1. Testopia (http://www.mozilla.org/projects/testopia/)
2. Testlink (http://sourceforge.net/projects/testlink/files/)
3. Plugin for Redmine
4. QATraq (http://sourceforge.net/projects/qatraq/)
5. TrackTest (http://trac-hacks.org/wiki/TestCaseManagementPlugin)
6. xStudio (http://www.xqual.com/)
7. QC
SQL Injections:
1. NetSparker (http://www.mavitunasecurity.com/netsparker/)

24. Основные инструменты для процесса разработки и
тестирования (1/2)
Кросс браузерность:
1. Web Service http://crossbrowsertesting.com/ - платный
2. Web Service http://www.browsershots.org/ - полностью бесплатен
3. Web Service http://litmus.com/ - платный
4. Использовать portable версии браузеров (есть свои нюансы)
5. Использовать виртуальные машины
а) Internet Explorer 6-9 (http://www.microsoft.com/download/en/details.aspx?id=11575)
б) Создать недостающие свои машины
6. Тестирование на мобильных устройствах (Android, iOS)
Инструменты автоматического тестирования:
1. Squid
2. TestComplete
3. QTP
4. AutoIt
5. Selenium
Инструменты для автоматического нагрузочного тестирования:
1. Grinder - бесплатен
2. jMeter – бесплатен
3. TestComplete – платный

25. С чего начинается
тестирование?

26. Статистика использования браузеров
Весь Мир Россия

27. Статистика использования различных OS

28. С чего начинается тестирование
Этапы:
1. Анализ требований на продукт
2. Тест Дизайн
3. Выполнение тестов
P.S: Обычно анализ требований и тест дизайн объединяют в один этап
Тест Дизайн – это этап процесса тестирования ПО, который включает в себя анализ
требований, создание/проектирование тестовых сценариев и определение
необходимых типов тестов, для достижения заданного уровня тестового покрытия
приложения или систем, находящихся под тестом.
Тест – последовательность действий, которая переводит системы из одного
состояния в другое.
Тесты бывают управляемые данными и управляемые поведением(логические
куда пользователь может отправиться из данного состояния)

29. Что должен включать в себя тест ?
Последовательность действий при создании и выполнении тестов должно быть:
1. Допустимые данные
2. Граничные данные
3. Недопустимые данные
Как легко и быстро запомнить, что должен включать в себя
тест:
Можно использовать триплет ISO(не путать с институтом):
I – is Input data or action (Входные данные или действия)
S – is State of system at which data will be input (состояние системы, которая
получает входные данные или действия)
O – is the expected Output (Ожидаемый Выход, выходные данные или
выходное состояние системы)

30. Тестовый набор
Тестовый набор – набор тестов реализующий бизнес-задачу, выполняемую
тестируемой системой.
Замечание:
Обычно под бизнес-задачей понимается объем функционала, описываемый одним
функциональным требованием(так просто доносить до тестировщика и заказчика.
Покрыли мы их или нет).
Тестовый набор как правило включает в себя тестовые сценарии и тестовые данные
или правила их генерации.

31. Вопрос
Это все хорошо и правильно,
но нужно ли это ?

32. Хаос- залог успеха

33. Ad-Hoc
Ad hoc (лат. Ad hoc — «по месту») является латинской фразой, означающей «к этому, для
данного случая, для этой цели». Как правило, используется для обозначения решения,
предназначенного для конкретной проблемы или задачи и не предназначенного для
какого-либо обобщения или адаптации для других целей.
Ad hoc тестирование –это тестирование в
полнейшем хаосе, без спецификаций и проектных
планов, т.е. тестирование без формализации
самого тестирования

34. Что дает Ad hoc?
1.Быстрое знакомство с системой
2.Специфические дефекты
3.Массу вопросов и предложений
4.Работу менеджера и программистам на
начальном этапе
5.Экономию времени

35. Что можно использовать вместо тестов с шагами?
Контрольный список (перечень, таблица, карта; англ. checklist) — список задач/тестов,
структурированных особым образом с целью достижения поставленных задач.
Плюсы:
1. Контрольные таблицы упрощают подачу информации
2. Контрольную таблицу составить гораздо проще
3. Контрольную таблицу можно вести в простом Exel файле
4. Идеально подходит для некрупных и стартап проектов
Минусы:
1. Для проведения тестов нужен опытный инженер
2. Не всегда понятно, что и где необходимо проверить

37. Вопросы
Не стесняемся задавать любые вопросы ;)
Спасибо, что не спите :)