Мне нравятся книги из серии Head First O`Reilly — они рассказывают просто о сложном. И я стараюсь делать также.
Когда речь идёт о базах данных, могут всплыть магические слова «Требования ACID». На собеседовании или в разговоре разработчиков — не суть. В этой статье я расскажу о том, что это такое, как расшифровывается ACID и что означает каждая буква.
Требования ACID — набор требований, которые обеспечивают сохранность ваших данных. Что особенно важно для финансовых операций. Мы же не хотим остаться без денег из-за разрыва соединения или ошибки в ПО, не так ли?
Текст подготовлен по материалам внутреннего семинара Максилект.
Снифферы - это инструменты, позволяющие перехватывать, анализировать и модернизировать все запросы, которые через них проходят. Они полезны, когда из потока нужно извлечь какие-либо сведения или создать нужный ответ сервера. Так можно проводить модульное тестирование продукта, в котором есть и бэк, и фронт, и разные команды со своей версионностью.
В этой статье я расскажу об основных функциях снифферов, которые могут быть полезны QA. Попробую не вдаваться в теорию, а сфокусироваться на практике. Наиболее популярными представителями анализаторов трафика сейчас являются WhireShark, Fiddler и Charles Proxy. Об удобстве интерфейсов и функционале каждого из них можно рассуждать долго, учитывая все плюсы и минусы. Но здесь я отдал предпочтение Charles, поскольку сам им активно пользуюсь. Буду рассказывать на его примере.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Когда я впервые устроилась автоматизатором, меня наняла компания, где до меня не было QA-инженера. Я никогда раньше не занималась автоматизацией, однако убедила компанию, что моих базовых знаний Java хватит, чтобы разобраться. Это было задолго до появления чудесных ресурсов вроде Test Automation University, поэтому я потратила много времени и сил на метод проб и ошибок, прежде чем автоматизировала тесты, которые бы запускались и проходили. Мои тесты были длинными, нестабильными, их было тяжело поддерживать, и они были переполнены неявными ожиданиями и дупликацией кода – но это были мои тесты, и я получала большое удовольствие, разбираясь с автоматизацией самостоятельно.
Затем компания наняла нового разработчика, и менеджер решил, что будет здорово, если он изучит наше ПО, изучая мои тесты. Не советуясь со мной, разработчик полностью их переписал. Меня это задело, пока я не поглядела в тесты и не увидела, что он реорганизовал их, применяя модели и методы page object так, что дупликация кода исчезла. Тесты стало так легко поддерживать! Тогда я узнала, что лучше сотрудничать, а не тащить все самостоятельно, потому что другие могут обладать отсутствующими у нас навыками.
Автор: Майкл Болтон (Michael Bolton) Оригинал статьи Перевод: Ольга Алифанова
Приятель, дружба с которым только началась, ведет тренинги по развитию навыков для начинающих тестировщиков. Сегодня он сказал, что его студенты начинают проект, включающий тест-дизайн, тест-техники и запуск тестов. Есть ли у тебя совет для них, спросил он? Вот мой ответ.
Тест-дизайн, тест-техники и запуск тестов – классные вещи. Я бы предпочел "выполнение тестов" "запуску тестов" – мой вариант показывает, что тест – это деятельность, активно выполняемая человеком, адаптирующимся по ходу дела. "Запуск тестов" звучит как рецепт или запрограммированный набор инструкций.
Я бы советовал начать с выполнения тестов. Но этот совет может несколько смутить тех, кто убежден, что тестирование имеет дело только с неким (почти) готовым продуктом и нацелено на поиск ошибок кода. В Rapid Software Testing мы смотрим на вопрос шире: тестирование – это процесс оценки продукта путем его изучения через опыт, исследование и эксперименты, включающие до некоторой степени вопросы, наблюдения, моделирование, вмешательства, и т. д.
Работая тестировщиком рано или поздно каждый из нас приходит к моменту, кода нужно выбрать свой дальнейший карьерный путь. Для большинства из нас этот выбор не так велик: кардинальная смена вида деятельности, менеджмент, автоматизированное тестирование. Этот выбор не так прост как кажется. Тем, кто пришел из «нетехнических» сфер деятельности и на код смотрит как на инопланетную письменность, может казаться, что автоматизация – это нечто сложное и непостижимое для гуманитарного ума. Однако, сейчас выбор инструментов для автоматизации тестирования настолько велик, что любой может выбрать для себя то, что нравится и больше подходит по сложности, стоимости и даже привлекательности.
Если позволяют способности и время, можно смело браться за Selenium со всеми его сложностями и преимуществами. Процесс освоения займет ни один месяц, и не каждый будет способен самостоятельно освоить этот инструмент. Часто тот, кто платит тестировщику зарплату, предпочтет нанять готового специалиста, чем обучать имеющегося, даже при условии, что инструмент бесплатный, получается что использовать его не так уж дешево.
Что же может сделать тот, кто желает освоить и начать применять автоматизированное тестирование на своем проекте при минимальных затратах времени и финансов? Выбрать бесплатный инструмент, который легко освоить и использовать без предварительной подготовки и больших затрат времени на освоение.
TestProject один из таких инструментов, определенно стоящий внимания. Рассмотрим некоторые преимущества инструмента.
Совсем недавно я услышал замечательную историю о проекте внутри крупной российской IT-компании, ищущей руководителя в отдел тестирования. Задача была простая: есть отдел из 20 человек, которые за последние несколько лет наколбасили несколько тысяч автотестов и спроектировали пачку тестов ручных. В целом все работало, но СТО на собеседовании сказал примерно следующее: “Ваша задача — выкинуть все это к чертям собачьим и сделать нормально. А то когда предыдущий QA Lead ушел, мы поняли, что вся эта инфраструктура у нас нигде не используется.”
Ситуация невообразимая. Так не бывает. У нас точно не так. У нас же не так?
Проблемы “works on my machine” и “ответственность за нерабочий код лежит на том, кто его деплоит”, ровно о том же. И пока разработчикам рассказывали про спасительный DevOps, тестировщики и QA-специалисты как-то со стороны смотрели на это “не шаля, никого не трогая, примус починяя”. Ну что, пришло время набросить и на этот вентилятор.
В этой статье мы с Артемом Ерошенко из Qameta Software попробуем разобраться, что такое “делать тестирование нормально” в новых проектах.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Любой, кто хоть раз стирал, сталкивался с этой ситуацией: складываешь постиранные вещи и обнаруживаешь отсутствие одного носка. Иногда он пропадает, потому что вообще не попал в стирку. Иногда он остается в стиральной машинке. Шутят даже про то, что она отправляет носки в другое измерение!
Интересна тут реакция людей на пропавший носок. Кто-то пожмет плечами и решит, что рано или поздно носок найдется. Другие потратят весь день на поиски утраченного носка, перерыв прачечную, все непостиранное белье, шкаф, подкроватное пространство, и много чего еще.
Это отличная метафора для тестировщиков, столкнувшихся со странным и сложным в воспроизведении багом. Некоторые решают, что раз баг сложно воспроизвести, надо идти дальше и тестировать что-нибудь еще. Другие немедленно посвящают все свое время поиску причин этого странного поведения, забивая на прочее тестирование. Как тут правильно поступать? Зависит от обстоятельств. В этой статье я перечислю три причины охотиться на юркий баг, и три причины отложить охоту на потом.
Регулярные выражения (их еще называют regexp, или regex) — это механизм для поиска и замены текста. В строке, файле, нескольких файлах... Их используют разработчики в коде приложения, тестировщики в автотестах, да просто при работе в командной строке!
Чем это лучше простого поиска? Тем, что позволяет задать шаблон.
Например, на вход приходит дата рождения в формате ДД.ММ.ГГГГГ. Вам надо передать ее дальше, но уже в формате ГГГГ-ММ-ДД. Как это сделать с помощью простого поиска? Вы же не знаете заранее, какая именно дата будет.
А регулярное выражение позволяет задать шаблон «найди мне цифры в таком-то формате».
Когда разрабатывается новая функциональность системы, аналитик пишет требования, а тестировщик их проверяет. До того, как начать реализацию. Потому что на этом этапе внести исправления дешевле всего.
Вот только на что обращать внимание при тестировании? Есть набор основных характеристик, которыми должна обладать хорошая документация:
