Уважаемые знатоки, нужна ваша помощь. Веб тестирование

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на QA DOU!

Стыдно сказать, но я работаю тестировщиком уже 8 лет. Фирма 15+ на рынке, но я подозреваю), что тут что-то не так.

Так сложилось в жизни, что мне предложили работу QA в перспективной фирме (я не буду писать названий, дабы не позорить или не хвалить). С тех пор, я многое читала, прошла онлайн курсы по тестированию ПО и тд. Но на моей старой работе, предложили печенько слаще. В общем, я не ушла оттуда. Мне поставили задание: наладить процесс тестирования у нас. А это — задача не из простых.

Я запуталась окончательно.

На нашей фирме (чтоб все понимали, как всё тут сложно) мы тестируем мануально десктоп апликухи. При этом, всё, что у нас есть — это одни и те же «тест-планы» (мы так называем что-то на подобие тест-кейсов), по которым мы идём с каждой новой версией по кругу. И так 8 лет) Один продукт. Мы никогда не вникаем в суть, не знаем, что мы делаем, как оно правильно называется, процессы там всякие, виды тестирования — я вас умоляю! Делаем тест-планы...)

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

Ну, надеюсь, не захламите меня))
Мне и самой смешно и грустно.

Помогите чем-то?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

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

Выполнив три этих шага мы можем составить(формализовать) подход к тестированию (test strategy, test approach). В этом подходе вы описываете каким образом и какие функции вы будете тестировать. Обычно в средних и больших проектах подход оформляют ввиде документа и предоставляют заказчику.

Дальше я бы пошел по простому пути и сделал тестовые случаи (test cases) на все требования/функциональности и составил матрицу (traceability matrix), что-бы показать какие требования какими тестами покрыты. Считается хорошим тоном иметь минимум 2 тестовых случая на каждое требование / функциональность. Один случай на позитивный сценарий , и один на альтернативный или негативный сценарий. Но в зависимости от требования тестовых случаев может быть какое угодно кол-во.
Для составления тестовых случаев удобно пользоваться техниками тест дизайна (техник не много, но они помогают сделать тесты хорошими) В кратце для проверки полей, валидации и т.д. — одни техники (классы эквивалетности, граничные значения), для проверки логики — другие (переходы состояний, таблицы решений).

Стоит сказать, что такой подход сработает если у вас есть время разобраться с продуктом и писать тестовую документацию. Если времени нет, то лучший вариант — исследовательское тестирование, однако там тоже есть свои концепции, подходы и эвристики.

Если есть вопросы — задавайте.

Спасибо вам большое!!!
Вот что значит, когда человек хочет помочь и понимает вопрос, который задали. Я вам очень благодарна, учту всё, что вы написали, если у меня будут вопросы (а это 100%), напишу вам!!!

Да. уж....а кто-то зная в 10 раз больше -не может джуном в QA устроиться, ибо «опыта нет»)
а тут 8 лет опыта..

и? вы решили просто выразить своё сожаление людям, которые не имеют опыта, заодно меня осудить?
зачем это?
не понимаю таких людей. в следующий раз просто пройдите мимо, если нет совета.

Так просто -требования клиента разбиваете на куски и пишете к каждому кейсы.
Чтобы абсолютно все работало -так не бывает ,клиент должен понимать, даже в релизе есть баги..
На самом деле да ,хотел слегка вас осудить..Сейчас миллион курсов ,где учат писать тест кейсы и тест-планы -для людей без опыта- они может и не особо полезны ,а вам в самый раз инвестировать в свое образование)
Вы Савина хотя бы читали?

Если бы вы почитали внимательнее, то знали бы, что я делала. Не имею желания с вами говорить.

Ну правильно, вы хотите на халяву, даже Савина не утрудившись почитать — стать супер тестировщицей..Я всегда за справедливость)
Как можно давать совет человеку, который даже не владеет терминологией?

Дали мне задачу, написать кейсы к одному серьёзному сайту. Я понятия не имею, зачем)) и с чего начинать.
Требования у них такие: надо, чтоб всё работало))
Для начала хотя бы элементарные тест кейсы сделайте:

okiseleva.blogspot.ru/...t-httpwwwfoodpandaru.html

Спасибо за советы)))! Всё учту. А вам пожелаю удачи и откланяюсь)

Цитата из фильма Брат-2:
«8 лет это много.
Мне тогда еще 20-ти не было.
Университет, перестройка,
Америка, coca-cola.
Замуж вышла, потом сразу
развелась.
Сначала в Нью-Йорке „Еsсоrt“
Sеrviсе» работала, это по вызову.
Потом кокаин, крэк...".

