Bhxbr922

Добрый день, коллеги.

Читаю сегодня про Парадокс пестицида в тестировании и у меня образовалась пара вопросов.

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

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

Но как заставить "старые" кейсы находить баги?

2) Как определить, что тесткейсов достаточно для тестирования фичи? Вот мы написали положительный кейс, негативный с определенными входными данными, можем ли мы сказать что рассмотрели все ситуации и 2-3-5-100 тест кейсов для тестирования только одной фичи достаточно.

3) Я в проекте пишу кейсы. Все кейсы прогоняем  на разных окружениях всё работает, дефектов нахожу очень мало. Говорит ли это о том, что я плохо их ищу? Как улучшить этот навык.

Заранее спасибо

Всем привет. Может вопрос и глупый, но хотелось бы понять разницу:

Часто спрашивают что вы тестируете backend  или front end и на этот вопрос  я не могу дать четкого ответа.

Вот у меня есть проект:

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

Я загружаю это приложение и тестирую функцию " добавить дом" при этом не лезу в базу ( надо ли- у нас тестировщики этим не занимаюся=\). Что я тогда тестирую backend или front end.

Мы тестируем только фичи, никаких апи или залезть в базу. 

За любые обьяснения буду благодарен.

Спасибо

Всем привет. 

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

Поэтому вопрос: чем в это время может заняться тестировщик кроме обучения? Как улучшить тестирование в проекте? Какие активности для улучшения качества существуют? Чем заняться когда нет работы

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

Дано:

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

Моя команда состоит из 5 разработчиков и меня, одного тестировщика. 

Когда я пришел никакого обучения не было, собирал знания по крупицам. 

• Разрабатывают долго, неделями может не быть поставки,тестов. Сейчас для проверки стараются писать автотесты.
• Базовых знаний разработки нет, когда прошу меня научить - " нет времени, да и зачем, ты же тестировщик". В итоге ни помочь коллегам, ни сделать свою работу.
• Некоторый тесты настолько сложные или технические, что разработчики сами их пишут "Так быстрее, сроки поджимают"
• В итоге работы мало, сводится все к манки тестированию, полностью прощупать проект не удается. т.к. он огромный и требований нормальных нет.  Когда находишь дефект даже негде проверить свои догадки, нужно сразу идти либо к опытному разработчику либо к архитектору ( только они знают ответ). 

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

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

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