Category: it

Category was added automatically. Read all entries about "it".

woman
  • abspro

вопросы после прочтения книг по тестированию

Взято отсюда , из блога Алексея Киселёва


Вопросы после прочтения книг по тестированию
Posted on



Вопросы и ответы, которые появились после прочтения книг:


  • В какой момент девелоперы должны делать юнит-тестирование?
    Я просмотрел множество ссылок в поисках наиболее простого ответа, везде примерно одно и то же. Юнит тесты – это тесты, которые можно запустить на этапе компиляции программы. Их задача – тестирование функций и классов, а не работающей программы. Фактически, юнит тесты полностью описывают и проверяют минимальные блоки из которых строится программа. Соответственно, не так важно, какой методологии мы следуем в проекте. При изменении, например, класса, мы начинаем запускать тест.

  • Должен ли аналитик или PM участвовать в организации юнит тестирования? Этот вопрос для меня оказался самым сложным.. Вопрос в степени участия. Аналитик, как мне кажется, не должен участвовать на

Collapse )

Комментарии

Эдуард Гелиаскаров на форуме uml2.ru ответил мне следующее (на второй вопрос):

Collapse )

woman
  • abspro

перепосты из блогов тестировщиков

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

отсюда.

Андрей Мясников.
Хроники отдела тестирования.
Часть 1: Джуниор.

День1.
Привели джуниора в отдел.
Глаза горят, ничего не умеет, всё хочет.
Сломал релиз-кандидата.
Улыбаемся, снисходительно хлопаем по плечу.

День3.
Новенький запарил.
Ломает всё.
Сломал даже стул.

Collapse )

Осенние мероприятия для тестировщиков в Санкт-Петербурге

Осень в Санкт-Петербурге будет горячей для тестировщиков: в сентябре состоятся четыре тренинга Алексея Баранцева, в октябре — три тренинга Натальи Руколь, а в ноябре в Питер вновь приедет конференция SQA Days, так что тестировщикам предоставляется масса возможностей для повышения своего мастерства. Конечно, посетить всё было бы здорово, но маловероятно, так что нужно выбирать, а мы постараемся вам в этом помочь, опубликовав описания тренингов с рекомендациями относительно того, на какую аудиторию они рассчитаны.

Ниже вы найдёте полные описания и ссылки на ещё более полные описания тренингов. Для начала просто список с датами:

Тренинги Алексея Баранцева

=======

Тренинг «Тест-дизайн от А до Я» (9 сентября) в каком-то смысле философский. В нём я пытаюсь рассказать не про правила тест-дизайна, а про идеи, которые породили эти правила, которые лежат в их основе.

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

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

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

=======

Тренинг «Автоматизация функционального тестирования веб-приложений: Selenium RC» (10 сентября) предназначен для тестировщиков-автоматизаторов веб-приложений. Selenium сейчас является одним из наиболее популярных бесплатных инструментов автотестирования веб-приложений, а среди русскоязычных тестировщиков, наверное, самым популярным.

Серьезная автоматизация тестирования требует умения программировать. Конечно же научиться программировать на однодневном тренинге невозможно (для этого у нас есть двухмесячный тренинг «Программирование для тестировщиков»), но если вы уже немного в этом разбираетесь – я покажу некоторые архитектурные приемы, позволяющие удобно организовать тесты и тем самым снизить затраты на их сопровождение и развитие.

Чтобы эффективно пользоваться инструментом, нужно хорошо знать его достоинства и недостатки, достоинства умело эксплуатировать, а недостатки преодолевать с минимальными потерями. Selenium обладает уникальной архитектурой, обеспечивающей с одной стороны поддержку большого количества браузеров, а с другой стороны, позволяющей разрабатывать тесты на различных языках программирования. Но за эту универсальность приходится расплачиваться, и в первую очередь – производительностью. Этому вопросу также будет уделено достаточно много внимания на тренинге.

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

=======

Тренинг «Тестирование методом свободного поиска» (11 сентября) нацелен главным образом на тест-менеджеров и менеджеров проектов, которые хотели бы начать использование этого подхода, но не знают, как управлять слабо формализованным процессом.

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

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

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

=======

Тренинг «Быстрый старт в тестировании» (12 сентября), как явствует из его названия, предназначен в первую очередь для начинающих тестировщиков. Пригодится он и тем, кто уже не считает себя начинающим, но хочет навести порядок у себя в голове, систематизировав знания о тестировании. Я расскажу не очень глубоко, но буквально обо всём, так чтобы слушатели могли представить себе общую картину того, как устроена профессия тестировщика и понять, какие есть пути развития и совершенствования своей профессиональной подготовки.

Впрочем, не менее полезен этот тренинг и для тех, кто сам не занимается постоянно тестированием, но работает рядом с тестировщиками и по долгу службы вынужден общаться с ними, кто хочет понимать, чем они занимаются (или должны заниматься), то есть — менеджерам проектов и отделов, разработчикам, аналитикам.

Тренинги Натальи Руколь

=======

«Управление автоматизацией тестирования» (1 октября). Этот тренинг будет проводиться впервые. Его цель – помочь тест-менеджерам построить эффективную автоматизацию даже в случае, если Вы сами не являетесь продвинутым техническим специалистом. Мы расшифруем все те страшные слова, которыми обычно ругаются автоматизаторы-разработчики и поизучаем, как это устроено внутри, а главное – что с этим делать?? Как сделать автоматизацию не чем-то «для галочки», а полезной проектной активностью, которая позволяет экономить затраты ручных тестировщиков? В чём разница автоматизации в маленьких и больших командах? Как отбирать тесты? Как измерять их эффективность? К концу этого тренинга Вы самостоятельно развеете массу широкораспростренённых мифов, которые препятстсвуют результативному взаимодействию миров автоматизированного и ручного тестирования ;)

