Перейти к содержимому

Тестирование безопасности
онлайн, начало 16 июня
Автоматизатор мобильных приложений
онлайн, начало 16 июня
Автоматизация тестирования REST API на Python
онлайн, начало 16 июня
Selenium WebDriver: полное руководство
онлайн, начало 18 июня
Фотография

Тестирование строго по ТЗ?


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 12

#1 crazy_kukla

crazy_kukla

    Новый участник

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Божко Виктория Васильевна
  • Город:Санкт-Петербург


Отправлено 14 ноября 2012 - 12:33

Всем доброго времени суток!

Я работаю в качестве тестировщика совсем еще не долго, но столкнулась с весьма неоднозначной ситуацией.
На проекте 2 тестировщика. Тестируем интранет-sharepoint проект.

В ходе тестирования, я проверяю не только строго по пунктам ТЗ и чеклиста, но и на различные типы уязвимостей, таких как html-, sql-инъекции, XSS... По мне, так это должно входить в обязательный минимум качественного продукта.

Но сегодня мне мой напарник задал вопрос - а зачем ты собственно это делаешь? Это не входит в ТЗ и нам за это не платят.

Вот и возник вопрос: а вы тестируете строго по ТЗ - шаг влево, шаг вправо - расстрел?
И вообще, нужно ли тестировать то, о чем с заказчиком не было договоренностей?
  • 0

#2 Лелик32

Лелик32

    Постоянный участник

  • Members
  • PipPipPip
  • 235 сообщений

Отправлено 14 ноября 2012 - 12:49

Но сегодня мне мой напарник задал вопрос - а зачем ты собственно это делаешь? Это не входит в ТЗ и нам за это не платят.

Я бы рассуждал так: есть деньги заказчика, они тратятся на то и то, которое расписано в договоре, в том числе и на тестирование. У вас скорее всего есть определенный тест-план, в котором расписано, что должно быть протестировано. Если в нем не указан такой пункт, как поиск уязвимостей, то заказчику значит, это и не нужно, иначе он бы попросил включить и данный тип тестирования, либо ваше руководство, чтобы срубить с него побольше денег, само настояло бы, что данный вид тестирования просто обязателен, иначе все, каюк! Раз такого не было, то, по-моему, целесообразно выполнять только то, что от вас требуется.

Конечно, с другой стороны, найдя несколько критичных дыр в безопасности, вы можете рассчитывать на похвалу со стороны начальства и возможно, в последствии, включения данного типа тестирования со стороны заказчика. И тогда, несомненно, ваша компания получит от этого какую-то выгоду.

Инициатива, зачастую, наказуема, а иногда и нет. Нужно найти золотую середину.

Удачи вам!
  • 0

#3 crazy_kukla

crazy_kukla

    Новый участник

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Божко Виктория Васильевна
  • Город:Санкт-Петербург


Отправлено 14 ноября 2012 - 13:40

то заказчику значит, это и не нужно, иначе он бы попросил включить и данный тип тестирования


При этом когда вышел релиз, заказчик сам выкатил один из багов, который я, увы, пропустила. Как раз о том, что отрабатывают скрипты на одной из форм.

В общем, ваш ответ мне понятен. Но убить перфекциониста в себе пока не получается ;)
  • 0

#4 Лелик32

Лелик32

    Постоянный участник

  • Members
  • PipPipPip
  • 235 сообщений

Отправлено 14 ноября 2012 - 17:05

Но убить перфекциониста в себе пока не получается ;)

А убивать и не надо, может пригодится при работе на другом проекте/компании. Некоторые это даже очень ценят.

У меня к вам такой вопрос: а как у вас учитывается время на тестирование? В поисках уязвимостей вы, безусловно, тратите свое время, выделенное на функциональное тестирование. Или я ошибаюсь? Если нет, то как вы успеваете протестировать и то, что необходимо, и еще и дополнительные области? Не на ночь же остаетесь? =)
  • 0

#5 crazy_kukla

crazy_kukla

    Новый участник

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Божко Виктория Васильевна
  • Город:Санкт-Петербург


Отправлено 14 ноября 2012 - 17:34

В поисках уязвимостей вы, безусловно, тратите свое время, выделенное на функциональное тестирование.


Хм, если отталкаваться от теории, то тестирование безопасности входит в область функционального тестирования. А вообще, такие простые вещи как xss, html-injections тестируются по ходу действия. Просто вместо валидных данных вводятся скрипты, дальше уже дело за малым - следить, где они себя проявят. Ну и время на заведение бага.

В общем-то не так уж и трудозатратно получается.
  • 0

#6 Лелик32

Лелик32

    Постоянный участник

  • Members
  • PipPipPip
  • 235 сообщений

Отправлено 14 ноября 2012 - 18:25

Хм, если отталкаваться от теории, то тестирование безопасности входит в область функционального тестирования.

Да вообще-то нет =)
  • 0

#7 kitsune

kitsune

    Активный участник

  • Members
  • PipPip
  • 137 сообщений
  • ФИО:Полина Антипова
  • Город:Санкт-Петербург

Отправлено 15 ноября 2012 - 06:27

