User-oriented подход к тестированию Web-приложений

Здравствуйте! Мне нужна помощь в определении понятия user-oriented approach to the testing of SW. Существуют в этой области какие-либо специальные подходы? Стандартные алгоритмы по которым инженер по тестированию должен проводить свои тесты. Есть ли в этой области какая-то стандартная логика, которой следует придерживаться в процессе работы. Меня конкретно интересует взгляд со стороны пользователя на проблему. Чем прежде всего должен руководствоваться тестер, чтобы решить проблему пользователя(опять-таки используя этот пресловутый end-user approach)? Чтобы как-то сузить задачу предлагаю рассматривать Web-based приложения. Для меня важно понять стандартную логику принятия решений в выяснении причины багов при обнаружении проблем конечными пользователями, в то время как в процессе тестирования все шло гладко, для примера. И как дополнение к вопросу подходит ли usability testing and B-testing к категории user-oriented approach to the testing of SW.

Здравствуйте! Мне нужна помощь в определении понятия...

Здравствуйте!

Мне тоже нужна ваша помощь - я хочу понять, что именно вы написали. Did you set UAT ennv by BUC post-conditions according to RFS setups? Hasta la victoria sempre? Unde-i frigaruia din portocale bengaleze?

Что такое SW?

C последними вашими двумя предложениями мне пришлось туго, скрывать не буду. Когда проходила собеседование потенциальный работодатель заявил,что у меня не хватает "end-user thinking" - так мне было сказано дословно. Что процесс тестирования нужно рассматривать с точки зрения конечного пользователя. Как он воспринимает систему(приложение). Мне была задана конкретная ситуация: что если тестирование прошло удачно - а продукт со стороны клиента все-таки не работает. Ваши действия? Мой ответ был - проверить среду в которой тестировался и реально используется продукт (SW, HW, browsers), конфигурации, да здесь же еще множество всяких факторов, которые могут всплыть при глубоком разборе действий пользователя при инсталляции продукта - в общем пример был задан абстрактный, как я считаю, без конкретного указания продукта тестирования. Так как каждая ситуация индивидуальна и ее следует разбирать конкретно. И собеседование я не прошла. Ответ был, что мне не хватает, дословно: "Strategy of thinking from customer perspective when you do testing". Мне, если честно, совсем непонятно что все-таки от меня требовалось. Все мои разборы этой темы упираются в тестирование изабилити, что ни коим образом не сочетается с примером, заданным мне на собеседовании(если продукт протестирован успешно - а у клиента он не работает). Вот мне и нужно понять, что это такое тестирование с продукта с точки зрения конечного пользователя? Только ли это тестирование юзабилити? Я привела цитаты работодателя, как они были получены мной на англ.яз - мне кажется это исключает двойной смысл, кот может возникнуть при переводе на русский. Я постаралась объяснить то, что написала в первом посте. Надеюсь, что теперь его содержание более понятно, и я все-таки жду ответа. Если возникнет желание ответить на вопрос в виде двоичного кода), не делайте этого, пож-та, я понимаю только 2 языка - русский и англ.яз.

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

Что такое SW?

SW -software - программное обеспечение

Во-первых, не принимайте всё это близко к сердцу. Ну, чем-то Вы не подошли потенциальному работодателю, может быть квалификационные требования не выполнены, может быть какие-нибудь иные, что там ещё проверяется на собеседованиях. А для отказа использована замечательная отмазка, к которой невозможно предъявить никаких претензий, потому что непонятно, что предъявлять. Более того, если попробовать действовать логически последовательно, и попробовать выяснить -- what do you mean by "strategy of thinking from customer perspective" -- это только усугубит ситуацию, потому что работодатель на это может ответить -- ну вот, сами же признаёте, что не знаете этого :)

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

Начать можно с просматривания и прослушивания выступлений Юли Нечаевой на различных конференциях:
http://software-test...ot-only-testing
http://software-test...esting-activity