=======

«Управление командой тестировщиков» (2 октября). Это мой любимый тренинг :) Сейчас он полностью переработан и нашпигован секретной информацией тайных спецагентов тест-менеджмента. Этот тренинг – о людях, потому что тестировщики – это в первую очередь люди, и умение формировать команду мотивированных рыцарей-джедаев – самое важное, что Вы можете сделать для своего проекта :) На этом тренинге Вас ждут непрерывные упражнения в группах, которые позволят не просто узнать теорию, а прочувствовать все темы на практике! А тем, кто и так всё знает – понаблюдать за своим менеджментом со стороны и получить массу полезной обратной связи!

=======

«Тест-дизайн для менеджеров» (3 октября). Этот тренинг тоже существенно переработан на основании последних отзывов. Половину тренинга мы проведём, занимаясь коллективным творчеством и знакомясь с различными инструментами тест-дизайна, которые созданы для сокращения трудозатрат на тестирование в разы. Это будут основы, которые позволят Вам сориентироваться в существующих подходах к тест-дизайну и научиться выбирать оптимальные варианты. Помимо этого, мы уделим массу времени таким темам, как создание «работающего» тест-плана, формирование команды тест-дизайна, выбор подходящего инструментария. Внимание! Тренинг настолько насыщен мозговзрывающей информацией, что перед ним необходимо хорошенько выспаться! :)

default

JIRA as TCMS

У кого-нибудь есть опыт хранения тест кейсов, создание execution plan и треканья процесса выполнения тест кейсов в JIRA (истользование JIRA как TCMS)?
Заказчик на джиру молится, спит с ней, ест с ней, вобщем все хочет делать через джиру...

Ищем тестировщика веб-сервисов

Компании "Ройбер" www.roiber.ru нужен человек, который не может быть доволен жизнью, когда какой-то из наших проектов неидеален с точки зрения битых ссылок, корректной верстки в 5 броузерах, системных ошибок и всего другого, что не дает нашим любимым пользователям наслаждаться нашими сервисами.

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

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

Если вы хотите получить эту работу, то пришлите нам на адрес az@roiber.ru полный список багов, который вы нашли на каком-нибудь сайте и свое резюме.


Общие требования:
знание русского языка
умение слушать и слышать
доступ в Интернет 5 дней в неделю с шириной канала не менее 128 Кб/с (чтобы Skype работал)
умение общаться с коллегами
ответственность, исполнительность
умение обучаться
умение быстро, эффективно и качественно работать удаленно

А еще нужно очень любить свою работу и ее результат.

Общие условия:
удаленная работа, свободный график, постоянная работа в перспективе
адекватные менеджеры, проекты, заказчики, сроки и оплата
интересные коллеги
обучение и наставничество
перспектива постоянного роста
flash
  • kr_nik

Тестирование на проекте. Использование Test Complete.

Соучастники.
Прошу помощи в следующей ситуации.
Уже некоторое время работаю на проекте, где в мои обязанности в том числе входит наладка тестирования.
Купили Test Complete и решили сделать так: записать для каждого модуля разрабатываемого ПО функциональные тесты, которые будут моделировать действия пользователя.

Есть:
1. Отдел, который занимается постановкой ТЗ и тестированием ПО. Это не программисты и не тестировщики. Это люди, которые разрабатывают требования и тестируют созданный продукт.
2. Команда программистов, в отделе внедренцев - 3 человека (один из них - я).

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

Сложности/вопросы:
- нужно ли определить строгий порядок отработки скриптов по этим модулям?
- какой минимальный набор требований для запуска процесса?
- нужно ли знакомить руководство отдела с планом тестирования, в случае его написания?
- как вообще создать план тестирования? Какова должна быть его детализация - укрупнённый план / до конкретной операции, либо должно быть описано каждое нажатие кнопки, ввод в EditBox и т.д. При его создании ориентироваться нужно на модульность или на функционал. Т.е. в первую очередь тестировать модуль программы?
- Какие есть стандартные удобные методологии либо шаблоны для реализации тест-планов?
- После написания тест-проекта, который охватывает весь текущий функционал, его нужно запускать - ежедневно / раз в два дня ?
- Как вы обрабатываете ошибки, которые в логе Test Complete? Пересылаете лог разработчикам либо сами фильтруете лог, интерпретируете ошибку и описываете разработчику, что ему нужно сделать или оформляете в tfs баг с указанием время тестирования и копией части лога? Поделитесь опытом в этом вопросе пожалуйста. Т.е., каким образом происходит коммуникация с разработчиками?


Возможно, некоторые вопросы довольно расплывчаты, или уже обсуждались не раз но буду рад информации, основанной на опыте. Читал сайты, однако всё, что написано - не всегда понятно, как должно быть применимо. По ходу чтения возникают вопросы, ответов на которые нет.
Спасибо.
  • Current Music
    Glenn Miller
  • levgem

(no subject)

Интеграционные тесты — кому писать?

Я сейчас активно работаю с фреймворком Ruby on Rails. Помимо всего прочего, он предоставляет инфрастуктуру тестирования: юнит-тесты, функциональные и интеграционные.

Collapse )

Т.е. интеграционные тесты позволяют на достаточно понятном языке писать именно пользовательские ситуации: пользователь "user1" залогинился, пошел в админский интерфейс, зашел в раздел создания игр, создал игру, потом другой пользователь залогинился и пошел в эту игру.

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