Little_CJIOH

 

 

 

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

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

 

А вы не пробовали сменить работодателя?)

 

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

 

В вашем случае не с процессами проблема, а с мудаками. Процессами это не лечится.

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

 

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

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

Таки я с вами категорически не согласен! Не перестали.

Топикстартеру.
У вас есть опыт. проблема в том, что он:
1) специфичен.
2) не поименован терминами принятыми в обществе.

 

Соответственно:
глоссарий istqb и классификация по нему того, что вы делали.
собеседования и проработка непонятных вам требований.

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

Я года два назад МТС уронил.

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

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

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

Facepalm driven development?
У меня есть хороший образец Экселевской таблицы в фомате xls. Пишите в первый столбец критерии приемки а во втором отмечаете фэйл или пасс.
А потом еще можно следующую версию в третьем.
А потом добавить сверху строку и писать в нее версию которую проверяли.

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

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

А потом можно статистики собирать, но это уже адвансед.
 

Для осознания принципа работы с терминами и наступления просветления настоятельно рекомендуется к прочтению:
https://testitquickl...0/termimimitre/

 

Есть контекст исполнения теста он может хранить переменные или объекты, реализация зависит от языка имплементации.

 

 

https://cucumber.io/...ep-definitions/

 

привет. спасибо.

как вы относитесь к такой штуке, как PicoContainer ?  (https://cucumber.io/...cucumber/state/)

Подходит? используйте.

Есть контекст исполнения теста он может хранить переменные или объекты, реализация зависит от языка имплементации.

 

Что смешно — у опытных тестировщиков те же проблемы, слишком опытный стоит слишком много, слишком умничает, не хочет нам тут всё аффтаматизираватЪ, возражает, спрашивает, какие-то тест-кейсы пишет… А вот джун, который был до тебя, делал всё быстро и вопросов не задавал, и баги находил… А ты вот нет…

Люто плюсую, мое самое больное место. Доказать что я стою в полтора-два раза больше чем тот кто фигачит тесты вдвое быстрее меня. а потом еще и смочь нанести пользы на означенную сумму.
Сколько автотестов вы написали на этом проекте? - Три сценария. за 2 недели. И эти тесты находили баг примерно раз в 2 недели. на протяжении полугода.
А у вас 2000? половина из которых регрессионные на найденные вручную дефекты, которые не принесут пользы никогда.  да они еще и мерцают и требуют постоянной поддержки. А покрытие какое? не строк, требований, примерно 70? Ах не знаете как посчитать требования и их у вас вообще нет как единого артефакта. А нанимаете зачем? чтобы больше тестов писать? морщусь потому, что вы мне только что сказали что у вас стратегии тестирования нет. Нет "быстрее, выше, сильнее" - это не стратегия.

 

 

 

Напишите их на pl/sql

Мне нужно не написать свои, а посмотреть какой набор обращений к БД идет при выполнении тестируемым приложением определенной операции.

Попросите разработчиков логгировать все обращения.

 

Разработка сторонней конторы. Отдается, "как есть"

https://stackoverflo...oracle-database

Не знаю, кому там что задолжал раздельчик. А статья про архитектуру систем, она про то. что тестировать а не про то как. Ответ на вопрос как, он всегда "it depends", это всегда прикладной уровень, а архитектура абстрактна, на ее основании можно только верхнеуровневый тест-план составить. Неабстрактная "архитектура" - это уже топология сервиса.

 

ЗЫ: При всей моей органической непереносимости Ольги Назиной, и при всех придирках к качеству изложения. Эта статья покрывает белое пятно на карте знаний очень многих тестировщиков, и я не помню чтобы мне попадалась статья лучшего качества на эту тему. Пока никто не написал лучше - просто must read.

не очень понятно кто целевая аудитория этой статьи

 

сначала идут простейшие картиночки, а потом внезапно начинается кластеризация

ЦА - начинающие тестировщики.

Переход там вполне естественный и кластеризация там очень схематичная и условная, особенно с БД.

Уровень детализации вполне достаточный чтобы понимать что так бывает и задать первые вопросы.

 

 

А чем QZ отличается от QT??)))))))))

ну вы даете коллега! Всем! Это-ж две большие разницы. Я бы даже сказал огромные!

А по мне и там и там начинающие, разве нет?))

 

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

Это не аппликушка, это гитхаб.

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

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

1. Чего ожидает потенциальный работодатель не знает никто.
2. "Традиционно" шаг в БДД это действие ценное с точки зрения бизнеса.
3. Вы меня извините, но человек делающий 

Than открыть страницу ya.ru
   And в поисковую строку ввести "яндекс маркет"
   Than найти по поисковому запросу яндекс маркет
   And перейти в яндекс маркет

 
на запрос

2. Зайти на yandex.ru.
3. Перейти в яндекс маркет

Это уже почти профнепригодность.