Публикации YuP

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

По типу контента

По пользователю

Вперед

Сортировать

Порядок

#57726 Открыта вакансия инженера по качеству ПО

Отправлено автор: YuP 25 июня 2008 - 11:22 в Работа/Санкт-Петербург

ООО "Специальный технологический центр".

На должность ИНЖЕНЕРА ПО КАЧЕСТВУ ПО требуется сотрудник, обладающий следующими качествами:
- Опыт работы в сфере производства ПО от 1 года - разработка, тестирование, документирование, реализация.
- Свободное владение ОС Windows, Linux - установка, архивирование/восстановление, администрирование основных функций.
- Знание основных аспектов tcp/ip и СУБД (MS SQL Server, Interbase)
- Знакомство с инструментами коллективной разработки: cvs, svn, Mantis, TrackStudio или др.
- Уверенное знание компьютерного железа - умение разобрать его и при необходимости собрать.
- Пунктуальность, способность периодически выполнять рутинную работу.
- Способность к обучению в новых для себя областях знаний.
- Высшее техническое образование.

Существенным преимуществом является опыт тестирования ПО и знание основ распространения радиоволн.

Должностные обязанности:
- Проектирование и разработка тестов.
- Настройка тестовых конфигураций: установка ПО, коммутация оборудования.
- Тестирование ПО на платформах Windows и Linux.
- Написание отчетов по результатам тестирования.
- Общение с разработчиками для уточнения места дефектов.

Условия работы:
- Зарплата от 35 тыс.р. Белая.
- Отпуск 1 месяц. Летом.
- Бесплатное питание.
- Медицинская страховка.

О компании:
Компания разрабатывает и производит радиотехническое оборудование.

Резюме отправлять на e-mail: ntc_tks@mail.ru.
Для уточнения информации по вакансии обращаться: ICQ 247374222, ntc_tks@mail.ru

#51738 Методология для исследовательских работ

Отправлено автор: YuP 22 января 2008 - 21:43 в QA: обеспечение качества

Спасибо за столь подробный ответ.

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

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

Еще раз спасибо.

#51685 Методология для исследовательских работ

Отправлено автор: YuP 21 января 2008 - 10:50 в QA: обеспечение качества

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

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

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

А вот какой подход использовать для организации стадии исследований и разработки макетов?

#50768 Повторное тестирование старой версии программы

Отправлено автор: YuP 19 декабря 2007 - 09:17 в Управление тестированием

YuP,
Скажите честно, вам нужен тест план?
или
Нужно объяснить заказчику куда уходят деньги?
или
что-то другое?

Отвечаю честно. Меня в данном случае интересует чисто формальная теория, для общего развития. Обосновать заказчику место, куда уходят деньги - не проблема :). И с тест-планами тоже вопросов нет. Почти ;).

Просто сначала показалось, что при тестировании совместимости с новым окружением уже выпущенного релиза нарушается установленный цикл разработки софта. Теперь все вернулось на круги своя. Я так понял, что рассматриваемое тестирование нельзя отнести ни к предыдущей версии продукта, ни к следующей. Это отдельная исследовательская активность, по результатам которой могут быть сформированы новые требования к следующей версии: "Реализовать поддержку такого-то оборудования..".

#50743 Повторное тестирование старой версии программы

Отправлено автор: YuP 18 декабря 2007 - 20:05 в Управление тестированием

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

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

2 Case. Действительно, можно сказать, что начинается цикл разработки опять с требований. Они изменились: теперь добавлено требование по поддежке нового оборудования. Мне вот только кажется странной возможность следующей ситуации: требования к новой версии сформулированы, а сама новая версия не появится, т.к. прежняя версия, оказалось, этим требованям удовлетворяет. За что заказчик платить должен? :) Второй раз за одну и ту же версию?

#50661 Повторное тестирование старой версии программы

Отправлено автор: YuP 17 декабря 2007 - 22:06 в Управление тестированием

Расскажите поподробнее. Какого рода программа? Какая у нее у функциональность? Какие были объемы тестирования в чел*часах? Имеются ли выделенные регрессионные тесты? Автоматизированные это тесты или ручные?

