Перейти к содержимому

Программирование на C# для тестировщиков
онлайн, начало 22 мая
Тестирование производительности: JMeter 5
онлайн, начало 22 мая
Погружение в тестирование. Jedi point
онлайн, начало 25 мая
Школа тест-менеджеров v. 2.0
онлайн, начало 27 мая

Little_CJIOH

Регистрация: 17 окт 2011
Offline Активность: Вчера, 13:09
-----

#176479 Запись трафика Oracle Client

Написано Little_CJIOH 08 мая 2020 - 12:24

 

 

 

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

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

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

 

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

https://stackoverflo...oracle-database


  • 1


#176356 Клиент-серверная архитектура в картинках

Написано Little_CJIOH 27 апреля 2020 - 12:14

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

 

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


  • 2


#176350 Клиент-серверная архитектура в картинках

Написано Little_CJIOH 27 апреля 2020 - 11:05

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

 

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

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

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

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


  • 1


#175504 Для тех, кто хочет разнообразить QA/QC/QE

Написано Little_CJIOH 10 февраля 2020 - 09:16

 

 

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

ну вы даете коллега! Всем! Это-ж две большие разницы. Я бы даже сказал огромные!
А по мне и там и там начинающие, разве нет?))

 

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


  • 1


#175243 Устранение конфликта слияния, если вы зашли в тупик

Написано Little_CJIOH 20 января 2020 - 12:46

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

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

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


  • 1


#174959 Правильность написания сценария

Написано Little_CJIOH 23 декабря 2019 - 09:11

1. Чего ожидает потенциальный работодатель не знает никто.
2. "Традиционно" шаг в БДД это действие ценное с точки зрения бизнеса.
3. Вы меня извините, но человек делающий 
Than открыть страницу ya.ru
   And в поисковую строку ввести "яндекс маркет"
   Than найти по поисковому запросу яндекс маркет
   And перейти в яндекс маркет
 
на запрос
2. Зайти на yandex.ru.
3. Перейти в яндекс маркет
Это уже почти профнепригодность.
  • 1


#174099 нужно ли тестировщику ВО в сфере IT, если планируется переезд из РФ?

Написано Little_CJIOH 20 октября 2019 - 17:08

Добрый день, уважаемые участники форума! 
 
Я свитчер, у меня 14 лет ВО в медицине в РФ и за рубежом со всякими ординатурами, аспирантурами, диссерами и т.д.
 
Некоторое время назад приняла взвешенное и обоснованное (не от хорошей жизни, это обсуждать не будем) решение уйти в тестирование ПО, коему в данный момент успешно обучаюсь. Я понимаю, что свитчеров в профессии довольно много и в целом ситуация как бы не сюрприз. 
Но: в течение 2х лет я перееду жить за границу. Так вот, если тут (в РФ) есть вакансии, да хотя бы стажировки, на которые реально устроиться толковому джуну с единственным минусом в виде отсутствия айтишной или около того вышки, то там (в солнечном забугорье) за все время поиска я их не встретила от слова совсем. 
 
В связи с чем встал вопрос получения второго высшего заочно, чтоб время не терять. Целевые страны в этом плане пришлось отклонить, тк 13 000 евро в год стажер/джун не потянет ну никак.
Стала читать отзывы про российские вузы в этом контексте - пока все только ругаются. 
Понятно, что со свободным английским сейчас реально обучиться самой, но без официальной корочки там, боюсь, никак.
 
Пожалуйста, поделитесь соображениями по поводу второго ВО в сфере IT заочно - computer science и иже с ним. 
То, что платно везде - это очевидно, вопрос в том, есть ли где - то в России хорошее качество такого образования, чтобы диплом котировался за рубежом?

ТМЦДО, Точнее ФДО ТУСУР. Получите диплом государственного образца от ТУСУР без указания каким именно способом вы обучались. Из минусов - один или 2 раза придется выбраться в Томск.

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


#173836 О количестве проверок функциональности

Написано Little_CJIOH 23 сентября 2019 - 14:45

Вы предложили полный перебор.

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

Разумным компромиссом является допущение что дефект вызывается комбинацией 2-х параметров. Соответственно надо подобрать наборы так, чтобы каждое значение каждого параметра хотя-бы раз совпало с каждым значением любого другого параметра. техника называется pairwise обычно для генерации наборов тестов используются инструменты принимающие на вход описание параметров и выдающие список комбинаций. Мне доводилось использовать Pict

 

Некоторые инструменты позволяют описывать и исключать невозможные комбинации и комбинировать не по 2, а по 3 параметра


  • 1


#173714 Варианты обхода ЭЦП (таблетка) в api-автотестах

Написано Little_CJIOH 12 сентября 2019 - 10:35

когда-то сталкивались с чем-то похожим

 

добавили флаг в конфиг по которому система определяет это дебажная сборка или продовая

если система определяет что сборка дебажная то дополнительные средства безопасности отключаются

 

наверное можно как-то лучше определять, без конфига

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

 

То есть сразу надо исходить из того что информация о волшебном параметре конфига и тестовая сборка утекут наружу через 5 секунд после сборки.


  • 1


#173177 Контроль занятости отдела тестеров

Написано Little_CJIOH 02 августа 2019 - 11:35

 

 

 

У нас решали такую проблему просто. В спринте у каждого был таск Overhead, куда легально можно было списывать до часа в день. Если за день набегало больше часа времени на всякое "активность незапланированная в спринт" (от "комп тупил, админы смотрели" до "внезапно пришлось делать рисёч, который сложно привязать к продуктовой задаче"), то приходилось заводить отдельную таску и списывать туда. Но случалось редко, на коммоновые задачи часа в день хватало.

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

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

Вот у нас в одном проекте таймшиты использовались для рассчета с заказчиком. Только в них нет тикетов, в них есть типы работ. и мы тупо раз в неделю вписываем 38 часов в "sprint work" и 2 часа в "Spikes, POCs". те самые capitals и expenses. То есть, если я играл в плойку в офисе потому что тикетов не подвезли - это 8 часов, а если болел или в отпуске был, то это 0.


  • 1


#172739 Как избежать повторяющихся проверок и шагов в тестировании

Написано Little_CJIOH 26 июня 2019 - 12:01

Нужен DataManager который контролирует создание и модификацию тестовых данных. Соответственно если нужные данные уже есть, просто отдает их, если нет - создает.


  • 1


#172650 Помощь с SQL запросом

Написано Little_CJIOH 20 июня 2019 - 10:01

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


  • 2


#172347 Ищу работу Тестировщик ПО Junior (г. Москва)

Написано Little_CJIOH 28 мая 2019 - 07:07

 

Даже боюсь представить что это за соображения по которым можно отказаться от такого предложения.

 

Вы просто там никогда не работали....

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


  • 1


#172313 Выбор фреймворка и подхода к автоматизации тестирования

Написано Little_CJIOH 27 мая 2019 - 09:41

 

2. UI тесты заменяются API- тестами, но не все, основные сценарии все равно надо проходить через UI

 

 На этот счет у меня есть идея. Приведу пример. Если я правильно вас понял, то например в моем web приложении, в UI есть кнопка, при нажатии на которую  дергается какая-то API ручка. Если я напишу тест на этот API я покрою проверку работы кнопки?  Ну и соответсвтенно если при нажатии на другую кнопку API ручка не дергается, то следовательно на эту кнопку нужно писать полноценный UI тест?

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

Это классическая "пирамида тестов"

 

 

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

Как мне кажется, это все равно не решит проблему. Нужно как-то менять саму архитектуру автотестов. А с этим как раз проблемы.

 

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


  • 1


#172309 Выбор фреймворка и подхода к автоматизации тестирования

Написано Little_CJIOH 27 мая 2019 - 07:54

1. не противоречит.

2. UI тесты заменяются API- тестами, но не все, основные сценарии все равно надо проходить через UI

 

Посмотрите:

https://sqadays.com/ru/talk/7636

Может добавится ответов.


  • 1




Яндекс.Метрика
Реклама на портале