Я работаю в качестве тестировщика совсем еще не долго, но столкнулась с весьма неоднозначной ситуацией.
На проекте 2 тестировщика. Тестируем интранет-sharepoint проект.

В ходе тестирования, я проверяю не только строго по пунктам ТЗ и чеклиста, но и на различные типы уязвимостей, таких как html-, sql-инъекции, XSS... По мне, так это должно входить в обязательный минимум качественного продукта.


Кто пишет чек-листы?
  • 0

#8 crazy_kukla

crazy_kukla

    Новый участник

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Божко Виктория Васильевна
  • Город:Санкт-Петербург


Отправлено 15 ноября 2012 - 13:31

Кто пишет чек-листы?


Сами и пишем. Из-за отсутствия как такового отдела тестирования, тестировщиков просто раскидывают на разные проекты - крутитесь как хотите, но чтобы функционал работал.

Вчера обсуждала с тест-лидом, она мою позицию поддержала. Ведь если портал потом сломают, вся вина будет по-любому на компании-разработчике.
  • 0

#9 Future

Future

    Опытный участник

  • Members
  • PipPipPipPip
  • 261 сообщений
  • Город:Москва

Отправлено 15 ноября 2012 - 16:15

Есть довольно много подходов к тестированию и всё зависит от того, насколько долго вы будите сотрудничать с заказчиком и насколько ценный он для вас. Т.е. можно отталкиваться от UAT тестов (практика плохая), но помните, что в первую очередь проект нужно сдать, вся лирика это потом уже. Во-вторых можно честно предупредить заказчика о том, что вы подозреваете, что могут быть тут дыры, это при условии что вас гонят по времени и вы физически не успеваете что-то проверить. В общем, в этой проблеме как и везде очень важна политика, а не просто следование бумажке. Если ваш тест лид не может выбить больше времени на тестирование, то скажем так, это не очень хороший тест лид. Я похожей ситуации поступал так, говорил менеджеру, что я НЕ успеваю протестировать и что я уже проверил, как говорится за базар нужно отвечать.
  • 0

#10 Vasiliy

Vasiliy

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 924 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 16 ноября 2012 - 07:43

Тоже приобщусь к теме.
Баги, которые вы заносите по уязвимостям, исправляются? Или они просто висят в BTS?
Может быть ваше руководство хочет продать тестирование безопасности заказчику отдельным пакетом и за другие деньги? А вы все уже нашли и вытащили на свет.
  • 0

#11 crazy_kukla

crazy_kukla

    Новый участник

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Божко Виктория Васильевна
  • Город:Санкт-Петербург


Отправлено 16 ноября 2012 - 17:27

Баги, которые вы заносите по уязвимостям, исправляются?



Исправляются. Программисты наши тоже хотят делать качественный продукт. И это обнадеживает:)
  • 0

#12 Future

Future

    Опытный участник

  • Members
  • PipPipPipPip
  • 261 сообщений
  • Город:Москва

Отправлено 18 ноября 2012 - 07:59

Как верно заметил Vasiliy всё зависит от того, что именно продаёт Ваша компания. Если она продаёт коробочный продукт (для примера пусть это будет компьютерная игрушка), то тут нужно выпускать максимально качественный продукт изначально. Если же, ваша компания "подсаживает" другую компания на продукт, то ваша задача находить баги и говорить о них, НО исправлять дозировано, т.к. вы продаёте саппорт, а если через 2 года вы уже почти всё зафиксите, то познаете понятие "недополученная прибыль". Тема довольно сложная и интересная одновременно, тут больше уже не тестирование, а политика.
  • 0

#13 OliaBudn

OliaBudn

    Новый участник

  • Members
  • Pip
  • 28 сообщений
  • ФИО:Будницкая Ольга

Отправлено 18 ноября 2012 - 08:16

Как верно заметил Vasiliy всё зависит от того, что именно продаёт Ваша компания. Если она продаёт коробочный продукт (для примера пусть это будет компьютерная игрушка), то тут нужно выпускать максимально качественный продукт изначально. Если же, ваша компания "подсаживает" другую компания на продукт, то ваша задача находить баги и говорить о них, НО исправлять дозировано, т.к. вы продаёте саппорт, а если через 2 года вы уже почти всё зафиксите, то познаете понятие "недополученная прибыль". Тема довольно сложная и интересная одновременно, тут больше уже не тестирование, а политика.

Вот из этого следует, что находить нужно. Глупо вести себя как страус. Как они будут исправляться - не забота тестировщика. Хотя конечно тут нужно чётко понимать, что для заказчика важно, а что нет. Раз баг с их стороны был зарепорчен- значит важно. На счет неважного тут тоже все неоднозначно: вот вроде сейчас и не важно.... Но это только пока не произошло что нибудь. А достаточно ли хорошо объяснили заказчику важность этого неважного? Понял ли он на что подписался? Не свалит ли на вас потом вину за неисправленные проблемы? В таких случаях подстраховываться надо... Но это дейсвительноуже политика.
  • 0


Инструменты тестировщика: Командная строка
онлайн
Практикум по тест-дизайну 2.0
онлайн
Программирование на Phyton для тестировщиков
онлайн
Тестирование производительности (JMeter)
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале