CamelCase, snake_case и другие регистры

CamelCase (с англ. — «ВерблюжийРегистр») — стиль написания составных слов, при котором несколько слов пишутся слитно без пробелов, при этом каждое слово внутри фразы пишется с прописной буквы. Стиль получил название CamelCase, поскольку прописные буквы внутри слова напоминают горбы верблюда.

Обычно используется внутри кода для названия переменных.

snake_case (с англ. — змеиный_регистр) — стиль написания составных слов, при котором несколько слов разделяются символом подчеркивания (_), и не имеют пробелов в записи, причём каждое слово обычно пишется с маленькой буквы — «foo_bar», «hello_world» и т. д.

Заполняем версию в баге

Это может быть одно поле, может быть несколько:

• Проявилось в версии;
• Исправить в версии;

Проявилось в версии

Вы каждые N недель выпускаете новую версию продукта: версия 1, 2, 3, 4, 5... Каждая версия чем-то отличается от прошлой (а иначе зачем она нужна?). Добавлен новый функционал, исправлены ошибки...

Соответственно, в каждой версии изменяет код. Поэтому очень важно знать, в какой версии баг проявился. А то, может, вы пытаетесь воспроизвести, а у вас не получается. И оказывается, что вы смотрите вчерашнюю сборку, в которой его еще нет. Сравнили версию приложения с указанной в баге, и обновились.

Как нарисовать карту приложения (mind map)

Мы (тестировщики) рисуем карты для того, чтобы показать их коллегам. Чтобы новичков по ним знакомить с проектом. Или чтобы показать аналитику для уточняющих вопросов «а я правильно понял, что...»?

Давайте разберемся, как нарисовать Mind Map по проекту. И как сделать карту простой и понятной. А, главное — нужной!

1. Изучите ваше приложение

Прочитайте ТЗ. Задайте вопросы аналитику. Да просто потыкайте систему и посмотрите, что она умеет. 

Статьи в помощь:

• Зачем вообще нужны программы
• Сколько вопросов задавать по ТЗ
• Открытые и закрытые вопросы

2. Выделите основные функции 

Задайте себе вопросы:

• зачем пользователю наш продукт?
• что он там делает?
• что мы хотим, чтобы он делал?

Мы начинаем рисовать с основных сценариев. А потом детализируем их, и дополняем карту второстепенными сценариями. 

Поздравляем Олесю с первой работой!

У нас в чатике одной из школ появилась новая success-story от Олеси!

******************************************************************

После курсов сразу стала отправлять резюме на должность junior qa. Как и советовали смотрела не только вакансии где ищут без опыта, но отправляла и туда, где опыт 1-3 года.

Отправила резюме примерно в 5 фирм (с сопроводительным письмом). Ответили мне 3. С одной вели переписку по почте, но они почти сразу сказали, что не готовы брать тестировщика без опыта. В двух других прошла собеседования с  HR, сделала тестовые задания (это были задания написать тест кейсы и чек листы), потом тех. собеседование.

Если есть эталонный файл для сравнения, вложите его в тест-кейс

Если вы пишете ожидаемый результат в тест-кейсе, и пишете, и пишете… А он все никак не закончится, остановитесь! Никто не будет читать стену текста. Лучше приложите некий эталон, с которым можно сверить результат. Ведь когда у нас получается стена текста? При тестировании большого отчета, в котором много колоночек, например. Вложите «правильный отчет»! И кратенько укажите, на что обратить внимание.

Это очень важно — не ограничиваться вложением эталона! Все равно надо подписать, на что конкретно мне обращать внимание. Это может быть текст отдельно, это может быть раскрашенный эталонный файл с комментариями внутри.

Главное — не делать из тестировщика тупую мартышку, которую заставляют бездумно сверять две таблички. «Не знаю, почему тут именно 2050, но в моем эталоне также, значит, работает!». Это может сделать и робот, да и сам тестировщик может в экселе просто сравнивать по ячейкам ожидание и реальность. Но знания системы ему не добавится.

Да и что будет, если эталонный файл устарел или просто продолбался? Можно сколь угодно долго бить себя пяткой в грудь и говорить, что «со мной такого точно не случится. Если я пишу «см аттач», я его вложу», но… Все бывает! 

Евангелист бизнеса. Сергей Абдульманов

Ссылка на OZON

Абдульманов — маркетинговый директор Мосигры. А эти ребята пишут хорошие и интересные статьи, поэтому я и купила книгу.

Книга хорошая, написана интересно и простым языком! Очень ценным является и то, что книга написана о России. Приятно почитать наших авторов ツ

Евангелист бизнеса — это тот, кто рассказывает о своей работе так, что все слушают, открыв рот. И ждут «продолжения банкета». Именно такой товарищ должен продвигать компанию в соцсетях, потому что старые варианты заголовков и статей вида «СРОЧНО КУПИ ПОСЛЕДНИЙ БИЛЕТИК ОСТАЛСЯ СКИДКА!!1» уже не работают, люди листают это как спам.

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

Что заставляет нас читать посты?

1. Неожиданность.
2. Развлечение.
3. Польза. 

Если есть комбо, это вообще супер. О, именно поэтому я обожаю серию книг Head First O`Reilly — там и польза, и развлечения. Иногда и неожиданности есть. Я и сама стараюсь в таком же стиле делать свои лекции, статьи, также и книгу пишу... В общем, старемся! ツ

Серия книг Head First O`Reilly

Серия книг «Head First O`Reilly» — это лучшие книги по программированию для новичков! Написаны на простом, понятном и доступном языке. Разжевывается буквально всё, так что книгу начинаешь с полного нуля и всё понимаешь.

А еще там много картиночек!   Потому что авторы против унылых стен текста. Так что вместо сухого рассказа у них есть диалоги программистов, вместе решающих какую-то проблему, беседы у камина между объектно-ориентированным и скриптовым языками программирования, и прочие фишки в таком духе.

Меня невероятно вдохновляют эти книги! Я с удовольствием прочитала книгу по SQL, когда уже давно «переросла» ее. Но уж очень люблю их стиль ¯\_(ツ)_/¯

Так что я настоятельно рекомендую эти книги к прочтению!