ch_ip

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

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

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

Если хотя бы половина из этого для проекта верна, то да, регрессия необходима всегда, т.к. никто не может предсказать последствия изменений и какие есть риски от конкретных изменений.
При грамотно выстроенном процессе тестирования, когда есть юнит и интеграционные тесты, запускающиеся при каждом изменении + функциональные тесты, которые запускаются каждую ночь на новых сборках, нужна минимальная регрессия, а в каких-то случаях можно обойтись и без нее. Плюс даже в тех случаях, когда она есть, необходимо периодически пересматривать, действительно ли нужен все тот же комплект проверок и думать, как оптимизировать.
В блоге у Оли Киселевой есть хорошая статья о том, как мы уже оптимизировали нашу регрессию — "Всегда ли нужна ручная регрессия? Жизнь_боль как двигатель прогресса"
+ сейчас мы думаем над тем, как полностью сделать ее автоматической и сократить затраты на весь цикл регрессионного тестирования до 4-6 часов одного человека в релиз (при это сама автоматическая регрессия, выполняемая роботом, может занимать до 2-3 дней). Стоит учесть, что наш продукт часто является критичным в цепочке основных бизнес-процессов Заказчика, поэтому мы не можем позволить себе пропустить ошибки, из-за которых система встанет (высокие финансовые риски для наших Заказчиков и репутационные риски для нас самих)

@LockerAT, вам слабо поможет то, что спрашивали конкретно у другого человека на собеседовании. ;-)
Потому что все зависит даже не от конторы, а от человека, который вас собеседует. И даже на одну и ту же вакансию одни и те же люди могут давать разные задачки в зависимости от того, как идет собеседование.
А так, вы все верно описали, спрашивают логические задачки, чтобы понять, умеет человек думать или нет; задачки на тест-дизайн (придумайте кейсы, протестируйте что-нибудь); описать ошибку; простые задачки на SQL, если указан в требованиях к вакансии.

Что скажете про новую площадку bugtest.ru?

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

Короче, вы определитесь с тем, как вы тестируете - если силами краудсорса, то не надо требовать столько данных и круто было бы предложить какие-то плюшки за бесплатное тестирование

ch_ip, спасибо большущее, буду разбираться.

Добавил еще полную инструкцию по настройке машины (выше) + упрощенный вариант скрипта для шейпинга.

 

Плюс у нас был также скрипт Жени Ли, позволяющий имитировать проблемы сети:

#!/bin/bash

usage() {
    cat <<EOF

usage: $0 options

OPTIONS:
  -v verbose mode
  -i interface
  -c clean rule
  -h show this message
  -r rule
    'delay ms'
    'delay_normal MAX_ms MIN_ms'
    'loss MAX_percent MIN_percent'
    'double percent'
    'noise percent'
    'mixing ms_dealy MAX_percent MIN_percent'

EXAMPLE:
  $0 -i eth0 -v -r 'delay 10' -r 'noise 3' -r 'loss 2 3'
  $0 -i eth0 -c
EOF
}

[[ -n "$1" ]] || { usage; exit 128; }

RULES=()

while getopts "shvr:ci:" OPTION
do
    case $OPTION in
        v)
            set -x
            ;;
        i)
            INTERFACE=$OPTARG
            ;;
        c)
            ACTION="del"
            ;;
        h)
            usage
            exit 1
            ;;
        r)
            RULES+=("${OPTARG}")
            ;;
    esac
done

if [ -z $INTERFACE ]; then
    echo "-i [interface] is required"
    exit 128
fi

ADD_COMMAND="tc qdisc add dev $INTERFACE root netem "
DEL_COMMAND="tc qdisc del dev $INTERFACE root netem "
SHOW_COMMAND="tc qdisc show dev $INTERFACE"

if [[ "$ACTION" == "del" ]]; then
    eval "$DEL_COMMAND 2>/dev/null"
    exit_code=$?
    eval $SHOW_COMMAND
    exit $exit_code
fi

argument_count_error () {
    echo "Arg error: $1"
    exit 128
}

for rule in "${RULES[@]}"; do
    case $(echo $rule | awk '{print $1}') in
        delay)
            if [[ "$(echo $rule | wc -w)" != 2 ]]; then argument_count_error delay; fi
            DELAY_VALUE=$(echo $rule | awk '{print $2}')
            shell_command_delay=" delay ${DELAY_VALUE}ms "
            ;;
        delay_normal)
            if [[ "$(echo $rule | wc -w)" != 3 ]]; then argument_count_error delay_normal; fi
            DELAY_VALUE_MAX=$(echo $rule | awk '{print $2}')
            DELAY_VALUE_MIN=$(echo $rule | awk '{print $3}')
            shell_command_delay_normal=" delay ${DELAY_VALUE_MAX}ms ${DELAY_VALUE_MIN}ms distribution normal "
            ;;
        loss)
            if [[ "$(echo $rule | wc -w)" != 3 ]]; then argument_count_error loss; fi
            LOSS_MIN_PERCENT=$(echo $rule | awk '{print $2}')
            LOSS_MAX_PERCENT=$(echo $rule | awk '{print $3}')
            shell_command_loss=" loss ${LOSS_MIN_PERCENT}% ${LOSS_MAX_PERCENT}% "
            ;;
        double)
            if [[ "$(echo $rule | wc -w)" != 2 ]]; then argument_count_error double; fi
            DOUBLE_PERCENT=$(echo $rule | awk '{print $2}')
            shell_command_double=" duplicate ${DOUBLE_PERCENT}% "
            ;;
        noise)
            if [[ "$(echo $rule | wc -w)" != 2 ]]; then argument_count_error noise; fi
            NOISE_PERCENT=$(echo $rule | awk '{print $2}')
            shell_command_noise=" corrupt ${NOISE_PERCENT}% "
            ;;
        mixing)
            if [[ "$(echo $rule | wc -w)" != 4 ]]; then argument_count_error mixing; fi
            MIXING_DELAY_VALUE=$(echo $rule | awk '{print $2}')
            MIXING_MIN_PERCENT=$(echo $rule | awk '{print $3}')
            MIXING_MAX_PERCENT=$(echo $rule | awk '{print $4}')
            shell_command_mixing=" delay ${MIXING_DELAY_VALUE}ms reorder ${MIXING_MIN_PERCENT}% ${MIXING_MAX_PERCENT}% "
            ;;
    esac
done

COMMAND="${ADD_COMMAND}${shell_command_delay}${shell_command_delay_normal}${shell_command_loss}${shell_command_double}${shell_command_noise}${shell_command_mixing}"

eval "$DEL_COMMAND 2>/dev/null"
eval "$COMMAND"
exit_status=$?
eval "$SHOW_COMMAND"

exit $exit_status

 

Мы использовали для этих целей машину с двумя сетевухами и линухом на борту.

На ней через iptables настраивали маршрутизацию, через tc - ограничение траффика.
статья в помощь: http://habrahabr.ru/post/119611/

спасибо, статья то что надо...

 

 

Инструкция по сетапу машины.

Настраиваем DHCP сервер для одного из интерфейсов:

Примечание: сейчас используются самые верхние входы, сверху-вниз: eth1 (целевая тачка), eth0 (вовне)

Редактируем файл /etc/network/interfaces, указываем статический IP для eth1

auto eth1
iface eth1 inet static
address 192.168.11.1
netmask 255.255.255.0
network 192.168.11.0

Перезапускаем networking так

  /etc/init.d/networking restart

Cтавим пакет isc-dhcp-server

  apt-get install isc-dhcp-server

Делаем так, чтобы dhcp-server раздавал адреса только на eth1
Редактируем файл /etc/default/isc-dhcp-server

  INTERFACES="eth1"

Потом редактируем файл /etc/dhcp/dhcpd.conf

subnet 192.168.11.0 netmask 255.255.255.0 {
option routers 192.168.11.1;
range 192.168.11.1 192.168.11.254;
option subnet-mask 255.255.225.0;
option domain-name-servers 10.40.0.1;
}

