Богдан Кирий, занимаясь тестированием перерасти в разработчика будет затруднительно. Tолько если в джуниор разработчика. A опытный тестировщик получает больше, и работа у него интереснее.
Путь из никого в тестировщики из тестировщика в программисты - да об этом можно часто прочитать там и сям, но вот честно, не будет счастья от такого. Причина просто психологическая. Eсли ты будешь думать о том как стать разработчиком - не будешь полностью отдаваться тестированию. A лучшие тестировщики это те, которые с душой подходят к делу. А если без души тестировать, то может не хватит "экспы", чтобы сделать скачок. Хотя, не буду спорить, все индивидуально. Однако, чаще те кто действительно стремятся в разработчики сразу стараются идти в разработчики. Это просто честно. Ведь так оно и впечатление плохое оставляет, мол "что же ты парниша, мозги-то нам пудрил, что хочешь быть тестировщиком, чтобы потом уйти в разрабы?"
Вобщем, "предостерегающий жест" я сделал. В любом случае удачи.
Обычно на системном блоке есть наклейка с ключом.
Кроме того, на таких системах, есть скрытый раздел для восстановления системы (например).
Прожимаешь клавишу при запуске и стартуешь восстановление.
Если вы затерли весь винт с потрохами, и никакой наклейки у вас нет, то придется обращаться в службу поддержки.
А вообще прошли те времена, когда ставили пиратские версии, это уже не нужно давно. Всегда есть официальный путь через службу поддержки.
Можно конечно попытаться воспользоваться более старым браузером, в надежде что страница выдаст другой формат, но скорее всего просто попросит обновить браузер.
Впринципе, если это как-то поможет, то ряд не обязательно должен быть прямым, он может быть закругленным. По аналогии, ряд в кинозале обычно прямой, но может быть и немного изогнутый, как в театре, скажем. Можно впринципе дальше невозбранно изгибать этот ряд как хочешь, хоть в кольцо.
Во-первых: не надо паниковать, капсовать и плакать. Во вторых: вам помогут, если вы дадите людям такую возможность. Код вы приложили. Это выгодно выделяет ваш вопрос из массы.
я написал код, но совершенно не понимаю как его исправить
Например, обьясните, что именно в этом коде не так? Что вы хотите улучшить?
В плане подхода, тут можно аргументировать, что нужно взять готовую библиотеку для CLI и не велосипедировать. С другой стороны, это локальное решение конкретной задачи. И привлечение сторонних библиотек только усложнит архитектуру. Задача кажется учебная, и я бы склонился в сторону полностью самописного решения, с записью и чтением данных в текстовый файл. Работа с текстовыми файлами - весьма полезный опыт.
Георгий еще вот пример из жизни: когда инструмент тестирования является частью приложения - если приложение сломано так что вообще ничего не запускается, то тесты вообще не отработают. И у нас к сожалению так. А если инструмент смотрит на приложение снаружи, он просто покажет все тесты красными.
Георгий, у нас не веб-приложение, и инструмент для UI тестирования свой. У нас он встроен в приложение. Но это не очень хорошо. Лучше когда приложение и инструмент разделены. Таким образом приложение физически не сможет повлиять на инструмент тестирования. Ну кроме случая когда приложение негативно влияет на операционную систему а это в свою очередь влияет на инструмент тестирования.
Представим вы из юнит теста запускаете приложение, запускаете браузер, запускаете тесты selenium, потом все сворачиваете.. На машине разработчика все так возможно будет работать. А как вы будете тестировать приложение если оно уже собраное, и в облаке/на сервере? Можно устроить так чтобы разрабатывать и прогонять тесты локально через JUnit. А при сборке тесты бы выгружались и их можно было запускать с любой машины. Придется всего лишь отвязать механизм запуска приложения от тестов. Т.е. всю процедуру подготовки приложения для теста. Тут надо подумать кто, когда, где и для чего будет пользоваться этими тестами. Тестировать ли продакшн? Да, конечно тестировать. Именно это то что будет видеть конечный пользователь. Это же классика, на машине разработчика все работает, а после сборки и деплоя "внезапно" приложение дохнет. Кто-то там какие-то конфиги забыл закоммитить, видите-ли.
Георгий, нет, тестовые сценарии это вспомогательный инструмент.
Ими пользуются для воспроизводимости, и повторяемости, и приблизительной оценки покрытия. Как список покупок - можно им пользоваться можно нет, важно чтобы на столе было что поесть в конце концов.
Я имею ввиду информацию о дефектах в продукте. Нашел дефекты, сообщил - молодец. Не нашел или не сообщил - их найдут пользователи.
Менеджерам важны эти тесткейсы, но тесткейсы это не тесты, надо это понимать.
(https://www.satisfice.com/download/test-cases-are-...
Людям нужна иллюзия контроля, а иллюзия контроля есть только тогда когда есть цифры. Я тоже регулярно снимаю статистику, чтобы определить "горячие точки" на которые нужно в первую очередь обратить вниманием, но я не делаю из цифр культа, и не подменяю ими цель. (См.Закон Гудхарта
Ваш продукт - найденная информация по дефектам. Для тестировщика, я считаю, есть единственная важная цифра - количество заведенных качественных и уникальных репортов за единицу времени. Качественный репорт, это тот который возьмут в работу и будут чинить, не завернут по любой другой причине, например из-за невоспроизводимости или беспорядочного описания.
Можно иметь дофига тестовых сценариев, в специальных дорогих программах для управления тестовыми сценариями, штаб тестировщиков, менеджера тестирования, автоматизацию тестирования. Но если в конце концов дефекты не выявляются или не чинятся (кстати довести выявленный дефект до его действительной починки, как я считаю тоже обязанность тестировщика, хотя тут некоторые могут быть со мной не согласны) - все впустую.
Вот у нас на проекте, с меня требуют увеличения количества автоматизированных тестов. Потом хотят, чтобы они все были зелеными, и все такое в этом духе. Но не это главная работа тестировщика-автоматизатора. Работа тестировщика-автоматизатора - с выявлять дефекты (в данном случае с помощью системы автоматизации).
Т.е. само собой разумеется, я хочу увеличивать покрытие, я хочу меньше false negative, я хочу качественный логгинг, потому что это упрощает мне анализ сбоя, и выявление дефекта (или он в продукте или он в тесте). Автоматизация добавляет своей сложности. Автоматизация может выдавать трудновоспроизводимые сбои. Сидишь, копаешься. Окупаются эти трудозатраты только за счет обьема.
Да все эти книги, сертификации, это попытка систематизировать работу тестировщика, чтобы о ней было удобнее разговаривать, сравнивать, считать, оценивать. Книги и сертификации хорошо продаются. Полезных книг о тестировании очень мало, они есть, но их мало. И в этих книгах, тех которые хорошие, описываются не методологии, не готовые рецепты, а парадигмы. Каким "видением" нужно наделить тестировщика чтобы он был хорошим тестировщиком.
Георгий, Важны не подходы, а информация которую тестировщик предоставляет проекту. Артефакт (~"осязаямый продукт") тестировщика - информация. Это надо усвоить. А все остальное второстепенно.
Игорь Мунтяну не надо удалять ничего. Напишите решение которое нашли. Вдруг кому-то пригодится. А вопрос я бы все равно отредактировал. Просто, когда вам еще раз понадобится совет, люди посмотрят на ваши предыдущие вопросы и скажут "ну если ему все равно, то и мне все равно". Репутация штука которой не надо пренебрегать.
Дорогой начинающий программист, код вываливать не в тег - нельзя. Это неуважение к читателям. Есть же теги для форматирования кода, это совсем нетрудно. А еще нельзя здавать вопросы в форме задания - вопрос удалят модераторы.
Эх... иногда хочется, чтобы люди сперва научились читать прежде чем научатся писать.
Putin_Krasav4ik2024, нет, по работе мне не приходилось. Подобор инструментов зависит от того, что именно вы хотите автоматизированно тестировать. В автоматизации тестирования как и в самом тестировании, два вопроса: "что" и "как". Первый, это понять а что именно я хочу проверить, в чем я хочу убедиться и второй - как правильно это сделать (автоматизированно или нет). Для того чтобы правильно поставитьь эксперимент, нужно понимать архитектуру/устройство приложения как минимум. Соответственно, нужно четко себе представлять, что влияет на проверяемое состояние.
EkS2019, долго только не ждите, неделю, две от силы, потом в офис. Меня взяли потому, что я проявил инициативу, а не пассивно ждал что мне ответят. Так вот, инициатива для тестировщика это одно из ключевых свойств характера - никто не прибежит делиться обьяснениями как устроена программа, всегда нужно поднять пятую точку или телефонную трубку и спрашивать, спрашивать и запоминать.
DEATH2298, а и нет никакой волшебной ссылки. А писал разьяснения по собственному опыту и сверял с источниками в интернете, чтобы убедиться, что моя интерпретация соответствует общепринятой. А так каждое понятие в отдельности разяснено в интернете, можно искать типа "use cases vs user stories". Можно искать "functional specification example document". Вы может быть удивитесь, но найти какие нибудь опенсорсные проекты которые прописывают себе спецификацию практически невозможно. Писать спецификацию, это очень дорого, и долго, для этого нужны специальные люди. И юзер сторис, даже если их "продают" в аджайле как легковесную замену фунциональной спецификации, не являются заменой, и хорошо их писать тоже, блин, надо уметь.
В аджайле просто обычно не пишут фунциональную спецификацию, а делают наброски, где затруднения и вопросы решают по мере их поступления в диалоге с заказчиком. И быстрее это или дешевле или гибче, это, конечно, трудно сказать. Но по опыту, никакая фунциональная спецификация не исключит в конце концов вопросов и неясностей. Так что что ты пишешь ее что нет. Так лучше наверно решать по ходу дела. Потому что в этом документе как таковом нет никакой ценности по окончании проекта, потом это мертвый артефакт.
С другой стороны в геймдизайне до сих пор используется диздок, это функциональная спецификация игры, и она очень подробна. Стоимость разработки игр очень большая, и спецификацию "заставляют" писать для того чтобы уже на этапе концепции отсеивать возможные будущие проблемы.
Путь из никого в тестировщики из тестировщика в программисты - да об этом можно часто прочитать там и сям, но вот честно, не будет счастья от такого. Причина просто психологическая. Eсли ты будешь думать о том как стать разработчиком - не будешь полностью отдаваться тестированию. A лучшие тестировщики это те, которые с душой подходят к делу. А если без души тестировать, то может не хватит "экспы", чтобы сделать скачок. Хотя, не буду спорить, все индивидуально. Однако, чаще те кто действительно стремятся в разработчики сразу стараются идти в разработчики. Это просто честно. Ведь так оно и впечатление плохое оставляет, мол "что же ты парниша, мозги-то нам пудрил, что хочешь быть тестировщиком, чтобы потом уйти в разрабы?"
Вобщем, "предостерегающий жест" я сделал. В любом случае удачи.