Тут есть 2 варианта:
1) Иди на контакт с руководством.
2) Иди в другую фирму.
3) Тебя уволят как человека вносящего смуту и не желающего выполнять свою работу.

// я же говорил, 2 варианта :)

Мне поставили задание: наладить процесс тестирования у нас
Для такої роботи краще найняти людину з відповідним досвідом. Початківцям прийдеться дуууже довго все розгрібати... Але спробувати варто.

Обязательно попробую! В любом случае, я могу предложить им этот вариант (с наёмом спеца) и после моих попыток) Спасибо за ответ!!

После 8 лет тестирования не уметь писать кейсы?)

Ну там же ничего сложно нет)
Для начала, надо понять, что надо — или просто простенький и изящный чек-лист, или детальное покрытие тестами. Далее разбить на функционал/интерфейс/бла-бла-бла и покрывать от позитивного к негативному, от важного к менее важному. Подробность и тщательность покрытия зависит от желания «заказавшего», времени и здравого смысла. Если хотят совсем детальное покрытие, имеет смысл сделать еще и смок/санити/кто как называет тест сет/чек лист, включив в него основные кейсы.
Теперь что касается гарантий, что все протестировано и что все «работает» — НИКТО и НИКОГДА такой гарантии не даст. В конце концов, если отталкиваться от самого определения «качества», можно «гарантировать», что продукт в достаточной степени соответствует требованиям и пригоден для использования, но никак не полное отсутствие багов и гарантию, что не будет никаких приколов на реальных данных/на реальном железе/и тд и тп. А протестировать все на 100% нереально в принципе.

Спасибо за ответ)
Я писала кейсы на курсах, а в реальной работе мы вообще не имели с этим дела. Это писали другие люди. И это мы называли тест-планами, Карл))) Так , про что можно говорить))

Но, я прислушаюсь к советам, спасибо большое!

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

Да, мне будет проще, разбивая — это однозначно! Потому, как в голове уже итак тот ещё плов))

Хм... Ну, начать надо с простого, ИМХО :)
Давайте начнём с требований. Принцип прост: есть требования — супер, нет требований — надо собрать.
Начнём с варианта, где они есть. В таком случае сначала тестируем требования: полнота, непротиворечивость, тестируемость. Расписывать, что означает каждый термин, не буду — слишком много букв выйдет. Эти термины расшифровываются в любой вменяемой статье по основам тестирования. Требования проходят тестирование? Замечательно, идём дальше. Нет? Обратно на доработку.
После тестирования требований начинаем составление тест кейсов. Для начала определяем функциональные области и стараемся разбить требования так, чтобы каждое из них относилось только к своей функциональной области. Зачем — будет ниже. Затем пишем тест кейсы, группируя их по функциональным областям и указывая для каждого из них, какие требования он покрывает и его (кейса) приоритет. После завершения написания тест кейсов, составляем матрицу покрытия требований кейсами: по вертикали — кейсы, по горизонтали — требования, на пересечении (в тест кейсе есть номера требований) — плюсик. Проверяем, чтобы все требования были покрыты кейсами. Покрыто всё? Идём дальше. Нет? Дописываем недостающие кейсы.
По сути, Ваша задача на этом выполнена: тестировать у Вас задачи нет, как я понял.
Для чего разбивать кейсы и требования по функциональным областям: во-первых, это удобно. Можно сосредоточиться на написании тестов для близкого по сути контента, а не разбрасываться. Некий аналог предложения для книги. Неудобно читать книгу, состоящую из одного огромного предложения, правда? ;) Во-вторых, в случае изменений в требованиях, данная структура позволит провести impact analysis и определить, какие кейсы необходимо изменить.

В случае, если требований нет, задача немного усложняется. В этом случае есть 2 стратегии:
1). Обращаемся к заказчику с просьбой предоставить требования; или
2). делаем проход Ad Hoc’ом, собираем требования самостоятельно на основе общей эрудиции и здравого смысла, затем отсылаем данные требования на подтверждение и коррекцию заказчику и начинаем цикл, описанный выше. Если заказчик недоступен или ему пофиг на наши усилия — просто игнорируем данный пункт и считаем, что требования верны. Естессно, в этом случае качество тестирования будет ниже.

Ну, как-то так :)

По Agile я процесс сейчас не расписываю, поскольку задача статическая, соответственно, бонус agile по дешёвому управлению изменениями здесь неприменим.

Спасибо большое!! Очень информативно! Как раз тут 2) подходит, ведь требований конкретных нет и выставить их сами не могут. Поэтому,я и включаю здравый смысл и придумываю,ч то бы я делала, что бы и как тестила.

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

полнота, непротиворечивость, тестируемость
. Группируйте их сразу по функциональным областям, чтобы не заниматься этой работой потом.
Затем составляйте тест кейсы так, как описано выше. Получите элементарное представление о том, как функционируют процессы тестирования в waterfall :)

Ух! Сколько инфы! Всё-таки, лучше, когда общаешься с людьми!

Беги, Лола, Беги!! ©

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

Я не желаю идти просто опозорившись) Я сперва сделаю всё, что я хочу сделать. Я хочу показать, что настоящий. умный тестинг существует. Но спасибо за совет =)

Валите от туда срочно. 8 лет делать одно и тоже это мрак((

Всё таки, я хочу в этом всём разобраться. Это уже мой дом))
Мне реально некому помочь тут рядом, потому,я очень хочу это сделать. Я не против учиться, вникать...

Тут не учиться и вникать надо, тут надо сваливать. На работе ты или развиваешься, или нет. Если ты в течении года ничего нового не узнал, то ты зря тратишь свое время.
Но я вас понимаю, у меня хватает знакомых и бывших сотрудников, для которых зп в 4к гривен это предел мечтаний, а компания это их родной дом. Если вы не видите проблемы, то живите дальше и не задавайте себе глупых вопросов.

Дело в том, что когда я психанула и всё таки захотела уйти за пониманием всего этого, то мне предложили: вот тебе свобода от тестов, делай что-то лучше. Я хочу этого, но уже сомневаюсь,что смогу( Немного теряю веру, но комменты тут мне дали кое-какую картину!
Кстати, когда-то мечтала в глобале работать)) Понимаю, что давно надо было...

Не тролльте) Видимо, советов у вас не так и много?)

А тут ивент для тестеров в среду www.facebook.com/events/1026019327483124 , может будет вам полезен.

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

Спасибо большое за поддержку! Я осознаю это, но рада, что хотя бы начала всё это переосмысливать, учить, вникать. Мне тяжело без наставника, не спорю. Но у меня есть надежда, а значит, не всё потеряно)

Чё-то вспомнился анекдот:

— СЖЕЧЬ!
— Но она такая красивая...
— Хорошо,... но ПОТОМ СЖЕЧЬ!

Это не смешно. Имейте уважение.

Одного стандарту для написання немає. Пишіть так, як Вам буде зрозуміліше.

Вы имеете ввиду, написать всё-всё как я представляю это всё?

Саме так. Був на декількох співбесідах. Одні фірми пишуть все детально від а до я і погоджують це все з замовником. Інші взагалі не ведуть документації. Треті- залежить від проекту. Мені колись потрібно було писати тест-кейси і чек-лісти. Вибрав варіант, який мені більше по душі припав (оскільки мені одному все рівно треба було це проходити і одночасно робити). Коли проект став дуже здоровим, то перейшов в основному на ’exploratory testing’

Да, я подумаю, наверное буду иметь ещё вопросы) Спасибо за ответ!

Я этим и занималась. Но теория без практики — просто слова, просто набор терминов. По крайней мере, так работает МОЙ мозг)

Вы правы — в смысле теории без практики. Но! Например, то, что написано в книгах — воспринимайте как набор некоторых рецептов, шаблонов того как МОЖНО сделать (точнее, как кто-то когда-то где-то сделал). Причем пишутся такие книги исходя из постулата — «мы так сделали и у нас что-то получилось лучше, чем было без этого». Вот и Вы относитесь к этому так же. Что-то прочитали, подумали, можно-ли (между прочим не всегда ответ положителен) применить это для Вашего случая, и как его применить. Попробовали. Получилось — отлично, нет — «отрицательный результат это тоже опыт». Не пытайтесь все охватить (все, что прочитали внедрить) за «один заход», Идите небольшими шажочками — и Вам так будет проще контролировать процесс, и окружающие с меньшей вероятностью будут Ваши предложения воспринимать в штыки (кстити, готовьтесь к тому, что «штыки» — разной длинны и остроты — обязательно будут). Потом анализируйте успехи/промахи — и идите дальше. Глядишь — и сами потом книжку напишете: " Как строить QA-процесс при разработке web-приложений с нуля" :-)
Удачи!

Спасибо большое! Это полезный совет! Я очень стараюсь, надеюсь, что всё получится.

Годный вброс:)

Пара цитат которые сделали мой день :

Стыдно сказать, но я работаю тестировщиком уже 8 лет.

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

Вас повысили из тестировщика до сейлз менеджера?)

