Сообщений в теме: 16

[MissLeman]

Всем здравствуйте.

 

Есть вопрос по такой ситуации. Разрабатываем систему управления делопроизводством (если кто сталкивался с Lotus, то немножко похоже с т.з. пользователя). Система очень большая, всего много: есть права пользователей (причем они разные для разных сущностей), есть проекты, папки с проектами, папка с документацией, занесение времени, еще целая куча разного функционала. Соответственно, когда внедряется какая-либо new feature, то затрагивается многое из этого. И нередко при тестировании оказывается, что какую-то область (процесс, сущность... ) просто забыли протестировать, ну вот не вспомнили, что у нас еще вот такой функционал есть, и все.

 

Собственно, вопрос - как избежать такой ситуации обеспечить надежное покрытие тестами? Если кто тоже работает на проекте с такой сложной штукой, поделитесь, пожалуйста, как вы пишете тест-кейсы для NFT? И где тут у нас корень проблемы?
 

Немного деталей:

- в формальном виде требований нет, есть чек-листы и тест-кейсы (да и то не на все и написаны, на мой взгляд, плохо, рвано, неструктурированно), пользовательский хелп и некоторое количество документов на вики, а так все у тестеров в голове

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

 

Спасибо.

[Little_CJIOH]

Вопрос, а как у вас на проекте работают с требованиями?
http://lazy-tester.b.../2014/02/4.html

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

[Spock]

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

 

проблема что надо найти зависимости, которые неочевидны - и протестировать и фичу и зависимости

 

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

 

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

[Molechka]

Пополняйте ваши чек-листы, указывайте связи проектов.

 

Например:

 

=================================

Чек-лист на заполнение ворклогов.

 

1. Ворклог на 2 часа

2. На весь день (8ч)

3. На полчаса

4. На 10 минут

 

Права пользователей:

1. Админ

2. Юзер с правами А

3. С правами Б

...

=================================

 

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

Начните со своей документации

[Dalay_LAMO]

работа с требованиями не поможет когда изменения будут затрагивать другую часть системы, типа - поменял что-то в пользователе, а надо протестировать и права, и отчёт по пользователям, и ввод времени, и ЦРМ, и шаблон отправки емайл и ещё что-нибудь - всё в разных местах. в требованиях зависимости часто не указаны
 
проблема что надо найти зависимости, которые неочевидны - и протестировать и фичу и зависимости
 
наверное на этапе груминга можно сделать этап по поиску зависимостей. Разработчики, тестеры, ПО и аналитики обсуждают на какие ещё части системы могут повлиять конкретные изменения
 
и постепенно создавать базу знаний по зависимостям, типа "Пользователь: права, отчёт по пользователям, ввод времени". ну во всяком случае хорошая помощь новичкам

 
Согласен в целом. Только у меня есть сомнения в наличии аналитиков на данном проекте:
 

Немного деталей:
- в формальном виде требований нет, есть чек-листы и тест-кейсы (да и то не на все и написаны, на мой взгляд, плохо, рвано, неструктурированно), пользовательский хелп и некоторое количество документов на вики, а так все у тестеров в голове

Логично при запиливании фичи запрашивать у разработчика affected area. Проблема в том, что разработчики далеко не всегда способны грамотно описать (или даже понять) эту саму affected area - и часто получается 2 крайности: "проверить достаточно только это, больше ничего не трогал" и "стоит проверить всё, сломаться могло что угодно".
Ну и как выше правильно советовали - улучшать чек-листы, добавляя зависимости (после всплывших багов и после более глубокого анализа).
Чек-листы пишут все тестировщики? Есть ли перекрёстное ревью чек-листов?

[SALar]

Крайне рекомендую: Миф о документации, продолжение

 

 

Первое. «Учебников», то есть – документации, доступным языком излагающей устройство вашей системы, у вас не будет никогда. Мысль, что ее может написать !"№ не понимающий в предмете «технический писатель» - как минимум забавна. Примерно, как вера в Деда Мороза, или волшебника на голубом вертолете.

Второе. Если у вас в компании нет людей, способных прочитать лекцию по вопросам архитектуры – вам уже !"№;, и никакие гипотетические «учебники» вас не спасут. А если есть – то никакие «учебники» вам не нужны.

 

От себя добавлю. Как правило, на архитектуру забивают. И кончается это примерно как у вас описано.

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

Все остальные методы - это лейкопластырь при гангрене. Отваливаться может и не будет, но...

[MissLeman]

Огромное спасибо всем за ответы!

 

 

Вопрос, а как у вас на проекте работают с требованиями?
http://lazy-tester.b.../2014/02/4.html

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

