Сообщений в теме: 8

[Toni_Cross]

Всем привет. Я новичок от слова совсем, пожалуйста, не кидайтесь тапками. Был на курсах, делал учебные проекты, читал книги, писал тест кейсы и чек листы, но четкой структуры в голове так и не сложилось. Расскажите, пожалуйста, как же правильно тестировать функциональную часть приложения? 

 

Варианты: 

Вариант 1) 

а) Сначала проверяем основную функцию приложения - ради чего оно было создано

б) Другие важные функции, которыми вероятно часто будут пользоваться юзеры

в) Все остальные функции (опционально, если время поджимает)

Это такой аналог санити тестинга

 

Вариант 2)

Отталкиваемся от требований - проверяем по максимуму каждое требование, начиная с требований с наивысшим приоритетом

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

 

Вариант 3) разбиваем логически все приложение на модули и тестируем каждый из них

Но тут вопрос - сначала делаем позитивные тесты всех модулей, а потом негативные, или сразу полностью протестить один модуль и переходить к следующему?

 

Вариант 4) используем туры Виттакера

 

Направьте на путь истинный, пожалуйста.

[Freiman]

А нет одного истинного пути.
Сколько евреев тестировщиков, столько и мнений.

 

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

 

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

[Toni_Cross]

А нет одного истинного пути.
Сколько евреев тестировщиков, столько и мнений.

 

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

 

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

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

 

Вариант 2) Второй вариант я бы использовал, если требований относительно много и не факт, что все успеем проверить. Я читал, конечно, что обычно с требованиями бардак полный и редко когда они бывают четко детализированы, но все же. Например, у нас есть большое поле для вода личных данных и прочей лабуды - есть такое учебный сайт у Портнова - energytelecom, вот что-то наподобие этого, только гораздо больше. И требований и спецификакаций там на 20 страниц, а время дали до вечера, а сейчас уже обед. Тогда будем тестировать самое важное, остальное в следующем релизе.

 

Вариант 3) Если приложение большое, типа вконтакте, тогда разбиваем все на модули: личные сообщения, моя страница, мои группы и.д. их можно разбить на еще более мелкие, но как самому организовать процесс тестирования таких гигантов пока слабо представляю, тут, наверное, менеджер должен распределить нагрузку между тестировщиками и выделить каждому фронт работ.

 

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

 

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

 

Ну, вот как-то так.

[Vasiliy]

Какая же сборная солянка у голове у выпускника курсов)) Это не тапочки в вашу сторону, это общее впечатление)

Чем отличаются варианты 1 и 2, на ваш взгляд?

 

Вы ответили правильно, на мой взгляд.

[Toni_Cross]

Какая же сборная солянка у голове у выпускника курсов)) Это не тапочки в вашу сторону, это общее впечатление)

Чем отличаются варианты 1 и 2, на ваш взгляд?

 

Вы ответили правильно, на мой взгляд.

Согласен с вами, ведь требования пишутся для функционала - приоритетная задача = приоритетное требование. Не думал как-то об этом, спасибо. 

[Spock]

вообще надо начинать с анализа рисков

 

надо составить не только список модулей, но и список фич

далее приблизительно выставить насколько вероятно что фича/модуль сломается, и насколько сильно поломка ударит по клиенту

 

вычислить риски (есть разные методы, гуглить)

 

в итоге получится список что надо тестировать в первую очередь и потратить больше ресурсов, а что в последнюю очередь

 

ну и конечно не забыть нефункциональное тестирование, например suitability: вообще приложение выполняет то, что нужно клиенту? может создали сайт чтобы фотографы заливали свои фотки, а лимит файлов 5Мб? тогда сайт будет работать отлично и по спеке, но будет никому не нужен

ну и другие виды нефункционального (гуглить), типа юзабилити и т.п.

[Little_CJIOH]

вообще надо начинать с анализа рисков

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

[SALar]

Присоединюсь к Павлу. Соваться в риски на этом уровне, да еще и без наставника... Это не просто потеря времени. Это, скорее вредительство.

 

Начнем с простого, и пойдем по восходящей кривой сложности.

 

1 левел. Можно начинать курить новичкам.

Слово товарищу Канеру. "lessons learned in software testing", урок 5. http://w-bf.livejour...om/199821.html 

 

2 левел. А что до кода?

• Тестирование производительности нужно проводить до написания кода.
• Тестирование юзабилити лучше начинать проводить на UX.
• Тестирование начинается с тестирования требований.
• И т.д.

 

3 левел. Приоритизация атрибутов качества по ГОСТ 25010 и "Парад стратегий".

Я делал список из поименованных стратегий в две дюжины пунктов. 17 штук читал на SQADays-15 (смотри http://blog.shumoos.com/archives/293 и http://blog.shumoos.com/archives/326)

Это сложно. Это действительно очень сложно.

 

4 левел. "План контроля и обеспечения качества ПО". Или "План создания качества"

Это очень полный документ. Примеров этого документа пока нет. Нигде. С участниками моих тренингов мы прошли примерно половину пути. 

[ermakidze]

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

Мой совет - не бойся ничего! Главное не бойся спрашивать: о том, на что обратить внимание при тестировании (аналитик, менеджер проекта, программисты могут помочь в этом). Если в проекте есть команда тестировщиков - то быстро втянешься, что протестировать и как подскажут коллеги. А потом придет понимание. Если нет - то тут много вариантов. Рекомендую начать с общения с начальством, с чего конкретно лучше начать - высокоуровненые функциональные тесты, или системные, или интеграционные и т. д.