Тестирование строго по ТЗ?
#1
Отправлено 14 ноября 2012 - 12:33
Я работаю в качестве тестировщика совсем еще не долго, но столкнулась с весьма неоднозначной ситуацией.
На проекте 2 тестировщика. Тестируем интранет-sharepoint проект.
В ходе тестирования, я проверяю не только строго по пунктам ТЗ и чеклиста, но и на различные типы уязвимостей, таких как html-, sql-инъекции, XSS... По мне, так это должно входить в обязательный минимум качественного продукта.
Но сегодня мне мой напарник задал вопрос - а зачем ты собственно это делаешь? Это не входит в ТЗ и нам за это не платят.
Вот и возник вопрос: а вы тестируете строго по ТЗ - шаг влево, шаг вправо - расстрел?
И вообще, нужно ли тестировать то, о чем с заказчиком не было договоренностей?
#2
Отправлено 14 ноября 2012 - 12:49
Я бы рассуждал так: есть деньги заказчика, они тратятся на то и то, которое расписано в договоре, в том числе и на тестирование. У вас скорее всего есть определенный тест-план, в котором расписано, что должно быть протестировано. Если в нем не указан такой пункт, как поиск уязвимостей, то заказчику значит, это и не нужно, иначе он бы попросил включить и данный тип тестирования, либо ваше руководство, чтобы срубить с него побольше денег, само настояло бы, что данный вид тестирования просто обязателен, иначе все, каюк! Раз такого не было, то, по-моему, целесообразно выполнять только то, что от вас требуется.Но сегодня мне мой напарник задал вопрос - а зачем ты собственно это делаешь? Это не входит в ТЗ и нам за это не платят.
Конечно, с другой стороны, найдя несколько критичных дыр в безопасности, вы можете рассчитывать на похвалу со стороны начальства и возможно, в последствии, включения данного типа тестирования со стороны заказчика. И тогда, несомненно, ваша компания получит от этого какую-то выгоду.
Инициатива, зачастую, наказуема, а иногда и нет. Нужно найти золотую середину.
Удачи вам!
#3
Отправлено 14 ноября 2012 - 13:40
то заказчику значит, это и не нужно, иначе он бы попросил включить и данный тип тестирования
При этом когда вышел релиз, заказчик сам выкатил один из багов, который я, увы, пропустила. Как раз о том, что отрабатывают скрипты на одной из форм.
В общем, ваш ответ мне понятен. Но убить перфекциониста в себе пока не получается ;)
#4
Отправлено 14 ноября 2012 - 17:05
А убивать и не надо, может пригодится при работе на другом проекте/компании. Некоторые это даже очень ценят.Но убить перфекциониста в себе пока не получается ;)
У меня к вам такой вопрос: а как у вас учитывается время на тестирование? В поисках уязвимостей вы, безусловно, тратите свое время, выделенное на функциональное тестирование. Или я ошибаюсь? Если нет, то как вы успеваете протестировать и то, что необходимо, и еще и дополнительные области? Не на ночь же остаетесь? =)
#5
Отправлено 14 ноября 2012 - 17:34
В поисках уязвимостей вы, безусловно, тратите свое время, выделенное на функциональное тестирование.
Хм, если отталкаваться от теории, то тестирование безопасности входит в область функционального тестирования. А вообще, такие простые вещи как xss, html-injections тестируются по ходу действия. Просто вместо валидных данных вводятся скрипты, дальше уже дело за малым - следить, где они себя проявят. Ну и время на заведение бага.
В общем-то не так уж и трудозатратно получается.
#6
Отправлено 14 ноября 2012 - 18:25
Да вообще-то нет =)Хм, если отталкаваться от теории, то тестирование безопасности входит в область функционального тестирования.
#7
Отправлено 15 ноября 2012 - 06:27
Я работаю в качестве тестировщика совсем еще не долго, но столкнулась с весьма неоднозначной ситуацией.
На проекте 2 тестировщика. Тестируем интранет-sharepoint проект.
В ходе тестирования, я проверяю не только строго по пунктам ТЗ и чеклиста, но и на различные типы уязвимостей, таких как html-, sql-инъекции, XSS... По мне, так это должно входить в обязательный минимум качественного продукта.
Кто пишет чек-листы?
#8
Отправлено 15 ноября 2012 - 13:31
Кто пишет чек-листы?
Сами и пишем. Из-за отсутствия как такового отдела тестирования, тестировщиков просто раскидывают на разные проекты - крутитесь как хотите, но чтобы функционал работал.
Вчера обсуждала с тест-лидом, она мою позицию поддержала. Ведь если портал потом сломают, вся вина будет по-любому на компании-разработчике.
#9
Отправлено 15 ноября 2012 - 16:15
#10
Отправлено 16 ноября 2012 - 07:43
Баги, которые вы заносите по уязвимостям, исправляются? Или они просто висят в BTS?
Может быть ваше руководство хочет продать тестирование безопасности заказчику отдельным пакетом и за другие деньги? А вы все уже нашли и вытащили на свет.
#11
Отправлено 16 ноября 2012 - 17:27
Баги, которые вы заносите по уязвимостям, исправляются?
Исправляются. Программисты наши тоже хотят делать качественный продукт. И это обнадеживает:)
#12
Отправлено 18 ноября 2012 - 07:59
#13
Отправлено 18 ноября 2012 - 08:16
Вот из этого следует, что находить нужно. Глупо вести себя как страус. Как они будут исправляться - не забота тестировщика. Хотя конечно тут нужно чётко понимать, что для заказчика важно, а что нет. Раз баг с их стороны был зарепорчен- значит важно. На счет неважного тут тоже все неоднозначно: вот вроде сейчас и не важно.... Но это только пока не произошло что нибудь. А достаточно ли хорошо объяснили заказчику важность этого неважного? Понял ли он на что подписался? Не свалит ли на вас потом вину за неисправленные проблемы? В таких случаях подстраховываться надо... Но это дейсвительноуже политика.Как верно заметил Vasiliy всё зависит от того, что именно продаёт Ваша компания. Если она продаёт коробочный продукт (для примера пусть это будет компьютерная игрушка), то тут нужно выпускать максимально качественный продукт изначально. Если же, ваша компания "подсаживает" другую компания на продукт, то ваша задача находить баги и говорить о них, НО исправлять дозировано, т.к. вы продаёте саппорт, а если через 2 года вы уже почти всё зафиксите, то познаете понятие "недополученная прибыль". Тема довольно сложная и интересная одновременно, тут больше уже не тестирование, а политика.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных