И даже их зарплата, в американских долларах, переведённая в украинский гривны — пахнет российскими рублями оккупанта.
(Сарказм)
Представляю ;)
Звонок. 3 часа ночи.
Unknown Dialer: чувак, мы тут баг в верстке нашли на
Мы понимаем, что ты уже давно работаешь в другой компании и на другом проекте...
Но, мы считаем, это твой долг исправить проблему.
Мы знаем где ты живешь...
У тебя есть...
Се-е-е-емь-ь-ь-ь дн-е-е-ей
:D
Топик Стартер (Gabriel Angelos), а что конкретно Вы предприняли чтобы решить проблему у себя на проекте?
(Ну, кроме того, что написали статью на ДОУ. Вот теперь то тестировщики прочитают, и им сразу станет стыдно)
P.S: я и есть тот 16 летний парень который описан у Вас в топике dou.ua/...ums/topic/9137
Да, что-то мы часто видимся :D
Date of birth: 05.17.1996
Не пишите дату рождения: +20 очков
Email: jena.aa(Ё)yandex.ru
Смените почтовый адрес на более формальный (ekisel(Ё)гмэйл.com) + 4 очка
English — pre-intermediate
Подтяните английский до intermediate: + 100 очков
EXPERIENCE:
Junior QA on PlayFon Corporation (5 month)
QA Engineer on ISD group (January — now)
Расскажите о проектах: какие технологии: +10 очков
с чем вы работали работали и какие инструменты применяли, Fiddler например, SQL запросы, Или Web-сервисы дергали? ... +40 очков
о ваших достижениях +80 очков
и обязанностях + 50 очков
Поищите на линкедине хорошие резюме людей, работающих в Куа и почерпните от туда идей: +30 очков
Оформите нормально Experience, короче, с датой начала проекта, датой завершения, а не в 2 строчки — +90 очков.
Ну, и самое важное: джуниору требуется в два раза больше удачи, чтобы найти работу.
Пока ищите, изучите нормально любой из популярных языков программирования: Python, Ruby, JavaScript, C#, Java. Базовые знания в программировании и умение написать что-то могут существенно повысить ваши шансы.
Ну да... подчеркну. Для QA сравнительно мало вакансий на рынке. Для джуниоров — ещё меньше. Но... есть.
А если не знаете куда дальше двигатся, то вот, хотябы отсюда можно начать:
dou.ua/...ums/topic/9137
Например, прошу упростить следующее выражение:
!(!a || b)
Редкий КПИ-шник вспоминает, что есть такое правило де Моргана, про закончивших НАУ
А что там де Морган говорил? Не о том ли, что выражение упрощается, если переменным дать осмысленные имена?
Вот это да :D
Приношу свои извинения, (будущий) синьйор тестировщик ;)
А если серьёзно, то это действительно очень классная история. Есть не много людей, которые, как говорит Портнов, просто «берут и делают», не взирая на сложности. По моему мнению (сложившимся по той истории Михаила), Вы — один из них.
Спасибо.
Открыть можно при помощи Xmind, оно там есть по ссылке рядом с майндмапом.
Это на 95% бесплатное приложение с открытым кодом.
www.xmind.net/download/win
Для девелоперов... Я могу подсказать примеры, вот например:
freemind.sourceforge.net/...ind_map_gallery
И ещё есть очень классная по Perl:
www.mindmeister.com/45209512/perl
Но, фишка тут в том, что изучая новую тему, наиболее эффективно будет если вы составите свою карту, удобную именно для вас. А в примерах — можно подсмотреть как другие делают
Я думаю, в каждом из нас живёт хомяк маньяк. Нет? Это только я такой? Аа-а-а-а! O_O
А хомяк, в той версии, между прочим, был не спроста :).
У себя в блоге я с периодичностью «Как наберётся» выкладываю дампы ссылок. Эту подборку я и назвал Хомяком, в том смысле, что «хватит интересные ссылки хомячить, пора бы уже и поделится»
blog.zhariy.com/...h/label/hamster
Саму, майндмапу, я составил, выбрав около 120 лучших ссылок из 800, которые накопились в «хомяке».
docs.google.com/...Bib1laX3c#gid=0
Сейчас я публикую ещё одну подборку со ссылками для тестировщиков-автоматизаторов. Разница в том, что добавление ссылок уже коллективное, через гуглформу, а публикуется каждый четверг.
Если что, то подписывайтесь на RSS и помогайте с ссылками :)
automated-testing.info/...ategory/novosti
И вот еще:
Как найти работу тестировщику?
software-testing.ru/...-09-25-10-55-10
Резюме оформлено, как будто вы кроме ноутпада другими текстовыми редакторами не владеете.
Найдите пример резюме для Джуниор Тестировщика в интеренетах, можете вот здесь ещё посмотреть шаблон:
www.kukook.com/...ntry-level.aspx
Инглиш у вас не «strong» и «good», а на первый взгляд Intermediate или Pre-Intermediate
otvet.mail.ru/...estion/22720477
В резюме у вас ноль технических скиллов.
Резюме не показывает насколько вы уже знакомы с тестированием. Позиций для человека который умеет читать и кликать мышкой — очень мало. Так просто «неквалифицированную» работу не найти.
Если вы действительно не представляете что делает тестировщик, то начните с книги Савина «Тестирование дот ком»
Еще есть бесплатный видео курс:
www.portnov.com/ru
Многие компании предоставляют курсы. Найдите и попробуйте записаться на один из них: это будет лучшей инвестицией.
По моему, так даже лучше
Поздравляю с хорошей статьёй (и новым годом :) )
Я помню историю от основателей Prom.UA, о том, как
Так вот вопрос: а почему все таки была выбрана Java для фреймворка, а не Python?
Обычно суровые Java-программеры пишут тесты и билд-скрипты на Пайтоне или Груви, а тут все наоборот :D
Добавлю:
Давайте задумаемся, где можно использовать BDD
Все очень просто. Ровно там, где можно описать, как должна себя вести система или отдельный метод. Т.е., практически везде.
Другое дело, как должны выглядит тесты.
Если вы реализуете модуль для подсчета скидок
Тогда, тесты должны быть написаны в более человеко-читабельной форме. Инструменты Conrordion, Fitnesse, Cucumber — не идеальны, но помогают писать тесты в такой форме.
Что если вы реализуете свой новый библиотечный контейнер MyList<t>?
Наверняка, всем, кроме программистов будет наплевать на детали. А те, для кого вы пишете MyList, с легкостью разберутся в ваших юнит-тестах без всякого выпендрежа с «As a system I want to have a MyList<t> in order to Add new elements»
Мне вот подумалось, что неплохо было бы коротенько рассказать историю возникновения подхода/методологии BDD. И я не стал себя останавливать.
Все началось с того, что у одного чела, Дэна Норта, не хватило фантазии ответить, входе своих тренингов по TDD, на один простой вопрос: а какие тесты мы должны вообще написать, чтобы было достаточно для покрытия функциональности?
И тут, к нему пришло прозрение: а давайте напишем в заголовках тестов, не что мы проверяем, а то, что мы ожидаем от работы еще не реализованной функциональности. Т.е. вместо того, чтобы заголовок теста звучал как: протестировать_что_sqrt_от_16_равно_4(), появились тесты:
должен_вычислять_квадратный_корень_для_положительных_чисел()
должен_вычислять_квадратный_корень_для_отрицательных_чисел()
и т.д.
Конечно же, и в этом случае, некоторых тестов может не хватать, но, теперь можно посмотреть в код тестов и выявить, какого кейса не хватает. Когда написано почти-человеческим языком, а не магией чисел — как-то читать легче.
Да, вы заметили, что заголовки теста теперь стали неким подобием спецификации/требованиями к классу или методу? Так оно и есть. И Бдышь! Так, около
Подобные идеи посещали головы людей и раньше, но, первым кто все описал, был Дэн Норт:
dannorth.net/...ntroducing-bdd
Кроме этой простой идеи с именами тестов, Дэн также описал то, что тесты написанные в таком духе, помогают и другим участникам команды лучше понимать функциональность, и в итоге, даже между собой разговаривать на «общепонятном языке» (ubiquitous language).
Если вы дочитали до этого места, и считаете, что ubiquitous language — это какая-то фигня. То, я прошу вас представить себе... собаку. Вот закройте глаза — и представьте себе собаку. Зачем? Узнаете в конце это поста этого текста. А можно, и сейчас пролистать.
В общем, наступил Дэн Норт своей статьей на мозоль проблемы взаимопонимания внутри команды. А заболела эта мозоль где-то за океаном, у Гойко Аджича ( gojko.net ), который этой проблемой всерьез и занимался. И тут-то он и написал книгу: Specification by Example (specificationbyexample.com). Которая как раз и подсказывает как достичь этого взаимопонимания, ubiquitous language, и не просто внутри команды, а внутри stackholder’ов, т.е. между заинтересованными лицами. Вот тестировщик, заинтересованное лицо? — Конечно, ведь он в команде работает и ЗП за это получает и хочет чтобы программисты написали успешный продукт. А программист? А заказчик/продуктовнер/продукт менеджер? — Ответ: Да. И настолько это была прикольная идея, спецификация через пример, что стала подмножеством BDD.
Дэн Норт и Гойко Аджич говорили еще об одной идеи. О том, что требования должны идти из потребностей бизнеса. Т.е., чтобы разработчики не фигачили всякую фигню, которая никогда никому и нужна не будет, а делали все для хорошего решения бизнес-задач вовремя. Учитывая то, что Дэн был больше человеком техническим, Гойко просто удалось эту идею лучше донести. Вот что означает этот «outside-in» в определении BDD.
Спускаясь с небес, давайте вернемся к инструментам. Наверное, это первое, что мы видим, и после чего, немногие из нас продолжают копать саму идею. Jasmine, Cucumber, BDDfy, Specflow и множество других... это... инструменты, которые помогают воплощать подходы BDD в жизнь.
Это не значит, что если вы возьмете молоток, то сразу же забьете гвоздь. Точно так же с BDD-инструментами. Они помогают работать людям, которые понимают теорию BDD. Но, вряд ли у вас получится что-то BDD-шное, только потому, что вы используете инструмент.
И вот вам еще один резкий поворот. Есть крылатая фраза «BDD is TDD done right». Которую многие понимают, как «BDD — это круто, а ваш TDD — фуфло». На самом же деле: BDD — это попытка сформулировать лучшие практики TDD. Т.е. BDD пересекается с TDD, предлагая хорошие практики решения некоторых проблем.
И вот еще резкий поворот. Статья от Дэна Норта о том, что BDD — это как TDD, но, если...
dannorth.net/...is-like-tdd-if
Я надеюсь, что мне удалось вас окончательно запутать, либо внести ясность.
----
* не знаю как вы, а я представил себе таксу. Я — тестировщик, и буду тестировать то, что вы напишите — как таксу. Если вы представили бульдога... нет, это не ваша проблема. Просто, мы говорим на разных языках, а не на... кхем... ubiquitous language
@Sergii Voloshyn, добавьте пункт «техникум/колледж» в «Образование»
Вот, кстати, по вопросам ворда из другого источника:
4 Reasons Why Recruiters Want Your Resume in Word Format
2. PDF and image files cannot be edited. Recruiters often need to change your resume prior to sending it to a client to add the staffing company’s logo, format it the way the client requires, or to remove your contact information.
Ctrl + D
;)