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

Публикации Green

110 публикаций создано Green (учитываются публикации только с 29 марта 2023)



#69755 Выбор коммуникатора.

Отправлено автор: Green 12 августа 2009 - 16:45 в Тестирование защищенности

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

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



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

Отправлено автор: Green 31 мая 2009 - 18:31 в Обучение тестировщиков ПО

Коллеги!

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

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

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

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

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



#67851 Патент на название

Отправлено автор: Green 26 мая 2009 - 15:09 в Свободное общение

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


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

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

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



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

Отправлено автор: Green 20 мая 2009 - 07:37 в Управление тестированием

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

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

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

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

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

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

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

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

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



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

Отправлено автор: Green 17 апреля 2009 - 07:59 в Автоматизированное тестирование

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

Александр,

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

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


Александр,

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

Но!

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

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

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

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

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



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

Отправлено автор: Green 16 апреля 2009 - 16:28 в Автоматизированное тестирование

Александр,

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

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



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

Отправлено автор: Green 16 апреля 2009 - 14:30 в Автоматизированное тестирование

...
Но хочется отметить, что майкрософт не топчется на месте в отношении тестирования ...


Team System Developer Center имеет блок по автоматизации тестирования (функционального и нагрузочного) - Test Edition.
http://msdn.microsof...m/dd408381.aspx



#66469 Юбилейная 5-я конференция SQA Days

Отправлено автор: Green 02 апреля 2009 - 15:06 в SQA Days

Сорри за оф-топ.

Блин! И тоже вынужден отказаться по той же причине.
SQA - это хобби, а Интернет - это работа.

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


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



#66462 Юбилейная 5-я конференция SQA Days

Отправлено автор: Green 02 апреля 2009 - 10:46 в SQA Days

В связи с совпадением по датам с РИФ+КИБ вынужден отказаться от посещения конференции. Жаль.


Блин! И тоже вынужден отказаться по той же причине.
SQA - это хобби, а Интернет - это работа.



#66347 QA Аутсорс

Отправлено автор: Green 28 марта 2009 - 18:44 в Управление тестированием

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

P.S.:Проект небольшой - но амбициозный :)



Вопрос, сформулированный таким образом, наводит на мысль, что Вы не сильно разбираетесь в аутсорсинге, а тем более в тестировании. (Сорри, мое личное предположение.)

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

Мое предложение такое.

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



#66062 В чем специфика Context-Driven подхода именно в тестировании?

Отправлено автор: Green 18 марта 2009 - 18:40 в Управление тестированием

Коллеги,

может показаться, что те, кто ратует за CDT - это прогрессивные ребята, а я - ретроград и тормоз прогресса. :diablo:
Но я совсем и не против CDT. Я даже за него. И давно пользовался такими приемами. Вот только не знал, что они так называются.

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



#66059 В чем специфика Context-Driven подхода именно в тестировании?

Отправлено автор: Green 18 марта 2009 - 17:08 в Управление тестированием

Странно. А как же тогда использование CDT в процессной методологии разработки, построенной на базе RUP?

Это невозможно. Я думаю нельзя натянуть CDT на какую-то методологию, потому что методология это не контекст. Методология это то, что уже натянуто на контекст.


Теперь настала моя очередь "тыкать пальцем в книжку". В приводимых выше ссылках у Канера есть раздел, посвященный CDT для RUP и других методологий.
:diablo:


Нашли кого слушать! Консультантов, которые этим зарабатывают деньги.

Хм. А кого слушать? Вас что ли? :) Нет, действительно интересно, чье мнение может быть для вас авторитетно? Только чтобы это был не консультант и не придумавший свою школу\религию.


А хотя бы и меня.
:blush:



#66020 В чем специфика Context-Driven подхода именно в тестировании?

Отправлено автор: Green 17 марта 2009 - 18:55 в Управление тестированием

Другими словами, context-driven testing - это очень просто. Прежде чем начать тестирование, следует спросить закзаичка о том, что он считает наиболее важным в релизе и скорректировать тест-план в зависимости от полученного ответа.

Сергей, читаем внимательно всё по вышеприведённым ссылкам :)

Это в точности соответствует подходу, который назван там context-aware: "... some people create standards, like IEEE Standard 829 for test documentation, because they think that it is useful to have a standard to lay out what is generally the right thing to do. This is not unusual, nor disreputable, but it is not context-driven. Standard 829 starts with a vision of good documentation and encourages the tester to modify what is created based on the needs of the stakeholders. Context-driven testing starts with the requirements of the stakeholders and the practical constraints and opportunities of the project. To the context-driven tester, the standard provides implementation-level suggestions rather than prescriptions."

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


Странно. А как же тогда использование CDT в процессной методологии разработки, построенной на базе RUP? Куда ж там тест-план делся?


Ребята,
вы иногда бываете такими наивными. :blush:

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

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

Но,
прошу обратить внимание. Я не говорю, что это плохо! Просто это не настолько хорошо или координально, как это пытаются преподнести.



#65984 В чем специфика Context-Driven подхода именно в тестировании?

Отправлено автор: Green 17 марта 2009 - 07:08 в Управление тестированием

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


Леша,
это ты, пожалуй, загнул.
:blush:

Согласно тому же Канеру CDT не является методологией и применим в рамках любого подхода тестирования. Так что о "новой школе" речь уж точно не идет. Да и против привычных техник он так же не выступает.



#65983 В чем специфика Context-Driven подхода именно в тестировании?

Отправлено автор: Green 17 марта 2009 - 07:02 в Управление тестированием

Коллеги,

вопрос очень интересный. И он меня занимает уже давно (как вы могли заметить по другим дискуссиям :blush: ).
Поэтому хочу поделиться своим видением вопроса.

Процессная методология разработки программ (и тестирования, как ее составная часть) родилась в ответ на попытку создать из разработки ПО конвеерное производство: сделать его планомерным, более предсказуемым, менее рискованным видом деятельности. В этом подходе доминирует позиция производителя. Заказчик и исполнитель договорились, спланировали работу, приступили к реализации в соответствие с принятым и утвержденным планом. Если появляются изменения и корректировки в ходе проекта, то процесс планирования начинается поновой: оценка изменений, корректировка плана, бюджета и т.д. В результате такого подхода, существенные изменения проекта равнозначны старту нового проекта и нового бюджет, соответственно. А как быть с уже потраченными средствами?

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

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

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

Другими словами, context-driven testing - это очень просто. Прежде чем начать тестирование, следует спросить заказчика о том, что он считает наиболее важным в релизе и скорректировать тест-план в зависимости от полученного ответа.



#65869 Новая статья: Антоним тестирования

Отправлено автор: Green 12 марта 2009 - 12:31 в Портал Software-Testing.Ru

Так все же речь идет о валидации или верификации?
Это вопрос риторический. На него отвечать не нужно.
:crazy:

Может и риторический, но уводящий в сторону.

Помнится, мы его уже весьма бурно обсуждали на форуме:
http://software-test...p?showtopic=771
http://software-test...p?showtopic=979

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


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



#65868 Что с переводом глоссария ISTQB получилось?

Отправлено автор: Green 12 марта 2009 - 12:27 в DrQuality.ru

есть ли у вас план товарищ Alfa? :)

Не понял. Какой план имеется ввиду?


план как закончить данный процесс с нужным результатом, правда вопрос скорее всего к Green


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

Ни от кого ответа пока не получил.
Либо все заняты, либо...



#65840 Новая статья: Антоним тестирования

Отправлено автор: Green 11 марта 2009 - 13:09 в Портал Software-Testing.Ru

Сейчас наш диалог выглядит примерно так:
- Автор: бла-бла-бла
- Я: моя позиция заключается в следующем - бла-бла-бла
- Оппоненты: ну ты, блин, не прав. Вот, почитай здесь (ссылка), здесь (ссылка), а вот еще здесь (ссылка).
- Я: объясняю свою позицию по другому - бла-бла-бла
- Оппоненты: ну ты, блин, не прав. Ты хочешь опорочить светлое имя нашего Учителя. Почитай его труды здесь (ссылка) и здесь (ссылка).
:smile:

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

:focus:


:smile:



#65833 Новая статья: Антоним тестирования

Отправлено автор: Green 11 марта 2009 - 09:49 в Портал Software-Testing.Ru

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

...

Так вот действия, которые предпринимает разработчик ни есть ни валидация, ни тестирование. А действия тестировщика вы можете назвать и валидацией, и тестированием. Это уже кому как нравится.

Сергей, прямо в тексте статьи стоит ссылка на википедию, которая поясняет, что именно автор имел в виду под валидацией: http://en.wikipedia....tion_(software)

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


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

Пользуйтесь своей головой и своими словами, что бы донести СВОИ мысли, а не тыкайте пальцем в книжку, ссылаясь на чужие мнения.

Сейчас наш диалог выглядит примерно так:
- Автор: бла-бла-бла
- Я: моя позиция заключается в следующем - бла-бла-бла
- Оппоненты: ну ты, блин, не прав. Вот, почитай здесь (ссылка), здесь (ссылка), а вот еще здесь (ссылка).
- Я: объясняю свою позицию по другому - бла-бла-бла
- Оппоненты: ну ты, блин, не прав. Ты хочешь опорочить светлое имя нашего Учителя. Почитай его труды здесь (ссылка) и здесь (ссылка).
:smile:

Не цепляйтесь за слова. Зрите в корень, как говорил Кузьма Прутков.

Если уж на то пошло, то в статье (перевод) есть такая фраза:
"...что тестирование это деятельность по валидации, что целью тестирования является проверка того, что программа соответствует спецификациям..."

Теперь читаем ссылочное определение:
"Verification: The process of determining that a computer model, simulation, or federation of models and simulations implementations and their associated data accurately represents the developer's conceptual description and specifications."

