Автор: Барри Эйгиатор (Barry Ehigiator) Оригинал статьи Перевод: Ольга Алифанова
Пессимизм определяется как тенденция подчеркивать или видеть плохое вместо хорошего, или верить, что плохое происходит чаще хорошего. В мире, где адвокаты от психологии и саморазвитию делают постоянный упор на значимость позитивного мышления (и у них есть на это основания), пессимистичный взгляд на мир часто считается отрицательной чертой. Однако в тестировании все должно быть наоборот – исследования показали, что определенный тип пессимизма, известный как "защитный пессимизм", может нам помочь.
Всем привет! Эту статью мы пишем вместе: Аня Долгинова и Миша Яковенко — UX-исследователи в Lamoda. Мы хотим рассказать, как правильно проводить юзабилити-тестирование с респондентом и получать четкие результаты.
Кажется, что исследовать пользовательский опыт просто: снял метрики, поговорил с участником, проанализировал показатели — и все готово. Но на самом деле все чуточку сложнее: начинающие исследователи делают много ошибок, поэтому получают некорректные данные, что может повлиять на дальнейшие решения по продукту.
Наша статья поможет правильно подготовиться к работе с респондентом, расположить его к себе, улучшить навыки своей работы и снять страх перед этим методом. Особенно она будет полезна начинающим UX-специалистам и всем специалистам, которые так или иначе взаимодействуют с интерфейсами.
Автор: Баз Дейкстра (Bas Dijkstra) Оригинал статьи Перевод: Ольга Алифанова
Если вы давно читаете мои статьи, то, возможно, знаете, что я большой поклонник WireMock, сервиса с открытым исходным кодом на Java, созданным для имитации API и виртуализации служб. Я даже создал и опубликовал бесплатный воркшоп с открытым исходным кодом по этому инструменту.
Лишь недавно, готовя курс по тестированию API на C# для заказчика, я узнал, что WireMock также портирован на C#. В этой статье я хочу пристальнее рассмотреть WireMock.Net, как (предсказуемо) называется эта библиотека. Прежде чем начать, сообщу, что честь создания и поддержки библиотеки принадлежит Штефу Хайнрату.
Привет! Меня зовут Валерий, я руковожу группой QA Fullstack компании SimbirSoft. В сфере тестирования чаще всего выделяют группы QA-специалистов и SDET. Но сейчас многие компании задумываются об оптимизации расходов, особенно это актуально для проектов с длительным периодом эксплуатации, вроде небольших монолитов или внушительных размеров систем с множеством интеграций и микросервисов. Рано или поздно наступает момент, когда требуется подключать специалистов, которые не только хорошо разбираются в продукте и могут тщательно его протестировать, но и тех, кто могут писать автотесты. Убить двух зайцев сразу помогут QA фулстеки.
В этой статье расскажу о том, как QA фулстеки могут существенно улучшить тестирование ПО, на каких проектах они принесут пользу, а для каких задач и почему лучше обратиться к другим специалистам. Материал будет полезен всем, кто хочет обеспечивать качество ПО на высоком уровне и увеличивать скорость выпуска новых релизов, оптимизируя при этом расходы на найм дополнительных специалистов.
Управление релизами охватывает все этапы продукта — от разработки и тестирования до продакшена. Это самая ответственная роль, которую может взять на себя IT-специалист. Вместе с коллегами из направления QA SimbirSoft рассказали, на что стоит обратить внимание IT-специалисту, стартующему в роли релиз-менеджера или решившему проанализировать процесс релизов на проекте.
Компетенции релиз-менеджера можно разделить на две части с точки зрения инструментов: техническую и работу с документами.
Зачастую перед QA-инженером стоит задача покрытия функциональности автотестами, при этом без избыточных проверок, по правильной пирамиде. Но, прежде чем начать покрывать бизнес-логику, стоит понять, а что, вообще, можно покрыть на unit-тестах.
Автор: Энди Найт (Andy Knight) Оригинал статьи Перевод: Ольга Алифанова
С большим волнением представляю вам довольно новую для вас и нашей отрасли идею: Открытое тестирование: что, если мы откроем наши тесты так же, как наш исходный код? Я говорю не просто о тест-фреймворках с открытым исходным кодом. Я говорю об открытии самих тестов. Что, если делиться тест-кейсами и процедурами автотестов станет нормой? Что, если для компаний будет нормальным открыто публиковать результаты тестов? И каков уровень открытости тестирования, к которому наша отрасль должна стремиться?
Всем привет, меня зовут Софья Бреева, я Team Lead QA. Моя статья для тех, кто только входит в эту профессию — поговорим о необходимых инструментах для начинающего тестировщика и литературе, которая поможет вам разобраться со многими практическими моментами. Если вы из тех, кто задается вопросом: «Ага, а есть книга, в которой я могу почитать об этом?» — этот материал будет вам полезен.
Наставничество — неотъемлемая часть моей рабочей жизни. Каждый день я взаимодействую со своими коллегами и часто им рекомендую что-то по профессии. Особенно это интересно джунам из QA, которые впитывают новую информацию как губки. Они только окунулись в сферу IT и чувствуют себя как ежики в тумане, при этом жаждут узнать как можно больше и поскорее. Поэтому цель моей статьи — помочь им рассеять этот туман, чтобы жизнь стала проще, и развитие пошло быстрее.
Автор: Пол Гриззаффи (Paul Grizzaffi) Оригинал статьи Перевод: Ольга Алифанова
Ранее я писал о концепции мягких ассертов. Процитирую себя: "Мягкий ассерт – это ассерт, результат которого записывается, но не останавливает выполнение тестового сценария на этой точке. Результаты всех мягких ассертов оцениваются в указанный автором тест-сценария момент, как правило, в конце; если какое-либо условие мягкого ассерта валидируется как ложь, мягкий ассерт сообщает о провале в результате, и тест-сценарий, как правило, отмечается как проваленный". Если вы пропустили предыдущую статью, прочитайте про концепцию мягких ассертов.