А как зовут тестировщицу и ее телефончик не надо сообщить? :acute:

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

Какие черные ящики :good:

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

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

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

#50660 Повторное тестирование старой версии программы

Отправлено автор: YuP 17 декабря 2007 - 21:34 в Управление тестированием

Добрый день.

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

Будут новые баги, значит их надо будет фиксить, будут новые выводы - значит их надо будет принимать к сведению.

По-моему все достаточно прозрачно.

Спасибо.

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

Но мне кажется, что по своей сути такое тестирование можно выделить в отдельный вид :good:

. Т.к. в отличие от других видов оно выполняется не после стадии разработки, (когда версия-претендент на релиз либо становится релизом, либо отдается программерам на ремонт), а перед разработкой следующей версии приложения. Релиз уже состоялся, програма работает у клиентов и менять предыдущую версию x.y.z на новую с таким же номером конечно никто не будет. А по результатам тестирования в лучшем случае новая версия выпущена не будет - если проблем с новой техникой не возникнет, а в худшем новая версия появится. Причем ее функциональность останется без изменений, а только будут исправлены ошибки совместимости с новым оборудованием.
Такое тестирование как бы изначально уже принадлежит следующей версии программы, с него начинается разработка новой версии (точнее, может начаться). Рассматриваемое тестирование инициирует разработку, определяя новые задачи программистам, оно направлено на формирование требований к программе, которые необходимо будет реализвать в ходе стадии разработки, а потом проверить реализацию на завершающей стадии тестирования и исправления багов.
Как видим, в данном случае меняется общий цикл разработки софта. Здесь он начинается с тестирования и заканчивается тестрованием :lol:

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

Что скажете?

#50627 Повторное тестирование старой версии программы

Отправлено автор: YuP 17 декабря 2007 - 09:55 в Управление тестированием

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

Но появилось новое оборудование, которое так же, как и старое должно корректно поддерживаться программой.

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

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

#48857 Академия Информационных Систем еще существует?

Отправлено автор: YuP 12 ноября 2007 - 21:27 в Обучение тестировщиков ПО

Хорошо. Тогда продолжим попытки контакта :).

#48808 Академия Информационных Систем еще существует?

Отправлено автор: YuP 10 ноября 2007 - 16:31 в Обучение тестировщиков ПО

АИС продолжает еще работать или больше ее нет?
А то на е-мэйлы они не отвечают уже пару месяцев.. На сайте расписание курсов пустое, последние новости датируются маем.

Неужели закрылись..

#48072 Выбор средства управления процессом тестирования (Test management

Отправлено автор: YuP 25 октября 2007 - 14:13 в Инструменты управления тестированием ПО

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

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

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

#47957 Наборы данных для тестов

Отправлено автор: YuP 23 октября 2007 - 12:56 в Управление тестированием

Вам действительно непонятно, или Вы шутите?

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

#47947 Наборы данных для тестов

Отправлено автор: YuP 23 октября 2007 - 12:22 в Управление тестированием

Можно, но неудобно, т.к.
1) Сколько наборов данных, столько шагов надо добавлять в тест. А при изменении количества редактировать тест.
2) Тест и так из нескольких шагов состоит. Поэтому не получится отметить, что произошла ошибка, скажем, на третьем шаге для второго набора данных.

#47943 Выбор средства управления процессом тестирования (Test management

Отправлено автор: YuP 23 октября 2007 - 11:55 в Инструменты управления тестированием ПО

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

Версионность требований нужна - но совсем не потому что это живой документ :)

Скорее не только потому, что это живой документ :)

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

Пример.
Есть 2 параллельные ветви разработки одного и того же продукта. Разошлись они совсем недавно из-за отличий в тонкостях ТЗ для двух разных заказчиков. Со временем ветви обязательно объединятся. Тест определенной функциональности немного отличается в деталях для одной ветви относительно другой. Мало того, сначала это был один тест, а теперь необходимо вести две его ветви. Можно бы сделать 2 теста - каждый на свою версию тестируемого приложения. Но т.к. отличия минимальны, а сам тест достаточно объемен, то удобнее вести 2 параллельные версии одного теста.