Никак :( У нас, как правильно предположил г-н Dalay_Lamo, действительно нету аналитиков.

 

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

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

 

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

 

Спасибо

[MissLeman]

Крайне рекомендую: Миф о документации, продолжение

 

 

Первое. «Учебников», то есть – документации, доступным языком излагающей устройство вашей системы, у вас не будет никогда. Мысль, что ее может написать !"№ не понимающий в предмете «технический писатель» - как минимум забавна. Примерно, как вера в Деда Мороза, или волшебника на голубом вертолете.

Второе. Если у вас в компании нет людей, способных прочитать лекцию по вопросам архитектуры – вам уже !"№;, и никакие гипотетические «учебники» вас не спасут. А если есть – то никакие «учебники» вам не нужны.

 

От себя добавлю. Как правило, на архитектуру забивают. И кончается это примерно как у вас описано.

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

Все остальные методы - это лейкопластырь при гангрене. Отваливаться может и не будет, но...

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

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

[SALar]

 

Крайне рекомендую: Миф о документации, продолжение

 

 

Первое. «Учебников», то есть – документации, доступным языком излагающей устройство вашей системы, у вас не будет никогда. Мысль, что ее может написать !"№ не понимающий в предмете «технический писатель» - как минимум забавна. Примерно, как вера в Деда Мороза, или волшебника на голубом вертолете.

Второе. Если у вас в компании нет людей, способных прочитать лекцию по вопросам архитектуры – вам уже !"№;, и никакие гипотетические «учебники» вас не спасут. А если есть – то никакие «учебники» вам не нужны.

 

От себя добавлю. Как правило, на архитектуру забивают. И кончается это примерно как у вас описано.

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

Все остальные методы - это лейкопластырь при гангрене. Отваливаться может и не будет, но...

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

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

 

 

Отвечу еще раз. С первого раза почти ни до кого не доходит. Вот Little_CJIOH на мои семинары который раз приходит.

 

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

 

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

[Spock]

SALar

 

ну а что делать в сложившейся ситуации? да, как всегда, надо было раньше... но раньше никто не делает этого...

[Little_CJIOH]

SALar
 
ну а что делать в сложившейся ситуации? да, как всегда, надо было раньше... но раньше никто не делает этого...

Официально запускать проект по внедрению качества. С целью, пониманием текущего положения, сроками, метриками и ответственными.
Если качество никому не нужно, то что может сделать тестирование, кроме констатации факта отсутствия качества?

[MissLeman]

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

[SALar]

 

SALar
 
ну а что делать в сложившейся ситуации? да, как всегда, надо было раньше... но раньше никто не делает этого...

Официально запускать проект по внедрению качества. С целью, пониманием текущего положения, сроками, метриками и ответственными.
Если качество никому не нужно, то что может сделать тестирование, кроме констатации факта отсутствия качества?

 

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

 

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

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

 

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

 

Продолжим? Я имею в ввиду комьюнити. Кому-то поможет. Может быть.

2deadgrunt

 

но раньше никто не делает этого...

 

> - К черту торпеды! - заорал Заяц, вставая. - Вперед! Полный ход!

http://blog.shumoos.com/archives/330

 

 

ну а что делать в сложившейся ситуации? да, как всегда, надо было раньше...

 

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

В сложившейся ситуации нужно... А все равно это не на один пост.

Посмотрите: http://forum.mnogosd...c.php?f=4&t=287

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

 

PS. Коллеги. Я знаю, что память у комьюнити как у аквариумной рыбки. Вот даже Алексей Федоров не знал. Найдите "Тест Гринкевича". Там простая инструкция, написанная кровью. Неполная, но простая.

 

PSS. Ключом к изменениям, как я понял, является знание психологии.

[BadMF]

 

 

 

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

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

 

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

 

Продолжим? Я имею в ввиду комьюнити. Кому-то поможет. Может быть.

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

[MissLeman]

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

 

Моя забота - не продалбывать баги. Не какие-то там хитропопые, а исключительно такие, которые потом находишь и мучительно краснеешь, потому что ну кааак можно было об этом не подумать? Как можно было не вспомнить, что например документ Х еще записывается в лог Y? И мне нужны какие-то практики, которые позволили бы учитывать взаимосвязи и зависимости (не в коде! в логике пользовательского поведения!) нового функционала. Я примерно представляю, как можно сделать такую - схему? матрицу? чек-лист? - но чем изобретать велосипед, лучше спросить тех, кто тоже имеет такой опыт.

 

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

 

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

[BadMF]

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

 

Моя забота - не продалбывать баги. Не какие-то там хитропопые, а исключительно такие, которые потом находишь и мучительно краснеешь, потому что ну кааак можно было об этом не подумать? Как можно было не вспомнить, что например документ Х еще записывается в лог Y? И мне нужны какие-то практики, которые позволили бы учитывать взаимосвязи и зависимости (не в коде! в логике пользовательского поведения!) нового функционала. Я примерно представляю, как можно сделать такую - схему? матрицу? чек-лист? - но чем изобретать велосипед, лучше спросить тех, кто тоже имеет такой опыт.

 

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

 

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

 

Перечитал ваш первый пост (до этого не читал =) ). Нормально у вас всё, как у большинства не крупных компаний.

Я занимался покрытием тестами системы, которую никто до меня системно не тестировал в течении 10 лет. Тут главное начать.

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

2) Так же вам надо план на покрытие тестами на ближайшие 3-6 месяцев. 

 

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

Если работа не велась системно, то быстро вы не сможете ничего сделать. 

[leftCh]

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

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