Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Вопрос на собеседовании на который не смог ответить


(FreeMan) #1

Вопрос на собеседовании-

Дано - есть 59 потоков данных которые в бинарном виде падают на ftp, специальная программа забирает, преобразовывает и сохраняет в 59 таблиц.
1 поток - это один тип услуги. Примеры: 1Смс, 2звонок в дом сети, 3в роуминге, 4заказ услуги по короткому номеру. Для каждого потока 1 таблица.

Задача - 1)описать, как ты будешь тестировать. Перечислить этапы, основные идеи, направления.
2)оценить время тестирования по разработанному тестовому плану.

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

Прежде чем озвучить , то что я сказал, хочу услышать мнение опытных людей , что отвечать в таких ситуациях? как бы вы ответили?

 


(ArtemIljin) #2

А что конкретно тестировать?

Как работает программа по рассортировке запросов? С какой скоростью потоки падают? Или это вопрос из разряда - тестировать всё?


(FreeMan) #3

В таком виде мне и был задан вопрос. Уточняющими вопросами выпытал следующее.Что по сути  звонки , услуги и т.д падают на фтп в виде бинарных данных потоками, каждый поток какая то услуга,  всего потоков 59. Например 25 поток звонков  и 34  потоков смс. итого 59 потоков. Каждый поток забирается программой и конвертируется в таблицу. В таблице мы видим время номер и т.д. . Но в начальные условия все это не входило.

 

И вот вопрос стоял так- как я все это буду тестировать?


(apetrovskiy) #4

Биллинг тестировать не доводилось (это ведь оператор связи или оператор, перепродающий услуги связи?), но идеи такие:

в биллинге важен учёт времени и средств, ну и реакция на событие (т.е., звонок, смс) должна быть в пределах некоторого времени (оговаривается).

Поскольку наверняка аппаратуру вам тестировать не надо (скорее всего, протестировали китайцы), тут надо формировать поток (обычным тлф, стендом или ещё как) и время начала, и продолжительность должны совпадать с данными таблицы.

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

Для этого куска биллинга наверняка подойдёт репорт в виде звонок (время, длительность, айди) - OK, смс (время, айди фром, айди ту) - баг.

Зато теперь понятно, что означает фраза "желательно/требуется опыт работы в телеком/билинг". :)


(ArtemIljin) #5

Как-то странно всё это. Биллинг тестировать - одна задача, целостность данных - другая, скорость обработки третья. И под каждую задачу нужен свой подход. Всё-таки сначала определяемся с типом тестирования, языками-технологиями, используемыми в проекте, а уже потом переходим к конкретике и оценке трудозатрат. Похоже, что компания (как это часто сейчас бывает) просто искала винтик на место одного из выпавших. :) А у вас оказалась не та резьба ;)


(FreeMan) #6

Считаю в корне не верно требовать от человека конкретное время в часах которе он затратит тестирования сферической лошади в вакууме.

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

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


 


(apetrovskiy) #7

да ну, это имхо задание на сообразительность и на кругозор в тестировании.

Им надо чтобы человек не растерялся, выдал идеи (не важно, какие - это же не в продакшн). Потом прикинул, что надо делать, оценил потребности команды (один или тесколько тестеров), время в днях/неделях/попугаях.

имхо тут важно предоставить свои прикидки с учётом факторов, которые могут зааффектить выполнение задания: обучение команды, написание тестового тула, можно упомянуть много всего "про запас": создание системы отчётов для этого теста (вдруг нет), создание "быстрого" набора тестов - короткого, для билдов и т.д.

Было время, когда у нас нанимали - несомненно, человек, видящий решения и проблемы привлёк бы моё внимание (а не стандартные, со "знанием ISQTB" - орфография не моя ). Спросить точный расклад по времени возможно, но он будет разниться от опыта кандидата, опыта команды на стороне кандидата, опыта команды на стороне нанимателя - нет, они хотели просто способность прикидывать.


(FreeMan) #8

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

Мой косяк был в том что я заволновался, мое повествование было  немного  сумбурным.

Подуспокоился, начал кидать примитивные формулы с относительными расчетами времени, на что мне сказали нужно конкретное время в часах. Тесть сверхповерхностно зная продукт я должен угадать то время которое они получили составив тест план. А бывают тест планы которые составляются несколько дней.


(kulasov) #9

1. Сгенерировать данные для всех потоков

2. Посмотреть в базе соответствие сгенерированных данных с записями в таблице.

По времени генерация на системе для каждого потока(зависит от сложности), ну думаю часов 4-6 и проверка в таблицах без джоинов еще 4-6 часа. Селекты делаются легко + просмотр.

еще на проблемы добавим 2 часа. Итого от 10 до  14 часов. 

Это на вскидку

