Feeds:
Записи
Комментарии

Archive for the ‘Документация’ Category

Роли озвучивали:

  1. Антон Мужайло — лучший QA 2019 всея Украины
  2. Алексей Лупан — равнодушный к футболу эксперт по стратегиям тестирования футболистов

Темы:

  • 00:01:15 — Начальное начало
  • 00:01:17 — Гости-шмости
  • 00:02:15 — В чём разница между «Тест-план» и «Тест-стратегия»?
  • 00:28:02 — Что сейчас происходит со стандартами разработки ПО (ISO-29119, IEEE-829, TMMI, ISTQB)?
  • 00:37:02 — Как планировать оптимально и с пользой?
  • 00:48:49 — Как можно планировать в мире аджайла?
  • 00:51:04 — Как держать планы в актуальном состоянии?
  • 00:58:02 — Приводит ли планирование к успеху, или это просто лишнее время?
  • 01:04:42 — Как быстро «сколхозить» стратегию?
  • 01:11:21 — Где брать примеры или Какие книги читать про это все?
  • 01:17:15 — Тест-менеджмент в эпоху удаленки.
  • 01:29:22 — Патроны в магазине.
  • 01:31:11 — Фингальный конец.

Telegram: t.me/automation_remarks

Стать патроном: www.patreon.com/automation_remarks

Read Full Post »

При сборке pdf в каталоге проекта появляется ряд служебных файлов, содержимое которых меняется от билда к билду. Их даже нет смысла засылать в репозиторий.

Можно удалять их перед коммитом.

find -regex '.*\.\(tex~\|sty~\|sh~\|bib~\|backup\|dvi\|ps\)' -print -delete

Можно сказать Kile, что после закрытия надо удалять все «временные файлы». Но закрывать Kile каждый раз перед тем, как сделать коммит — как-то странно.

Можно добавить все такие файлы в .gitignore Но эти файлы так и лежат в каталоге проекта.

А можно компилировать проект, принудительно создавая всякие такие файлы в отдельном каталоге.

(далее…)

Read Full Post »

Иногда в телевизоре начиналась телепередача «В гостях у сказки». Было волнительно.

Анастасия Зуева, В гостях у сказки

Анастасия Зуева

И да, это чёрно-белая картинка с телевизионными искажениями, бо вы офигели требовать цветной FullHD в советском телевизоре.

Александр Александров сказок не читает, но при запуске видео с его докладами у меня всегда возникает то самое ощущение из навсегда ушедшего времени и волнение ожидания торта.

Его новый доклад — повышенной степени адекватности и глубокого погружения в тему. Не только описаны ужасы проектной повседневности в тестировании, но и предложено включить здравый смысл для их разруливания.

И там вообще не для джунов (там над вами хохмят).

Я перегнал доклад в полноценную текстовую версию, бо оно того варто. Видео — в конце.

Александр Александров
Экономика тестирования. Версия 1.0 (2018)

 

О чём будем говорить

  • Общеизвестные (но не до конца) истины, или почему такая тема
  • На что влияет экономика тестирования
  • Что такое Версия 1.0 — Подробно
  • Зачем нужна Версия 2.0 — Кратко

Почему такая тема

Эту тему я обдумывал на протяжении прошедшего года, и ещё не нашёл ответы на многие важные вопросы.

(далее…)

Read Full Post »

Иногда может понадобиться составить краткую памятку по проекту. Или его мини-описание.

Иногда это надо делать не для проекта, а для отдельных компонентов функциональности. Как правило, когда дело доходит до компонентов, у аналитиков происходит ясный глюк о том, что все те, кто войдут в проект, будут знать-понимать то же самое, что они сейчас знают-понимают. Соответственно и компоненты описываются без объяснений и предисловий.

А нужно, чтобы «Любой желающий мог быстро прочесть и понять что это за проект, какой там функционал и как юзеры будут его тыркать» (форум).

Можно набросать вот такой документ:

1. Цель проекта

2. Функциональные возможности приложения
<Из каких частей состоит? Для чего они? Что можно сделать? Их зависимости….>

3. Особенности ролей пользователей
<Какие роли могут быть на проекте? Их права, обязанности,…>

4. Варианты использования
<Список основных сценариев использования приложения всеми ролями пользователей>

5. Зависимости проекта с другими системами
<Как будет использоваться? Специфика, интеграции,…>

Но это объёмная вещь. Это не читается быстро, и быстро не понимается. И написано, как всегда, казённым языком священного армейского устава.

Попробуйте кратко объяснить проект любому уличному бомжу.

Начнете в стиле «Мужик, смотри, это нужно для того, чтобы…«. Потом вы осознаете, что нужно контекст объяснять, а не реализацию, и перейдёте на «Чтобы выполнить такую-то задачу, мы используем такую-то шняжку…»

Потом в документах будете всегда писать грамотно и сразу всем всё будет понятно.

Бомжу опосля не забудьте проставиться, он ждёт вас.

Read Full Post »

У меня уже произошло стойкое углубление в LaTeX, что привело к массивным экспериментам со множеством его пакетов, поэтому наличие полного набора всего и сразу мне благостно. Заранее же не знаешь, куда любопытство заведёт.

Вся инструкция в txt http://bit.ly/2Er0x6o (Dropbox).

Внимание, даже в txt в ряде случаев происходит искажение символов в тексте — ординарные кавычки превращает в фигурные, а дефис превращается в подобие тире.

Презентабельности ради почти то же самое в pdf — http://bit.ly/2GIUSOX

(далее…)

Read Full Post »

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

Но и тест-кейсы не последнее дело, это «тяжелое вооружение«, и когда оно бабахает, то неприятеля сносит ко всем прабабушкам. Но чтобы оно бабахнуло, надо долго крутить дулом и прицеливаться…

Можно быть приверженцем одного типа вооружения, но использовать надо всё, что попадается под руку, а не стрелять только воробьями по пушкам, типа я весь такой концептуальный и аджальный.

У тест-кейсов должны быть предусловия (‘pre-conditions’ по-вашему).

Во всех этих pre-condition для тест-кейсов уместно учитывать много всякого (и чем больше там будет учтено, тем лучше). Иногда в предусловиях полезно буквально процитировать требования, на основе которых тест-кейс был написан.

Цитировать требование в прекондишнах — это всяческий гуд, но, как всегда, есть сложности с реализацией…

Как это всё сделать?

1
Гиперссылка на требования

Да, но не менее 70% гиперссылок в любом документе неизбежно «дохнут» на протяжении полугода, а когда требования начинают переписывать, менять строки местами и нумерацию следом, то едрить вашу медь…

И очень сильно задалбывает постоянно куда-то переходить по ссылкам и в разбираться в обустройстве другого документа, ведь редкий документ в разгаре работы пишется

  • внятно,
  • грамотно,
  • однозначно,
  • красиво
  • и понятно.

Увы.

2
Логическая отсылка на нумерацию требований. Не зря они всегда пронумерованы, как законы.

Да, логические отсылки вроде «Смотри Евангелие от Программиста 9.43» более долговечны, нежели гиперссылки, но они почти постоянно нуждаются и в сопутствующих гиперссылках, и в уточнении на предмет «не поменялось ли там что-нибудь».

В какой-то момент и они перестают помогать, и тогда автор кейса начинает громко и смачно икать, бо его постоянно проклинают.

3
Процитировать требование

Самое шикарное решение. Обычно хочется (да редко можется) просто увидеть прямо на экране тест-кейса тот текст, на который сделана отсылка. Логичное решение: буквально процитировать требование в прекондишне.

С другой стороны, полное цитирование требований в тест-кейсах недальновидно, бо когда тест-кейс перестает соответствовать действительности, например, из-за того, что требования поменялись, и его надо переписать, то там переписывать и переписывать… Тогда икается всем.

Шо делать?

От страха перед иканием большинство тестировщиков (97,12%) сильно тупят и не решаются ни на то, ни на сё. А если будут требования переписываться? А если нет? А если будут? А если нет? Аааа…

Ответ: бэээ! Требования иногда переписывают, но не так часто, как может показаться, поэтому отставить панику.

Нет, когда требования начинают переписывать, это действительно Содом и Геморрой, но это беда для всех сразу, а не только для тестировщиков.

Обычно после такой беды тест-кейсы начинают переписывать, через неделю всем понятно, что переписывать — с ума сойти, и что кейсы лучше не переписывать, а написать с нуля. Жалко, конечно, но разумнее.

Заодно тестировщики начинают лучше понимать бедных программистов.

Каждому кейсу свой жизненный срок, это нормально. К этому надо привыкнуть и перестать заморачиваться поиском идеального глобального решения. Надо просто написать понятные тест-кейсы и снабдить их указанием требования, на котором тест основан, а как это сделать — неважно. Можно по-всякому.

 

Read Full Post »

Заголовки тест-кейсов вполне можно писать и без «проверить, что» или «Убедиться в том, что».

Достаточно просто ответить на хитрый вопрос «А что мы проверяем этим кейсом?»

А ответ «А мы проверяем то, что на сервер разрешено загружать только файлы с расширениями, разрешенными в параметре document-types» мы нагло сокращаем, выбросив необязательное вступление, и — вот вам элегантный заголовок-утверждение «На сервер разрешено загружать только файлы срасширениями, разрешенными в параметре document-types«.

Почему заголовок выглядит как утверждение? А потому, что должно же в этом мире что-то быть однозначным.

Помним и о том, что первое слово в каждом действии должно быть глаголом.

Read Full Post »

Download the pdf file

This is not an another ’Full glossary of terms used in Software Testing’, or ’Let’s bring together every known term in our industry, because everyone needs it. . . ’.

I just had to notice my own definition dictionary of some terms, so I did it.

English is not my native language, so you can ping me about ANY inaccuracy in this doc. Thank you in advance.

This doc will be updated, if needed.

Also you can:

  1. ask me, if something wrong or unclear.
  2. understand, that some terms require a detailed explanation, which is a subject of a whole lesson, apart from of a glossary.
  3. use and share this doc in any way with no commercial purposes.

Read Full Post »

Скачать доклад (.pptx с анимацией)

Или посмотреть без анимации:

Или вот нам видео:

Read Full Post »

В субботу, 23 августа 2014, в Одессе, при организации «Provectus IT, Inc.» пройдет «QA Expert Day».

В программе:

* Константин Пелиховский, IT-консультант: «Требования к заказчику. Роль QA в процессе постановки тех. задания»

* Дмитрий Влаев, QA automation engineer & Test Manager & QA manual/automation coach в Luxoft: «Как работает браузер»

* Дмитрий Подымов , Senior QA/Lead в Live Nation project (Provectus) : «A/B testing или реинкарнация Библейского змея…»

* Мой мастер-класс, душевно посвященный написанию тест-планов:
— общие заблуждения и ожидания от этого документа
— смысл создания тест-плана
— ситуации, в которых тест-план вообще не нужен
— алгоритм создания качественного тест-плана
— как эволюционировала работа с тест-планами в Google и какой с этого можно получить профит в наших краях

Место проведения: город Одесса, пер. Веры Инбер 5, 3-й этаж (офис Provectus IT).

Регистрация участников — обязательно.

Участие бесплатное.

А потом я побежу дальше на юга к тамошним морям вернусь в Киев.

Read Full Post »

Сэнсэй Баранцев в стенах глобаллоджиевского G-Club развертывает идеи о требованиях, которые всегда существуют.

Да требования же всегда есть!

Говорит, что не понимает тестировщиков, которые говорят, что «требований нет». Требования есть всегда, иначе программисты не смогли бы написать софт. Если сам заказчик не знает, что и как должно быть, но программисты уже сделали, следовательно, требования находятся в сознании у программистов. Надо идти к ним и выяснять.

«Требования существуют всегда. Точка».

Если надо давить авторитетом, то мэйдзин Александр Александров говорит то же самое уже который год.

А вот когда «нет четких требований» — это понятно. Это нормально. Требования не сформулированы, это нормально.

Почему тестировщики требуют требования?

От страха, йоптыть 🙂

Страшно принимать технические решения, если нет их обоснования, которое одобрено кем-то из «старших».

Страшно ошибиться.

Страшно, в общем.

Лечить этот страх следует посредством ног. Босоногие гуру аюр-веды всегда советовали ходить к программистам и обсуждать причины и решения, которые были приняты.

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

В сознаниях, если угодно.

Все остальное тоже оговаривается, но не фиксируется в документах. Если не участвуешь в тусовке, то и требования, и основания для изменений, и вообще причины принятия определенных решений проходят мимо твоего сознания.

Эффективность тестирования зависит напрямую от взаимосвязей в группе разработки, а не от качественно подготовленной документации.

То есть, всеми своими левыми руками я ратую за то, что надо создавать отдельные боевые группы «программист + тестировщик». Личностные отношения в таких группах сделают больше, чем аналитическая подготовка.

Аналитическая подготовка — это всеобщий план артиллерийского предварительного обстрела.

После обстрела все равно остаются живые неприятели, и все равно нужно бегать в штыковую атаку. В штыковой атаке все происходит ситуационно, не всегда согласовано с большим планом сражения. Тут как раз срабатывает уровень подготовки к бою каждого солдата в отдельности, и «Конвенция о женевских военнопленных» тут может не действовать…

Теперь вот что. Меня иногда искренне спрашивают, мол, чего это ты так говоришь, что Баранцев крут — «чего там особенного?»

Ну, особенного там то, что он умеет основательно раскладывать события, факты и суждения по логическим полочкам, ибо — математика, и систематизировать их.

Я так не умею. Я мыслю скорее ассоциативно, нежели строго логически.

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

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

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

В записи Сэнсэй говорит о том, что невозможно гарантировать полное тестирование требований потому, что невозможно учесть все условия, в которых работает софт.

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

PS Волновать работников Глобала лейблом SysIQ на рукаве моей футболки не пришлось — суббота, офис пустой.

PPS Старый G-Club был уютнее. Ощущался как более масштабный, что ли…

Read Full Post »

Во-первых, под словом «Workflow» в Mantis подразумевается «Переходы состояний процесса». Но мне проще сказать «воркфлоу», нежели «переходы состояний».

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

Хотя там есть даже язык «волапюк»…

В третьих, нужно покопаться в коде приложения.

Залогинившись под административным аккаунтом, переходим на страницу «manage > Manage Configuration > Workflow Transitions»

По-русски: «управление > Управление конфигурацией > Переходы состояний процесса«.

По-простому: http://вашMantis/manage_config_workflow_page.php

По-умолчанию в Mantis присутствуют следующие статусы:

  • new
  • feedback
  • acknowledged
  • confirmed
  • assigned
  • resolved
  • closed

Есть еще связанный статус ‘reopened’, но рассматривать его пока незачем.

Логика связей между статусами очень грамотная и продуманная, но подходит не всем и не всегда.

В частности, в нашем офисе разработчикам понадобился новый статус задач ‘Active’, для того, чтобы быстро узнавать, кто и чем у них занят прямо сейчас.

Мы таки добавили новый статус, хотя поначалу намеревались переименовать один из существующих.

Но добавить новый статус и дальновиднее, и интереснее 🙂

