Home

Автор: Петтер Мален (Petter Måhlén)

Оригинал статьи: https://labs.spotify.com/2014/04/11/qualities-of-quality/

Перевод: Ольга Алифанова

Я сейчас в отпуске по уходу за ребенком, и времени на труд, требующий концентрации, у меня маловато, потому что мой главный приоритет – решение проблем ребенка, и меня все время отвлекают. Но между этими делами можно подумать о разных вещах и иногда ответить на почту. Я размышляю об одной конкретной теме – качестве – последнюю пару недель, и сейчас, когда мой сын спит, я попытаюсь написать об этом. Моя основная идея в том, что качество на стороне разработчика сильно отличается от качества на стороне пользователя, и, как правило, важнее.

В одном из своих писем я сказал, что "почти идеальное качество кода – это мета-свойство", что означает, что оно влияет на другие параметры и улучшает их, и что оно просто необходимо для достижения нормальных скоростей разработки. Я думаю, стоит пояснить эту мысль более детально, рассмотрев разные виды качества.

Обычно, когда говорят о качестве, люди думают о том качестве, которое наблюдает конечный пользователь: качество продукта - баги, недостатки интерфейса, и всякое такое. Качество продукта – это нефункциональная характеристика, и ее можно приоритезировать по отношению к другим характеристикам (производительность, улучшенный дизайн, улучшенный алгоритм рекомендаций, и так далее). Тип качества, который можно назвать мета-характеристикой – это качество со стороны разработчика, что можно назвать качеством внедрения. Это такие штуки, как понятность и читабельность кода, легкость повторного использования, и отсутствие багов. Качество внедрения не влияет на пользовательский опыт, зато оно влияет на производительность команды, работающей над улучшением пользовательского опыта. Эти два вида качества пересекаются, но они – не одно и то же.

Автор: Александр Мешков

Оригинальная публикация

Не так давно, буквально три года назад, мир тестирования всполошила новость о том, что теперь наконец появится стандарт в области тестирования программного обеспечения, который будет выпущен как ISO (International Organization for Standardization).

Почему это так важно было для мира тестирования?

Тестирование достаточно молодая профессия и лишь небольшая часть в целом всей ИТ отрасли. Возьмите своих знакомых не из ИТ, и спросите, что они знают о тестировании?

— Тестирование? Что? Это анкеты заполнять? Программы? Не, не слышали?

И это не просто мнение знакомых, даже такие мировые стандарты в области управления ИТ, как COBIT5 или ITIL пишут всего пару строк о тестировании.

В рамках онлайн-конференции для тестировщиков и тест-менеджеров TEST Labs 2016 наши коллеги говорили о последних трендах в области обеспечения качества и управления тестированием, а также рассказывали об опыте освоения новых программ и инструментов. Ниже вы найдете видео докладов, где:

1. Юрий Слива поделился основными понятиями и принципами работы Data Warehouse.

2. Григорий Сенин рассказал о «лучших практиках» тестирования, чем они хороши, что плохого в их несоблюдении и когда можно ими пренебречь.

3. Ольга Пронина поведала об опыте работы команды, оказавшейся в ситуации информационного вакуума.

Автор: Оксана Разина

Оригинальная публикация: http://quality-lab.ru/misconceptions-of-exploratory-testing/

Исследовательское тестирование — термин, применяемый в противопоставление сценарному подходу к тестированию. Думаю, нет нужды говорить, насколько потрясающих результатов можно достичь, совмещая оба этих подхода, но чаще всего у нас просто не хватает времени на развернутый анализ и полноценное проектирование тестов.

Именно поэтому наиболее удачным решением может оказаться выбор исследовательского тестирования в моно-варианте. Поскольку сам термин «исследование» подразумевает индивидуальную заинтересованность и вовлеченность в процесс, мы все сразу же задумываемся о подводных камнях данного подхода.

Конечно, говоря о тестировании, нельзя не упомянуть распространенные ошибки самих тестировщиков. Есть такой психологический момент: если не обозначены рамки, то начинает казаться, что можно делать всё, что угодно. И этот процесс будет называться тестированием. Многие начинающие тестировщики совершенно необоснованно думают, что «исследовательское» тестирование позволяет не соблюдать основные принципы тестирования.

Автор: Нина Белан, Tutu.ru

Оригинальная публикация: https://habrahabr.ru/company/tuturu/blog/320326/

«Это должно быть сделано еще вчера», «Протестируйте как-нибудь быстренько», «Время от начала разработки до выкладки на продакшн должно быть минимальным, а если возможно — еще меньше» — наверное, многим знакомы подобные цитаты. И покуда мы (тестировщики) — одно из последних звеньев в цепочке разработки, именно нам чаще всего приходится балансировать между скоростью выхода фич и их качеством.

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

