В этом то и затруднение, т.е waterfall и agile это методы разработки и планирования работы. не могу понять сути задания и чем же всё таки будет отличать тестирование по водопадной модели, от тестирования по гибкой.

Вот и все остальные этого понять не могут) Возможно Вы неправильно поняли задание?

Странное задание. Ну опишешь ты процесс тестирования калькулятора по каскаду и чем он будет фактически отличатся от обычного тестирования? Что там, что там все стадии тестирования будут одинаковы и идти друг за другом. Наверное таким образом больше хотят увидеть как ты понимаешь сам жизненный цикл разработки, так за чем же в такой "извращенной" форме формулировать задание? Наверное действительно надо подробнее уточнять, что конкретно от тебя хотят увидеть.

Имхо, импровизация в бизнесе никому не нужна.

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

Выскажу как я на это смотрю:

 

1. Скорее всего Вы обложались в самом начале и не смогли выделить самого главного.

2. Работа проведена впустую. Вы потратили свое время и время заказчика. Время - деньги!  И не малые (я про заказчика).

3. Кто Вам сказал тестировать логику и сравнивать как у конкурентов? С чего Вы решили, что у конкурентов она верная?

4. Разработчиков нет и не надо. Они Вам не помогут, а только запутают.

5. Тестовое задание явно на 20 минут. Завести баг на несоответствие ТЗ с тестируемым функционалом. Дальнейшие действия факультативно.

 

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

  Я с Вами не соглашусь.

  По вашей версии рабочий процесс должен проходить так - пришел заказчик, сказал хочу приложение которое делает сложные расчеты с разными зависимостями, вот вам формула для расчета - делайте. Тестироващик смотрит на формулу с большим колличеством переменных и на глаз определяет что она неправильная? Ну это наверное подходит только для случая если тестировщик ранее был инженером и работал в этой сфере.

  Я понимаю, что требования нужно тестировать, но как тестировать логику сложных расчетов? Гугл не знает таких формул, чтобы самому вывести формулу нужно изучить предмет, а это тоже время и не малое, а может вообще заказчик у другой компании заказал чтобы ему разработали эту логику и есть только несколько конкурентов которые ее тоже используют и в открытом доступе такой информации нет(это я конечно преувеличиваю, но все же)

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

Подобная ситуация с формулами расчета у меня недавно встречалась.

В отчете о проверенном фукционале писал так:

"Данные рассчитываются в соответствии с ожидаемым результатом, однако формула расчета отличается от формулы указанной в ТЗ."

 

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

Спасибо, что поделились опытом, так и сделаю.

Вам все правильно ответили.

Вполне возможно, что это как раз задание с подвохом — кто найден ошибку в ТЗ, сопопставив с конкурентами?

 

Поэтому ответ на тестовое задание "мне нужна правильная формула или я не могу тестить" вводит в недоумение. А что, ничего другого, кроме формулы, вы проверять не планировали?

Если с вас просят список багов, оформляйте баг. Честно говоря, не вижу в нем ничего блокирующего, хотя я и само задание не видела. Но если и правда ошибка в формуле, то баг хороший, нетривиальный, показывает, что вы способны включать мозг, а не только сверять сделанное с документацией.

 

Единственное, что смущает → объем задания. Сколько времени вы уже потратили? Что от вас просят на выходе?

Не надо работать бесплатно и делать домашки на неделю времени. Задача должна быть на 10-30 минут. Ну или на пару часов для начинающего, как раз дать демо, сказать, кому задавать вопросы и ждать результата

Я все уже понял и осознал)) Все равно спасибо за ответ. Ошибки документации оформил, продолжаю тестировать.

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

  Добрый день.

  Нужен совет опытных специалистов. На собеседовании получил домашнее задание протестировать небольшой веб продукт. И вот кажется абсолютно ничего сложного, есть Тест Задание с нормальной детализацией, назначили человека, который будет играть роль представителя заказчика и ему можно направлять вопросы "что, да как?" должно работать.

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

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

  Так вот вопрос - что делать?)) продолжить тестировать и рапортовать блокер с ссылкой на ошибку в ТЗ или есть иные выходы из этой ситуации.

  Я начинающий тестировщик и насколько знаю все требования уточняются и проверяются до начала проектирования приложения и дизайна тестов. Тоесть эта ошибка должа была быть выявлена еще до того как приложение уже сделано. Хотя может на практике по другому...

Дорого времени суток.

Если тема еще актуальна хотел бы с преогромнейшим удовольствием получить практику. Савина прочел, хожу на курсы по тестированию, времени вагон и тележка потому, что в отпуске. А главное желание и запал так как очень проникся идеей стать тестировщиком. Буду благодарен за помощь.