В мире разработки программного обеспечения изменения происходят быстро. Какие-то технологии вспыхивают и исчезают, другие становятся незаменимыми составляющими нашей повседневной жизни. Мир тестирования программного обеспечения, как и любая другая сфера, не стоит на месте. За последние пять лет мы наблюдали не только новые требования к тестировщикам, но и эволюцию самих методов и подходов. В этой статье взглянем на то, какие требования предъявлялись к тестировщикам пять лет назад, то, как они отличались от требований сегодняшнего дня и что нам ожидать в будущем.
Привет, Хабр! Меня зовут Алия, и вот уже шесть лет я являюсь инженером-тестировщиком. Здесь я делилась многим, от собственных проектов по адаптации новичков и аттестации тестировщиков до проектирования мебели по ИТ-модели. А в этой статье я хочу поделиться своим первым опытом демонстрации программного продукта и рассказать, что необходимо для подготовки.
Привет, Хабр! Меня зовут Алия, я - инженер-тестировщик. Почти год назад я переехала в новую квартиру и стала обустраивать её во многом своими силами. У меня была мечта — попробовать отреставрировать какую-нибудь старую мебель. И вот пришло время действовать. Я пошла на "Авито" и купила за 450 рублей тумбу из ДСП с ужасным покрытием белой краски. Как истовый айтишник я постоянно применяю разные модели и практики в работе. Я подумала: почему бы не модернизировать тумбу по одной из моделей жизненного цикла? Ведь эти модели настолько стандартные — их можно применять для чего угодно.
В этой статье хочется поднять наболевшую для большинства тестировщиков тему – это доступы к тестируемым программным продуктам. Не всегда доступы к ПО предоставляют тестерам здесь и сейчас. И именно поэтому сотрудники вынуждены ждать начало этапа STLC, относительно к этапам работ проекта именно из-за такой проблемы.
Время идет, сроки становятся все короче и короче, а тестировщику еще не предоставили возможности «познакомиться» с программой. Конечно, тестер задастся вопросом: «А как я успею изучить ПО и уж тем более протестировать, если у меня нет доступа к нему?». Здесь я вам отвечу, что изучить и протестировать – можно. Даже без входа в приложение.
Привет, Хабр! Ранее я писала о том, как адаптировать тестировщика, который только-только приступил к работе на проекте. В этой статье я хочу уделить особое внимание адаптации нового сотрудника на проекте и почему это так важно: проведу сравнительный анализ одного и того же проекта на основе своего опыта и кураторства нового тестера.
В первой главе этой статьи про оценку тестировщиков я писала об оценке сотрудника по текущему грейду. Теперь же, во второй части, нам предстоит описание оценки знаний и навыков для повышения грейда.
Как много тестировщиков в IT? Спойлер: очень много. Все они проходят курсы, чтобы войти в мир тестирования, но и проверка знаний новых специалистов заканчивается на моменте сдачи экзаменов на курсах и далее при собеседовании. А что дальше? Вспомнит ли тестировщик тот материал, который проштудировал во время обучения через 1 год? А через 3 года? Решение – было. В этой статье расскажу про пилотный проект оценки тестировщика по его текущим знаниям.
На протяжении 5 лет работы инженером-тестировщиком я всегда старалась найти ходы и выходы, чтобы упростить и оптимизировать процесс тестирования (рутина и монотонность – это не мое). Спойлер: у меня не получилось. В этой статье я хочу вам рассказать историю регрессионного тестирования на проекте, и о том, как у меня не получилось его оптимизировать ручным и авто-тестированием.
Меня зовут Алия, я – инженер-тестировщик с 5-летним стажем, в повседневном рабочем процессе занимающийся тестированием банковского приложения. И в местную «Вселенную» хочу войти с историей о том, как мне однажды удалось преодолеть трудную ситуацию, связанную с уходом из команды опытного сотрудника и приходом неопытного, предложить свое решение – и преуспеть.
