Подходите к руководству и сообщаете, что планируете работать из дома, т.к. в кабинете с вами сидит потенциально заразный человек, а вам болеть никак нельзя.
- Форум тестировщиков
- → Публикации QuadBit
18 публикаций создано QuadBit (учитываются публикации только с 16 мая 2023)
Отправлено автор: QuadBit 29 января 2019 - 00:00 в Свободное общение
Подходите к руководству и сообщаете, что планируете работать из дома, т.к. в кабинете с вами сидит потенциально заразный человек, а вам болеть никак нельзя.
Отправлено автор: QuadBit 25 января 2019 - 20:10 в Автоматизированное тестирование
1) Конечно, если время позволяет + на ранней стадии разработки костей фреймворка это достаточно частое мероприятие, пока руку не набьешь.
2) Обязательно
Отправлено автор: QuadBit 22 января 2019 - 19:03 в Тест-дизайн и ручное тестирование
Много это сколько? Впервые слышу, чтобы проблемой заведения багов были излишние затраты времени(имею в виду не для новичков, а в рамках команды, которая понимает и использует тикеты багов). Для актуализации багов есть их статусы, можно вытащить все на выше рекомендованную скрам доску и тратить хотя бы часок в начале спринта на ревью беклога\при регрессе, если делать это регулярно, то этой проблемы не может возникнуть в принципе.
Отправлено автор: QuadBit 03 декабря 2018 - 16:43 в Личный рост, карьера, развитие
реально, только надо резюме правильное сделать, под работу конкретную.
я дважды уходил на менеждера через hh.ru
Попробую, не убудет. Под какие задачи искались, если не секрет?
Отправлено автор: QuadBit 03 декабря 2018 - 12:12 в Личный рост, карьера, развитие
Проще найти в текущей конторе нужную позицию и расти там. Как правило, менеджмент это не та сфера, где могут взять новичка со стороны.
Обращаю внимание, что поработать полгода на позиции руководителя в старой конторе и уйти в новую не прокатит (как правило). В резюме будет читаться - попробовал новую должность и не справился.
Только что хотел дополнить исходный вопрос вопросом реально ли попасть со стороны на менджерскую позицию. Печально, нет большого желания даже полгода работать обычным тестировщиком, чтобы что-то доказывать на новом месте, когда уже имеется значительный опыт управления командами, а в старой компании желания оставаться нет. В общем-то не сюрприз, конечно.
Отправлено автор: QuadBit 25 ноября 2018 - 18:52 в JMeter - Тестирование производительности
Ссылку на Property в запросе в конце урла + наверняка внутри есть что-то готовое, чтобы циклично задавать значение, но 2 года назад я костылил ещё одним аддоном считывающим из файла построчно в свойство.
Отправлено автор: QuadBit 08 ноября 2018 - 19:00 в Автоматизированное тестирование
Не, не получится, это как пельмени разлепить
так короче если сервак не отозвался, приложение
загружает свою демку и я уже с этим ничего поделать не могу
только перезапуск только хардкор
Неявные ожидания?
Отправлено автор: QuadBit 24 сентября 2018 - 20:19 в Свободное общение
В общем-то ряд недостатков вроде не очевидной необходимости лезть в код страницы и проверки на инъекции, для которой достаточно ввести пару символов весьма обесценивают тест как что-то серьезное. С 1 попытки нашел 18 из 20( вроде столько было когда проходил) "багов". Написал автору, он намекнул как найти оставшиеся 2. Просто пофанится - почему бы и нет. Рассматривать как сколько-то исчерпывающий тест на основные\профильные навыки - точно нет.
Отправлено автор: QuadBit 23 сентября 2018 - 09:01 в Свободное общение
Здравствуйте (:
QuadBit, Вы правы, скорее всего не хватает погруженности в логику приложений. Решил, что пока отложу этот вопрос. Сядем, пообщаемся, а там видно будет. Просто первый раз столкнулся с тем, что не могу положиться на человека в работе, скорее всего в силу его неопытности. Как бы только, как высказался один из предыдущих форумчан, через год не стало только хуже.
Вы не знаете, есть ли практика продления испытательного срока, есть ли в этом смысл?
Я помню только 1 случай удачного исхода продления испыталки дальше 3 месяцев за последние 4 года моей работы. Во всех остальных случаях приходилось расставаться. Но я говорю о компании, где были налажены процессы обучения\введения в проект и на 99% это была некомпетентность работников. Как в вашем случае - не знаю.
Отправлено автор: QuadBit 22 сентября 2018 - 20:30 в Свободное общение
Если результат работы вас не устраивает и вы не знаете, когда сможете его оценивать более объективно, при этом остальные члены команды при тех же условиях входа и работы выдают результат - то конечно увольнять. Другое дело, что стоит подумать, почему так вышло. Может стоит прописать какие-то правила по стандартному воркфлоу, добавить точки проверки, которые обеспечат лучшее понимание почему именно работа не выполняется. Вообще мало деталей, нужны конкретные кейсы в чем проявилась лень в тестировании конкретной задачи. Это вполне может быть результатом не погруженности в логику приложения, а не ленью, и тут свалить всю вину на него уже никак не получится. Но конечно бывают и просто не подходящие для этой работы люди.
Отправлено автор: QuadBit 20 августа 2018 - 11:06 в Автоматизированное тестирование
Речь шла скорее о тесте, который после создания какой-нибудь записи проверит её и на фронте селениумом и на беке посредством апи фреймворка. Можно ещё и в БД залезть, что мелочиться По делу - это сходу нарушает принцип 1 тест - 1 проверка, не говоря о абсолютно неизбежном повышении сложности -> хрупкости теста. Я бы начал с ответа на вопрос "А зачем" и посмотрел, оправдывает ли цель все сопутствующие сложности. Из практики я такое видел 1 раз - написали после того как проект сдали и изменений более не планировалось фундаментальных. Использовалось как приемка, обойтись спокойно могли и без них. Хотя сейчас перечитав первоначальный пост, понял, что возможно другое имеется в виду.
Отправлено автор: QuadBit 06 августа 2018 - 15:52 в Автоматизированное тестирование
Хорстман, Эккель. В каких "всех"? В какой "реальности"?
Отправлено автор: QuadBit 05 августа 2018 - 18:06 в Личный рост, карьера, развитие
Мне интересно, кем и с какой целью это "резюме" писалось. Пока что это выглядит как каша из первых попавшихся терминов довольно разного профиля, но хоть как-то попадающего под запрос "QA".
Отправлено автор: QuadBit 31 июля 2018 - 14:48 в Начинающему тестировщику
А регрессионное - это проверка того, что те новые фиксы, фичи, обновления не сделали новые баги
Новые баги в старом функционале, не просто новые. Например, у вас был какой-нибудь список, который определенным образом формируется. Поверх него можно осуществлять ещё какие-то сортировки\выборки. Если вы поменяли алгоритм формирования первоначального списка - логично будет проверить все связанные действия.
Т.е. откуда я буду знать, что именно должно быть протестировано этим видом теста?
Платиновый вопрос, в идеале - нужно протестить абсолютно весь старый функционал. В реальном мире - вам нужно максимально выявить интеграционные связи измененного функционала и существовавшего до изменений. Как? Документация( всякие ERD, flowchart, etc), общение с разработкой, аналитиками, опыт на конкретном проекте и составление сьютов на определенные части интеграции. Если есть изменения, которые попадают под 1-2 теста съюта - прогоняете его целиком на регрессе.
Отправлено автор: QuadBit 31 июля 2018 - 13:46 в Автоматизированное тестирование
То есть селениум вас не смущает
Ещё как смущает, как и весь пост в целом, но пока ответа "все так делают у нас" не было, была надежда, что инструментарий выбран исходя из какой-то логики. + меня интересовало почему BDD, а уж почему так коряво - 3 дело. Если принципиален именно руби - я в целом согласен с мнением BadMF, но лично я предпочитаю небольшие удобства, предоставляемые фреймворками вроде того же restAssured, testng, allure, классика, в общем, для большинства есть адаптации под руби, однако совершенно не понятно, что такого сам руби дает, что стоит писать именно на нем, а не яве\питоне.
Отправлено автор: QuadBit 30 июля 2018 - 19:02 в Автоматизированное тестирование
Чем обусловлен выбор фреймворков? Особенно Cucumber.
Отправлено автор: QuadBit 30 июля 2018 - 17:48 в Начинающему тестировщику
Баг-репорт без шагов и ожидаемых результатов? А что в нем тогда будет, только заголовок "как есть сейчас" и угадай сам, чем это плохо?
Приведите пример такого бага. Может, если тестировать сам процесс, то шаги и не будут нужны. Но объяснить, чем плохо сейчас и хорошо как вы ожидаете, все же надо
Без шагов ещё, пожалуй, можно жить, если заголовок исчерпывающий. А вот как описать баг без ОР - для меня загадка.
Отправлено автор: QuadBit 30 июля 2018 - 16:16 в Работа/Москва
- С опытом применения Javascript или Python в автоматизации тестирования
Возможность нанять свою собственную команду и выстроить автоматизацию с нуля, с любыми фреймворками
Community Forum Software by IP.Board Русификация от IBResource
Лицензия зарегистрирована на: Software-Testing.Ru