Так все же речь идет о валидации или верификации?
Это вопрос риторический. На него отвечать не нужно.
:smile:



#65828 Новая статья: Антоним тестирования

Отправлено автор: Green 11 марта 2009 - 07:40 в Портал Software-Testing.Ru

... слепую ярость...


Хорошее название для фильма, но плохой аргумент в обсуждении.
:smile:

Вроде там понятно написано:
Валидация - деятельность, нацеленная на попытки доказательства корректности программы.
Тестирование - исследование программы и донесение информации о тех или иных аспектах качества до лиц, принимающих решения.
Методами валидации не получится исследовать систему. Валидация != тестирование, но это и не взаимоисключающие вещи и сравнивать их как минимум бестолково.


Валидация и тестирование - это набор задач (действий). Если они !=, но и не взаимоисключающие, то они имеют пересечение (если их представить в виде областей на плоскости). Значит какие-то задачи у них совпадают, а какие-то нет. Вот именно перечень не совпадающих задач я и хотел получить.
Это риторический вопрос. На него можно не отвечать.
:focus:


Автор (и Вы за ним) проводит противопоставление двух понятий: валидация и тестирование. Основанием для этого является заявление о том, что набор действий, скрывающихся за этими терминами - служат разным целям.

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

Мой любимый пример.
При проверке программы разработчик ставит перед собой цель, убедиться в том, что написанный им код - работает. И он убеждается в этом.
Тестировщик же ставит перед собой цель, убедиться в том, что проверенный разработчиком код, не работает. И убеждается в правильности своего предположения.

Так вот действия, которые предпринимает разработчик ни есть ни валидация, ни тестирование. А действия тестировщика вы можете назвать и валидацией, и тестированием. Это уже кому как нравится.

По поводу "что такого делает автор" я уже давал ссылку, далее можно копать блоги Канера, Баха, их книжку Lessons Learned in Software Testing (только на английском). По теме risk-based testing есть книжка Pragmatic Software testing от Рекса Блэка. Правда, все это на английском языке.


Первую почитывал (даже в оригинале :smile: ) ... лет 6-7 назад. Видимо, забыл уже.
К тому же, отсылка к чужому мнению не есть изложение собственных представлений.
:dirol:



#65812 Новая статья: Антоним тестирования

Отправлено автор: Green 10 марта 2009 - 14:13 в Портал Software-Testing.Ru

Сергей, я прям таки удивлён столь категоричной реакцией. Видимо действительно трудно понять приверженцев "чужой" школы, сторонников другой парадигмы.
...


Алексей,
большое спасибо. Ты да же не догадываешься, как ты прав.

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

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

Заранее благодарю.



#65758 Что с переводом глоссария ISTQB получилось?

Отправлено автор: Green 07 марта 2009 - 19:29 в DrQuality.ru

Коллеги,

два сообщения.

1. Выложил таблицу на майкрософтовский сервис. Всем участникам разослал сообщение и открыл доступ.
Что понравилось - наличие версионности и прямой доступ в файловое хранилище через проводник.

2. Я решил не раздавать всем желающим не законченный перевод.
Давайте закончим работу!



#65755 Новая статья: Антоним тестирования

Отправлено автор: Green 07 марта 2009 - 13:02 в Портал Software-Testing.Ru

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

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

У меня точно не было. Всегда приходилось жестко планировать работу, выбирать между первостепенным и второстепенным, между тем что оставить в работе, а что отбросить или отложить. На основании чего можно делать такие выводы? Я полагаю, на основании четкого структурированного подхода: спецификация, требования, критерии, сроки и т.п. Даю 100% - свой отчет о проделанной работе автор формулирует именно в таких терминах.

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

Но!

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

Однако, когда это преподносится мне как откровение свыше, то я вспоминаю историю с борьбой сторонников процессных и быстрых методологий в разработке (историю см выше).



#65754 Что с переводом глоссария ISTQB получилось?

Отправлено автор: Green 07 марта 2009 - 12:46 в DrQuality.ru

Кстати, это не работает фича по публикации для коллективного доступа.
Но фича по расшариванию и коллективной работе над документом - работает.

Просто для доступа нужен Гугловский экаунт.

Механизм прост:
1. Заходите в гугловский экаунт или в почтовик Gmail.
2. Слева вверху есть ряд линков - жмете на Documents
- открываются Гугл Докс и вы там видите нужный файл и полным доступом на редактирование.

Кто подписывался на файл с НЕ гугловского ящика, можете выслать мне гугловский - я расшарю для вас документ по новой.

P.S.
В личных сообщениях форума не нашел фичу по добавлению файла в сообщение.



#65753 Что с переводом глоссария ISTQB получилось?

Отправлено автор: Green 07 марта 2009 - 12:39 в DrQuality.ru

Да, получилось экселевским файлом сделать.
Вышлю.

Только слишком сырой пока словарик.
Будем доделывать!

Ищу альтернативу гуловским докам.
Посмотрю на майкрософт.