Wolonter

Принято. Я полагаю, что ваши цели неверны. После этого все остальные рассуждения смысла не имеют.

Прочитайте "Цель" Эли Годратта. Я его читал раза три. И вам советую.

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

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

Болтали как-то с нашей тестировщицей. Я ей и посоветовал: ты когда ручками проверяешь - спроси у программиста:
- А ты на это unit-тесты написал?
Она меня спрашивает:
- А потом отмечать, кто написал, а кто нет и тебе передавать?
- Нет, не надо ничего отвечать. Просто спроси. Они тебе скорее всего скажут что нельзя написать, так как там приходится контекст поднимать или еще чего.
- И что? Записать в таску?
- Нет. Ты ответ вообще не слушай ты спроси и все.
- Ладно...

Через пару дней.
- Работает! Пишут! Беру я такую-то задачку, спрашиваю у пограммиста про юнит тесты. А он и говорит:
- Нет. Хм... ты пока не тестируй эту задачку...

Как-то так.

Здравствуйте!
... и будут заставлять менеджеров ставить задачи опираясь на нее. На данный момент из того, что есть
- описание того, что тестируем
- где и на чем (ОС и браузеры)
- ссылки где найти проект
- ссылки на ТЗ и дизайн

Если рассматривать тикет как способ коммуникации - то он должен быть таким, чтоб глядя на него не хотелось бы никому задавать лишних уточняющих вопросов, правильно?
Я бы хотел еще знать:

• кто писал код, когда писал код, что изменилось в системе контроля версий - то есть ссылку на тикет программиста
• на что обратить особое внимание (от менеджера) - что должно работать нупалюбому
• на что обратить внимание (от программиста) - что могло сломаться, скрытые связи и так далее

И еще объем работ. Как бы сказать пояснее... Как то так:

— Степан! У гостя карета сломалась.
— Вижу, барин. Ось полетела. И спицы менять надо.
— За сколько сделаешь?
— За день сделаю.
— А за два?
— Ну… За… Сделаем и за два.
— А за пять дней?
— Ну, ежели постараться — можно и за пять.
— А за десять?
— Ну, барин, ты задачи ставишь! За десять дён одному не справиться, тут помощник нужен — хомо сапиенс!

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

нет. Продукт не такой уж и маленький. Но устойчивый.

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

Вместо этого у вас есть прекрасная возможность заняться вкусными вещами.
совместимость, устойчивость, нагрузку и т.п - я об этом.

Выглядеть это может например так: "Здрасте, гражданин начальник, по данным гугл аналитикс на вебинтерфейс нашего продукта заходят 6% пользователей с браузера дельфин, а в нем аяксы криво отрабатывают. 6% это 5 миллионов пользователей, мы будем ради них это чинить?"
Или так: "Внедренцы говорят, что Самый Большой Клиент переводит все сервера на соляру, давай я на ней инсталляцию и интеграцию с веб-сервисами погоняю".

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

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

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

Вот очень верная мысль.

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

Ценность опытного тестировщика - доверие к нему. К его словам: тут я проверил, все чисто.

Здравствуйте уважаемые форумчане!
У меня проблема следующая.
какую тему выбрать,ведь автоматизированным тестированием я не занималась.
Тестирую я СЭД,система электронного документооборота,повторюсь опыта особо нет.

Разработка стратегии тестирования СЭД. Планирование и проведение тестирования СЭД.

• • Проблема. Почему тестируем. Предпосылки необходимости тестировщика. Проблемы продукта. Проблемы проекта. Особенности тестирования СЭД в этом контексте.
  • Требования к квалификации тестировщиков. Использовать ли бетатест. Особенности тестирования СЭД в этом контексте.
  • Тестовое покрытие. Что будем тестировать? Логику, интеграцию с другими системами, инсталляторы. Обоснование. Особенности тестирования СЭД в этом контексте.
  • Способы тестирования. Почему не будем автотестировать? Будем ли тестировать методом свободного поиска? Или по сценариям? По документации? По нормативным документам? Особенности тестирования СЭД в этом контексте.
  • Что делаем с результатами. Как определяем факт наличия дефекта и его критичность, важность. Багтрекер. Приоритезация дефектов. Контроль изменений. Процесс исправления дефекта. Особенности тестирования СЭД в этом контексте.
