Тестирование веб-приложений. Нужен ликбез. Есть тестеры?

Расскажите мне, пожалуйста, как проводится тестирование веб-приложения со множеством полей для заполнения, форм и так далее. Интересует User Acceptance Testing (не знаю как правильно по-русски). Начиная с подготовки сценариев, тест-кейсов, но больше ориентируясь на само, собственно, тестирование и главное, организацию всех отзывов и нахождению ошибок. Логи? Как структурировать этот поток отчетов о найденных багах? Баги же бывают не тольк: нажал это, произошло то. А например, весь сценарий нарушен. И на экране есть опции, которых там быть не должно.

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

Редаговано: monkey (19-06-2012 23:44)

Автоматизировано
Про русский забудь. Русскоязычных тестеров уже нет!
Тебе нужно за деньги или просто поговорить ?

Max Dieand, поговорить. Образовать. Тестеры есть. Мне себя надо образовывать. На прошлых работах была QA команда с лидером, который этим всем руководил. Тут этого нет, а "тестеры по совместительству" есть. И мне надо расписывать задания более детально, а я в тестировании плаваю. Просто не приходилось никогда делать эту работу, и было неинтересно просто для себя учить. Мне надо, чтобы кто-то добрый сказал: "Яночка, тестирование делается так. И так. Баги мы приоритетизируем (как по-русски) так, тикеты открываем в системе (система есть, тут можно обойтись общим)." Меня интересует обший сбор данных от 10, скажем, тестеров и приоритезация багов. Это капец как быстро надо исправить, эти могут пожить до второго релиза. То есть как этот док собрать в кучу.

Редаговано: monkey (19-06-2012 23:53)

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

Max Dieand, скинула. Повторюсь. КАК тестировать, у меня вопроса не возникает. я понимаю этот процесс. Стопорюсь на моменте, куда все тестеры должны скидывать сообщения об ошибках. И как их потом располагать в соответствии с приоритетом (лингво стазало, что так правильно выражаться)

monkey, ты себе противоречишь ))
Установите багтрекинговую систему. Много шаровых есть. В них можете трекать все баги, аттачить туда же логи и т.п.

http://forum.sources.ru/index.php?showtopic=254395&hl=

Max Dieand, есть система (через TFS, тапочек не надо, не я выбирала). Но из-за острой нехватки времени эти баги надо отправлять не все скопом, а рассказать какие важные. Это будет решать руководство. Вот я и в ступоре, как их все в кучу собрать.

monkey,


Тут непонятно - что будет решать руководство ? Какие - важные ?

_dem, именно. Есть 100 ошибок, допустим. какие-то надо срочно исправить, а какие-то могут отправиться в ящичек и ждать следующего релиза. Ошибки могут быть срочными и несрочными, сложно исправимыми и легко исправимыми. Так вот важные и легко исправимые уйдут в запрос в первую очередь, потом важные, но сложные, потом легко исправимые и не очень важные (поле поплыло в форме, которую никто никогда не смотрит, и в ближайшие полгода смотреть не будет), потом сложно исправимые и неважные. Тестирование будет циклами: репортнули ошибки в порядке их убывания по важности, девелоперы пыхтят исправляют недели две, потом опять тестирование две недели. насобирали кучку, опять отправили
и так далее. Вот меня напрягает процесс собирания всех ошибок в кучу и расставлению их в порядке убывания оп важности. Сложность уже девелоперская команда будет оценивать.

monkey, ну смотри по предметной области, как тебе тут помочь ?
В общем - сортируй ошибки по потенциальному финансовому урону * вероятность проявления, все остальные критерии - частные случаи урона в кеше.

Вот тебе и рейтинг важности.

Added after 1 minutes:

 monkey,  собирание/приоритезация - как-то не вопрос вообще. Добавь в требования к описании ошибки "на что может повлиять" - это поможет в оценке важности.

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

_dem, я наверное непонятно выражаюсь. У меня есть 5 человек, к примеру, тестирующих систему. Что им на листочек выписывать свои замечания? Вот они мне принесли пять листочков (или прислали пять документов в комментариями в тест кейсах). Как мне их все вместе соединить? И показать руководству, чтобы они по рейтингу распределили.  И как руководство будет ставить напротив каждого бага единичку, двойку или тройку? Очень важный. не очень важный. А потом переписывать важные в багтракинговую сисему? Вот собственно в чем затык. Не КАК собрать данные, а как оптимизировать их обработку.

Added after 4 minutes:



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

monkey, вылавливаешь в офисе сисадмина. Говоришь ему - мне нужен установленный redmine.  http://www.redmine.org/

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

Потом делаешь экспорт всех незакрытых багов и импортируешь в багтрек.

Вообще надо тестеров пустить в багтрек - у вас там какой-то бардак, похоже.


===

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

Added after 1 minutes:

monkey, а шо, нету способа как-то раком поставить трекер, чтобы тестерам тоже можно было что-то разумное там делать ?
Ну дебилизм. Есть тракинг, но в нем нету тестеров. Bug/task трекер - вообще основной инструмент в софтописании.

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

Added after 1 minutes:

 _dem, мы не код тестируем, а приложение со стороны юзера, и со стороны предъявленных бизнес требований. Код тестируют специально обученные люди.

Был бета-тестером 1C, Microsoft, Adobe. Будут вопросы - пиши, лучше в почту.

Разобрались. Можно закрывать. Спасибо всем.