Это учитывая что систему мы знаем, имеем документацию. Если не знаем то тут можно и год тестировать

 


(xwizard) #10

собеседовались на должность Junior Enginer?

 

1. Завёл бы баг на архитектуру системы.

2. Ответ на:

"описать, как ты будешь тестировать. Перечислить этапы, основные идеи, направления."

стандартно - сначала надо исследовать предметную область, понять что в данном случае будет важно, составить список рисков и требований (если этого еще нет)

на основе этого написать тест план и рапланировать тестовые активности.

Для тестирования в данном случае необходимо определить несколько уровней.

ответ на прямой вопрос "как ты будешь тестировать это готовое приложение без доступа к исходному коду" - написание скриптов, генерящих запросы на все 59 потоков и проверяющих данные из таблиц (кроме функционального добавляем тестирование безопасности и нагрузочное). Более детальное планирование сильно зависит от конкретного проекта.

3. Ответ на:

"оценить время тестирования по разработанному тестовому плану."

необходимо выяснить:

 - сколько есть тестеров, их уровень понимания того как работает продукт и уровень тестерских знаний

 - на сколько различны тест кейсы по сложности, сколкьо тест кейсов может протестировать один тестировщик за день/неделю.

на основе чего уже можно рассчитать время (плюс прибавить несколкьо дней прозапас).


(FreeMan) #11

Темы запостил на нескольких форумах, и в общем результата такой-

В большинстве случаев все говорят разными словами , что оценку в часах (а от меня требовали конкретное время в часах) дать не возможно. Т.к. мало входных данных. Оценить можно относительно. На задание давалось 30 минут. За 30 минут можно пофантазировать о том что бы я включил в тест план, но давать результат  в часах нереально. Сама формулировка "оценить время тестирования по разработанному тестовому плану" некорректна, т.к. без этого разработанного плана ничего реально оценить невозможно. А разработка плана может занять от нескольких , часов, до нескольких дней, в зависимости от ресурсов, сложности объекта тестирования, персонала и многих других начальных условий.

Но узнал много нового, т.к. у всех были интересные наработки по тест планам.

Вообще если у кого есть хорошие тест планы выложите почитать плиз, для личного развития.


(xwizard) #12

RUP


(FreeMan) #13

Ну а реавльные примеры? это я уже читал)


(kulasov) #14

Вы слишком усложняете простую задачу.

От вас просто хотели услышать основное направление. Вы приходите и должны сделать так чтоб продукт работал, а не расписывать макулатуру. 

Задача где нужно проверить, что данные постули в базу, не сложная. И не нужно расписывать колосальные тест планы.

Именно это скорее всего от вас хотели услышать, а вы начали все усложнять.

"Пришелувиделпобедил."

Именно это от вас хотели услышать.


(ArtemIljin) #15

Соглашусь, все-таки это вопрос без правильного ответа.  А тут уж можно набрасывать на вентилятор:

Задавать уточняющие вопросы, выдавать варианты - гипотезы. Выбрать одну из них и оценить по времени. Настоять на своём. Или проявить гибкость... Что-то из раздела стресс тестирования.

Жаль только, что выхлопа от этого вопроса не так много. Нужно уметь применять такие вопросы и давать на них обратную связь. Похоже, что в данном случае обратная связь не была дана.

 


(apetrovskiy) #16

Ваша контора юзает RUP? (просто любопытно, RUP же все реже упоминается в вакансиях).

у наших менеджеров обычно было два пойнта

1) это что-то бюрократическое, по мнению интернетов - о чтении книг про RUP речь никогда не шла :)

2) не гоже для знатного мелклсофтовского партнера вражьи технологии пользовать 

так и завернули

 


(Максим Таран) #17

А что такое поток в их понятии? Файл в каталоге или что-то ещё?


(kulasov) #18

 

  • Поток выполнения, нить (англ. thread) — в программировании наименьшая единица обработки, исполнение которой может быть назначено операционной системой процессору. В большинстве случаев поток находится внутри процесса.
  • Многопоточность — модель программирования и исполнения кода.

Стыдно не знать.

В задании не имеет заначение 59 процессов или один процесс с 59 потоками


(apetrovskiy) #19

почему thread, а не stream? как-то больше подходит к терминологии файловых систем.


(Максим Таран) #20

Стыдно путать понятие потока выполнения (то есть программного кода) и потока данных, уважаемый  kulasov. :) Потоки данных - это никак не поток выполнения. А с учётом того, что Вы говорили об ftp, то вообще непонятно что имеется в виду об потоке данных ибо суть ftp: "FTP (англ. File Transfer Protocol — протокол передачи файлов) — стандартный протокол, предназначенный для передачи файлов по TCP-сетям (например, Интернет)." И никоим образом не связан с программным потоком. Так что мой вопрос вполне закономерен. :)