Документ описывает организацию процесса тестирования в IT-компаниях Академгородка, включая определения тестирования, роли в команде и методы. Он анализирует зависимости тестирования от бизнес-задач и методологий разработки, таких как Scrum и Waterfall. В конечном итоге, обсуждаются карьерные пути тестировщиков и эволюция их ролей в зависимости от требований рынка и компании.

1. Организация тестирования в IT-компаниях
Академгородка.
Карьерный путь тестировщика

2. 2
 Часть 1: Что такое тестирование вообще
Определения тестирования и обеспечения качества.
Классификация. Обзор ролей и артефактов тестирования
 Часть 2: Тестирование в реальной среде
Зависимость тестирования от задачи бизнеса, структуры
компании и используемой методологии
 Часть 3: Собственно карьера
Входные условия. Стоимость. Пути развития
Тест-менеджмент

3. Часть 1. Теория
3
 Чем мы всё-таки занимаемся? Определение
тестирования ПО и качества продукта
 Как тестировать?
 Кто тестирует?
 Жизненный цикл бага
Тест-менеджмент

4. Базовые понятия: Качество Продукта
4
 По каким критериям мы понимаем, что приложение
качественное?
 Функциональность — делает ли приложение то, что от него
требуется
 Надежность — работает ли приложение без сбоев
 Производительность — работает ли приложение с
приемлемой скоростью
 Удобство использования
 Если коротко и с практической точки зрения:
качество – соответствие требованиям заказчика
Тест-менеджмент

5. Базовые понятия: Тестирование
5
Первый баг
09.09.1945г. ученые Гарвардского университета,
тестировавшие вычислительную машину Mark II Aiken
Relay Calculator, нашли мотылька, застрявшего между
контактами электромеханического реле, и Грейс Хоппер
произнесла этот термин
Тест-менеджмент

6. Эволюция представлений о тестировании
6
 Проверка соответствия между реальным поведением
программы и ее ожидаемым поведением на конечном
наборе тестов, выбранном определенным образом.
[IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004]
 Техническое исследование программы для получения
информации о ее качестве с точки зрения
определенного круга заинтересованных лиц. [С. Kaner,
1999]
 Это не действие. Это интеллектуальная дисциплина,
имеющая целью получение надежного программного
обеспечения без излишних усилий на его проверку. [B.
Beizer. Software Testing Techniques, Second Edition. NY:van Nostrand
Reinhold, 1990]
 Процесс наблюдения за выполнением программы в
специальных условиях и вынесения на этой основе
оценки каких-либо ее аспектов. [ANSI/IEEE standard 610.12-
1990: Glossary of SE Terminology. NY:IEEE, 1987]
 Процесс выполнения программы с намерением найти
ошибки. [Г.Майерс. Надежность программного обеспечения. М:Мир, 1980]
1980
1987
1990
1999
2004
Тест-менеджмент

7. Эволюция представлений о тестировании
7
 Фокус процесса тестирования смещается в
сторону проверки требований
Тест-менеджмент

8. Цели тестирования
8
 Тестирование помогает достичь заданного
уровня качества продукта в процессе его
разработки
 Поиск и определение дефектов, и в идеале -
предотвращение
Тест-менеджмент

9. 9
 Тестировщик предоставляет сервис группе
разработки
 Команда разработки ожидает от тестировщика
актуальной и точной информации:
 о текущем состоянии программного продукта
 прогноза успешности разработки - сможет ли
проектная команда поставить продукт в срок и в
надлежащем качестве, если сохранятся
существующие тенденции обнаружения и
исправления дефектов?
 Какие корректирующие меры рекомендуется
предпринять, если прогноз неблагоприятный?
Тест-менеджмент
За что отвечает тестировщик

10.  Модульное/Интегрированное
 Альфа/Бета
 Новой
функциональности/Регрессионное/Приемочное
 White/Black/Grey box
 Test design/Exploratory
 Manual/Automated
 Функциональное
 Нагрузочное
 Интерфейса
 Безопасности
 И тд
Классификации тестирования
Тест-менеджмент
10

11. Как тестируем: уровни системы
11
 Модульный (Unit) уровень
Тестирование целостности кода на уровне логических
модулей
 Интеграционный уровень
Тестирование промежуточных результатов разработки
системы
 Системный уровень
Проверка полностью построенной системы на
соответствие сформулированным требованиям
Тест-менеджмент

12. Как тестируем: снаружи
12
Black box (Functional) Testing
 Тестирование с точки зрения конечного
пользователя
Тест-менеджмент

13. Как тестируем: изнутри
13
White box (Structural) Testing
 Анализ приложения на уровне кода:
 Ручное (экспертное тестирование кода)
 Автоматизированное тестирование инструментами
статического анализа
Тест-менеджмент

14. Как тестируем: «умные руки»
14
Grey box testing («серый» ящик)
 Тестирование с применением знаний о коде
приложения и подробностей реализации
функциональности
Тест-менеджмент

15. Как тестируем: Exploratory testing
15
Тестирование методом свободного поиска
 Exploratory – если проводится на
незнакомой системе,
 Ad hoc- на уже изученной, но спонтанным
образом -"на удачу"
Тест-менеджмент

16. Как тестируем: тест-дизайн
16
 Начинаем с анализа требований заказчика
 1 пункт требования = 1 тест кейс
 Незаменим при тестировании регрессий,
приемочном тестировании
 Плюсы
 Позволяет дать оценку времени на
тестирование
 Позволяет зафиксировать требования
заказчика
 Минусы
 Необходимость поддержки тест-планов
 При ручном тестировании – проверка на
выносливость тестировщика
Тест-менеджмент

17. Как это выглядит
17
Тест-менеджмент
Test procedure Expected result
comment
Result
Step 1
Click on the button
“Voir”.
Step result
Details of all the
selected servers are
displayed
Pass/Fail/Skipped
 Test aim
 Pre-condition

18. Как тестируем: автоматизация
18
Тест-менеджмент
 capture/playback tools – запись действия
тестировщика во время ручного
тестирования
 сode-driven testing – cоздание теста
непосредственно на языке
программирования
 keyword-driven testing – создание тестов
при помощи «ключевых слов».
Объединение автоматизации с созданием
сценариев тестирования

19. Как это выглядит
19
Тест-менеджмент
 ### script UI operation
menu “Window/Open Perspective/Other...” | click
with [window “Open Perspective”] {
table | select-item “My RCP Perspective”
button OK | click
}
• ### ensure that project with a name “foo” exists in
the workspace
get-projects | any project { project.name() == “foo” } |
true

20. Как это выглядит
20
Тест-менеджмент

21. Как тестируем: проверка производительности
Тест-менеджмент
21
 Тестирование производительности (performance
testing) – определение показателей
производительности системы при типовой нагрузке.
 Нагрузочное (load testing) - определение параметров
производительности при максимально прогнозируемой
нагрузке на систему
 Стрессовое (stress testing) – определение параметров
производительности системы в случае ограниченности
или недоступности ресурсов
 Тестирование надежности (reliability testing) –
определение параметров производительности в
условиях длительной эксплуатации, в том числе с
большими объемами данных

22. Как тестируем
 Тестирование интерфейсов
 Usability-тестирование
 Тестирование безопасности
22
Тест-менеджмент

23. ОСНОВНЫЕ РОЛИ
 Тест-менеджер, менеджер проекта по тестированию
 Тест-аналитик
 Тест-дизайнер
 Тестировщик, Инженер по тестированию
ВСПОМОГАТЕЛЬНЫЕ РОЛИ
 Администратор тестовой системы, приложений
поддерживающих жизненный цикл тестирования
 Администратор баз данных, менеджер баз данных
Обзор ролей и артефактов в
тестировании
Тест-менеджмент
23

24. Обзор артефактов тестирования (RUP)
24
 Дизайнер
 Test Strategy
 Test Automation Architecture
 Test Environment Configuration
 Test Suite
 Тест-менеджер
 Test Plan
 Test Evaluation Summary
Тест-менеджмент

25. Обзор артефактов тестирования (RUP)
25
 Тестировщик ПО
 Test script
 Test log
 Аналитик
 Test Case
 Test-Ideas List
 Workload Analysis Model
 Test Data
 Test results
Тест-менеджмент

26. Обзор ролей и артефактов тестирования
(практика)
26
 Роли:
 Тест-менеджер
 Тестировщик (тестировщик-аналитик, тестировщик-
программист)
 Что используется на практике:
 Тест план
 Чек-лист/Тест сьют
 Тест кейс
Тест-менеджмент

27. Типичный алгоритм работы с дефектами
Работа с дефектами
Тест-менеджмент
27
Open In Progress
Resolved
- Fixed
- As Designed
- Deferred
- Cannot Reproduce
- Obsolete
Reopen
Verified
- Fixed
- As Designed
- Deferred
- Cannot Reproduce
- Obsolete
Closed

28. Работа с дефектами
28
 Правило наименования дефектов «Где? Что? Когда?»
 Правила описания дефекта те же, что и для тестового
случая. Однако добавляется отличие ожидаемого
результата от полученного
Тест-менеджмент

29. Часть 2. Реальность
Тестирование в компаниях Академгородка
29
 Зависимость от задач бизнеса (заинтересованность в
тестировании)
 Тестирование не воспринимается всерьез. Уровень качества
заказчика особо не интересует
 Тестирование служит скорее внутренним целям, чем внешним
 Тестирование служит критерием сдачи проекта
 Специфические задачи - аутсорс тестирования, разработка своей
системы автоматизации тестирования
 Зависимость от технологий
 Можем ли автоматизировать тестирование
 Работа с багтрекинговой системой
 Зависимость от методологии работы
 Scrum
 Waterfall
 «Сели и сделали»

30. Продуктовые компании/Waterfall
30
Тест-менеджмент
 Продуктовые компании/Waterfall
 Компании-разработчики собственного ПО
 Разработка по каскадной модели – вначале разработка, потом
тестирование
 Отдельный отдел тестирования
 Особенности
 Ваша команда – команда тестировщиков
 В основном, регрессионное тестирование
 Отлаженная схема работы
 Есть возможности (и необходимость) не только ручного тестирования
 Плюсы, они же минусы
 Стабильность

31. Продуктовые компании/Waterfall
31
Тест-менеджмент
 Зависимость от задач бизнеса (заинтересованность в
тестировании)
 Тестирование служит скорее внутренним целям, чем внешним
 Следствие
 Нет сильной необходимости в детальных тест-планах
 Зато есть потребность в автоматизации. Однако потребность в
основном со стороны самих тестировщиков
 Есть возможности обучения и горизонтального роста. Если повезет, то и
вертикального

32. Продуктовые компании по-русски
32
Тест-менеджмент
 Зависимость от задач бизнеса (заинтересованность в
тестировании)
 Тестирование не воспринимается всерьез. Уровень качества заказчика
особо не интересует, пока чего-либо не случится
 Организация процесса
 Доработка существующих модулей по нечетким требованиям заказчика
 Как правило, нет выделенного тестировщика. Продукт тестирует либо
сам разработчик, либо аналитик
 Особенности
 Постоянное взаимодействие с разработчиком – при благоприятных
условиях, это плюс
 С необходимостью организации тестирования смиряются только после
больших провалов
 Как правило, на тестирование нет денег и времени (на тестирование
закладывается 10% времени от всей разработки)

33. Сервисные компании/Scrum
33
Тест-менеджмент
 Сервисные компании/Scrum
 Компании, выполняющие разработку на заказ
 Проекты небольшие и иностранных заказчиков
 Использование скрам-методологии
 Особенности
 Ваша команда – программисты
 В основном, проверка новой функциональности. Чем дальше к
завершению проекта, тем больше регрессионного тестирования
(логично, собственно)
 Необходимость демонстрировать результаты работы раз в 2 недели –
необходимость критериев качества

34. Сервисные компании/Scrum
34
Тест-менеджмент
 Зависимость от задач бизнеса (заинтересованность в
тестировании)
 Тестирование служит критерием сдачи проекта
 В то же время, есть проекты, где заказчик не заинтересован в деталях