• Планирование тестирования на основе выбранной стратегии. Особенности тестирования СЭД в этом контексте.
• Тест-дизайн на основе выбранной стратегии. Особенности тестирования СЭД в этом контексте.
• Интеграция тестирования в процессы разработки(Как тестируют в рупах, ватерфаллах и прочих эджайлах). После чего начинаем и когда заканчиваем тестирование. Особенности тестирования СЭД в этом контексте.
• Выбор стратегии тестирования на основе имеющихся средств - квалификации, времени, ресурсов. Особенности тестирования СЭД в этом контексте.
• Оценка полезности тестировщика. Пострелиз баги. Трудозатраты. Особенности тестирования СЭД в этом контексте.
• Итоги полугода работы и что хотелось бы улучшить и изменить в проекте, продукте, тестировании, разработке, всем процессе. Эссе "Почему я ненавижу СЭД?"

Возможно, я у вас потом этот диплом куплю.

Позвольте поднять столь эпическую тему с парочкой вопросиков от новичка:
1) Стоит ли в кейсах подробно расписывать тестирование вводных значений для большОго количества полей ввода. Допустим на странице 10 таких полей, все они должны воспринимать только кириллицу и соответствовать ещё ряду мелких условий. Грамотным ли будет тест кейс, где единожды будут упомянуты все вводные значения (например: ввести "1111" нажать enter, ввести "11,11" нажать enter, etc), а далее будет что-то вроде "Протестировать поле ввода "Описание"?

Мы пишем документ, чтоб его читали. А прочитавший, видимо будет тестировать.

Кто?
Прочтет суровый, закаленный в продакшенах ветеран? Прочтет новичок? Их отдадут внештатным кликерам? Документ будет просто историей и справочным материалом?
Как?
По этим сценариям будут лабать автотесты?
Как определят результат тестирования?
Было ли сложно вычислить значения для полей ввода? Достаточно ли здравого смысла, чтоб понять, что тут бага?
Какие баги ищем?
Любые? Ограничения полей ввода? Проверяем реализацию прав?

Ответьте на вопросы. Представьте читателя вашего документа. И будет понятно, надо ли дотошно описывать каждую цифру или достаточно будет напоминалки (не забудь проверить копипаст, дран-н-дроп и sql-инъекцию).

По собственному опыту - для ручного тестирования хватает таких напоминалок + список связей. А сценарии как-то сами генерятся.

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

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

Как-то так.

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

Все придумано до нас. надо только правильно прочесть первоисточники.

Например:

1. Гордыня. Сам страдаю. Приходишь в проект и видишь - они же неправильно живут! Им же надо немедленно все объяснить! И процесс поставить. И приоритеты поменять. Немедля! И только через месяц понимаешь, что единственное полезное что ты сделал - это подал на обеде соль, а все было настроено неплохо и не просто так. Ну и не мешает интересоваться - зачем это тебя взяли вообще. Может не процесс менять, а спеки вычитывать, да.

2. Уныние. Новичку на проекте обычно что - обычно да, дают читать документацию. Через неделю хочется повеситься. Слабые духом переходят с чтения документации на башорг, упорные реально прочитывают ее всю, а просветленные изучают продукт и домен. С помощью документации в том числе.

3. Алчность. "Мне платят несчастные <очень мало денег>!" Ну, обычно на это можно ответить так: "Ты и их не стоишь. Тебе 21 год, это численная характеристика твоего идиотизма"

4. Зависть. "Почему я должен исполнять черную работу и глупые ритуалы, когда остальные занимаются интересными вещами?" Помни путь: сперва повторять за учителем, затем понять смысл своих действий и постичь их идею, и лишь после этого - отринуть ритуалы и следовать духу. Так учат карате, программированию, рисованию и скраму.

Ну и остальные грехи в меру воображения...

Добрый вечер!
План отличный, все предельно ясно. А можно узнать что нибудь о плане тестирования? Если тестировщик новичок в этом деле? Хотелось бы услышать план для тестировщика... Ситуация похожая сейчас...

