Что мешало танцевать уволенному тестеру?

если Вам есть что сказать - я с удовольствием :slight_smile: а так - вижу, что наши позиции практически совпадают.

ОФФ./2

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

похоже на [urban legend] :), вы траекторию падения на клавиатуре отследите. :lol:

1 лайк

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

Автоматическое тестирование:

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

Хотите верьте - хотите нет.
Я реально это тестировал.
Я не могу вам дать ссылку на баг-трекер - это все таки закрытая конфиденциальная инфа.

да не надо, я все равно не пойму. Просто интересно как телефону удалась комбинация “Shift” “+”:lol:

Михаил, конечно спорить с вами о QA наверное глупо, но я в корне не согласен.

Простой пример:
Кусок функционала. Для его тестирования нужно 4 m/d.
Время на его автоматизацию - 8 m/d.
Для высокого качества нам нужно провести 3 цикла тестирование+E2E тестировании при разворачивании ПО на площадке заказчика.

Итого: 4*4=16 m/d - время затрачиваемое на ручное тестирование.
8+(2-4)=10-12 m/d - время на автоматизацию, где (2-4) - время потраченное на запуск-анализ результатов-ассейсмент и заведения багов

Итого: мы экономим 4-6 m/d или 32-48 часов работы, которые можно потратить на другую часть функционало.

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

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

да нет, не критично… take it easy

3 лайка

Время на автоматизацию умножьте еще на 10. Добавьте столько же на поддержание до конца проекта.

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

А почему на 10?
Если мы автоматизируем простой кусок?

Скажем проверить табы и атрибуты на табах. (на 50 различных объектах)
Вносим атрибуты и объекты в ексель или xml файл - его скармливаем в слегка модифицированный автотест предыдещего проекта.

Выйдет как раз лое в 2 раза. Да и вручную гораздо легче ошибку в проверке - монотонный тупой труд.

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

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

кстати, Михаил, Вы не думали брать на outsource небольшие проекты? компаниям это может быть выгодно, т.к. разворачивать отдельную тестовую среду ради недели тестирования часто не хочется.

мы постоянно 3-4 проекта тестируем, интегрируя их в учебный процесс. Но нам не любой проект годится.

ясно, я Вам в личку написал

это конечно может быть и важно, но обычно подобные мелочи не критичны вообще (если будет ошибка - будет патч … а “ловить” специально - можно только от большого количества лишнего свободного времени), разве нет?

я не хотел продолжать, но… все приведенные символы сгруппурованы в одном кластере клавы, а до бокового плюса надо еще допрыгать;)

конечно если проект серьезный и долгоиграющий - то без автомейшн не обойтись .

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

У Вас в компании кто-то использует специально разработанные средства автоматизации тестирования? QTP, Selenium, Silktest - что-то из этого ряда?