=) Как-то так вышло, что от меня всего хотят)

#1
вам горит и вы ищете консультанта?
вам не горит, хотите разобраться и рассчитываете на список литературы?

#2
у вас компания разрабатывала декстопный продукт, а теперь будет продавать сервис по тестированию веб-сайтов? э?

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

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

что именно вас интересует?

Представьте себе ситуацию: вы ничего не понимаете в тестировании. Но вам хочется получить протестированный сайт... та пусть будет доу.юа. Вот у вас такое желание. Вы заказчик)) Протестируйте мне доу, напишите к нему документацию. К главным, базовым функциям.
Давайте представим, что это возможно взять и просто сделать. Вопрос:
1) С чего начать?
2) Можно ли написать на него тест-план, если я например не могу сказать, сколько это времени займёт, ведь я и не аналитик...
3) Можно ли сделать так: написать план, написать кейсы, мысленно распределить, кто что делает, может даже протестить (ведь я уже немного понимаю в этой кухне, просто на практике, в других компаниях, я не делала этого, только на курсах что-то типа того). Я понимаю, как тупо это всё звучит...)

Давайте представим, что это возможно взять и просто сделать
разобраться с целью. заказчик хочет обнаружить функциональные баги или нефункциональные? если функциональные, то быстро(smoke тестирование) или глубоко(overall)? определенные разделы или вообще везде(exploratory?)? у него у самого есть понимание, как система должна работать? или предполагается, что вы угадаете по имеющейся информации все ограничения, назначение и подводные камни(черный ящик? белый ящик?)? как с поддержкой разных браузеров и ОС? а с мобильными устройствами?
если не функциональные, то что там, скорость загрузки или скорость работы, загрузка процессора в определенные моменты, скорость отклика интерфейса, юзабилити?
что должно быть получено в результате? набор тест-кейсов для возможности повторить в любой момент другим составом? просто заключение «вроде, норм, вот, список обнаруженных проблем»? показатель «качество» в неких процентах(ну, да, звучит глупо, но мало ли)?

не то, чтоб я загрузить хочу.
но входящих данных очень мало.
как вам такой вариант: поискать матерого и опытного QC уровня не ниже «Lead» в качестве консультанта?

если такой вариант не подходит, конкретизируйте вопросы. «с чего начать?» это не конкретный вопрос. К сожалению.

Хорошо, я уточню, только соберусь с мыслями.

1. Начните с того, что узнайте какой основной флоу будет у конечного пользователя этого сайта.
1.1. Что еще может конечный юзверь.
1.2 Разработайте сьюты по фолу
1.3 Узнайте о конф-ии прода и какую нагрузку должен держать. Сделайте минимальный лоад тестинг желательно с профайлером дабы узнать где есть места для оптимизации если вдруг пользователей будет х10-х100.
1.4 Автоматизируйте повторяющиеся шаги
2. Сделайте тест план по сьютам+приоритетам/эссайнментам/эстимейшнам
3. Можно, но лучше документируйте т.к. хаос будет однозначно

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

Спасибо! Домой приду, расспрошу вас! =)

ну смотри.
составь mindmap(search_google_images:"mindmap website testing«) разделов сайта, либо его функционала.
можешь взять mindmap разных видов тестирования из поисковой выдачи и по ним составлять что делать. нарисуй вначале на бумажке, потом переноси в удобоваримый электронный вид.

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

для back-end открываются базы и смотрится — есть ли обновление баз при выполнении разных действий(для того же инет-магазина записями будут регистрация юзера, оформление покупки и т.д)

плюс универсальный подход к сайту — «стать пользователем сайта». т.е. нужно в голову вбить мысль, что тебе нужна эта услуга и попытаться эту услугу получить. Это будет основным тест-действием. Плюс так можно найти конфликты бизнес-логики и архитектуры(юзеру нужно одно, а на сайте это сложно реализовано, непрозрачно)

Класс!!!!!! Спасибо огроменное!! Это как раз то, что мне поможет! Потому, что в моей голове правильное тестирование — это как огромный набор пазлов, которые раскидали по всему дому, и я хожу, собираю их, чтоб получилась картина в конце пути)

с хэппи-пасов
Отличный слэнг, бро

Чего сленг, ИМХО обыное определение:
en.wikipedia.org/wiki/Happy_path

мне кажется сложно сильно ), по крайней мере 1.3, и 1.4 учитывая ситуацию

Уважаемые знатоки, нужна ваша помощь. Веб тестирование
отвечает Александр Друзь

С радостью с вами бы поржала))) Но реальный вопрос)

Підписатись на коментарі