Проблемы с регрессивным тестирование

В компании я единственный тестировщик, самый что ни на есть джуниор первого левела.
Дали мне тестировать проект, который находится на стадии завершения.
Тест-кейсы не писал, на это просто нет времени. Только ручное тестирование, не более.
Дотестировал его до такого состояния что очень трудно найти новый баг. Вобщем ПОЧТИ готов к live.
Но тут заказчик попросил добавить пару новых фич, их добавили и ...., посыпались такие баги и в таких местах где их никогда и не было.
А вопрос в следующем, как можно исправить ситуацию не имея тест кейсов? Если только повторным ручным тестирование всего проекта, то как избежать подобных ситуаций в будущем?

В компании я единственный тестировщик, самый что ни на есть джуниор первого левела.
Дали мне тестировать проект, который находится на стадии завершения.
Тест-кейсы не писал, на это просто нет времени. Только ручное тестирование, не более.
Дотестировал его до такого состояния что очень трудно найти новый баг. Вобщем ПОЧТИ готов к live.
Но тут заказчик попросил добавить пару новых фич, их добавили и ...., посыпались такие баги и в таких местах где их никогда и не было.
А вопрос в следующем, как можно исправить ситуацию не имея тест кейсов? Если только повторным ручным тестирование всего проекта, то как избежать подобных ситуаций в будущем?

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

В компании я единственный тестировщик, самый что ни на есть джуниор первого левела.
Дали мне тестировать проект, который находится на стадии завершения.
Тест-кейсы не писал, на это просто нет времени. Только ручное тестирование, не более.
Дотестировал его до такого состояния что очень трудно найти новый баг. Вобщем ПОЧТИ готов к live.
Но тут заказчик попросил добавить пару новых фич, их добавили и ...., посыпались такие баги и в таких местах где их никогда и не было.
А вопрос в следующем, как можно исправить ситуацию не имея тест кейсов? Если только повторным ручным тестирование всего проекта, то как избежать подобных ситуаций в будущем?

1. Дружить с программистами. Чтоб знать- что меняли.
При этом полезно представлять архитектуру ПО.
Потому как программисты тож могут забыть - что там наулучшали, и что при этом могло сломаться(((.
2. Ну тест-кейсы Вас бы и не спасли ))). Так что не переживайте.
3. Еще несколько релизов, и нюхом будете чувствовать, что могло сломаться))).

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

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

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

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

Это лишь один из возможных вариантов.

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

Это лишь один из возможных вариантов.

А другие какие?

как можно исправить ситуацию не имея тест кейсов?

Чек-лист.

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

Это лишь один из возможных вариантов.

А другие какие?

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

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

ЗЫ: Overquoting FTW

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

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

ЗЫ: Overquoting FTW

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

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

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

PS. Участковый терапевт лечит согласно схеме. В схеме и прописано - какие антибиотики больному выписать )))

А я и не писал, что если не могут ответить, то это хорошо. Это плохо, только вопрос в том, где оно плохо. Не факт что в архитектуре.

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

а это есть нормально, привыкайте.)

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

в вашем случае - да только повторным.


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

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

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


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

и второй вопрос - какой проект? с чем работаете?

Вы вообще не писали ничего по всему проекту?
никаких записок пометок чек-листов никаких черновиков сумасшедшего тестировщика???
баги?вы их описывали? воспроизведение прописывали как?

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

и второй вопрос - какой проект? с чем работаете?

WEB-проект одной компании, реклама продуктов, услуг и пр.

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

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

WEB-проект одной компании, реклама продуктов, услуг и пр.

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

Сколько у вас было времени?

+- 2кг. ни сроков, ни тз. Просто дали сайт - тестируй. Иногда при добавлении новой фичи просили обратить на неё особое внимание.

вы уложились в сроки?

наверно да...

осталось время?

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

сколько бы по вашему у вас времени занял чек -лист?

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

как вы думаете вам облегчила бы работу имеющаяся документация тот же тест или чек лист в случае когда - залили новую фича и все полетело?

я не знаю, я только пытаюсь узнать как это НУЖНО делать ПРАВИЛЬНО. А пока, если честно, я очень сомневаюсь что мне поможет чек лист или тест лист. (Простой пример. Заходим на такуюто страницу, а там съехала кнопка или в IE7 поехала вёрстка). Ведь такие баги можно увидеть только визуально).

насколько хорошо вы знаете данный проект?

достаточно хорошо.

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

баги которые МОГУТ появиться я не могу оценить пока их не увижу.

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

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

+- 2кг. ни сроков, ни тз. Просто дали сайт - тестируй. Иногда при добавлении новой фичи просили обратить на неё особое внимание.

а почему вы изначально не задумались как протестировать "Правильно"?

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

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

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

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

я не знаю, я только пытаюсь узнать как это НУЖНО делать ПРАВИЛЬНО. А пока, если честно, я очень сомневаюсь что мне поможет чек лист или тест лист. (Простой пример. Заходим на такуюто страницу, а там съехала кнопка или в IE7 поехала вёрстка). Ведь такие баги можно увидеть только визуально).

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

достаточно хорошо.

очень хорошо)
но, далее:

баги которые МОГУТ появиться я не могу оценить пока их не увижу.

ложь

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

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

почему?
обьясню:
вы можете при определенных фича определить ГДЕ может быть дыра, если ВЫ ЗНАЕТЕ продукт, если ВЫ ЗНАЕТЕ что за ФИЧА будет.

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

но у вас только такие баги?

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

вы сможете прикинуть что может произойти.
1. если вы знаете как работает разработчик данной фича, вы поймете, то ли он на 99,99% просто поменяет цвет, то ли навернет работоспособность кнопки, ее кликабельность, вызов функции и пр.
2. если вы не знаете разработчика - вы представляете что это самый ужасный разработчик в мире, и отбрасываете сразу вариант что в 99,99 %... вы поняли я думаю.

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

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

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

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