В-третьих, если на интервью вам задали вопрос "что если тестирование прошло удачно, а продукт со стороны клиента все-таки не работает -- ваши действия?", почему бы не задать встречный вопрос, и даже не один:
1) что означает "тестирование прошло удачно"?
2) что означает "продукт не работает"?
3) каковы мои предполагаемые полномочия, чтобы делать какие-нибудь действия?

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

Да, теперь стало понятнее.

Итак, было собеседование.

Вас спросили про то, что делать, если тестирование прошло удачно, а клиент говорит, что сайт "не работает".

Тут, конечно, возникает вопрос: в каком таком смысле оно было протестировано удачно, если клиент признаёт продукт унылым?

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

Точного ответа на вопрос нет, бо делать тут можно много всякого.

По-совести, надо сразу вскочить, понадергать патлы ближайшим заместителям, заорать: "Да как они это допустили!" и уволить сразу всех участников разработки. А потом разобраться, почему уже проведенное тестирование не выявило проблемы, с которыми столкнулись юзеры, учесть полученный опыт при очередном раунде тестирования, если проект еще продолжается.

Наверное, ваш визави ожидал ответ вроде "для предотвращения этой ситуации надо было тестировать с точки зрения пользователя"...

Что тут подразумевается?

Всего лишь то, что тестировщик ВНЕЗАПНО воображает себя "конечным пользователем", и пробует пощупать разрабатываемый продукт живьём, без спецификаций. Личного опыта сёрфинга в сети для этого дела должно хватать сполна.

Определенной методологии для подобного тестирования нет, бо область очень метафизична. Есть только "подход" и личный опыт тестировщика.

Тестировщик же в принципе бывает пользователем веб-магазинов?

Я в таком случае просто воображаю себя пользователем сайта, и тестирую сайт не "Сейчас я проверю корректность работы этой функции согласно требованию номер 2.12.4.17.2", а с точки зрения "Ща я эту шняжку положу в корзину, а потом и вот ту шнягу, и теперь в корзине я ожидаю увидеть информацию о том, что...".

Этот подход, конечно, требует склонности и тренировки.

Например, следует дополнить свой рабочий словарь словом "шняга"...

Чем прежде всего должен руководствоваться тестер, чтобы решить проблему пользователя? Только человеческим состраданием, ведь тестировщики не решают проблемы пользователей :) Они могут попытаться выявить проблемы до выпуска продукта в эфир, и сообщить о них кому надо, не более того.

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

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

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

Предположите, что переход на страницу с формой регистрации есть и с главной страницы, и из корзины. Предположите, что тестировали всегда переход с главной, а какой-то юзер решил зарегистрироваться в ходе оформления заказа, и опаньки, при завершении регистрации все содержимое его корзины обнулилось... Или же линк на регистрацию из корзины для тестовых целец закрыли заглушкой href=#, да потом забыли раскрыть...

Видите, как много всего предполагается?! Понимаете, почему подобное редко документируется?!

Например, в спецификациях было бы глупо указывать условие "сайт должен открываться". Оно же подразумевается :)

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

Правильно ли вы ответили?

Это очень правильный ответ с точки зрения тех, кто пришли в тестирование из мира телекома. Стандарты всему голова. Отклонения недопустимы. Вспышка слева - удар током.

Это не очень правильный ответ с точки зрения тех, кто пришел в тестирование из сложно стандартизируемого мира сайтостроения. Тут всё - отклонения... Тут недопустимо говорить юзеру "баг на сайте из-за того, что у тебя неподходящий компьютер". Тут надо делать так, чтобы работало даже у "того" юзера.

Это не хорошо и не плохо - это типично.

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

Вам заявили, что у вас не хватает "end-user thinking". И что процесс тестирования нужно рассматривать с точки зрения конечного пользователя.

Ну, не нужно, а можно. Или точнее - следует, для более полной и всесторонней подготовки продукта к эфиру.

Этот "финкинг" можно расшифровать как "думай, как пользователь и соответственно, тестируй приложение так, словно ты и есть этот пользователь".