По причинам удобства, хотелось, чтобы статус ‘active’ можно было устанавливать наиболее быстро и просто, без постоянного развертывания выпадающего списка статусов…

Блин, это сделать даже быстрее, чем разъяснить.

Также встал вопрос про статусы ‘acknowledged’ и ‘confirmed’. Вопрос встал такой — нафига нам эти статусы? Мы ими не пользуемся. Надо бы их прибить.

Понеслось!

(далее…)

Read Full Post »

Иногда бывает сложно начать работать с требованиями.

Мешают толстые книги, в которых в подробностях описано такое, что становится страшно вообще думать о документировании требований, а не…

Однако есть простейший способ для начала работы с требованиями. Вот пример issue:

Summary «Export product list to Excel (csv)»

Description [3:42:34 PM] Маркетинг: а на счет экпортировать репортик?
будет такая возможность?
[3:42:56 PM] Программист: tebe nado exportirovati vse dannie ili postrani4no?
ili konkretnuiu stroku?
[3:44:20 PM] Маркетинг: одной строки не достаточно. мне надо чтоб то что я выберу фильтром (все отфильтрованные продукты) можно было скачать и потом работать с эксель файлом.

Status: Resolved.

И все отлично 🙂

А главный секрет в том, чтобы требования хотя бы как-нибудь хотя бы где-нибудь были записаны в виде БУКВ, а не в виде «Мы созванивались и это дело обсудили«.

Оформлять все это дело можно потом как угодно по какой угодно схеме и методике.

Read Full Post »

Обращение к нации

Дорогой разработчик,

в нашем мире существуют люди, которые могут найти баги даже в идеально написанной тобою программе. Обороняться от такой несправедливости бессмысленно, поэтому лучше это дело упорядочить.

Для этого используются системы управления дефектами вроде «Mantis».

  • Да, можно называть дефекты багами. Главное не в названии, главное в том, что их надо чинить.

(далее…)

Read Full Post »

Начитался книги «Программист-прагматик. Путь от подмастерья к мастеру» от Эндрю Хант и Дэвид Томас, и искренне считаю, что, по-меньшей мере, про неортогональные вертолеты должен знать каждый, кто хоть как-то причастен к разработке софта.

И что из пулемета стрелять надо трассирующими, как это описано в книге «Рэмбо II» — каждый 5-й патрон — трассирующий, поэтому создается впечатление, что пулемет стреляет огнем и сильно ревёт, отсюда и название.

И много еще чего прагматичного.

Например, про написание документации к проекту… Цитата из докладной записки авиакомпании British Airways, опубликованная в журнале “Pilot Magazine”, декабрь 1996 г.

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

Ввиду недавних случаев неоднозначного толкования этих правил считаем необходимым дать их более четкую формулировку…

Это восхитительный пассаж — на таком расстоянии нет ни одной точки. Попытки читать это вслух вызывают ржаку.

Второе упражнение: напишите короткую инструкцию по завязыванию бантиком шнурков на ботинках.

Когда дойдете до: “Теперь оберните большой и указательный пальцы так, чтобы свободный конец шнурка проходил под левым шнурком во внутреннюю петлю…” — звоните…

Это феноменально трудное задание. И все же большинство из нас могут зашнуровать ботинки, не напрягая мозги.

Теперь напишите отличную документацию к проекту…

Настолько впечатлен, что даже написал краткий, но внятный обзор этой книги для software-testing.ru в рамках конкурса на лучший отзыв о прочитанной книге.

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

  • «клиен-тсервер»,
  • «всс эти приемы»
  • или простое отсутствие точки в конце предложения.

Единственное исключение — прелестный пассаж про то, что даже спецредакторский софт может пропустить ошибки:

Ведь в право писании мокнут встретить си и такие ушиб кий, кто торты про грамма не смолит у ловить.

Read Full Post »

Older Posts »

%d такие блоггеры, как: