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

Программирование на Java для тестировщиков
онлайн, начало 17 июля
Практикум по тест-дизайну 2.0
онлайн, начало 17 июля
Первый Онлайн ИНститут Тестировщиков
онлайн, начало 20 июля
Selenium WebDriver: полное руководство
онлайн, начало 24 июля

brontozjabr

Регистрация: 14 дек 2010
Offline Активность: 24 июл 2019 11:09
-----

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

В теме: Процесс найма сотрудника со стороны работодателя

19 апреля 2012 - 10:23

И вот тут еще помимо отличного материала есть очень хорошие ссылки: Собеседование, как тестирование черного ящика

Спасибо за ссылку, хороший материал.

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

Когда я был в поисках работы, то многие компании (не думаю, что у них высокий конкурс, т.к. про них я порой вообще ничего не знал) так и поступали - сначала высылают тестовое задание, если провалено, то делали отписку "Удачи" и т.п.

Учитесь работать с резюме. Ну и само по себе задание типа "поискать ошибки в программе" бестолковое.

Вы предлагаете приглашать всех откликнувшихся на собеседование? Ок! А как мне выявить их компетенцию? Ну поработаю я с рюземе, почитаю о их достижениях и умениях. Дальше что? Как экзаменатор в университете пытать людей, задавая вопросы "Что это такое? Дай определение вот этому", "Как это делается?"... Или "Вы умеете это делать?". "Отлично, тогда мы Вас берем!" А как мне удостовериться, что он умеет это делать на самом деле?

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

Поправляйте меня, если что не так.


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

Хотела вам предложить прочитать интересную статейку в журнале Testing Planet (issue 6) про практический опыт собеседования тестировщиков, автор описывает, как собеседовал одновременно несколько человек. Вдруг поможет.
Если не хочется искать номер в интернетах, давайте email, могу прислать.

В теме: Тестирование как сервис, предоставляющий услуги всем группам разработк

19 апреля 2012 - 10:12

В продолжение семинара 14 апреля статья о производственных потоках: http://habrahabr.ru/post/139194/

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


Минусы вроде как понятны, но возник вопрос по поводу вашего подхода к решению проблемы, возникающей при следующих условиях:
-на каждый проект должна выделяться своя команды тестирования
-есть несколько проектов, скорость разработки и нагрузка значительно различаются и на каком-то из них двум тестировщикам сложно справляться, а на некоторых один будет не особо сильно нагружен
-руководство не может/не хочет нанимать столько специалистов, чтобы каждый проект получил достаточное их количество для работы без "превышения трафика" через команду тестирования
В итоге наступает момент, когда в одном проекте почти полное затишье (если в этом проекте занимаются поддержкой существующих продуктов и очень редко выкатывают что-то новое), а в другом, где нужно немедленно, как обычно хотят этого менеджеры, выйти на рынок или просто удовлетворить срочно заказчика - нужны дополнительные пары рук и глаз. Приходится утягивать эти свободные руки с медленных проектов (если они, конечно, будут) + вводить в курс дела (дополнительные временные затраты). В таком случае напрашивается такая организация процесса, когда есть единая команда тестирования и уже из неё для каждого проекта забираются люди в необходимом количестве и желательно чтобы каждый хотя бы по разу поработал с каждым проектом.
Попытались бы вы решить проблемы, оставляя обязательно каждому проекту свою команду тестирования?

В теме: Средства коммуникации отдела разработки и отдела тестирования

28 февраля 2012 - 08:51

У нас используется Redmine, который помогает решать все перечисленные задачи.
Разделение на команды можно организовать в виде отдельных проектов (у нас есть отдельный проект Приёмка и тестирование), а можно просто передавать внутри одного проекта задачи между разработчиками и тестировщиками.
Уведомление по email настраивается. И опять же есть возможность проставлять оценки отдельным задачам.

В теме: ваша должность в трудовой книжке

13 декабря 2011 - 10:40

Программист.

В теме: Знаем про проблему, но не чиним

11 июля 2011 - 15:08

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


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

Яндекс.Метрика
Реклама на портале