Feeds:
Posts
Comments

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

Download Software Testing Glossary (pdf, from Dropbox).

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. download this pdf for free.
  2. ask me, if something wrong or unclear.
  3. understand, that some terms require a detailed explanation, which is a subject of a whole lesson, apart from of a glossary.
  4. use and share this doc in any way with no commercial purposes.
Advertisements

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 развертывает идеи о требованиях, которые всегда существуют.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Скачать в mp3]

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’. Вопрос встал такой – нафига нам эти статусы? Мы ими не пользуемся. Надо бы их прибить.

Понеслось!

(more…)

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 »

На SQA Days еще можно подавать доклады на следующие темы:

* функциональное тестирование;
* интеграционное тестирование;
* тестирование производительности;
* автоматизация тестирования и инструментальные средства;
* конфигурационное тестирование;
* тестирование удобства использования (usability);
* тестирование защищенности (security);
* статические методы обеспечения качества;
* внедрение процессов тестирования на предприятии;
* управление процессами обеспечения качества ПО;
* менеджмент команд тестировщиков и инженеров качества ПО;
* аутсорсинг тестирования;
* тестирование системных приложений (не Web), а также тестирования игр и мобильных приложений;
* мотивация проектной команды и сертификация специалистов в области обеспечения качества ПО.

03 апреля – последний срок докладов;

18 апреля – сообщение о принятии докладов;

25 апреля – последний срок подачи окончательных (готовых к печати) текстов докладов;

14-15 мая – основные дни конференции.

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

Доклад должен быть оформлен в виде статьи размером до 6 страниц в формате .doc и отформатирован в соответствии с опубликованным на сайте конференции шаблоном, расположенным по адресу sqadays_2010_template_rus.zip.

Авторы должны зарегистрироваться на сайте https://cmt.research.microsoft.com/SQA2010/ и до 03 апреля 2010 загрузить туда подаваемые статьи.

Из статьи необходимо удалить всю информацию об ее авторе.

Статьи отбираются с использованием процедуры двойного слепого рецензирования членами Программного комитета).

Авторы принятых секционных докладов, круглых столов, мастер-классов освобождаются от уплаты организационного взноса за участие в конференции.

Авторам принятых стендовых докладов предоставляется скидка на участие в конференции. Цена рассчитывается, исходя из фактической даты подачи доклада.

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

Правила полностью.

Я тоже пишу доклад 🙂

Read Full Post »

Older Posts »

%d bloggers like this: