Игорь: Дело не в идеальности и супервостребованности. Дело в адекватном принятии ситуации и соблюдении договоренностей с работодателем.
Я не говорю, что как только на часах стукнуло 18:00 надо встать, бросив продакшен в огне и идти домой, забив на продукт и команду.
Я говорю про то, что надо понимать, что как только стукнуло 18:00 - вы начинаете тратить своё личное, нерабочее, время на работу. И это понимать должны вы и ваш работодатель. И вы, и работодатель, должны это время ценить, потому что ресурс, собственно, ограничен.
Я говорю про то, что дедлайны закрытые вечерами-ночами - это все ещё сверхурочные. И если такие ситуации не разовые и случаются постоянно - это хороший повод побеседовать с работодателем на тему их оплаты. Или сменить работу.
Или, по крайней мере, сменить своё отношение к своей работе, потому что если работодателю плевать на ваше время, силы и, в целом, на вас - то почему вам должно быть не плевать на него и его продукт?
Вы говорите, что здорово быть супервостребованным. Да, действительно здорово. Но у вас не останется ни сил, ни времени на саморазвитие, что бы стать таковым, если вы будете овертаймить бесплатно на человека, который тупо сел вам на шею.
С расстоянием Левенштейна всё не так однозначно, т.к. добавление пробела (LGG3 vs LG G3) и замена одного символа (LG G3 vs LG G4) даст одинаковое расстояние, но при этом ожидаемый результат разный.
Т.е. как минимум придется сначала выпилить все возможные разделители из обоих строк.
Категорически не согласен с вами.
Берем условные 25" и разрешение 2560х1440 и сравниваем условные BenQ и Dell, которые могут стоить с разницей 10%.
Dell дает сильне лучшую картинку.
lakegull: Скорее у вас, т.к. менеджмент все таки не про то, что бы делать все самостоятельно.
Безусловно, среди контрол фриков и любителей микроменджмента есть много тех, кто в итоге в своих повседневных задачах охватывает несколько областей IT и еще несколько из области бизнеса.
Но это до тех пор, пока объем работы по ним не начинает занимать 24/7/356.
Дальше уже приходится делать по уму, делегировать и уделять внимание не вопросам айти, а вопросам процессов, взаимодействия людей и координации проекта.
Менеджер, самостоятельно решающий конкретные IT задачи = плохой менеджер.
Алексей Николаев: Проблема в том, что след будет сложнее, чем Форум -> IP адрес -> Провайдер.
Даже если предположить, что это был исключительно разовый случай и вы больше никогда и никуда без тора не попадали. (А это весьма утопичная ситуация, на самом деле)
Во первых история вашего логина -> это прямая связь вас с пулом адресов провайдера. Это напрямую вас не деанонит, но значительно сужает круг лиц по сравнению с world wide.
Во вторых при заходе на форум у вас дернется еще миллион скриптов рекламы, гугл аналитика, виджеты соц.сетей и прочее, которые все радостно передадут ваш IP адрес дальше к себе, что бы потом лучше таргетировать на вас рекламу, или просто продавать ваши данные.
Итого вместо одного только форма связка user_id <-> ip будет уже в десяти местах. И могу вам с уверенностью сказать, что гугл, например, эту информацию не удалит никогда.
Илья: Такой вариант всего один: выходить на работу и работать.
Поэтому я и говорю, что на мой взгляд оптимальным вариантом будет - нагуглить must have вещи (для базового понимания процессов, с которыми придется работать), а дальше по мере работы уже читать всякие замечательные книжки исходя из собственных интересов и потребностей.
Список майтхэв вещей, на мой взгляд, был чуть выше в ссылках.
1) Умение гуглить, решать проблемы и задавать вопросы самостоятельно (а не ждать, пока всё сделают за тебя).
2) Понимание процессов и основных артефактов тестирование + базовое (интуитивное) представление о практиках тестдизайна.
3) SQL и понимание специфики разработки(веб\мобилы и пр).
Madmath:
Немного не по порядку пойду, но всё таки.
- По поводу ISTQB и документации. Дело не в том, что ISTQB это плохо и ни в коем случае не надо читать и проходить сертификацию.
Дело в том, что их цель - отточить свои теоретические знания для прохождения этой самой сертификации, а не научить человека тестированию.
Это не учебное пособие, это аналог ISO`шных или любых других стандартов.
При этом для джуниор тестировщика гораздо полезнее получить весь тот же объем информации в виде 10 страниц (вместо <80) сжатого и привязанного к практике текста.
Без массы красивых и длинных определений и прочего. Просто так, как это работает де факто.
В определенный момент почитать их конечно полезно и нужно, но не на старте карьеры явно.
По поводу курсов от мейла.
Первое, что меня смущает - это создатели. За исключением нескольких столпов QA индустрии, типа Заразы, я совсем не уверен, что это те люди, к которым стоит прислушиваться.
Просто потому, что качество тестирования и продуктов... ну, мягко говоря страдает, даже в сравнении с другими Российскими компаниями.
Если же более конкретно, я мельком глянул курс на который вы ссылались, и там... 30% капитана очевидности, 30% воды и 30% довольно спорных советов, порожденных видимо тем, какой опыт получили создатели курсов.
По поводу книжек...
Ну серьезно, джуниор тестировщику советовать книгу по тест дизайну?
На старте карьеры ему нужно открыть гугл, набрать "Практики тест-дизайна" и понять, как и когда их применять. Всё.
Книжка, на мой взгляд, ну прям очень сильный оверхед.
Я, конечно, допускаю что там всё отлично изложено и т.д., но честно говоря считаю, что тематический гуглинг даст ту же инфу в более сжатом и более правильном, во многом, изложении.
Сразу советую обратить внимание на Page-Object паттерн, если ещё не знакомы: selenium-python.readthedocs.org/page-objects.html
Немного тяжело въехать и сходу подстроить архитектуру, но значительно упрощает жизнь в целом и поддержку тестов в частности.
В целом, всё просто:
UI-автотесты для большинства проектов по своей логике предельно просты - найти, клацнуть\сендтекст, проверить и всё в таком духе. Никакой сложной логики там нет.
Основная проблема в их поддержке и развитии ложится на поддержание в актуальном состоянии ссылок на элементы (xpath и прочие ништяки).
Внедрение BDD в таком проекте - добавление ещё одной прослойки-интерпритатора, на которой что-то может отвалиться.
На мой взгляд BDD более-менее актуален как аналог TDD (для большого количества Unit-тестов, покрывающих весь проект).
В основном за счет того, что спект логики в юнит-тестах как правило шире, чем в UI тестах.
+ BDD тесты в итоге выступают вполне себе читаемой документацией.
Для UI тестов ни то, ни другое не слишком актуально, по этому надо думать насколько внедрение оправдано (какую пользу принесет внедрение оного).
К сожалению, чаще всего внедряют из-за "потому что модно" и "читал на хабре, хотел попробовать".
Давайте начнем с простого: оценка по страницам - она как бы натянутая и имеет мало общего с реальностью.
Это то же самое, что сайты по страницам оценивать.
Вопрос цены - в часах.
Рейты у мобильных разработчиков +- такие же, как и у остальных. < 10$ для нубов(ака джуниоров) и индусов, 15 - 25$ для разработчиков с опытом, 25$->бесконечность для "гуру".
Потому что все зависит от функционала на этих экранах. Все зависит от того, нужно ли будет интегрироваться со сторонними сервисами или вашим бэкендом (или приложение stand alone).
Нужно тестировать, в конце концов.
В итоге - разработка двухэкранного приложения вполне может занять 20 часов рабочего времени (100$ за экран) у более-менее мидл разработчика (с рейтом 10$ час).
Я бы, лично, ещё столько же времени заложил на переделывание под изменившиеся требования.
А добавить сюда ещё рисование и согласование дизайна с вами, прикручивание аналитики, всяческих интеграций со сторонними сервисами и прочим - глаза на лоб лезут.
Дмитрий Королёв: Да, таки вы правы. Касательно десктопов был не прав, каюсь.
Что касается мобилок - тем не менее, даже официальные эмуляторы, увы, часто расходятся с живыми девайсами.
Нет знаний - садись, гугли и получай оные.
Потому что если человек пошел работать тестировщиком, то один из наиболее критичных навыков - умение самостоятельно обучаться, решать проблемы и находить уже реализованные решения.
Александр Краснов: ну, в любой tms (тот же тестрейл или тестлинк) есть, так или иначе уровни вложенности. Как на уровне разных сущностей - тест сьют -> тесткейсы, так и на уровне категорий и субкатегорий в тест-сьютах.
По сути это и есть древовидная структура, и выделить нужную ветку не составляет проблем. Если же вам нужно красивое gui дерево аля майндмэп - то вряд ли такие инструменты есть, ибо на реальном количестве тестов эта модель будет нежизнеспособна.
Денис Мариан: С автоматическим созданием тега будет проблема - будут бесконечно плодиться тэги.
Грубо говоря, один раз человек скажет "1000 рублей на еду", другой раз скажет - "1000 рублей на продукты", третий раз скажет - "сходил в магазин, потратил 1000 рублей".
По сути это одна статья расходов, но по факту у вас будет 3 тэга.
В описанной вами схеме основная проблема: вы предполагаете, что пользователь будет говорить по заданной схеме <сумма> <тэг> <заметки>.
По факту это будет не так.
Со схемой <сумма> <тэг> все несколько проще, узнали сумму - остальное тэг, и наоборот.
Чем больше элементов в схеме - тем сложнее будет правильно соотнести элементы.
Я не говорю, что как только на часах стукнуло 18:00 надо встать, бросив продакшен в огне и идти домой, забив на продукт и команду.
Я говорю про то, что надо понимать, что как только стукнуло 18:00 - вы начинаете тратить своё личное, нерабочее, время на работу. И это понимать должны вы и ваш работодатель. И вы, и работодатель, должны это время ценить, потому что ресурс, собственно, ограничен.
Я говорю про то, что дедлайны закрытые вечерами-ночами - это все ещё сверхурочные. И если такие ситуации не разовые и случаются постоянно - это хороший повод побеседовать с работодателем на тему их оплаты. Или сменить работу.
Или, по крайней мере, сменить своё отношение к своей работе, потому что если работодателю плевать на ваше время, силы и, в целом, на вас - то почему вам должно быть не плевать на него и его продукт?
Вы говорите, что здорово быть супервостребованным. Да, действительно здорово. Но у вас не останется ни сил, ни времени на саморазвитие, что бы стать таковым, если вы будете овертаймить бесплатно на человека, который тупо сел вам на шею.