Если хочется, конкретным машинам в сети можно принудительно раздать адреса; в тот же файл добавляем такие строки:

host host1 {
hardware ethernet bc:5f:f4:38:6e:a9
fixed-address 192.168.11.99
}

Еще надо сделать так:

  dhcpd -t -cf /etc/dhcp/dhcpd.conf

Перезапускам сервис так

  sudo service isc-dhcp-server restart

Остановить сервис так

  sudo service isc-dhcp-server stop

 

Гоним весь траффик с eth0 на eth1 при помощи магии iptables

Делаем раз

Вписываем в /etc/sysctl.conf строку net.ipv4.ip_forward = 1

 

Делаем два

  iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE

Делаем три

  iptables --append FORWARD --in-interface eth1 -j ACCEPT

Сохраняем правила

  iptables-save > /etc/somewhere

 

В /etc/network/interfaces добавляем строку

  post-up iptables-restore < /etc/somewhere

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

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

 

Шейпим траффик при помощи tc

Чтобы замедлить траффик на интерфейсе eth1, например, на 200ms

  sudo tc qdisc add dev eth1 root netem delay 200ms

Чтобы удалить правило

  sudo tc qdisc del dev eth1 root netem delay 200ms

Чтобы ограничить скорость исходящего траффика используем скрипт shape.sh (код ниже), запускать его так:

  sudo bash shape.sh -i eth1 -s 512

остановить

  sudo bash shape.sh -i eth1 -k

NB: интерфейсы надо задавать последовательно, то есть нельзя сказать -i 2, если не запускали -i 1

При манипуляциях с iptables не забывать что данные проходят через chain FORWARD, а не INPUT. Например:

#дропать dns-траффик к целевой машине
iptables -I FORWARD -p udp --sport 53 -j DROP
#удалить правило
iptables -D FORWARD -p udp --sport 53 -j DROP

Скрипт shape.sh для шейпинга траффика авторства Никиты Налютина и Жени Ли:

#!/bin/bash
# set -x
 
DEV_UP='ifb0'
UNITS='kbit'
#  kbps: Kilobytes per second
#  mbps: Megabytes per second
#  kbit: Kilobits per second
#  mbit: Megabits per second
#  bps: Bytes per second

usage() {
    cat <<EOF

usage: $0 options

OPTIONS:
  -i interface
  -k stop
  -s bandwidth

EXAMPLE:
  $0 -i eth0 -s 512
  $0 -i eth0 -k
EOF
}

[[ -n "$1" ]] || { usage; exit 128; }

start() {
    BANDWIDTH="$1"

    # up
    modprobe ifb
    ip link set dev ifb0 up

    # redirect
    tc qdisc add dev $DEV_DOWN ingress
    tc filter add dev $DEV_DOWN parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev $DEV_UP

    # parents
    tc qdisc add dev $DEV_DOWN root handle 1: htb default 42
    tc qdisc add dev $DEV_UP root handle 1: htb default 42

    # child
    SPEED=$(echo "$BANDWIDTH$UNITS")
    tc class add dev $DEV_DOWN parent 1: classid 1:42 htb rate $SPEED ceil $SPEED
    tc class add dev $DEV_UP parent 1: classid 1:42 htb rate $SPEED ceil $SPEED

    # filters
    tc filter add dev $DEV_DOWN protocol ip parent 1:0 prio 1 u32 match ip src $IP flowid 1:42
    tc filter add dev $DEV_UP protocol ip parent 1:0 prio 1 u32 match ip dst $IP flowid 1:42

    echo $SPEED
}

stop() {
    tc qdisc del dev $DEV_DOWN root
    tc qdisc del dev $DEV_UP root
    tc qdisc del dev $DEV_DOWN ingress
    ip link set dev ifb0 down
}

while getopts "s:i:k" OPTION
do
    case $OPTION in
        i)
            DEV_DOWN=$OPTARG
            [[ -n "$DEV_DOWN" ]] || { usage; exit 128; }
            IP=`ip addr show $(echo wlan0) | grep 'inet ' | egrep -o "[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}" | head -n1`
            ;;
        k)
            stop
            ;;
        s)
            stop
            [[ -n "$OPTARG" ]] || { usage; exit 128; }
            start $OPTARG
            ;;
        h)
            usage
            exit 1
            ;;
    esac
done

Запуск: sudo bash shape -i 1 -s 512
Останов: sudo bash shape -i 1 -k
Хелп: sudo bash shape usage
NB: интерфейсы надо раздавать последовательно, то есть нельзя сказать -12, если не запускали -i1

 

 

Еще один вариант:

modprobe ifb
ip link set dev ifb0 up
tc qdisc add dev eth1 ingress
tc filter add dev eth1 parent ffff: protocol ip u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0
tc qdisc add dev ifb0 root handle 1:0 netem delay 2ms
tc qdisc add dev ifb0 parent 1:1 handle 10: tbf rate 2000kbit buffer 1600 limit 3000

sudo tc qdisc delete dev ifb0 root -  чтобы очистить правила

Мы использовали для этих целей машину с двумя сетевухами и линухом на борту.

На ней через iptables настраивали маршрутизацию, через tc - ограничение траффика.
статья в помощь: http://habrahabr.ru/post/119611/

Когда-то коллективным разумом составили такой чек-лист

Почему такая разница в англ и русском(украинском?) варианте?

Англ:

контакты нечитаемы. Зачем скайп совмещен с телефоном?

a test engineer in developing  - это что-то новенькое. Знаю SDET, а такое впервые вижу. SDET подразумевает серьезные навыки написания кода, которых у вас нет.

SDLC - что это? (я, кончено, расшифровал, но люди, которые отсеивают резюме в больших компаниях не будут тратить на это время)

Waterfall - водопад знаете? А я большое озеро знаю. Как-то надо согласовать все же, о чем идет речь, а то набор слов получается. Тестировщик, который не умеет понятно формулировать мысли никому не нужен

basic of Agile - это вообще неясно, как понимать.

что такое test automation background?

basic Java, basic JavaScript, advanced SQL, basic – HTML. - почему к HTML особое отношение и он через дефис?

Tools: JIRA, MySQL, Selenium, HP Quality Center, HP Load runner, Eclipse, SVN. - помните, в детстве такая игра была "выбери лишнего"? ВОт найдите тут лишний элемент и удалите его. Selenium, HP Quality Center, HP Load runner, нужно указывать обязательно с уровнем, на котором владеете данным инструментом

Languages: Ukrainian, Russian , English - Pre-Intermediate. Вот эта строчка читается так: все языки знаю на уровне pre-intermediate

Strong attention to details. - резюме говорит об обратном, начиная с ошибки в названии файла

2013-Course of software-testing (URL) - ссылки должны быть ссылками!

 

Общая неконсистентность резюме: если вы знаете такие штуки как Selenium и HP QC, то где та работа, на которой вы их использовали? Где список книг по профессии, который вы прочли? Откуда серьезное знание SQL?

Судя по образованию, институт вы закончили год назад. Чем занимались этот год?

Где указание на общую компьютерную грамотность? Какими осями владеете, на каком уровне?

 

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

Почитайте анализ резюме, хотя бы в этой теме. Ошибки в основном одни и те же у всех.

5) "Microsoft Office Word, Microsoft Office Excel опытный пользователь" - люди которые так пишут в резюме совсем ничего не знают об этих продуктах. Вот вам пример опытного пользователя:

ворд:

http://www.youtube.c...h?v=RZp7BvQJnU8

Это извращение, а не продвинутое использование Ворда. Ворд он для другого, а пиктограммки надо в соответствующих редакторах рисовать.
Равно как и знание VBA имеет слабое отношению к знанию Экселя

У меня вопрос к вам, дорогие коллеги, как у вас проводится тестирование мобильных устройств и что бы вы посоветовали в данной ситуации?

