Комментарии 27
Очень неплохо.
Залип на описании тестов полей логин/пароль.
Помню, как доводил руководителя разработки одной шарашкиной конторы (пришлось пересекаться по работе много лет назад), между делом выискивая косяки именно в полях авторизации. То у них номер телефона из 30 символов состоял, то написание через 8() не видел, то ещё что-нибудь – увлекательный квест, короче. Даже если левой ногой просто для души заниматься.
Самая простая и очевидная идея для тестирования — взять и воспользоваться (и не пару минут — «вроде работает», а как положено).
Порой зайдёшь на какой-нибудь известный сайт и диву даёшься, сначала что нифига не тестируют и выкатывают, а потом что и устранить долго не могут, т.е. и служба поддержки кое-как работает.
Порой зайдёшь на какой-нибудь известный сайт и диву даёшься, сначала что нифига не тестируют и выкатывают, а потом что и устранить долго не могут, т.е. и служба поддержки кое-как работает.
прям с первых тезисов стало страшно
Предлагаю вспомнить, что такое тестирование ПО. Хорошее определение в википедии
Ключевые слова: проверка соответствия между реальным поведением программы и её ожидаемым поведением. Если ожидаемое поведение не описано, какие тесты получатся?
Предлагаю задуматься, когда говорят «держи, тестируй!» и не дают спецификацию (ТЗ), тестировщик сам чего хочет добиться? Что-то сделать? Что-то сделать, за что платят деньги? Получить удовольствие? Получить новые знания/умения? Закрепить текущие знания/умения?
Или таки проверить соответствие?
Вот выдали нам (тестировщикам) функционал и сказали:
— Держи, тестируй!
А с чего начать? Для новичка это может быть целой проблемой. Особенно когда нет подробного ТЗ. Поэтому я решила создать эту подборку, где можно поискать вдохновение! ツ
Предлагаю вспомнить, что такое тестирование ПО. Хорошее определение в википедии
Тести́рование програ́ммного обеспе́че́ния — процесс исследования, испытания программного продукта, имеющий своей целью проверку соответствия между реальным поведением программы и её ожидаемым поведением на конечном наборе тестов, выбранных определённым образом (ISO/IEC TR 19759:2005)
Ключевые слова: проверка соответствия между реальным поведением программы и её ожидаемым поведением. Если ожидаемое поведение не описано, какие тесты получатся?
Предлагаю задуматься, когда говорят «держи, тестируй!» и не дают спецификацию (ТЗ), тестировщик сам чего хочет добиться? Что-то сделать? Что-то сделать, за что платят деньги? Получить удовольствие? Получить новые знания/умения? Закрепить текущие знания/умения?
Или таки проверить соответствие?
Ключевые слова: проверка соответствия между реальным поведением программы и её ожидаемым поведением. Если ожидаемое поведение не описано, какие тесты получатся?
КМК как минимум для программ с GUI бо́льшая часть ожидаемого поведения не прописывается явно.
если есть поле ввода, то ожидается, что при наборе в этом поле «а» в тексте появится «а», а не «б», что эта буква вставится в позиции курсора, а не заменит 2 символа перед ним и т. п.
Я, кстати, видела и подробные ТЗ, с скринами из GUI и описанием каждой финтифлюшки. ТЗ на авторизацию в системе там занимало 5 листов вместо 2 строчек)) Угадайте, как быстро такое устаревает)
Поле ввода, на платформе apple, android, и во множестве популярных web-фреймворках, ведет себя внезапно строго по style guide платформы/фреймворка.
То есть, есть документ, в котором рассказано, каким должно быть поведение. Конечно, базовые случаи, типа при вводе «а» появляется именно «а», видимо нужно проверить, но кажется, такого рода проверки пишутся один раз для всего проекта, по одному комплекту на один тип ui-контрола, не? При добавлении нового нового view/экрана/итд, вызывают готовый комплект базовых тестов для этого типа контрола.
То есть, есть документ, в котором рассказано, каким должно быть поведение. Конечно, базовые случаи, типа при вводе «а» появляется именно «а», видимо нужно проверить, но кажется, такого рода проверки пишутся один раз для всего проекта, по одному комплекту на один тип ui-контрола, не? При добавлении нового нового view/экрана/итд, вызывают готовый комплект базовых тестов для этого типа контрола.
Ну вы прям по Савину говорите, что у нас всегда есть ТЗ, желательно максимально подробное и понятное )) И существует лишь этот идеальный мир, а еще разработчики багов не допускают, и тестировщики совсем не нужны)
нет, у меня почти никогда не было ТЗ. Но первое, что я в этом случае делал — писал ТЗ, а не пытался «что-то сделать, похожее на деятельность». Причина этому простая — если мне ставят задачу недостаточно четко, для её выполнения, с высокой вероятностью, результат моей работы не будет принят с первого раза (а скорее всего со второго, третьего итд), и с еще более высокой вероятностью, суммарные затраты на переделки будут выше, чем сначала «договориться на берегу» — написать ТЗ, хоть в каком-то виде, по которому можно будет принять работу, а потом уже приступать к работе.
Это настолько общий принцип любых коммерческих отношений, что даже удивительно, что приходится его объяснять.
Это настолько общий принцип любых коммерческих отношений, что даже удивительно, что приходится его объяснять.
И что, то, что вы написали ТЗ «хоть в каком-то виде», говорит о том, что идеи для тестов больше не нужны? ТЗ вы пишете сразу в виде тест-кейсов, подробно описывая любой «шаг влево-шаг вправо»? Зачем тогда тестировщики то нужны, с таким ТЗ разработчики пусть сами автотесты клепают)
вообще не понимаю, что такое «идеи для тестов».
Тест — это проверка. Идеи как проверить, наверное нужны. Но в статье же, по сути, о том, что «если непонятно, что проверять, какие могут быть идеи»?
Своими комментариями пытаюсь донести, что если нет понимания что проверять, то ответ на этот вопрос нужно искать не за пределами проекта, а внутри.
Тест — это проверка. Идеи как проверить, наверное нужны. Но в статье же, по сути, о том, что «если непонятно, что проверять, какие могут быть идеи»?
Своими комментариями пытаюсь донести, что если нет понимания что проверять, то ответ на этот вопрос нужно искать не за пределами проекта, а внутри.
Ну если не понимаете и не видите в них смысла, значит, эта статья не для вас, всего то и делов.
Даже если у нас есть ТЗ, и неважно, кто его написал, вы или аналитик — это еще не значит, что не возникнет вопроса что проверять. Особенно у новичка, который еще в принципе не знает, какие тесты могут быть, что нужно проверять для того или иного поля
Даже если у нас есть ТЗ, и неважно, кто его написал, вы или аналитик — это еще не значит, что не возникнет вопроса что проверять. Особенно у новичка, который еще в принципе не знает, какие тесты могут быть, что нужно проверять для того или иного поля
Конечно, это статья не для меня. Но я написал комментарий потому, что считаю, что начальный тезис «дали тестировать непонятно что, что делать — вот 100500 вариантов» — вредна при тестировании.
Если возникает вопрос что проверять, ответ на этот вопрос нужно искать не в рамках тестирования. И это очень важно понимать особенно новичку в тестировании.
Не вижу никакой проблемы, если тестировщик обратится к аналитику, продакту, и уточнит — «вот тут что должно быть?».
Если продолжить тезис про поля ввода из соседней ветви:
— все поля ввода одинаковые, текст, максимальный размер введенного?
Если, например есть, поля ввода с валидаторами, где-то за рамками тестов ведь должно быть записано «в этом поле разрешены только цифры», «в этом поле — месяц, 1-2 цифры»? Если такое не записано, как тестировщик может написать тест на ввод месяца в текстовое поле? Он должен проверять все варианты? Какие из вариантов считать правильными, какие нет? «январь», «янв», «01», «1», какие?
Если возникает вопрос что проверять, ответ на этот вопрос нужно искать не в рамках тестирования. И это очень важно понимать особенно новичку в тестировании.
Не вижу никакой проблемы, если тестировщик обратится к аналитику, продакту, и уточнит — «вот тут что должно быть?».
Если продолжить тезис про поля ввода из соседней ветви:
— все поля ввода одинаковые, текст, максимальный размер введенного?
Если, например есть, поля ввода с валидаторами, где-то за рамками тестов ведь должно быть записано «в этом поле разрешены только цифры», «в этом поле — месяц, 1-2 цифры»? Если такое не записано, как тестировщик может написать тест на ввод месяца в текстовое поле? Он должен проверять все варианты? Какие из вариантов считать правильными, какие нет? «январь», «янв», «01», «1», какие?
Чтобы уточнить у аналитика «что вот тут должно быть», нужно для начала додуматься до такой проверки, что «это вообще нужно проверить».
И это как раз про что проверять. И очень странно, что ответ на этот вопрос, который имеет прямое отношение к тестированию, нужно искать где угодно, но только не в тестировании.
И это как раз про что проверять. И очень странно, что ответ на этот вопрос, который имеет прямое отношение к тестированию, нужно искать где угодно, но только не в тестировании.
все правильно вы пишете, но нынешние методики scrum/agila/kanban не предполагают наличия документации. Единственный выход — самому дописать ТЗ и послать на утверждение стейкхолдерам. И если не ответят, то считать молчание — знак согласия.
будьте добры, покажите примеры статей, где пишут, что в scrum/kanban/agile не предполагается документация. Боюсь, вы путаете с «не предполагается отдельной фазы проектирования всего продукта, до начала работ».
Если взять семейство agile-методик, у которых ключевой момент — короткие итерации, то насколько короткой итерацию не делай (хоть вообще один день), всегда есть «заказчик», «исполнитель», «ожидаемый результат». Ожидаемый к концу итерации. Записывают его на доске, в issue или просто встретившись утром у кулера обмениваются парой-тройкой фраз, если исполнителю не будут понятно, что от него ожидают — скорее всего, он сделаеткакую-то фигню не то, что ожидают.
Мне, как заказчику, нужен результат, за фигню я не готов платить.
Я, как исполнитель, ровно в той-же степени хочу выдать результат, если, конечно, мне важно, что бы за мою работу заплатили.
Очень странно рассчитывать, что за фигню будут платить. Еще более странно платить за фигню, хотя окружающая действительность как бы говорит, что так поступают чаще, чем хотелось бы. Успокаивает только то, что ожидаемый результат платят значительно больше (на порядки?) чем за фигню.
Если взять семейство agile-методик, у которых ключевой момент — короткие итерации, то насколько короткой итерацию не делай (хоть вообще один день), всегда есть «заказчик», «исполнитель», «ожидаемый результат». Ожидаемый к концу итерации. Записывают его на доске, в issue или просто встретившись утром у кулера обмениваются парой-тройкой фраз, если исполнителю не будут понятно, что от него ожидают — скорее всего, он сделает
Мне, как заказчику, нужен результат, за фигню я не готов платить.
Я, как исполнитель, ровно в той-же степени хочу выдать результат, если, конечно, мне важно, что бы за мою работу заплатили.
Очень странно рассчитывать, что за фигню будут платить. Еще более странно платить за фигню, хотя окружающая действительность как бы говорит, что так поступают чаще, чем хотелось бы. Успокаивает только то, что ожидаемый результат платят значительно больше (на порядки?) чем за фигню.
это мне было сказано тимлидом, когда я пожаловался на отсутствие документации к библиотеке, которой было необходимо пользоваться.
Могу только развести руками и пожелать вам, когда вы будите тимлидом (если еще не стали) — старайтесь более точно формулировать свои мысли.
К большому сожалению, ситуация когда приходится пользоваться не очень качественным продуктом (сторонняя библиотека — продукт, которым вы пользовались, наличие документации, её актуальность — один из критериев качества) распространена шире, чем хотелось бы. На мой взгляд выход из этой ситуации следовать трем пунктам
* определить для себя нижний уровень качества
* всегда выбирать более качественный продукт в рамках бюджета
* если по итогам всех выборов и оценок не удается достичь минимального уровня, либо не браться за задачу, либо пересматривать бюджет, либо пересматривать задачу.
По сути это ровно то же самое/, что я пытаюсь донести в соседних комментариях — без четкого понимания «что должно быть в результате», не вижу вариантов хорошо решить задачу тестирования.
К большому сожалению, ситуация когда приходится пользоваться не очень качественным продуктом (сторонняя библиотека — продукт, которым вы пользовались, наличие документации, её актуальность — один из критериев качества) распространена шире, чем хотелось бы. На мой взгляд выход из этой ситуации следовать трем пунктам
* определить для себя нижний уровень качества
* всегда выбирать более качественный продукт в рамках бюджета
* если по итогам всех выборов и оценок не удается достичь минимального уровня, либо не браться за задачу, либо пересматривать бюджет, либо пересматривать задачу.
По сути это ровно то же самое/, что я пытаюсь донести в соседних комментариях — без четкого понимания «что должно быть в результате», не вижу вариантов хорошо решить задачу тестирования.
Ох, спасибо, очень актуально ️
Спасибо за материал, полезно.
Спасибо большое, мне как новичку данная информация расширяет горизонт планирования и осуществления проверок!
Тут надо бы поправить...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Где брать идеи для тестов (подборка полезных ссылок)