Пара слов о себе: я тестировщик, имела опыт работы в проектах разного масштаба, была единственным тестировщиком на проекте и работала в командах, в которых использовались разные подходы и методологии. По моему опыту, работать по Lean Startup — это круто, но тут есть и подводные камни для тестирования, о которых неплохо знать заранее.

Для начала стоит немного рассказать о том, чем занимается наша компания. Туту.ру — сервис по онлайн-покупке ж/д, авиа- и автобусных билетов, туров и других вещей, связанных с путешествиями. Один из наших проектов — "Туры" — еще в стадии активного развития, он очень динамичен, функциональность быстро меняется. Наши PO (продукт-оунеры) практикуют Lean Startup, и в частности мы проводим очень много экспериментов.

Автор: Катрина Клоки (Katrina Clokie)

Оригинал статьи: http://katrinatester.blogspot.ru/2016/12/the-testing-pendulum-finding-balance-in.html

Перевод: Ольга Алифанова

Насколько детальным должно быть исследовательское тестирование?

Я наткнулась на этот вопрос в темах Cambridge Lean Coffee, которые Джеймс Томас собирает в своем блоге. Этот вопрос я слышу достаточно часто, и регулярно использую одну и ту же аналогию в моем ответе: маятник тестирования.

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

Автор: Юлия Бурматова

Оригинальная публикация

При разработке нового продукта рано или поздно появляется вопрос «Нужно ли тратить деньги и время на тестирование?» Не буду говорить, что оно нужно всегда — это не так. На мой взгляд, есть ситуации, в которых тестирование нецелесообразно.

Когда стоит отказаться от тестирования

Оригинальная публикация

Автор: Вероника Латипова

Перед каждым разработчиком ПО рано или поздно встает задача оценки качества выпускаемого продукта. Зачастую руководители небольших проектов считают непозволительной роскошью прибегать к услугам профессиональных тестировщиков. Ведь, на первый взгляд, кто, если не сам разработчик или пользователь может наилучшим образом найти недостатки в программе? По сути, в этом случае все исследование сводится к бета-тестированию («Бе́та-тести́рование (англ. betatesting) – интенсивное использование почти готовой версии продукта (как правило, программного или аппаратного обеспечения) с целью выявления максимального числа ошибок в его работе для их последующего устранения перед окончательным выходом (релизом) продукта на рынок, к массовому потребителю»).

Практика использования клиентов – потребителей продукта в качестве тестировщиков в последнее время стала достаточно популярной. Мы постараемся оценить очевидные на первый взгляд плюсы и минусы бета-тестирования и тестирования специалистами. Все ли из них оказываются «плюсами» или «минусами» при ближайшем рассмотрении?

Автор: Майкл Болтон (Michael Bolton)
Оригинальная публикация: Do You Need More Testers? A Context-Driven Exercise
Перевод: Сергей Высоцкий и RA

Эта дискуссия о лучших практиках в отрасли началась недавно на comp.software.testing:

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

Мой (слегка отредактированный для этого блога) ответ был...

• Если вы собираетесь найти все баги, то 100 тестеров на программиста будет куда лучше чем полтора. Ваши клиенты могут счесть это впечатляющим (если они захотят за это платить), но ваш финансовый директор взбесится. И все еще не будет никакой гарантии, что вы найдете все баги.
• Если вы хотите сэкономить, то 0 тестировщиков будет куда лучше, чем полтора на программиста. Это даже может сработать, но будет ли вы уверенны в том, что все важные вопросы о вашем продукте были заданы, а ответы на них были получены?
• Если уж вы собрались действительно сэкономить, то 0 тестеров на 0 программистов будет самым лучшим решением.

Мы еще не говорили о квалификации тестировщиков и программистов, вовлеченных в процесс. Мы ничего не сказали об области бизнеса и сопутствующих рисках. Мы еще не говорили о том, считаете ли вы тест менеджеров и админов тестерами, или можно ли считать ваших программистов тестировщиками, когда они тестируют. (Мы так же не поговорили о ситуации, возникающей, когда вы принимаете эти "1,5 тестера на программиста" как "лучшую практику" для команды из трех программистов буквально - какую половину от пятого тестировщика вы бы хотели сохранить? Подсказка: выбирайте ту, что с головой).

Автор: Джон Эндрюс (John Andrews)

Оригинал статьи: https://testingfromthehip.wordpress.com/2016/12/14/raise-problems-not-bugs/

Перевод: Ольга Алифанова

Недавно я написал в своем твиттере примерно следующее:

"Когда рассказываете о чем-то, найденном в процессе тестирования, называйте это проблемой, а не багом. Вы поразитесь, насколько лучше вас начнут понимать".

Причина для этой статьи в том, что, по моему мнению, наша ценность как тестировщиков – это наша способность исследовать продукт и информировать команду о потенциальных проблемах. Мне нравится слово "проблема" куда больше, чем "баг", и я постараюсь объяснить, почему.