Tech Talks @NSU: Организация тестирования в IT-компаниях Академгородка. Карье...Tech Talks @NSU
http://techtalks.nsu.ru
5 апреля 2012. Организация тестирования в IT-компаниях Академгородка. Карьерный путь тестировщика (Мария Колчинская, AcademSoft)
«Мария Колчинская (AcademSoft) рассказывает о процессах тестирования и карьере тестировщика»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Tech Talks @NSU: Организация тестирования в IT-компаниях Академгородка. Карье...Tech Talks @NSU
http://techtalks.nsu.ru
5 апреля 2012. Организация тестирования в IT-компаниях Академгородка. Карьерный путь тестировщика (Мария Колчинская, AcademSoft)
«Мария Колчинская (AcademSoft) рассказывает о процессах тестирования и карьере тестировщика»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Модуль 8. Лекция 37-38. Управление качеством проектаYana Brodetski
Управление качеством проекта
● Планирование управление качеством
● Определение и характеристики дефекта;
● Задачи управления дефектами;
● Классификация важности дефектов;
● Виды тестирования;
● Правильное описание дефекта;
● Жизненный цикл дефекта;
● Работа с базами дефектов;
● Метрики на основе дефектов.
● Составление тест плана
В статье рассмотрен ряд вопросов связанных с тестированием 64-битного программного обеспечения. Обозначены сложности, с которыми может столкнуться разработчик ресурсоемких 64-битных приложений, и пути их преодоления.
Презентация на комплексную тему Continious integration-Automated Testing-Agile, показывается связи между этими темам, обоснование автоматического тестирования , и вложения ресурсов для развертывания автоматического тестирования и непрерываной интеграциия. Все темы тесно связаны между собой , хотя бы появились независимос друг от друга.
Поиск ловушек в Си/Си++ коде при переносе приложений под 64-битную версию Win...Tatyanazaxarova
В результате появления на рынке персональных компьютеров 64-битных процессоров перед разработчиками программ возникает задача переноса старых 32-битных приложений на новую платформу. После переноса кода приложения высока вероятность его некорректной работы. В статье рассмотрены вопросы, связанные с верификацией и тестированием программного обеспечения. Обозначены сложности, с которыми может столкнуться разработчик 64-битных Windows приложений и пути их преодоления.
От Зефира в коробке к Structure Zephyr или как тест-менеджеру перекроить внут...
Сергей Слесарев
1. Отличия в работе тестировщика в
компании-разработчике ПО и компании-
пользователе ПО
Сергей Слесарев. БИНБАНК
sslesarev@msk.binbank.ru
2. Содержание
• Основной принцип в отношении тестирования,
принятый в компаниях-пользователях
• Содержание работ тестировщика
• Кто выполняет тестирование
• Уровень планирования и документирования
• Работа с дефектами и требованиями
• Выводы
3. Основной принцип в
отношении тестирования
В отношении тестирования в компании-пользователе
ПО принят следующий основной принцип:
«Нам требуется, чтобы стоимость покупки +
внедрения + сопровождения + издержек_из-
за_production_issues была минимальная, а
качество ПО – не цель, а только средство
достижения этого требования»
Если наличие ошибок в ПО не ведёт к издержкам, а
затраты на их исправление существенны, то такие
ошибки не следует исправлять.
7. Место тестирования в
компании-пользователе ПО
Компания-
пользователь
Компания-
пользователь
ПользователиПользователи
Компания-
разработчик
Компания-
разработчик
ТестировщикиТестировщики Бизнес-
поддержка
Бизнес-
поддержка
АналитикиАналитики
Тех. поддержкаТех. поддержка
9. Содержание работ
тестировщика
В компании-пользователе отдел тестирования входит в
состав IT-подразделения и воспринимается
менеджерами скорее не как отдельное независимое
подразделение, а как часть IT.
Отличие 1: В обязанности тестировщиков
входят различные задачи, иногда далёкие от
тестирования. В то же время, тестированием
могут заниматься другие подразделения.
10. Содержание работ
тестировщика
Из-за того, что большинство коллег не технические
специалисты, а специалисты в своей предметной
области, им требуется объяснять то, что в
компании-разработчике знают все сотрудники.
Отличие 2: Существенная часть работы состоит
в объяснении коллегам принципов
тестирования.
Например, для чего нужна дефект-трекинговая
система, для чего тестирование нужно планировать,
и его результаты документировать.
12. Кто выполняет
тестирование
Для небольшого отдела тестирования затруднительно
глубоко овладеть функциональностью всех
используемых в компании-пользователе
приложений. Сотрудники подразделения-заказчика
и подразделения поддержки владеют отдельными
приложениями гораздо лучше.
Отличие 3: Тестировщикам необходимо
организовывать тестирование силами
подразделения-заказчика и подразделения
поддержки.
13. Уровень планирования и
документирования
Из-за того, что существенную часть тестирования
выполняют не профессиональные тестировщики,
вытекают 2 следующих отличия.
Отличие 4: Ad hoc тестирование часто
проводится в тех случаях, когда по всем
правилам и канонам требуется проводить
тестирование, сопровождающееся более
точным планированием и документированием.
От тестировщика требуется уметь или очень быстро
научиться управлять процессом тестирования в
таких условиях.
14. Использование дефект-
трекинговой системы
Отличие 5: Процесс работы с дефектами в
некоторых случаях требуется
организовывать без использования дефект-
трекинговой системой.
Пользователей много, времени на то, чтобы всех их
научить пользоваться дефект-трекинговой системой
и убедить в том, что это необходимо, потребуется
больше, чем подстроить свою работу под эту
особенность. Тестировщикам самим заносить
дефекты, найденные пользователями – тоже не
вариант, т.к. это тоже потребует много времени.
16. Критичность дефектов для
компании-пользователя
В компании-пользователе можно гораздо более точно
оценить критичность дефекта и принять решение о
том, нужно ли добиваться его исправления. Кроме
того, может возникнуть ситуация, когда проблемы в
текущей версии более критичны, чем любые
потенциальные дефекты.
17. Оценка критичности
дефектов
Отличие 6: Приложения могут быть установлены
на продуктивную среду с известными
дефектами или почти без тестирования.
Уточнения: в некоторых случаях требования к качеству
системы в компаниях-пользователях может быть
даже более строгие, чем в компаниях-
разработчиках.
Установка приложения с дефектами характерна для
внепланового процесса, когда надо срочно
исправить какую-нибудь проблему.
20. Изменение требований
Отличие 7: Изменения требований приходят не от
аналитиков в виде документа, а от
пользователей, «из первых рук», в
нерегламентированном виде.
Изменения требований:
• В необработанном, неформализованном виде
(иногда даже устно).
• Частота не регламентирована.
• Тестировщик получает не решение об изменении
требований, а сам участвует в процессе принятия
решения.
21. Выводы
Работа тестировщика в компании-пользователе
отличается от работы в компании-разработчике.
• Требуется ещё больше коммуникативных навыков.
• Требуется больше гибкости, умения не жестко
следовать общим принципам приоритезации, а
адаптировать их к среде.
• Есть больше возможностей сменить направление
работы, особенно, если предметная область
представляет интерес.
• Есть возможность принять участие в построении
процессов в тестировании и более широко – в IT.
Компанией-пользователем в докладе называется организация, которая занимается разработкой ПО и для её функционирования требуется сложное ПО.
Основная цель доклада – рассказать об основных отличиях в работе тестировщиков в компаниях-разработчиках ПО и компаниях-пользователях ПО.
Есть компании-пользователи, в которых процессы работы подразделения тестирования отлажены очень хорошо. В докладе рассматривается компании, в которых процессы строго не установлены.
В компании-разработчике тестировщики тесно взаимодействуют в первую очередь с аналитиками и программистами. Взаимодействие с конечными пользователями, как правило, проходит через посредников.
В компании-пользователе тестировщики тесно взаимодействуют со службой поддержки и с конечными пользователями, а взаимодействие с программистами, как правило, проходит через посредников.
У компании-разработчика, как правило, много пользователей, и чаще всего нельзя точно сказать, какой дефект окажется критичным, а какой нет. Поэтому многие дефекты классифицируются как критичные.
Типичные примеры:
Изменения в законодательстве: если мы внедримся завтра, то мы получим много проблем у пользователей, службы тех.поддержки и т.д; но если мы не внедримся, то бух. учёт не будет соответствовать требованиям Центробанка и у нас просто не примут отчётность.
"Дыра" в безопасности интернет-банка: если мы внедримся завтра, то мы получим вот эти известные и, возможно, ещё какие-то другие функциональные проблемы; но если мы не внедримся, то у клиентов будут продолжать воровать деньги.
Коллекторская программа: если мы внедримся завтра, то мы получим проблемы с производительностью; но если мы не внедримся, то коллекторы не смогут эффективно работать и будут "рвать" не просрочивших кредит, а IT-подразделение.
Отход от традиционного стандарта по тестированию в некоторых случаях даёт выигрыш по скорости, позволяет получить удовлетворительное качество и, при этом, завершить процесс в установленные сроки.
Правильный процесс:
1. Не получит финансирования
2. Долгий
3. Не состыкуется с остальными процессами, т.к. они не другом качественном уровне. Если остальные процессы (аналитики, разработки и т.д.) организованы нестрого, то нельзя организовать высококачественный процесс тестирования.