Дано - есть 59 потоков данных которые в бинарном виде падают на ftp, специальная программа забирает, преобразовывает и сохраняет в 59 таблиц. 1 поток - это один тип услуги. Примеры: 1Смс, 2звонок в дом сети, 3в роуминге, 4заказ услуги по короткому номеру. Для каждого потока 1 таблица.
Задача - 1)описать, как ты будешь тестировать. Перечислить этапы, основные идеи, направления. 2)оценить время тестирования по разработанному тестовому плану.
Был задан такой вопрос на собеседовании, я вначале попытался сказать , что по таким входным данным нереально оценить реальное время время затрачиваемое на тестирование, но мне сказали, что для спеца это как нефиг делать. В итоге понаписал всякого и место не получил.
Прежде чем озвучить , то что я сказал, хочу услышать мнение опытных людей , что отвечать в таких ситуациях? как бы вы ответили?
В таком виде мне и был задан вопрос. Уточняющими вопросами выпытал следующее.Что по сути звонки , услуги и т.д падают на фтп в виде бинарных данных потоками, каждый поток какая то услуга, всего потоков 59. Например 25 поток звонков и 34 потоков смс. итого 59 потоков. Каждый поток забирается программой и конвертируется в таблицу. В таблице мы видим время номер и т.д. . Но в начальные условия все это не входило.
И вот вопрос стоял так- как я все это буду тестировать?
Биллинг тестировать не доводилось (это ведь оператор связи или оператор, перепродающий услуги связи?), но идеи такие:
в биллинге важен учёт времени и средств, ну и реакция на событие (т.е., звонок, смс) должна быть в пределах некоторого времени (оговаривается).
Поскольку наверняка аппаратуру вам тестировать не надо (скорее всего, протестировали китайцы), тут надо формировать поток (обычным тлф, стендом или ещё как) и время начала, и продолжительность должны совпадать с данными таблицы.
Если к потоку привязан тариф, то и это вычисляется (это может быть очень сложным, кстати - скидки, смена тарификации в зависимости от продолжительности, кол-ва звонков в день и ещё кучи условий) и сравнивается с таблицей. Но я сильно подозреваю, что это всё считается другим модулем. А в табличках наверняка что-то вроде: время звонка, длительность, айди абонента, возможно, айди партнёра (роуминг, сервис коротких номеров).
Для этого куска биллинга наверняка подойдёт репорт в виде звонок (время, длительность, айди) - OK, смс (время, айди фром, айди ту) - баг.
Зато теперь понятно, что означает фраза "желательно/требуется опыт работы в телеком/билинг". :)
Как-то странно всё это. Биллинг тестировать - одна задача, целостность данных - другая, скорость обработки третья. И под каждую задачу нужен свой подход. Всё-таки сначала определяемся с типом тестирования, языками-технологиями, используемыми в проекте, а уже потом переходим к конкретике и оценке трудозатрат. Похоже, что компания (как это часто сейчас бывает) просто искала винтик на место одного из выпавших. :) А у вас оказалась не та резьба ;)
Считаю в корне не верно требовать от человека конкретное время в часах которе он затратит тестирования сферической лошади в вакууме.
Я в прогнозировании трудозатрат новичок, но лично мое мнение без изучения спецификации, без обозначенных ресурсов и инструментов невозможно судить о реальных трудозатратах.
Попробовал все в относительных формулах показать, иксы там игрики, но меня завернули. Блин неприятно капец было.
да ну, это имхо задание на сообразительность и на кругозор в тестировании.
Им надо чтобы человек не растерялся, выдал идеи (не важно, какие - это же не в продакшн). Потом прикинул, что надо делать, оценил потребности команды (один или тесколько тестеров), время в днях/неделях/попугаях.
имхо тут важно предоставить свои прикидки с учётом факторов, которые могут зааффектить выполнение задания: обучение команды, написание тестового тула, можно упомянуть много всего "про запас": создание системы отчётов для этого теста (вдруг нет), создание "быстрого" набора тестов - короткого, для билдов и т.д.
Было время, когда у нас нанимали - несомненно, человек, видящий решения и проблемы привлёк бы моё внимание (а не стандартные, со "знанием ISQTB" - орфография не моя ). Спросить точный расклад по времени возможно, но он будет разниться от опыта кандидата, опыта команды на стороне кандидата, опыта команды на стороне нанимателя - нет, они хотели просто способность прикидывать.
Просто мой мозг захлебнулся от количества идей при таких входных данных, меня понесло... начал говорить развертывание нескольких сред, мне сказали хрен тебе, потом я там начал говорить , что на определенном этапе использовал бы автоматизацию, мне сказали успокойтесь и бла бла бла...
Мой косяк был в том что я заволновался, мое повествование было немного сумбурным.
Подуспокоился, начал кидать примитивные формулы с относительными расчетами времени, на что мне сказали нужно конкретное время в часах. Тесть сверхповерхностно зная продукт я должен угадать то время которое они получили составив тест план. А бывают тест планы которые составляются несколько дней.
2. Посмотреть в базе соответствие сгенерированных данных с записями в таблице.
По времени генерация на системе для каждого потока(зависит от сложности), ну думаю часов 4-6 и проверка в таблицах без джоинов еще 4-6 часа. Селекты делаются легко + просмотр.
еще на проблемы добавим 2 часа. Итого от 10 до 14 часов.
Это на вскидку
Это учитывая что систему мы знаем, имеем документацию. Если не знаем то тут можно и год тестировать
"описать, как ты будешь тестировать. Перечислить этапы, основные идеи, направления."
стандартно - сначала надо исследовать предметную область, понять что в данном случае будет важно, составить список рисков и требований (если этого еще нет)
на основе этого написать тест план и рапланировать тестовые активности.
Для тестирования в данном случае необходимо определить несколько уровней.
ответ на прямой вопрос "как ты будешь тестировать это готовое приложение без доступа к исходному коду" - написание скриптов, генерящих запросы на все 59 потоков и проверяющих данные из таблиц (кроме функционального добавляем тестирование безопасности и нагрузочное). Более детальное планирование сильно зависит от конкретного проекта.
3. Ответ на:
"оценить время тестирования по разработанному тестовому плану."
необходимо выяснить:
- сколько есть тестеров, их уровень понимания того как работает продукт и уровень тестерских знаний
- на сколько различны тест кейсы по сложности, сколкьо тест кейсов может протестировать один тестировщик за день/неделю.
на основе чего уже можно рассчитать время (плюс прибавить несколкьо дней прозапас).
Темы запостил на нескольких форумах, и в общем результата такой-
В большинстве случаев все говорят разными словами , что оценку в часах (а от меня требовали конкретное время в часах) дать не возможно. Т.к. мало входных данных. Оценить можно относительно. На задание давалось 30 минут. За 30 минут можно пофантазировать о том что бы я включил в тест план, но давать результат в часах нереально. Сама формулировка "оценить время тестирования по разработанному тестовому плану" некорректна, т.к. без этого разработанного плана ничего реально оценить невозможно. А разработка плана может занять от нескольких , часов, до нескольких дней, в зависимости от ресурсов, сложности объекта тестирования, персонала и многих других начальных условий.
Но узнал много нового, т.к. у всех были интересные наработки по тест планам.
Вообще если у кого есть хорошие тест планы выложите почитать плиз, для личного развития.
Соглашусь, все-таки это вопрос без правильного ответа. А тут уж можно набрасывать на вентилятор:
Задавать уточняющие вопросы, выдавать варианты - гипотезы. Выбрать одну из них и оценить по времени. Настоять на своём. Или проявить гибкость... Что-то из раздела стресс тестирования.
Жаль только, что выхлопа от этого вопроса не так много. Нужно уметь применять такие вопросы и давать на них обратную связь. Похоже, что в данном случае обратная связь не была дана.
Поток выполнения, нить (англ.thread) — в программировании наименьшая единица обработки, исполнение которой может быть назначено операционной системой процессору. В большинстве случаев поток находится внутри процесса.
Многопоточность — модель программирования и исполнения кода.
Стыдно не знать.
В задании не имеет заначение 59 процессов или один процесс с 59 потоками
Стыдно путать понятие потока выполнения (то есть программного кода) и потока данных, уважаемый kulasov. :) Потоки данных - это никак не поток выполнения. А с учётом того, что Вы говорили об ftp, то вообще непонятно что имеется в виду об потоке данных ибо суть ftp: "FTP (англ. File Transfer Protocol — протокол передачи файлов) — стандартный протокол, предназначенный для передачи файлов по TCP-сетям (например, Интернет)." И никоим образом не связан с программным потоком. Так что мой вопрос вполне закономерен. :)
testomat.io управление авто тестами