Ребята, я к вам с философским вопросом. Расскажите, как вы

определяете качество разрабатываемого продукта и по каким критериям это самое качество определяете?

У каждого приложения свои критерии

Спасибо, кэп :)

Ну а чё ты хотел)) ну доступность сайта например может быть критерием

🙄 Ты ошиблась

а почему философский, это вполне прикладной вопрос и на него вполне есть четкие ответы в профессиональной литературе.

🤷‍♂

Мне, конечно, в соседнем чате уже по шапке прилетело за такое, но скажите, что такое качество?

О, вы мне вопросом помогли) отлично, спасибо

😂

Требованиями. Качество напрямую зависит от требований (но так как их в принципе нормально мало кто формирует, то от ожиданий. Если ждут отклик 2ms, а он 5 ms, качество страдает. Если ждут отклик 20ms-25ms, а у вас 21 ms то все отлично. Вот что такое качество в энтерпрайз проекте ИТ формата.

Ну вот видите: кому-то помогает. ¯\_(ツ)_/¯

Согласен, я сам всегда на позитиве, просто интересовал именно ответ) Понимаю что мне ещё учиться и разбираться очень долго🤔

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

Спасибо💪😊 Я сегодня спрашивал как развиваться и что учить, если хочу стать тестировщиком ПО. Мне ответили: начни тестировать любые вещи, карандаши, чашки, часы🤔 Но ведь это не относится к ПО. Как протестировать часы? Начать с позитивного тестирования, тест функциональности, что как мне кажется почти одно и то же, Ui тест, что ещё записать в чек-лист? Или тестирование вещей это просто рассказать о них?

Очень часто кто такое любит говорить, не понимают реальность тестирование вещей) Карандашей, часов и тд)

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

Качество определяется компанией по итогу, многое упирается в цели компании, ее контракты, заказчиков и т.д. Тестировщик != оценщик качества, он выступает как рентген, если хотите, а за качество отвечают аналитики,ПМ-ы, разрабы и т.д. Тестировщики в меньшей степени. Не знаю откуда эта мода пошла на ярлыки с двумя буквами. Они влияют на качество продукта, но не отвечают за него.

Качество - это степень удовлетворенности клиента полученным продуктом. Понятие - абсолютно субъективное. То, что хорошо для одного пользователя -💩 для другого (apple vs android, bmw vs hundai) Адекватно Оценить качество чего-либо одним-двумя-пятью критериями невозможно. Самый лучший способ оценки - это спросить у пользователей и разработчиков напрямую. (Пользователем может быть разрабочик, тестировщик, заказчик, бизнес аналитик, суппорт, и тп, а не только Ваши клиенты) Универсальных критериев - нет. Все зависит от контекста.

А сам клиент знает что хочет? На самом деле это воистину философский вопрос.

Не факт) но оценить то, что вы ему даете он может (например, по пятибальной шкале) если он будет рад - значит вы «понимаете» своего клиента Если нет - нужно меняться, или искать других клиентов :) не просто так в мире столько марок авто и телефонов)))

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

Ну это очень спорно, клиенты разные есть, если это гос.сектор(военка)-то без вопросов,здесь согласен. А если бизнес? У меня самого проект такой сейчас,поэтому я так и смело говорю. Попа боль одним словом.

реально ведь если почитать источники, то можно найти ответ на этот вопрос.. в чем именно проблема?)

По школе Rapid Software Testing, "Качество это нечто ценное для определённого лица, имеющего значение". Определи что важно для тех кто имеет значение. Посмотри что есть в продукте. Если они довольны, если у них от продукта есть то что им надо, а неудобства от продукта не перевешивают его позитивные стороны -- вот оно качество.

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

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

Возможно, не будем спорить, просто у каждого свой опыт. Я сужу из своего.Видно Вам повезло на заказчиков.По-доброму завидую.

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

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

Согласен. Радует одно-пока есть они, значит у нас есть работа)

Клиент может хотеть того что невозможно в текущих пределах технологий, или то что реализуемо с таким трудом что надо очень долго писать очень специфическое решение, или то что вызовет массу багов в приложении. У меня в практике был и такой запрос на оценку "возьмёмся ли мы за это", и такой проект. Во втором случае проект был реализован, но очень не так как пришли первоначальные три эскиза от клиента. В третьем случае я месяц репортил баги на то что клиент хотел, пока клиент не сдался и не перехотел.

Безусловно! Задача грамотного специалиста (по работе с клиентами, не тестировщика) как раз объяснить клиенту, что его хотелки невозможны или будут стоить триллион и 12 лет разработки. К сожалению, в реальном мире часто случается вариант "мы знаем, что это невозможно, но пока этого не поймёт заказчик, мы будет три года с него бабки брать". Впрочем, к тестированию это как раз прямо не относится. А третий случай -- он, ну, нормальный, для современных реалиях. Не зря сейчас так популярен эджайл (хоть он и значительно дороже разработки по не-гибкой модели) -- так продукт в каком-то виде выводится в продакшн и собирается обратная связь. Скажем так, каждая итерация -- по сути, эксперимент.

И вам спасибо 💜