Существуют в области "user-oriented approach to the testing of software" какие-либо специальные подходы? Есть ли стандартные алгоритмы по которым инженер по тестированию должен проводить свои тесты? Есть ли в этой области какая-то стандартная логика, которой следует придерживаться в процессе работы?

Есть, наверное.

Поэты стихи как пишут? По алгоритмам? По шаблонам? По интуиции?

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

И тем не менее, музыку создают люди, а машины ее только воспроизводят.

То есть, можно проверить алгеброй гармонию можно. Но построить новую гармонию посредством алгебры...

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

Подходит ли usability testing and B-testing к категории user-oriented approach to the testing of SW.

Под B-testing подразумевается бета-тестирование?

Подходит.

Тут все подходит.

И напоследок.

Вас отшили по поводу того, что вам не хватает "Strategy of thinking from customer perspective when you do testing". Ну, делов-то, это не приговор вам и не указание "развиваться отсюда до обеда". Мне как-то отказали от должности на основании того, что мне не хватает аналитического склада мышления, а я так удивился, что даже не стал уточнять, что они там под аналитикой подразумевают...

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

Кстати:

1) вспомнилось "Хочешь неслабо выступить — завязывай с жаргоном";

2) тут вам никто не запрещает разделять абзацы пустыми строками :)

Спасибо вам большое за ответы. Вы укрепили меня в той мысли, которая была у меня изначально. И что тестирование с точки зрения конечного пользователя нельзя подвести под какие-то стандартные шаблоны. Каждая ситуация индивидуальна и требует анализа.

Сейчас я параллельно со своей основной работой прохожу стажировку в компании, которая первоначально забраковала мое "end-user thinking". И мне в задачу поставили изучить эту стратегию тестирования, с точки зрения конечного пользователя - говорят, что так же должна быть спец лит-ра на эту тему. А я то в свою очередь понимаю, что это полная ерунда, и только опыт работы с продуктом может развить и направить мышление в нужное русло, - определять узкие места приложения, наиболее часто возникающие проблемы, и что в первую очередь нужно проверить/тестировать. С чем-чем, а уж с логикой у меня проблем, как мне казалось, никогда не было.

За 1,5 месяца стажировки (я в это время тестирую продукт) я дополнительно перечитала кучу литературы о видах и методологиях тестирования, но ответа на вопрос, поставленный на собеседовании так и не нашла, все упирается в тестирование юзабилити, но это не то. Скоро у меня будет повторное собеседование. Желание получить эту позицию - ОГРОМНОЕ. Мне нравится продукт, который компания разрабатывает, и во время стажировки я еще больше в этом укрепилась. Здесь есть возможность роста, новые для меня технологии, и тестирование производится не сайтов, а именно веб-приложений. Так что провалить 2 раз, конечно, совсем не хочется, уж очень много сил и энергии я вложила. Да, и естественно, опять ожидаю того же вопроса) ну чтобы опять не отказали с отсутствием "end-user thinking", решила обратиться на форум, чтобы опытные тестировщики дали совет))))

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

Попробуйте тестировать продукт с точки зрения пользовательских сценариев, это с одной стороны есть тестирование, а с другой "end-user thinking". Т.к. пользовательские сценарии опираются именно на конечного пользователя, литературы на эту тему кстати достаточно :)

Что такое SW?

SW -software - программное обеспечение

Эх, блин, замылился глаз. Для меня SW это SolidWorks forever ;-)

Помнится когда-то давно (или не очень) видел запись конференции\тренинга на http://software-testing.ru
Суть была в том, что тестировщик дожен не только пытаться сделать конечный продукт максимально приближенный к спецификации, но и такой, чтобы конечному пользователю понравился. Так вот там был пример: продукт прошел стадию тестирования на ура, все как по спеке, но после продакшина спросом не пользовался и деньги на разработку такого продукта были потрачены впустую. Докладчик намекнул, что именно отдел обеспечения качества должен был провести исследование, которое бы предотвратило подобную ситуацию после стадии продакшина. Сдается мне, что интервьюер, который вас собеседовал тоже смотрел эту запись или даже был там :)

ПС: никак не могу вспомнить название :(