Перейти к содержимому

Toni_Cross

Регистрация: 14 июн 2017
Offline Активность: 16 июл 2017 23:29
-----

Мои сообщения

В теме: Как же, собственно, тестировать?

04 июля 2017 - 14:33

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

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

 

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

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


В теме: Как же, собственно, тестировать?

04 июля 2017 - 14:11

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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


В теме: Собеседование: тест план для лифта

15 июня 2017 - 13:59

Всем спасибо за ответы! Сам не понимаю, как я мог так облажаться :scare:   ну, теперь хоть буду знать и в следующий раз не опозорюсь)