тестирования. Но оно все равно поддерживается на хорошем уровне
 Особенности
 Как правило - детальный тест-план. Вам надо очень четко
проговаривать, что же именно вы протестировали
 Приемочное тестирование
 Автоматизация тестирования. Две крайности – при проекте-поддержке
возможно автоматизировать все. При проекте-разработке нового ПО
слишком мало времени для автоматизации. Хотя, тут больше зависит от
технологии
 Рост практически невозможен. Углубление умений – да, но рост,
горизонтальный или вертикальный – нет.

35. Сервисные компании/Тестирование на аутсорс
35
Тест-менеджмент
 Зависимость от задач бизнеса (заинтересованность в
тестировании)
 Тестирование и есть суть проекта. Разработки нет
 Особенности
 Обязателен детальный тест-план
 Способы тестирования определяются заказчиком
 Возможен горизонтальный (если проекты идут разнообразные) или
вертикальный рост.

36. Часть 3. Карьерный путь
36
 Входные условия
 Требуемое образование/опыт, зарплата, обязанности
 Опытный тестировщик/QA
 Требуемые знания, зарплата, обязанности
 Разновидности – QA/аналитик, автоматизатор (функциональное
тестирование), автоматизатор (нагрузочное тестирование,
производительности) и тд и тп. В принципе специализироватся
можно в любом направлении тестирования, если в этом есть
необходимость бизнеса
 Эволюция тестировщика как тестировщика
 Переход в другие профессии IT
 Да любые, кроме архитектора. То есть как правило нет проблем
перейти в саппорт, аналитику, программирование, внедренца...
 Тест-менеджер

37. Часть 3. Карьерный путь
37
Входные условия
 Требуемое образование – в принципе любое, но желательно ИТ либо
математическое
 Опыт – тоже любой. Это неважно
 Зарплата – 15/20 т.р.
 Обязанности – работа по имеющемуся тест-плану либо просто укажут,
что проверить

38. Часть 3. Карьерный путь
38
Опытный тестировщик/QA
 Образование здесь уже никого не волнует. Оно становится важным
для самого человека
 Опыт – важен. Причем уже требуется не просто опыт создания
кейсов/сценариев и т.д. Знание языков программирования – чем
дальше,тем жестче требование
 Зарплата – от 20 т.р. (наивные) до 70 т.р. (выше не видела)
 Обязанности – настройка тестовой среды, анализ спецификаций,
создание скриптов для автоматизации, тестовая документация...

39. Эволюция тестера или почему тестеры не хотят
быть тестерами
39
Надоело верифицировать баги
Надоело исполнять тест кейсы
Надоело писать тест кейсы
Не придумываю фичи
Хочу писать код
Хочу писать другой код
(с) Сергей Олейников, Parallels

40. Карьерный путь «обычного кишиневского
ИТшника»
40
Ну очень напомнило Академгородок
Обычный кишиневский айтишник большую часть жизни:
 мечтает стать программистом,
 проводит время в маленьких компаниях,
 поддерживает зарубежные долгосрочные проекты,
 работает в окружении малочисленного коллектива, большую часть
которого составляют вечно приходящие и уходящие «студенты».
Затем обычный кишиневский айтишник как следует учит Java,
английский вперемешку с французским и навсегда уезжает в
Канаду.
(с)перто Алексей Лупан testitquickly.com/2010/11/21/37/

41. Эволюция тестера - тест-менеджер
41
 Обязанности:
 Контроль объема проекта
 Планирование и контроль выполнения задач по
тестированию
 Управление персоналом
 Контроль рисков, связанных с тестированием
 Мотивация персонала
 Но! О тестировании методом свободного
поиска и программировании вам, скорее
всего, придется забыть
Тест-менеджмент

42. Эволюция тестера...
42
...ограничена исключительно Вашими
талантами. Грейс Мюррей Хоппер, нашедшая
первый баг, стала контр-адмиралом ВМФ США
Тест-менеджмент