Что можно в итоге предложить:
1) еще раз посмотреть на баги, найти общие моменты и попытаться еще раз приоритизировать список конфигураций, чтобы можно было, например, всегда проверять на трех, а еще на трех дополнительно. В следующий релиз опять проверять на трех обязательных и трех других дополнительных и т.д. То есть покрывать все устройства не каждый раз, а в течение нескольких релизов
2) отдать на аутсорс - но велик риск, что качество будет не таким, как вы ожидаете
3) посоветоваться с разными программистами, которые видели приложение, и еще раз подумать, что из списка проверок можно автоматизировать. На симуляторах совсем никак нельзя проверять, обязательно на живых устройствах надо?
Может быть можно автоматизировать не всю проверку, а часть каких-то сценариев или шагов, которые являются подготовительными к проверке, чтобы уменьшить время, необходимое на прохождение сценария
4) попробовать использовать биржи типа fixber или oDesk, где есть много тестировщиков с разными устройствами. Сразу решает и проблему рутины и проблемы покрытия.
5) выпускать релизы часто и проверять новые релизы на одном устройстве каждый раз. Все равно же пользователи не будут обновлять приложение каждую неделю. А процент тех, кто будет, - мал, что позволит провести фактически бесплатное бета-тестирование.О критичных ошибках вам сразу сообщат ;-)

Тема и обсуждение непередаваемо прекрасны. Давненько таких не было. Слежу за обсуждением с самого начала и несколько офигеваю от реакции сообщества.
Собственно, что имеем на старте?
ТС озвучил проблему: есть мобильная версия, которую надо тестировать на 12 выбранных устройствах 1 раз в 2 месяца. Тестирование на одном устройстве занимает 1 час. Чтобы протестировать полностью необходимо 12 раз пройти тест-комплект, но тестировщик один, времени, которое есть чтобы протестировать - 1 день. Сейчас в качестве решения проблемы используется привлечение программистов к тестированию, но это не всем нравится, поэтому ТС ищет другие варианты решения проблемы.
 
Совершенно нормальная ситуация, особенно учитывая дополнение ТС о том, что раньше с ресурсами на  тестирование было лучше (3 человека), а сейчас пока так, как описано.
Итого, у команды, которая выпускает продукт, есть проблема (продукт выпускается командой, поэтому проблемы одного из участников команды в плане выполнения части работ, на самом  деле являются проблемами всей команды).
Какие проблемы есть:
выполнение 12 циклов тестирования по одному плану - это просто убийственно
1) с точки зрения мотивации человека, который этим занимается. Допускаю, что есть маньяки, готовые и 20 раз подряд проходить по одному сценарию, но обычно люди  начинают испытывать раздражение после трех одинаковых сценариев подряд.
2) следствием 1 является все меньшая концентрация и способность обнаружить ошибки при повторном прохождении сценария, причем снижение этой способности идет по нарастающей, и 10 цикл почти бесполезен с точки зрения вероятности найти ошибку, которая не совсем краш посередине сценария.
 
Итого, на старте скорее всего (полностью ситуации не знаю, поэтому предполагаю) имеем следующее:
можно или не проводить часть тестирования, или проводить его неэффективно, или в качестве временной меры привлечь разработчиков.
Плюсы привлечения прекрасно расписаны ТС тут

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

Это неверно. Почитайте книжки по теме, например "Психбольница в руках пациентов" Алана Купера

 

P.S. Ваш ответ очень похож на троллинг в той форме, которая на форуме не приветствуется

Резюме хорошее. Мой совет: уместите все на одну страницу.

Шанс высокий, я только не знаю, что у нас с разрешениями на работу сейчас.

Параллельно поиску работы начните читать литературу по тестированию.

И такого подхода я еще нигде не видела, кроме данного портала =)

 

Оля, есть разные тренинги. Есть очные с домашними заданиями и по 4 часа.

Например, в упоминавшемся уже Люксофте

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

 

1. Что вам нравится в своей работе?

2. Какие черты характера помогают вам любить тестирование?

3. Без чего нельзя стать хорошим тестером?

1. Всё нравится: возможность сделать программы лучше, удобнее, логичнее для пользователей. Большой простор для развития и карьерного роста. Все время можно заниматься интересными задачами.

2. Любознательность, дотошность, перфекционизм, непрекращающееся "а что будет, если..."

3. Без воображения