А я уже описал его вкратце:

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

Дальнейшее - от контекста и конкретного приложения.

Ватман А1
xmind

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

Тайм-ауты не используй друг, на темную сторону силы ведут они.

1. Использовать можешь ты мечом световым владения навыки:

public boolean waitPresentOrAbsentElement(final By by, long maxTimeOutInSeconds, final boolean presentOrAbsent)
    {
        WebDriverWait wait = new WebDriverWait(_driver, maxTimeOutInSeconds);
        boolean result;
        try
        {
            wait.until(new Function<WebDriver, Boolean>()
            {
                @Override
                public Boolean apply(WebDriver driver)
                {
                    // ^ - Сложение по модулю 2 
                    // Таблица истиности и описание.
                    // true^true = false - Ожидаем элемент, но элемент отсутствует - ждем далее.
                    // true^false = true - Ожидаем элемент, элемент присутствует - завершаем ожидание.
                    // false^true = true - Ожидаем исчезновение элемента, элемент отсутствует - завершаем ожидание. 
                    // false^false = false - Ожидаем исчезновение элемента, но элемент присутствует - ждем далее.
                    return Boolean.valueOf(presentOrAbsent ^ driver.findElements(by).isEmpty());
                }
            });
            result = true;
        }
        catch (TimeoutException exc)
        {
            result = false;
        }
        return result;
    }

2. Или же познать глубинную суть силы можешь ты:

    @Override
    public WebElement findElement(By by)
    {
        waitForAsyncCall();
        return getWebDriver().findElement(by);
    }

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

З.Ы. Это то, что нужно?

Меня интересует один аспект. Есть ли возможность проводить автоматическое тестирование сайта, например каждый час, и в случаи неудачных результатов, посылать сообщение об ошибке на почту. Есть ли возможность сделать это с помощью Selenium или есть такой функционал в JMeter?
буду благодарен за любые ответы..)

Вероятней всего, вам нужен jenkins. Легко устанавливается, умеет все перечисленное. Рекомендую.
Там есть еще плагины для отчетов и прочих графиков, которые так нравятся начальству.

что такое модель тестирование, например)) и с чем ее едят))

своя версия:
1) Тестирование сайта на предмет его работоспособности (от выбора товара, до его заказа)
2) Тестирование сайта на наличии графических огрехов
3) Тестирование сайта на предмет наличия в нем орфографических и пунктуационных ошибок

я правильно понимаю общий смысл?

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

Что бы сделал я? Взял бы пару листов А3 и написал:
- Что вообще можно тестировать - вообще все знакомые слова - юзабилити, орфографию, логику, регрессию, безопасность, нагрузочное тестирование, боевой сервер, тестовый стенд. Слов 20.
- Как я могу тестировать: пецкать руками, найти рабов бета тестеров, написать автотесты, записать сценарии, столкнуть работу на коллегу,
- Когда я буду это делать? Ночами, по утрам, 4 часа в день, срок - ближайший месяц, день, год. Исходя из сроков вычеркнуть нереальное из первых двух пунктов.
- Узнать, на кой это все надо. Чего от меня ждут. Может ждут сто багов. Может ждут качество. Может ждут отчет. С учетом этой строки - пересортировать все, что выше.
- Представить себе конечный результат. Список багов? Где этот список? На листочке? В трекере? Налаженный процесс разработки и тестирования? Как выглядит налаженность? Отчет? В экселе, в ворде? Как выдадут бабло? На карту, налом, вебманями?

Недавно развлекались с ребятами тестированием интернет магазина.

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

Кстати, ребята тогда нашли багу, позволяющую заказать товар на отрицательную сумму, жаль дыра фиксилась на уровне банка.

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

Отучать себя говорить "Я это протестировал", "я закончил проверять", "оно работает", "все, можно отдавать заказчику".

Чужой и мой переводы 10 урока Канера кстати, в тему.

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

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

Как-то так.

...насколько часто приходится с такими ситуациями сталкиваться другим.

Насколько мне известно - нашим ручным тестерам - постоянно.