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

Школа тест-менеджеров v. 2.0
онлайн, начало 16 октября
Школа для начинающих тестировщиков
онлайн, начало 17 октября
Python для начинающих
онлайн, начало 16 октября
Организация автоматизированного тестирования
онлайн, начало 18 октября

Green

Регистрация: 12 дек 2006
Offline Активность: 28 окт 2012 08:40
-----

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

В теме: Выбор коммуникатора.

12 Август 2009 - 16:45

1C-Битрикс: Корпоративный портал

Если есть вопросы, то готов пообщаться более предметно.
Предварительно можно посмотреть на www.bitrix.ru

В теме: Отечественная программа сертификации SQA и QA инженеров

31 Май 2009 - 18:31

Коллеги!

Несколько примитивный подход. Что значит - а давайте забацаем!? Это как-то смахивает на пионерский энтузиазм типа, а давайте бабушку переведем через дорогу? А потом оказывается, что это не наша старуха!

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

Вот вам первый вопрос.
Кто будет платить за сертификцию?
Тестировщики? Компании?

Второй вопрос.
Что будет побуждать их выкладывать деньги?
Почему они будут выкладывать пару тысяч рублей за сертификацию?
(Кстати, сколько тысяч будет стоить эта процедура?)

И третий.
Чем эта сертификация отличается от существующих и чем она лучше высшего образования?

В теме: Патент на название

26 Май 2009 - 15:09

Читал сегодня журнал один и там была реклама от MS. Внизу рекламы ссылка на сайт - microsoft4business.ru)) Вячеслав, не было мысли закрепить за собой имя сайта или часть его, чтобы другим не повадно было копировать?:)


Единственный способ воспрепятствовать регистрации какого-нибудь домена в Интернете - зарегистрировать его на себя.

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

Других ограничений на копирование ЧАСТИ названия домена нет.

В теме: как поднять процессы в компании с точки зрения качества и тестирования

20 Май 2009 - 07:37

Почитал я эту ветку... и даже написать нечего. Уже все написано выше. Значит, буду критиковать.
:aggressive:

Во-первых, Haul, видно, что знаний и опыта у вас в этой области нет. Зачем брались за эту работу? Но это вопрос риторический.

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

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

Кто виноват?
Виноваты конечно Вы. Если бы у Вас было больше опыта или был больший выбор, то Вы бы не оказались в этой ситуации.

Что делать?
1. Снять с себя миссию спасителя.
2. Четко ограничить рамки своей компетенции. Начать с точки приема программы в тестирование и закончить точкой выдачи результатов тестирования. Все что внутри - Ваше, что снаружи - на кого бог пошлет.
3. Определить, какой именно результат должна выдать группа тестирования по итогам тестирования (что будет написано в отчете).
4. Определить, что потребовать от разработчиков до начала тестирования программы (какую информацию они должны представить, в каком виде и что сделать), а так же чем грозит продукту не выполнение каждого из требований.
5. Определить, что должно быть сделано остальными по результатам тестирования и как это проверить/подтвердить.
6. "Выбить" из начальства санкции за не выполнение требований приемки/передачи продукта в тестирование.
7. Определить, что именно, в каком порядке и каким образом будет тестироваться (и в таком порядке результаты отмечать в отчете о тестировании).

Для начала этого хватит.

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

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

В теме: Автоматизировать тестирование с помощью Microsoft Team System, как это

17 Апрель 2009 - 07:59

Почерпнул из практики нашей компании :clapping:

Александр,

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

Вы эти данные где-то почерпнули или это Ваши собственные наблюдения?


Александр,

на мой субъективный взгляд, Ваши графики соответствуют действительности только на стадии прогонки тестов. Тогда ручное выполнение действительно "берет" больше времени чем автоматизированное. И, действительно, чем больше тестов, тем выигрыш во времени больше.

Но!

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

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

Но и в ней (перспективе) тоже не все так однозначно.

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

Так что я бы не стал приводить столь спорные графики без должного статистического анализа.

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