Сообщений в теме: 12

[crazy_kukla]

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

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

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

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

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

[Лелик32]

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

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

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

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

Удачи вам!

[crazy_kukla]

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

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

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

[Лелик32]

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

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

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

[crazy_kukla]

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

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

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

[Лелик32]

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

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

[kitsune]

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

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

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

[crazy_kukla]

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

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

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

[Future]

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

[Vasiliy]

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

[crazy_kukla]

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

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

[Future]

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

[OliaBudn]

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

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