среда, 20 мая 2020
The last rose of Cintra
Has blood upon her thorns
A forgotten tale of Elder Blood
And all things past reborn
Swirling spheres of otherness
Of hope and doom forlorn
Her path could lead to happiness
Or the end of times for all
Ghosts of futures falling
Have saddled up to ride
Seeking the Lion Cub of Cintra
Last living of her pride
And every hand will reach for
The power that lies untold
The time of axe and sword is nigh
Blood-red seeds of war are sown
Has blood upon her thorns
A forgotten tale of Elder Blood
And all things past reborn
Swirling spheres of otherness
Of hope and doom forlorn
Her path could lead to happiness
Or the end of times for all
Ghosts of futures falling
Have saddled up to ride
Seeking the Lion Cub of Cintra
Last living of her pride
And every hand will reach for
The power that lies untold
The time of axe and sword is nigh
Blood-red seeds of war are sown
четверг, 21 февраля 2019
Ма́ра (праслав. *mara — «призрак»[1], др.-рус. мара, рус. мара, мо́рок, змора[2], укр. мара, белор. мара́, словацк. mara, болг. мара́ва «кошмар», болг. марок «призрак, привидение») — в славянской мифологии призрак, привидение[3][4][5]. В европейской[6] мифологии — злой дух, демон, садящийся по ночам на грудь и вызывающий дурные сны, сопровождающиеся удушьем под весом демона, отчего сами дурные сны также стали носить имя кошмара.
Источник
Марена (польск. Marzan(n)a, Śmiertka, словацк. Morena, Marmuriena, чеш. Morana, Smrtka, укр. Марена) — в западно-[1] и в меньшей степени восточно-славянской традиции[2] женский мифологический персонаж, связанный с сезонными обрядами умирания и воскресания природы. Имя Марены[3] или Мары[4][5] носит чучело, кукла или деревце в ритуалах проводов зимы и встречи весны[1].
Источник
Магура
Дочь громовержца Перуна, дева туч – прекрасная, крылатая, воинственная – подобна скандинавским валькириям. Сердце ее принадлежит воинам, богатырям. На поле боя Магура поддерживает воинским кличем, ее золотой шелом блестит на солнце, вселяя надежду в сердца. Когда же воин падал от удара вражьего меча или пронзенный стрелой, Магура взмахивала крыльями, касалась холодных уст и давала выпить воды из золотой чаши в виде черепа. Воин пил воду из чаши богини, и душа его улетела в рай-вырей для вечной жизни. Этот последний поцелуй Магуры доставался только храбрым и мужественным воинам.
источник
читать дальше
Фараонка, фараон, фараончик, фалярон — в русском фольклоре, согласно легенде, известной с XVI века[1] духи воды обоих полов, русалки (в западном понимании — «от головы до пояса человек, от пояса до ног — соминый плеск»), которые произошли от египтян, утонувших в Чермном море при погоне войск «фараона лютого» за Моисеем и евреями во время Исхода. Их кони превратились в полуконей-полурыб[1]. Это проклятые погибшие люди с глухим и хриплым волшебным голосом, которым суждено оставаться в таком обличье до конца света.
Любопытно, что в отличие от традиционных славянских русалок — человекоподобных утопленниц, фараонки из всего русского бестиария наиболее близки к западноевропейским «хвостатым» русалкам. Изображения таких полудев-полурыб в древнерусской резьбе называются именно «фараонками».
источник
Морская дева[1][2] (морская муза[3], фараонка, морская сирена, европейская русалка, белор. вадзяная каралеўна[4], укр. морська панна[4], чеш. Mořská panna, словен. Morska deklica[4], англ. Mermaid) — мифологический персонаж, встречающийся в легендах и мифах народов Европы, дева с рыбьим хвостом вместо ног, живущая в море. Мужской аналог — морской муж[1] (англ. Merman). В восточно-славянской мифологии — дочь Морского царя.
В поздней русской литературе и кинематографе под западным влиянием, образ Морской девы слился с образом славянской русалки, которая по внешнему виду была похожа на человека и ходила на двух ногах. В англоязычном бестиарии для славянских русалок употребляется слово rusalka, а для морских дев — mermaid[5].
источник
Морской муж, мужской аналог русалок в мифологии
Фараонки на Бестиарии и ВикиМифы
Источник
Марена (польск. Marzan(n)a, Śmiertka, словацк. Morena, Marmuriena, чеш. Morana, Smrtka, укр. Марена) — в западно-[1] и в меньшей степени восточно-славянской традиции[2] женский мифологический персонаж, связанный с сезонными обрядами умирания и воскресания природы. Имя Марены[3] или Мары[4][5] носит чучело, кукла или деревце в ритуалах проводов зимы и встречи весны[1].
Источник
Магура
Дочь громовержца Перуна, дева туч – прекрасная, крылатая, воинственная – подобна скандинавским валькириям. Сердце ее принадлежит воинам, богатырям. На поле боя Магура поддерживает воинским кличем, ее золотой шелом блестит на солнце, вселяя надежду в сердца. Когда же воин падал от удара вражьего меча или пронзенный стрелой, Магура взмахивала крыльями, касалась холодных уст и давала выпить воды из золотой чаши в виде черепа. Воин пил воду из чаши богини, и душа его улетела в рай-вырей для вечной жизни. Этот последний поцелуй Магуры доставался только храбрым и мужественным воинам.
источник
читать дальше
Фараонка, фараон, фараончик, фалярон — в русском фольклоре, согласно легенде, известной с XVI века[1] духи воды обоих полов, русалки (в западном понимании — «от головы до пояса человек, от пояса до ног — соминый плеск»), которые произошли от египтян, утонувших в Чермном море при погоне войск «фараона лютого» за Моисеем и евреями во время Исхода. Их кони превратились в полуконей-полурыб[1]. Это проклятые погибшие люди с глухим и хриплым волшебным голосом, которым суждено оставаться в таком обличье до конца света.
Любопытно, что в отличие от традиционных славянских русалок — человекоподобных утопленниц, фараонки из всего русского бестиария наиболее близки к западноевропейским «хвостатым» русалкам. Изображения таких полудев-полурыб в древнерусской резьбе называются именно «фараонками».
источник
Морская дева[1][2] (морская муза[3], фараонка, морская сирена, европейская русалка, белор. вадзяная каралеўна[4], укр. морська панна[4], чеш. Mořská panna, словен. Morska deklica[4], англ. Mermaid) — мифологический персонаж, встречающийся в легендах и мифах народов Европы, дева с рыбьим хвостом вместо ног, живущая в море. Мужской аналог — морской муж[1] (англ. Merman). В восточно-славянской мифологии — дочь Морского царя.
В поздней русской литературе и кинематографе под западным влиянием, образ Морской девы слился с образом славянской русалки, которая по внешнему виду была похожа на человека и ходила на двух ногах. В англоязычном бестиарии для славянских русалок употребляется слово rusalka, а для морских дев — mermaid[5].
источник
Морской муж, мужской аналог русалок в мифологии
Фараонки на Бестиарии и ВикиМифы
понедельник, 11 февраля 2019
Запись чисто для вида
понедельник, 05 февраля 2018
В Древнем Египте Осирис — бог произрастания и царства мертвых изображался зеленым цветом, который содержит две противоположные тенденции: жизни и смерти, т.е. является амбивалентным символом. Зеленый, входил в любимое цветовое сочетание древних египтян: зеленый — белый — красный. В Древнем Египте красный лотос был символом крови, пролитой Осирисом. Как и в Китае, этот цвет считался цветом благородного сословия, воинов, царей. Важное символическое значение в Древнем Египте имел голубой или синий цвет, соответствующий истине.
вторник, 22 декабря 2015
Многие считают, что тестирование ПО — это поиск ошибок. Иногда я говорю тестировщикам: «не старайся найти как можно больше ошибок, старайся пропустить как можно меньше!», и меня не понимают: а в чём разница?
А разница огромная! В этой статье я хочу рассказать, в чём она заключается, и какие инструменты необходимо использовать для настоящего полезного тестирования.
Что такое поиск ошибок?
Я тестирую продукт. Моя задача — завести как можно больше багов. Оно и логично! Заводить баги тестировщику всегда приятно, это видимый измеримый результат работы, И чем их больше, тем больше меня ценят как тестировщика.
Какие области я буду тестировать в таком случае? В первую очередь, самые нестабильные. Зачастую они нестабильны потому, что менее приоритетны, но это неважно, значительно важнее количество багов.
Что будет, если я столкнусь со сложновоспроизводимым багом? ROI на его исследование считается в голове очень быстро. Зачем мне с ним возиться, если я за это же время смогу завести 3 менее критичных, зато простых в заведении?
Какие тесты я буду проводить в первую очередь? Конено, самые нестандартные. Ввести в поле логина «Войну и мир», поделить на ноль, вставить в профиль фотографию в формате .exe.
Скажу по секрету — иногда на собеседованиях тестировщики в ответ на просьбу «протеструйте калькулятор» перечисляют интересные и дельные тесты, но в числе первых тридцати нет теста «проверить сложение» и другие базовые операции.
Именно так выглядит поиск ошибок — не имеющий ничего общего с тестированием.
Что такое тестирование?
Я тестирую продукт. Моя задача — пропустить как можно меньше приоритетных для пользователя багов. Чем меньше багов пропущено, чем меньше недовольства клиентом выражено — тем выше я оцениваю эффективность своей работы.
Какие области я буду тестировать в этом случае? Естественно, я начну с самых приоритетных для пользователя. Даже если они стабильно и успешно работают, я всё равно буду проверять основные пользовательские сценарии, чтобы ни в коем случае не пропустить серьёзных проблем.
Что будет, если я столкнусь с трудностями? К примеру, со сложновоспроизводимым дефектом, или непониманием бизнес-процесса пользователя, или нехваткой требований? Если это важный функционал, то я буду выяснять «что не так», «как правильно». На заведение дефекта в итоге может уйти немало времени, и с точки зрения баг/время результат эффективности тестирования будет не очень высок, зато у меня появятся более глубокие знания о продукте, архитектуре, пользователях.
Какие тесты я буду проводить в первую очередь? Конечно, самые-самые стандартные. Выполнение самого основного сценария в самых основных условиях, чтобы убедиться, что самый важный функционал работает. И только после этого я перейду к менее стандартным сценариям.
Результаты тестирования и поиска ошибок
В случае с поиском ошибок, в краткосрочной перспективе результаты выше: багов заводится больше и сразу.
Но в долгосрочной перспективе всё не так радужно:
из-за отсутствия глубоких знаний о продукте, постепенно начинает расти % пропущенных дефектов
команда разработки занята исправлением страшных-ужасных-немыслимых багов, полученных путём клика на одну и ту же кнопку 144 раза под IE в полнолуние
в релиз попадают некоторые ужасно неприятные и очевидные для пользователя баги
количество находимых ошибок в ДОЛГОСРОЧНОЙ перспективе падает
Как перейти от поиска ошибок к тестированию?
Чтобы тестирование было эффективным и полезным в долгосрочной перспективе, необходимо следовать простым правилам и использовать ключевые инструменты тестирования:
1. Анализ продукта и документирование тестов
Кликая на кнопки, можно завести много багов — но нельзя сказать, что было проверено. Единственное решение — документирование тестов. Подробные тест-кейсы, удручающие тестировщиков и отнимающие уйму времени, бывают нужны очень редко. А вот чек-листы с перечнем «что нужно проверить» — необходимы.
Что они дают:
Вы анализируете продукт, выписываете основные фичи, действия, их параметры. Таким образом существенно снижается риск что-либо забыть.
Чек-листы — отличная напоминалка «здесь надо вникнуть глубже». Есть какая-то невнятная фича с недостаточным описанием. Как её тестировать? В тестировании без тестов проще всего сказать «я вернусь к этому позже», и уже никогда не вернуться. А с тестами — у вас будет висеть тест, в котором непонятно как и что проверять, вы будете такие тесты видеть и не забудете необходимость выяснения.
Чек-листы можно и НУЖНО согласовывать. С разработчиками, аналитиками. Вся команда включается в процесс тестирования, тестировщики узнают много нового о продукте, коллективный разум улучшает качество тестирования. И помимо однократного повышения качества отдельно взятого чек-листа, повышается качество тестирования в целом: тестировщики начинают больше учитывать в тестировании, развиваться, эти знания со временем окупаются в виде более результативного тестирования.
Залог успеха в ведении тестов — создание карты, по которой вы будете идти. Цель — покрыть весь продукт. Только пожалуйста, не надо отмазок об ужасной ресурсоёмкости — я покрывала проекты с миллионами строк кода меньше чем за месяц-полтора. И в процессе написания таких тестов поднимались неожиданные вопросы и всплывали критичные ошибки, которые несмотря на наличие горе-тестеров болтались в продукте годами.
2. Оценка тестирования
Чтобы не быть слепыми котятами, необходимо оценивать эффективность тестирования. Анализировать пропущенные ошибки и причины их пропуска. Покрытие функционала и кода тестами. Уровень удовлетворения пользователей, через анкеты и сбор обратной связи. Качество заведения ошибок, опрашивая разработчиков.
ВСЕГДА есть что улучшать, и отсутствие непрерывного процесса совершенствования — неизбежное болото.
3. Обсуждение целей тестирования с командой
Многие считают, что у тестирования есть какие-то мифические цели. И что они всегда одинаковы.
Как бы не так!
В каждом проекте, компании, команде цели свои собственные. Все ли их понимают одинаково? Проговаривали ли вы их вслух?
Чтобы приносить максимум пользы, надо хорошо понимать, в чём эта самая польза заключается. И не удивляйтесь, если мнение РМов и разработчиков не будет соответствовать вашему. Надо не переубеждать их, а подстраиваться под текущие проектные цели!
4. Понимание пользователей и их бизнес-процессов
Для меня загадка, как это возможно, но тем не менее это факт: зачастую тестировщики проверяют продукт, ничего не зная о пользователе.
Как этот продукт используется?
Зачем он вообще нужен, какие проблемы решает?
Какая средняя квалификация у пользователей?
В каких условиях работают пользователи? На каких окружениях, оборудовании?
Не надо догадок и додумок про «в среднем про отрасли»! Тестировщики должны ИДЕАЛЬНО знать СВОИХ пользователей. Часто им эту информацию не предоставляют аналитики. Одумайтесь! Не зная пользователя, тестировать продукт по-нормальному невозможно.
5. Техническая квалификация и понимание архитектуры
Для иллюстрации приведу баг, который на меня недавно завели в баг-трекере:
Зайти на сайт тестируемого продукта http://****.ru в браузере Firefox
Ввести логин и пароль
Зайти с того же компьютера в браузере Opera
Просит повторно ввести логин и пароль, автоматически не логинится.
Такие баги не просто бесполезны, они позорят тестировщиков и дискредетируют отрасль в целом! Чтобы заводить дефекты правильно, необходимо понимать платформу, на которой написан тестируемый продукт. Если мы говорим про веб-тестирование, то можно хотя бы указать в баг-репорте возвращаемый сервером код ошибки, посмотреть подробности файрбагом, предоставить подробную информацию и сэкономить разработке массу времени!
Выводы
Очень многие разработчики не любят тестировщиков. И правильно делают!
Зато хороших тестировщиков любят и ценят все. Но тестировщиков, а не кликеров и багозаводильцев!
Учитесь узнавать, что не так, что не нравится другим участникам команды разработки. Обязательно исследуйте пропущенные ошибки и делайте всё для того, чтобы больше их не пропускать. Не гонитесь за заведением багов — вашей мантрой должны быть «счастье пользователя», «качественный продукт» и «успешный проект», а не «завести как можно больше багов» — ОЧЕНЬ часто эти 2 цели оказываются слишком далеки друг от друга.
И да пребудет с вами сила!
А разница огромная! В этой статье я хочу рассказать, в чём она заключается, и какие инструменты необходимо использовать для настоящего полезного тестирования.
Что такое поиск ошибок?
Я тестирую продукт. Моя задача — завести как можно больше багов. Оно и логично! Заводить баги тестировщику всегда приятно, это видимый измеримый результат работы, И чем их больше, тем больше меня ценят как тестировщика.
Какие области я буду тестировать в таком случае? В первую очередь, самые нестабильные. Зачастую они нестабильны потому, что менее приоритетны, но это неважно, значительно важнее количество багов.
Что будет, если я столкнусь со сложновоспроизводимым багом? ROI на его исследование считается в голове очень быстро. Зачем мне с ним возиться, если я за это же время смогу завести 3 менее критичных, зато простых в заведении?
Какие тесты я буду проводить в первую очередь? Конено, самые нестандартные. Ввести в поле логина «Войну и мир», поделить на ноль, вставить в профиль фотографию в формате .exe.
Скажу по секрету — иногда на собеседованиях тестировщики в ответ на просьбу «протеструйте калькулятор» перечисляют интересные и дельные тесты, но в числе первых тридцати нет теста «проверить сложение» и другие базовые операции.
Именно так выглядит поиск ошибок — не имеющий ничего общего с тестированием.
Что такое тестирование?
Я тестирую продукт. Моя задача — пропустить как можно меньше приоритетных для пользователя багов. Чем меньше багов пропущено, чем меньше недовольства клиентом выражено — тем выше я оцениваю эффективность своей работы.
Какие области я буду тестировать в этом случае? Естественно, я начну с самых приоритетных для пользователя. Даже если они стабильно и успешно работают, я всё равно буду проверять основные пользовательские сценарии, чтобы ни в коем случае не пропустить серьёзных проблем.
Что будет, если я столкнусь с трудностями? К примеру, со сложновоспроизводимым дефектом, или непониманием бизнес-процесса пользователя, или нехваткой требований? Если это важный функционал, то я буду выяснять «что не так», «как правильно». На заведение дефекта в итоге может уйти немало времени, и с точки зрения баг/время результат эффективности тестирования будет не очень высок, зато у меня появятся более глубокие знания о продукте, архитектуре, пользователях.
Какие тесты я буду проводить в первую очередь? Конечно, самые-самые стандартные. Выполнение самого основного сценария в самых основных условиях, чтобы убедиться, что самый важный функционал работает. И только после этого я перейду к менее стандартным сценариям.
Результаты тестирования и поиска ошибок
В случае с поиском ошибок, в краткосрочной перспективе результаты выше: багов заводится больше и сразу.
Но в долгосрочной перспективе всё не так радужно:
из-за отсутствия глубоких знаний о продукте, постепенно начинает расти % пропущенных дефектов
команда разработки занята исправлением страшных-ужасных-немыслимых багов, полученных путём клика на одну и ту же кнопку 144 раза под IE в полнолуние
в релиз попадают некоторые ужасно неприятные и очевидные для пользователя баги
количество находимых ошибок в ДОЛГОСРОЧНОЙ перспективе падает
Как перейти от поиска ошибок к тестированию?
Чтобы тестирование было эффективным и полезным в долгосрочной перспективе, необходимо следовать простым правилам и использовать ключевые инструменты тестирования:
1. Анализ продукта и документирование тестов
Кликая на кнопки, можно завести много багов — но нельзя сказать, что было проверено. Единственное решение — документирование тестов. Подробные тест-кейсы, удручающие тестировщиков и отнимающие уйму времени, бывают нужны очень редко. А вот чек-листы с перечнем «что нужно проверить» — необходимы.
Что они дают:
Вы анализируете продукт, выписываете основные фичи, действия, их параметры. Таким образом существенно снижается риск что-либо забыть.
Чек-листы — отличная напоминалка «здесь надо вникнуть глубже». Есть какая-то невнятная фича с недостаточным описанием. Как её тестировать? В тестировании без тестов проще всего сказать «я вернусь к этому позже», и уже никогда не вернуться. А с тестами — у вас будет висеть тест, в котором непонятно как и что проверять, вы будете такие тесты видеть и не забудете необходимость выяснения.
Чек-листы можно и НУЖНО согласовывать. С разработчиками, аналитиками. Вся команда включается в процесс тестирования, тестировщики узнают много нового о продукте, коллективный разум улучшает качество тестирования. И помимо однократного повышения качества отдельно взятого чек-листа, повышается качество тестирования в целом: тестировщики начинают больше учитывать в тестировании, развиваться, эти знания со временем окупаются в виде более результативного тестирования.
Залог успеха в ведении тестов — создание карты, по которой вы будете идти. Цель — покрыть весь продукт. Только пожалуйста, не надо отмазок об ужасной ресурсоёмкости — я покрывала проекты с миллионами строк кода меньше чем за месяц-полтора. И в процессе написания таких тестов поднимались неожиданные вопросы и всплывали критичные ошибки, которые несмотря на наличие горе-тестеров болтались в продукте годами.
2. Оценка тестирования
Чтобы не быть слепыми котятами, необходимо оценивать эффективность тестирования. Анализировать пропущенные ошибки и причины их пропуска. Покрытие функционала и кода тестами. Уровень удовлетворения пользователей, через анкеты и сбор обратной связи. Качество заведения ошибок, опрашивая разработчиков.
ВСЕГДА есть что улучшать, и отсутствие непрерывного процесса совершенствования — неизбежное болото.
3. Обсуждение целей тестирования с командой
Многие считают, что у тестирования есть какие-то мифические цели. И что они всегда одинаковы.
Как бы не так!
В каждом проекте, компании, команде цели свои собственные. Все ли их понимают одинаково? Проговаривали ли вы их вслух?
Чтобы приносить максимум пользы, надо хорошо понимать, в чём эта самая польза заключается. И не удивляйтесь, если мнение РМов и разработчиков не будет соответствовать вашему. Надо не переубеждать их, а подстраиваться под текущие проектные цели!
4. Понимание пользователей и их бизнес-процессов
Для меня загадка, как это возможно, но тем не менее это факт: зачастую тестировщики проверяют продукт, ничего не зная о пользователе.
Как этот продукт используется?
Зачем он вообще нужен, какие проблемы решает?
Какая средняя квалификация у пользователей?
В каких условиях работают пользователи? На каких окружениях, оборудовании?
Не надо догадок и додумок про «в среднем про отрасли»! Тестировщики должны ИДЕАЛЬНО знать СВОИХ пользователей. Часто им эту информацию не предоставляют аналитики. Одумайтесь! Не зная пользователя, тестировать продукт по-нормальному невозможно.
5. Техническая квалификация и понимание архитектуры
Для иллюстрации приведу баг, который на меня недавно завели в баг-трекере:
Зайти на сайт тестируемого продукта http://****.ru в браузере Firefox
Ввести логин и пароль
Зайти с того же компьютера в браузере Opera
Просит повторно ввести логин и пароль, автоматически не логинится.
Такие баги не просто бесполезны, они позорят тестировщиков и дискредетируют отрасль в целом! Чтобы заводить дефекты правильно, необходимо понимать платформу, на которой написан тестируемый продукт. Если мы говорим про веб-тестирование, то можно хотя бы указать в баг-репорте возвращаемый сервером код ошибки, посмотреть подробности файрбагом, предоставить подробную информацию и сэкономить разработке массу времени!
Выводы
Очень многие разработчики не любят тестировщиков. И правильно делают!
Зато хороших тестировщиков любят и ценят все. Но тестировщиков, а не кликеров и багозаводильцев!
Учитесь узнавать, что не так, что не нравится другим участникам команды разработки. Обязательно исследуйте пропущенные ошибки и делайте всё для того, чтобы больше их не пропускать. Не гонитесь за заведением багов — вашей мантрой должны быть «счастье пользователя», «качественный продукт» и «успешный проект», а не «завести как можно больше багов» — ОЧЕНЬ часто эти 2 цели оказываются слишком далеки друг от друга.
И да пребудет с вами сила!
На форуме тестировщиков и в блогах часто появляются вопросы: с чего
начинать тестировщику, который только-только выбрал свою стезю?
С одной стороны, сейчас много курсов в этой области, которые проводятся
на базе портала Software-Testing.Ru, УЦ Luxoft, EPAM Systems и т.д.
С другой стороны, начинающему тестировщику далеко не всегда нужны курсы.
Если вы ещё не знаете, в каком направлении развиваться, какие области
интересны, какие знания хочется получать – то о каких курсах идёт речь? А
комплексного ВУЗовского образования для тестировщиков в СНГ пока что
нет… В итоге, многие люди не могут быстро «влиться» в профессию, найти
направление для развития и понять, «что и как надо изучать для быстрого
старта?».
Поэтому, я составила инструкцию для начинающих тестировщиков или людей,
которые только выбрали себе эту область деятельности, и снабдила её
максимумом ссылок, чтобы информацию не приходилось собирать по крупицам.
Надеюсь, что эта инструкция поможет Вам в выбранном начинании.
1. Прочитайте как минимум одну книгу по тестированию
Этот пункт поможет ознакомиться со сленгом тестировщиков, понять общие
принципы и понять, насколько вообще эта отрасль для вас интересна. Для
начала наиболее понятной и доступной будет книга Романа Савина про тестирование веб-проектов.
Она написана настолько легко и весело, что проблемы «сложно дочитать»
точно не возникнет: наоборот, вы не сможете оторваться, пока не
дочитаете. А времени это займёт немного, 4-6 часов – и готово!
В качестве альтернативы, могу порекомендовать Библию Тестировщиков от Сэма Канера,
потёртый печатный экземпляр которой попал мне в руки впервые почти 10
лет назад. Этой книге более 20 лет, поэтому она может ввести начинающего
тестировщика в заблуждение «печатью баг-репортов в трёх экземплярах»
или особенностями тестирования консольных приложений. Но при этом в ней в
замечательной, доступной форме перечислены все ключевые вопросы
тестирования, затронута тема коммуникаций в тестировании (которая важна,
и которую пока никто пока что не описал лучше).
2. Просмотрите вакансии и оцените, что чаще всего требуется от тестировщиков
Многие начинающие тестировщики ищут знания, которые всем нужны. И
начинают изучать никому ненужные термины, осваивать нераспространённые
инструменты и тому подобное. Не додумывайте! Рассмотрите различные
вакансии в своём городе. Выберите те, описания которых вам понравились,
мотивировали вас. Какие знания требуются в них? Акцентируйтесь на
получении только этих навыков, не изучайте ничего такого, что никому не
нужно!
3. Приступайте к практике!
Наверное, вы думали, что следующим этапом будет «прочитать книгу по
выбранному инструменту» или «поиск информации на форуме»? Как бы ни так!
Знания без практики ничего не стоят, поэтому, при изучении любых новых
навыков, вам потребуется практика. В худшем случае, выберите для себя
задания, максимально приближенные к жизни, и выполните их. В лучшем –
найдите короткую подработку. На портале фрилансеров
вы всегда сможете найти задачи по тестированию. Честно признавайтесь,
что вам это нужно для обучения, и просите в 10 раз меньше других. Не
жадничайте – это единственный способ получить реальную жизненную
практику, и не забудьте получить отзывы!
В качестве альтернативы фри-лансу, если у вас хороший английский, рассмотрите uTest – этот сервис объединяет удалённых тестировщиков по всему миру.
Выбирайте задачи, которые будут для Вас достаточно интересны и сложны, чтобы была возможность осваивать что-то новое.
4. Станьте регулярным читателем форума для тестировщиков
В процессе решения задач у вас обязательно возникнут сложности и
вопросы, на которые вам смогут ответить на форуме. Помимо решения
конкретных проблем, форум также позволяет быть всегда в курсе
нововведений, наблюдать за трендами отрасли. В книгах новые темы
появляются с задержкой в несколько лет, что уж говорить о русскоязычных
книгах!
Самым распространённым форумом для тестировщиков в СНГ является Форум Software-Testing.Ru.
Если же у вас хорошо с английским языком (а в тестировании он очень
важен!), то особо полезным будет самый крупный англоязычный форум SQA Forums.
На этом ресурсе, если повезёт, на ваши вопросы могут ответить такие
признанные мировые гуру, как Сэм Канер, Джеймс Бах, Ричард Блэк и
другие.
5. Подпишитесь на рассылку для тестировщиков
Чтобы не стоять на месте и продолжать развиваться, вам пригодится
подписка на рассылку. Благодаря такому регулярному напоминанию об
интересных новостях, статьях, событиях и темах на форумах и блогах, вы
всегда будете в курсе жизни тестировщиков. Подписаться на русскоязычную
рассылку о тестировании и качестве, которую ведёт Виктория Птицына на
Subscribe.Ru, можно здесь.
Сейчас во всех крупных городах стали появляться клубы тестировщиков.
Благодаря им, можно ходить на регулярные бесплатные встречи, общаться в
среде специалистов, знакомиться, задавать вопросы и получать ответы.
Также, клубы – это прекрасная возможность поиска работы, так как на них
часто ходят тест-менеджеры.
Свои сайты уже есть у сообществ Москвы, Санкт-Петербурга, Новосибирска, Казани, Харькова, Днепропетровска и Бишкека.
А если вашего города нет в списке — то просто создавайте свой клуб! И вам польза, и всем тестировщикам вашего города.
7. Создайте свой блог и начните учить других тому, что вы уже освоили.
Обучение — лучший способ познания! Каждый из нас решает задачи
по-своему, находя уникальные пути. Возможно, именно ваш способ будет
лучшим, оптимальным? Для создания блога вы можете использовать простой и
абсолютно бесплатный движок Blogspot, а чтобы о нём узнали другие тестировщики, добавьте его в трансляцию тест-блогов.
Тогда, полученные вами знания не запылятся, вы получите полезную
обратную связь от опытных тестировщиков, структурируете полученные
знания и даже, возможно, заинтересуете кого-либо, кто ищет себе
сотрудников
И главное: никаких затрат, только плюсы!
Готовы?
Тогда вперёд!
начинать тестировщику, который только-только выбрал свою стезю?
С одной стороны, сейчас много курсов в этой области, которые проводятся
на базе портала Software-Testing.Ru, УЦ Luxoft, EPAM Systems и т.д.
С другой стороны, начинающему тестировщику далеко не всегда нужны курсы.
Если вы ещё не знаете, в каком направлении развиваться, какие области
интересны, какие знания хочется получать – то о каких курсах идёт речь? А
комплексного ВУЗовского образования для тестировщиков в СНГ пока что
нет… В итоге, многие люди не могут быстро «влиться» в профессию, найти
направление для развития и понять, «что и как надо изучать для быстрого
старта?».
Поэтому, я составила инструкцию для начинающих тестировщиков или людей,
которые только выбрали себе эту область деятельности, и снабдила её
максимумом ссылок, чтобы информацию не приходилось собирать по крупицам.
Надеюсь, что эта инструкция поможет Вам в выбранном начинании.
Итак, 7 шагов от чайника к тестировщику.
1. Прочитайте как минимум одну книгу по тестированию
Этот пункт поможет ознакомиться со сленгом тестировщиков, понять общие
принципы и понять, насколько вообще эта отрасль для вас интересна. Для
начала наиболее понятной и доступной будет книга Романа Савина про тестирование веб-проектов.
Она написана настолько легко и весело, что проблемы «сложно дочитать»
точно не возникнет: наоборот, вы не сможете оторваться, пока не
дочитаете. А времени это займёт немного, 4-6 часов – и готово!
В качестве альтернативы, могу порекомендовать Библию Тестировщиков от Сэма Канера,
потёртый печатный экземпляр которой попал мне в руки впервые почти 10
лет назад. Этой книге более 20 лет, поэтому она может ввести начинающего
тестировщика в заблуждение «печатью баг-репортов в трёх экземплярах»
или особенностями тестирования консольных приложений. Но при этом в ней в
замечательной, доступной форме перечислены все ключевые вопросы
тестирования, затронута тема коммуникаций в тестировании (которая важна,
и которую пока никто пока что не описал лучше).
2. Просмотрите вакансии и оцените, что чаще всего требуется от тестировщиков
Многие начинающие тестировщики ищут знания, которые всем нужны. И
начинают изучать никому ненужные термины, осваивать нераспространённые
инструменты и тому подобное. Не додумывайте! Рассмотрите различные
вакансии в своём городе. Выберите те, описания которых вам понравились,
мотивировали вас. Какие знания требуются в них? Акцентируйтесь на
получении только этих навыков, не изучайте ничего такого, что никому не
нужно!
3. Приступайте к практике!
Наверное, вы думали, что следующим этапом будет «прочитать книгу по
выбранному инструменту» или «поиск информации на форуме»? Как бы ни так!
Знания без практики ничего не стоят, поэтому, при изучении любых новых
навыков, вам потребуется практика. В худшем случае, выберите для себя
задания, максимально приближенные к жизни, и выполните их. В лучшем –
найдите короткую подработку. На портале фрилансеров
вы всегда сможете найти задачи по тестированию. Честно признавайтесь,
что вам это нужно для обучения, и просите в 10 раз меньше других. Не
жадничайте – это единственный способ получить реальную жизненную
практику, и не забудьте получить отзывы!
В качестве альтернативы фри-лансу, если у вас хороший английский, рассмотрите uTest – этот сервис объединяет удалённых тестировщиков по всему миру.
Выбирайте задачи, которые будут для Вас достаточно интересны и сложны, чтобы была возможность осваивать что-то новое.
4. Станьте регулярным читателем форума для тестировщиков
В процессе решения задач у вас обязательно возникнут сложности и
вопросы, на которые вам смогут ответить на форуме. Помимо решения
конкретных проблем, форум также позволяет быть всегда в курсе
нововведений, наблюдать за трендами отрасли. В книгах новые темы
появляются с задержкой в несколько лет, что уж говорить о русскоязычных
книгах!
Самым распространённым форумом для тестировщиков в СНГ является Форум Software-Testing.Ru.
Если же у вас хорошо с английским языком (а в тестировании он очень
важен!), то особо полезным будет самый крупный англоязычный форум SQA Forums.
На этом ресурсе, если повезёт, на ваши вопросы могут ответить такие
признанные мировые гуру, как Сэм Канер, Джеймс Бах, Ричард Блэк и
другие.
5. Подпишитесь на рассылку для тестировщиков
Чтобы не стоять на месте и продолжать развиваться, вам пригодится
подписка на рассылку. Благодаря такому регулярному напоминанию об
интересных новостях, статьях, событиях и темах на форумах и блогах, вы
всегда будете в курсе жизни тестировщиков. Подписаться на русскоязычную
рассылку о тестировании и качестве, которую ведёт Виктория Птицына на
Subscribe.Ru, можно здесь.
6. Найдите клуб тестировщиков в своём городе
Сейчас во всех крупных городах стали появляться клубы тестировщиков.
Благодаря им, можно ходить на регулярные бесплатные встречи, общаться в
среде специалистов, знакомиться, задавать вопросы и получать ответы.
Также, клубы – это прекрасная возможность поиска работы, так как на них
часто ходят тест-менеджеры.
Свои сайты уже есть у сообществ Москвы, Санкт-Петербурга, Новосибирска, Казани, Харькова, Днепропетровска и Бишкека.
А если вашего города нет в списке — то просто создавайте свой клуб! И вам польза, и всем тестировщикам вашего города.
7. Создайте свой блог и начните учить других тому, что вы уже освоили.
Обучение — лучший способ познания! Каждый из нас решает задачи
по-своему, находя уникальные пути. Возможно, именно ваш способ будет
лучшим, оптимальным? Для создания блога вы можете использовать простой и
абсолютно бесплатный движок Blogspot, а чтобы о нём узнали другие тестировщики, добавьте его в трансляцию тест-блогов.
Тогда, полученные вами знания не запылятся, вы получите полезную
обратную связь от опытных тестировщиков, структурируете полученные
знания и даже, возможно, заинтересуете кого-либо, кто ищет себе
сотрудников
Результаты выполнения 7 шагов
- Вы получите необходимые знания и опыт
- Разберётесь с требованиями в отрасли
- Немножко заработаете на utest и/или free-lance
- Завяжете массу полезных контактов
- С удовольствием проведёте время в клубах и сообществах
- Поделитесь интересными наработками с ещё более «начинающими» тестировщиками
И главное: никаких затрат, только плюсы!
Готовы?
Тогда вперёд!
Прочесть книги -
1)Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах.Романа Савина.
adm-lib.ru/testirovanie/testirovanie-dot-com.html
Книга растолковывает "Что, Зачем и Как делает тестировщик".
2)Тестирование программного обеспечения (Сэм Канер, Джек Фолк, Енг Кек Нгуен)
на русском bookre.org/reader?file=555615&pg=3
на английском hfs1.duytan.edu.vn/upload/ebooks/3989.pdf
Подписаться на рассылку «Как стать тестировщиком» от Натальи Руколь
natalyarukol.ru/maillist/
Просмотреть вебинары Михаила Портнова на ютубе +даю ссылку на материалы www.portnov.com/ru к онлайн курсам.Это очень полезный ресурс.Спасибо большое Михаилу за него.
Приступайте к практике!
На портале фрилансеров www.free-lance.ru/ вы всегда сможете найти задачи по тестированию. Выбирайте подходящие себе и вперед!
Если у вас хороший английский, рассмотрите www.utest.com/ – этот сервис объединяет удалённых тестировщиков по всему миру.
С хорошим английским вы можете пройти видеокурс www.udacity.com/course/viewer#!/c-cs258/l..
Ну и конечно же Форумы. Помогут не только разобраться с дополнительными вопросами, но и будут обучать Вас каждый день.
Стать активным читателем этих сайтов:
software-testing.ru/
www.qaclubkiev.com/p/blog-page_8401.html
forum.qaclub.com.ua/
natalyarukol.ru/
www.protesting.ru/
Чего хотят менеджеры?
Следующий список составлен путём проведения опросов, анализа результатов собеседований и даже просто «разговоров в курилке». От «усреднённого начинающего тестировщика» ожидается:
Умение работать с документацией и требованиями.
Умение создавать тест-кейсы.
Умение писать баг-репорты.
Знание HTML/CSS, SQL, XML.
Знание английского и/или иных иностранных языков (как минимум – на уровне чтения и понимания технической литературы).
Минимальные навыки автоматизации тестирования.
Если речь идёт о подготовке junior automated software test ingengineer, то добавляются следующие требования:
Знание Java на уровне написания элементарных приложений.
Умение разрабатывать модульные тесты.
Умение использовать такие средства как JUnit, TestNG, JMock, HtmlUnit, SeleniumRC, TestComplete.
Читаем:
vk.com/club28941412?w=wall-28941412_2272
vk.com/club28941412?w=wall-28941412_2269
А если есть деньги-идите на курсы.
1)Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах.Романа Савина.
adm-lib.ru/testirovanie/testirovanie-dot-com.html
Книга растолковывает "Что, Зачем и Как делает тестировщик".
2)Тестирование программного обеспечения (Сэм Канер, Джек Фолк, Енг Кек Нгуен)
на русском bookre.org/reader?file=555615&pg=3
на английском hfs1.duytan.edu.vn/upload/ebooks/3989.pdf
Подписаться на рассылку «Как стать тестировщиком» от Натальи Руколь
natalyarukol.ru/maillist/
Просмотреть вебинары Михаила Портнова на ютубе +даю ссылку на материалы www.portnov.com/ru к онлайн курсам.Это очень полезный ресурс.Спасибо большое Михаилу за него.
Приступайте к практике!
На портале фрилансеров www.free-lance.ru/ вы всегда сможете найти задачи по тестированию. Выбирайте подходящие себе и вперед!
Если у вас хороший английский, рассмотрите www.utest.com/ – этот сервис объединяет удалённых тестировщиков по всему миру.
С хорошим английским вы можете пройти видеокурс www.udacity.com/course/viewer#!/c-cs258/l..
Ну и конечно же Форумы. Помогут не только разобраться с дополнительными вопросами, но и будут обучать Вас каждый день.
Стать активным читателем этих сайтов:
software-testing.ru/
www.qaclubkiev.com/p/blog-page_8401.html
forum.qaclub.com.ua/
natalyarukol.ru/
www.protesting.ru/
Чего хотят менеджеры?
Следующий список составлен путём проведения опросов, анализа результатов собеседований и даже просто «разговоров в курилке». От «усреднённого начинающего тестировщика» ожидается:
Умение работать с документацией и требованиями.
Умение создавать тест-кейсы.
Умение писать баг-репорты.
Знание HTML/CSS, SQL, XML.
Знание английского и/или иных иностранных языков (как минимум – на уровне чтения и понимания технической литературы).
Минимальные навыки автоматизации тестирования.
Если речь идёт о подготовке junior automated software test ingengineer, то добавляются следующие требования:
Знание Java на уровне написания элементарных приложений.
Умение разрабатывать модульные тесты.
Умение использовать такие средства как JUnit, TestNG, JMock, HtmlUnit, SeleniumRC, TestComplete.
Читаем:
vk.com/club28941412?w=wall-28941412_2272
vk.com/club28941412?w=wall-28941412_2269
А если есть деньги-идите на курсы.
воскресенье, 29 ноября 2015
