И
Все прекрасно конечно, романтично😊 Но если какой то убер придирчивый покупатель докопается? Мол ввод в заблуждение? Такого не было еще?
А это точно связано с тестированием? 🙃
Size: a a a
2020 November 04
AS
Все прекрасно конечно, романтично😊 Но если какой то убер придирчивый покупатель докопается? Мол ввод в заблуждение? Такого не было еще?
А как ? Машину времени придумает ?
AA
офф топ, пардоньте
AA
Вино и тестирование идут рука об руку😉
И
Anton Stepanov
Ну это я все изучил про токены и как они работают. Вот про то, что ему задаётся определённо время на рефреш, это не знал, за это отдельное спасибо. Пишу тест кейсы, щас буду дальше соображать
Время не на рефреш, а время жизни токена, после которого тебя разлогинит.
AS
офф топ, пардоньте
бутыль за 3-5 т.евро местный не возьмёт ,а если возьмёт ,то за 1 с завода. А иностранцы не приедут да же . Всё удаленно и шито крыто )
AG
@azshoo ты вот рассказывал о том, какие ты задачки даёшь на собеседованиях (практические), мол, ожидаешь, что кандидат тебе порассуждает как он будет что-то тестирует, если я не ошибаюсь.
Можешь, пожалуйста, написать, какие "основные" пункты ты отмечаешь в их ответе? (в плане, как они собираются тестировать)
Грубо говоря, есть ли какие-то конкретные "критерии" приёмки этого задания?
Можешь, пожалуйста, написать, какие "основные" пункты ты отмечаешь в их ответе? (в плане, как они собираются тестировать)
Грубо говоря, есть ли какие-то конкретные "критерии" приёмки этого задания?
Ну, это в целом зависит от задачи, но сводится к:
0) Тестирует продукт, а не ищет баги.
1) Начинает с наиболее важных кейсов, дальше двигается вниз по приоритетам.
2) Начинает с простых кейсов, потом двигается к сложным.
3) Задаёт вопросы на очевидные косяки/недостатки в требованиях.
4) Если предлагает какое-то из множества решений (например инструменты, виды документации, етк) - может объяснить почему именно их и зачем.
0) Тестирует продукт, а не ищет баги.
1) Начинает с наиболее важных кейсов, дальше двигается вниз по приоритетам.
2) Начинает с простых кейсов, потом двигается к сложным.
3) Задаёт вопросы на очевидные косяки/недостатки в требованиях.
4) Если предлагает какое-то из множества решений (например инструменты, виды документации, етк) - может объяснить почему именно их и зачем.
И
Ну, это в целом зависит от задачи, но сводится к:
0) Тестирует продукт, а не ищет баги.
1) Начинает с наиболее важных кейсов, дальше двигается вниз по приоритетам.
2) Начинает с простых кейсов, потом двигается к сложным.
3) Задаёт вопросы на очевидные косяки/недостатки в требованиях.
4) Если предлагает какое-то из множества решений (например инструменты, виды документации, етк) - может объяснить почему именно их и зачем.
0) Тестирует продукт, а не ищет баги.
1) Начинает с наиболее важных кейсов, дальше двигается вниз по приоритетам.
2) Начинает с простых кейсов, потом двигается к сложным.
3) Задаёт вопросы на очевидные косяки/недостатки в требованиях.
4) Если предлагает какое-то из множества решений (например инструменты, виды документации, етк) - может объяснить почему именно их и зачем.
А если уточняющие вопросы появляются не сразу, а в процессе тестирования - это для тебя играет какую-то роль?
AG
А если уточняющие вопросы появляются не сразу, а в процессе тестирования - это для тебя играет какую-то роль?
Нет, мне хочется что бы:
а) Человек не игнорировал косяки/пробелы в требованиях (особенно там, где это критично).
б) Человек не выдумывал их сам, или если выдумывает - говорил бы об этом явно, типа "в требованиях вот про это не было, я предположил что будет вот так (потому что ...), в таком случае ..."
а) Человек не игнорировал косяки/пробелы в требованиях (особенно там, где это критично).
б) Человек не выдумывал их сам, или если выдумывает - говорил бы об этом явно, типа "в требованиях вот про это не было, я предположил что будет вот так (потому что ...), в таком случае ..."
AG
Когда он это делает - не важно.
A
Когда он это делает - не важно.
спорно. Когда вопросы к требования возникают уже в процессе тестирования - это аффектит все команду и сроки. Этап тестирования требований ведь не просто так существует. Понятно что не все проблемы сразу бывают очевидны, но когда они вылезают так поздно - не оч круто
AG
спорно. Когда вопросы к требования возникают уже в процессе тестирования - это аффектит все команду и сроки. Этап тестирования требований ведь не просто так существует. Понятно что не все проблемы сразу бывают очевидны, но когда они вылезают так поздно - не оч круто
Ну, давайте начнём с того, что я говорил про задачки на собеседованиях, где ни команды, ни этапа тестирования требований нет в принципе.
Во вторых, конечно лучше находить все баги заранее.
А ещё лучше - писать без багов, тогда вообще всем хорошо.
Проблема в том, что жизнь немного многограннее.
Этап тестирования требований не гарантирует, что в требованиях нет багов.
Этап тестирования реализации не гарантирует, что в оной нет багов.
Пропустили баг (в коде, требованиях, дизайне, не важно где) - повод подумать, чего нехватило что бы найти раньше, но это все ещё стандартная рабочая ситуация.
В третьих, это всё зависит от команды, процессов и прочего.
Многие замечательные команды живут без требования как таковых и без тестирования требований как этапа SDLC, и им норм. :)
Ну и последнее: "не очь круто" - это когда баги в требованиях выливаются в потери для бизнеса.
А всё остальное - это нормальный рабочий процесс, который можно тюнить и менять, если хочется, можно оставлять как есть, если и так всех устраивает. :)
Хотя вру, даже в ситуациях, когда это выливается в потери для бизнеса - тоже можно оставлять как есть, если всех всё устраивает. :)
Во вторых, конечно лучше находить все баги заранее.
А ещё лучше - писать без багов, тогда вообще всем хорошо.
Проблема в том, что жизнь немного многограннее.
Этап тестирования требований не гарантирует, что в требованиях нет багов.
Этап тестирования реализации не гарантирует, что в оной нет багов.
Пропустили баг (в коде, требованиях, дизайне, не важно где) - повод подумать, чего нехватило что бы найти раньше, но это все ещё стандартная рабочая ситуация.
В третьих, это всё зависит от команды, процессов и прочего.
Многие замечательные команды живут без требования как таковых и без тестирования требований как этапа SDLC, и им норм. :)
Ну и последнее: "не очь круто" - это когда баги в требованиях выливаются в потери для бизнеса.
А всё остальное - это нормальный рабочий процесс, который можно тюнить и менять, если хочется, можно оставлять как есть, если и так всех устраивает. :)
Хотя вру, даже в ситуациях, когда это выливается в потери для бизнеса - тоже можно оставлять как есть, если всех всё устраивает. :)
A
Ну, давайте начнём с того, что я говорил про задачки на собеседованиях, где ни команды, ни этапа тестирования требований нет в принципе.
Во вторых, конечно лучше находить все баги заранее.
А ещё лучше - писать без багов, тогда вообще всем хорошо.
Проблема в том, что жизнь немного многограннее.
Этап тестирования требований не гарантирует, что в требованиях нет багов.
Этап тестирования реализации не гарантирует, что в оной нет багов.
Пропустили баг (в коде, требованиях, дизайне, не важно где) - повод подумать, чего нехватило что бы найти раньше, но это все ещё стандартная рабочая ситуация.
В третьих, это всё зависит от команды, процессов и прочего.
Многие замечательные команды живут без требования как таковых и без тестирования требований как этапа SDLC, и им норм. :)
Ну и последнее: "не очь круто" - это когда баги в требованиях выливаются в потери для бизнеса.
А всё остальное - это нормальный рабочий процесс, который можно тюнить и менять, если хочется, можно оставлять как есть, если и так всех устраивает. :)
Хотя вру, даже в ситуациях, когда это выливается в потери для бизнеса - тоже можно оставлять как есть, если всех всё устраивает. :)
Во вторых, конечно лучше находить все баги заранее.
А ещё лучше - писать без багов, тогда вообще всем хорошо.
Проблема в том, что жизнь немного многограннее.
Этап тестирования требований не гарантирует, что в требованиях нет багов.
Этап тестирования реализации не гарантирует, что в оной нет багов.
Пропустили баг (в коде, требованиях, дизайне, не важно где) - повод подумать, чего нехватило что бы найти раньше, но это все ещё стандартная рабочая ситуация.
В третьих, это всё зависит от команды, процессов и прочего.
Многие замечательные команды живут без требования как таковых и без тестирования требований как этапа SDLC, и им норм. :)
Ну и последнее: "не очь круто" - это когда баги в требованиях выливаются в потери для бизнеса.
А всё остальное - это нормальный рабочий процесс, который можно тюнить и менять, если хочется, можно оставлять как есть, если и так всех устраивает. :)
Хотя вру, даже в ситуациях, когда это выливается в потери для бизнеса - тоже можно оставлять как есть, если всех всё устраивает. :)
Когда всех все устраивает, можно вообще все что угодно, без каких либо ограничений, даже адекватных. Поэтому такие ситуации вообще нет никакого смысла обсуждать.
Вообще я видимо немного упустила в диалоге, что речь идет о задачках на собеседовании, поэтому да, резонно 🤷♀️
Вообще я видимо немного упустила в диалоге, что речь идет о задачках на собеседовании, поэтому да, резонно 🤷♀️
AG
Не, ну я к тому, что всё же упирается в cost vs value.
Предположим, ребята из тестирования часто находят косяки в требованиях уже после того, как по этим требованиям написан код.
Что бы решить, нужно ли это править, нужно понять:
1. Во сколько времени\денег это обходится (те самые сроки, переключение разработчиков между задачами, етк).
2. Сколько времени\денег понадобится, что бы это исправить (напр. писать больше требований, тестировать требования перед тем, как начинать писать код, т.д. т.п.)
Если 1 > 2 -> можно начинать что-то менять.
Если 1 < 2 -> тоже можно, но зачем?
Предположим, ребята из тестирования часто находят косяки в требованиях уже после того, как по этим требованиям написан код.
Что бы решить, нужно ли это править, нужно понять:
1. Во сколько времени\денег это обходится (те самые сроки, переключение разработчиков между задачами, етк).
2. Сколько времени\денег понадобится, что бы это исправить (напр. писать больше требований, тестировать требования перед тем, как начинать писать код, т.д. т.п.)
Если 1 > 2 -> можно начинать что-то менять.
Если 1 < 2 -> тоже можно, но зачем?
AS
Какие есть варианты тест кейсов проверки формы авторизации при вводе логина и пароля и есть функция показать пароль
V
Всем привет, в рамках обучения на курсе необходимо найти сайт/мобильное приложение для оттачивания навыков тестирования. Оно должно быть не совсем простым, но и не особо перегруженным.
Тематика любая.
Подскажите, пожалуйста, совершенно ничего не могу найти интересного в открытых бета-тестингах
Немного переживаю, что какой-нибудь интернет-магазин для джуна будет несколько обширной задачей
Спасибо!
Тематика любая.
Подскажите, пожалуйста, совершенно ничего не могу найти интересного в открытых бета-тестингах
Немного переживаю, что какой-нибудь интернет-магазин для джуна будет несколько обширной задачей
Спасибо!
ТНС энерго багованный,
Автосуши для андроида,
Есть баги на Ростелеком, емех, ivi для ТВ
Автосуши для андроида,
Есть баги на Ростелеком, емех, ivi для ТВ
И
Почему к техникам тест-дизайна причисляют исчерпывающее тестирование, а в принципах тестирования говорят о том, что исчерпывающее тестирование невозможно проделать?
✨
Почему к техникам тест-дизайна причисляют исчерпывающее тестирование, а в принципах тестирования говорят о том, что исчерпывающее тестирование невозможно проделать?
Б
Почему к техникам тест-дизайна причисляют исчерпывающее тестирование, а в принципах тестирования говорят о том, что исчерпывающее тестирование невозможно проделать?
Тут как бэ на днях в вакансии писали одной ид будущих обязанностей найти все баги в программе
NB
Почему к техникам тест-дизайна причисляют исчерпывающее тестирование, а в принципах тестирования говорят о том, что исчерпывающее тестирование невозможно проделать?
серьезно такая техника есть?)