Вот другой аспект применения версионности тестов.

#47924 Наборы данных для тестов

Отправлено автор: YuP 23 октября 2007 - 09:44 в Управление тестированием

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

#47917 Выбор средства управления процессом тестирования (Test management

Отправлено автор: YuP 23 октября 2007 - 08:08 в Инструменты управления тестированием ПО

Изначально тест полный - использовался первый из двух способов открытия Окна1. И остался полным - тестировщик решил использовать второй путь.

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

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

#47914 Наборы данных для тестов

Отправлено автор: YuP 23 октября 2007 - 07:54 в Управление тестированием

:) Хотел попроще написать.. Попробую еще раз.

Это все значит вот что:
Ручное тестирование.
Имеется один тест, состоящий из 10 шагов. Название теста "Тест1".
Тест "Тест1" необходимо выполнить на 2 наборах данных. На шаге 1 используется параметр №1 из текущего набора данных, на шаге 2 - параметр "2, и т.д.
"Тест1" включен в единственный скрипт или набор тестов "ТестСкрипт1".

Появляется новый билд тестируемой программы.

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

А мне логичным представляется, чтобы система отобразила "Тест1" два раза - первый раз со ссылкой на набор данных №1, второй раз - на набор данных №2. Соответственно тестировщик может для первого набора данных выбрать результат "Успех", а для второго "Провал".

Так понятнее?

#47904 Наборы данных для тестов

Отправлено автор: YuP 22 октября 2007 - 20:02 в Управление тестированием

Хочется вот чего.. Запускаем тестирование. Появляется перед глазами Тест1 с Набором_данных1. Проверили, нажали "Pass". Открывается Тест1 и Набор_Данных2. Проверили, оказалось "Faild".

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

#47903 Выбор средства управления процессом тестирования (Test management

Отправлено автор: YuP 22 октября 2007 - 19:55 в Инструменты управления тестированием ПО

С таким тестом - да, согласен, версионность не очень нужна, результат говорит о многом.

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

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

#47899 Наборы данных для тестов

Отправлено автор: YuP 22 октября 2007 - 18:47 в Управление тестированием

Как и многие присутствующие выбираю систему управления процессом тестирования :). Пересмотрел уже большое их количество.. На 100 подходящей, да что там, хотя бы на 75% пока не нашел.

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

Расскажите, как обойтись одним только описанием теста, без ссылки на набор данных. Ну неужели копировать тест столько раз, сколько есть наборов?

#47898 Выбор средства управления процессом тестирования (Test management

Отправлено автор: YuP 22 октября 2007 - 18:34 в Инструменты управления тестированием ПО

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

#47897 Выбор средства управления процессом тестирования (Test management

Отправлено автор: YuP 22 октября 2007 - 18:31 в Инструменты управления тестированием ПО

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

#47848 Тестирование, конфликт, стресс -> разрушение личности

Отправлено автор: YuP 20 октября 2007 - 06:02 в Управление тестированием

Вы знаете.. внимательно следил за дискуссией, и не понял одного: у вас команда или нет?

Следил-следил и не выдержал, решил написать :dance:

...

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

. Можно перенести эту логику и на команду. atermath, постарайтесь осознать это и переключиться с моего ЧАСТНОГО примера на более высокий уровень абстракции. Если вы занимаетесь тестированием, то не могли не испытать радости от виртуозно сломанной программы или от обнаружения архитектурной ошибки в системе :smile:

. Где тут созидание?

Тестирование, как армия - направлено на созидание, но выражается в разрушении. :acute:

#47842 Тестирование, конфликт, стресс -> разрушение личности

Отправлено автор: YuP 19 октября 2007 - 14:17 в Управление тестированием

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

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

#47841 Тестирование, конфликт, стресс -> разрушение личности

Отправлено автор: YuP 19 октября 2007 - 14:08 в Управление тестированием

rlabs и greyver, спасибо за комментарии :acute:

.

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

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

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

Вперед

Реклама на портале