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

Archive for the ‘Банальное’ Category

А действительно, чего это мне кажется, что разница между верификацией и валидацией всем понятна без примера?

Нужен конкретный пример. А то без примера каждому… парню кажется, что его принимают за идиота.

Например, здравствуйте, дети, вот это револьвер Смит и Вессон. Им можно решать разные задачи на поле боя. А ещё из него программист может выстрелить себе в ногу несколько раз. Сейчас я вам это покажу на конкретном примере. Ну, чья нога послужит хорошим, конкретным примером? Кто из вас знает C++?

Если пример непонятный — нет, ты не идиот, просто давным-давно, в другом мире

Глава первая, вступательная в зыбкое болото терминов

Верификация — проверка соответствия приложения прописанным требованиям.

Валидация — проверка соответствия приложения всем остальным (подразумеваемым) требованиям.

Ну, и чо?

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

Когда я сам проектировал тесты, да ещё и для какой-то финансовой аппликухи — приходилось знать/понимать точно, какие тесты покрывают прописанные требования (верификационные), а какие тесты покрывают НЕпрописанные требования (валидационные) и соответственно их разделять по разным сборникам тестов. И это всё стало осязаемым и важным.

(далее…)

Read Full Post »

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

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

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

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

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

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

(далее…)

Read Full Post »

Очень крутой доклад. Настя умеет!

Про всё то, что из нашего царства аутсорсинга постоянно не видно.

Read Full Post »

Обычно вы делаете это с PowerPoint. На слайде у вас картинка какой-то черной коробки и текст вроде «Тестирование чёрного ящика или поведенческое тестирование — стратегия (метод) тестирования функционального поведения объекта (программы, системы) с точки зрения внешнего мира, при котором не используется знание о внутреннем устройстве тестируемого объекта. Под стратегией понимаются систематические методы отбора и создания тестов для тестового набора. Стратегия поведенческого теста исходит из технических требований и их спецификаций». Вы зачитываете этот текст почти дословно (пропуская запятые и интонации, бо дыхания не хватит), и спрашиваете, всё ли понятно.

Пример подобного слайда

Пример подобного слайда (элементарно нагуглено)

Да, говорят вам. Понятно, чоуж.

(далее…)

Read Full Post »

Что может быть более глупым, чем «Я посмотрю, как оно работает, и напишу про это тест-кейсы»?

Read Full Post »

Я многого не знаю. Например, я не знаю, кто был тот мудак, который раз и навсегда перевёл термин agile как «гибкий». Имя есть?

Flexible — гибкий.

Agile — проворный, подвижный, верткий, живчик.

Тестирования ради, усядьтесь голым попом на горячую сковородку — вы моментально станете agile.

Впрочем, кое-что я знаю — Асхат Уразбаев первым мощно предложил опечатался про слоган внедрения agile в 2014-ом году.

Есть мнение о том, что данный способ внедрения уже известен древним пользователям русского языка (тыц, тырдыц), однако красочности он от этого не теряет.

А ещё я знаю следующее: agile не методология и не процесс. Это надстройка над уже существующей методологией и уже существующими процессами. И если их нет, то внедрять agile не на что.

То есть, у вас может не быть скрама и доски на стене, а agile может быть. У вас процесс производства может не меняться, а agile над ним — работает.

(далее…)

Read Full Post »

Сегодня осознал, что меня всё ещё называют репортёром:

Репортёр

Репортёр по версии Jira

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

Сегодня в Виннице группа успешно завершаемого винницкого буткэмпа перед приступанием к выпускному экзамену ВНЕЗАПНО одарила тренеров сладо-шняжками с очень личностными инскрипциями.

Вот моя:

Олимпийская подяка

Олимпийского уровня подяка

Наш корреспондент обнаружил вон какой клад в коробке (из-под обуви) под именным инскриптумом:

 

Read Full Post »

Коллинз - Водить как Стиг

Бен Коллинс — Водить как Стиг

В поезде читал «Водить как Стиг» Бена Коллинса (второе издание, Альпина нон-фикшн, Москва, 2018).

Высокое качество печати и оформления, отличный текст, но все-таки четыре ошибки в тексте нашел, из них две совершенно нелепые. Глаз царапает, ну да ладно.

А вот на стр. 155 разверзлись хляби подземельные, и стало ыыыы:

Санитарное тестирование

Санитарная проверка

Вах-вах-вах, не может же быть же…

Может.

Sanity check

Sanity check

Короче, нет никакого санитарного тестирования.

Само слово Sanity переводится на русский язык проще:

  • вменяемость,
  • здравомыслие,
  • нормальная психика.

Нет там никаких санитаров. То, что вы называете Sanity, по-сути есть Smoke testing.

Я ещё не знаю, когда эти термины появились, но уже давно ясно, что это два разных названия одного и того же феномена. Просто тестировщики называют это Smoke, а программисты называют это Sanity. Так они привыкли, так оно укрепилось в их литературе.

Судя по моему опыту чтения старых книг для программистов, sanity было первым.

Канер в своей книге Testing Computer Software (1988, у меня второе издание, 1999-го) не упоминает ни про smoke, ни про sanity. Самое близкое к ним есть в главе 3 ‘Test types & Software development‘ на стр. 51, и ВНЕЗАПНО оно там называется «Acceptance testing»:

Each time you receive a new version of the program, check whether it’s stable enough to be tested. If it crashes at the slightest provocation, don’t waste your time on it. This first bit of testing is called acceptance or qualification testing.

На стр. 54 та же тема с уточнениями в разделе ‘Final acceptance testing and certification‘:

If your company developed the program on contract, the customer will ran an acceptance test when you deliver it. In small projects, this test may be informal. For most projects, however, test details are agreed to in advance, in writing. Make sure the program passes the test before trying to deliver it to the customer. An acceptance test usually lasts less than a day. It is not a thorough system test. Beizer (1984) describes the preparation and execution of formal customer acceptance tests. Perry (1986) is, in effect, a customer’s guide to creating acceptance tests. Consider using Perry (1986) to structure your negotiations with the customer when you jointly design the acceptance test.

Цитата на books.google.com

Для тех, кто не может прочитать больше одного предложения в абзаце перевожу:

заранее и письменно согласуйте с заказчиком набор приёмочных тестов. Убедитесь сами в том, что релиз на них не завалится. Ранее об этом писали Бейзер (1984) и Перри (1986).

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

А вот в 2001-ом Канер уже упоминает Smoke testing в «Lessons Learned in Software Testing: A Context-Driven Approach» на страницах xxvi (это предисловие, там сходу заявлены определения ключевых терминов), 41, 121, 162, 163, 169, 141 и 144. И ни разу не упоминается sanity testing.

Рекс Блэк в «Ключевые процессы тестирования» (2004) упоминает эти два термина одновременно. В русскоязычном издании «Лори» 2006-го года они на стр. 532:

Приемочное тестирование, тестирование на исправность (Smoke Test, Sanity Test). Тестирование, проверяющее, насколько стабильная предлагаемая на тестирование версия, чтобы можно было начинать штатное тестирование. Обычно это подмножество всего комплекта тестов, как правило, автоматизированное, затрагивающее все части системы, по крайней мере, поверхностно. Качественные приемочные тесты обычно довольно долго проверяют работу системы, чтобы проявились серьезные проблемы надежности и работоспособности. Термин “smoke test” (тест на задымленность) взят из электротехники: когда инженер включает цепь, первичный тест проверяет, не дымятся ли компоненты.

Википедия

ВНЕЗАПНО сообщает о том, что сэнити — даже не из мира тестирования, термин существует сам по себе, и применим ко всем аспектам человекодеятельности, от сервировки обеденного стола до запуска ядрённой атомной бомбы на головы мирных жапонцев.

In computer science, a sanity test is a very brief run-through of the functionality of a computer program, system, calculation, or other analysis, to assure that part of the system or methodology works roughly as expected. This is often prior to a more exhaustive round of testing.

Огромное, гигантское отличие от smoke test, да?!

ISTQB (скачать файл Glossary all terms 3.1.pdf).

Sanity test объявлен синонимом smoke test (стр. 61).

В канонах ISTQB вы не сомневаетесь, не так ли?!

Толковалка ISTQB

It is a kind of software testing which is done by the testers to ensure that the functionality is working as expected.

Огромная разница со smoke test, да?!

Кто-то сделал почти тот же обзор книг в поисках тех же терминов, что и я: almeln.github.io, и пришел к тем же выводам.

О переводах: «Да, но ведь гугл переводит это слово именно так!»

Google перевод слово Sanity

Google переводит слово Sanity

Гугл переводит так, как считает правильным большинство. Там можно предлагать другие переводы слов, можно даже устроить флешмоб и добиться перевода какого-то слова совершенно по-дурацки, и гуглу будет норм.

И напоследок. Я предполагал, что ебалайтунг с терминологией присущ нашему, русскоязычному сектору. Например, вон чего на protesting.ru пишут:

В некоторых источниках ошибочно полагают, что санитарное и дымовое тестирование — это одно и тоже. Мы же полагаем, что эти виды тестирования имеют «вектора движения», направления в разные стороны.

Но он процветает и на английской стороне. Быстро нагуглилась статья на эту тему с сайта h2kinfosys.com — оба термина представлены как нечто обособленное. Понятия не имею, что это за контора из штата Джорджия (США), но о себе они говорят «H2k Infosys provides world class IT Training, Real-time Live Project to gain hands on experience, and IT Staffing services».

Надо ли возражать людям вообще?

Read Full Post »

Короче, что-то под капотом засвистело не по-детски. Но как-то смутно, как-то урывками.

То свистит.

То не свистит.

Но когда свистит — то прям ващще…

Начал искать первопричину этого автогреха. Пару дней отсиживал в засаде (за рулём), то разгоняя машину, то адски тормозя, то петляя по улицам стольного града.

И таки нашёл! 🙂

(далее…)

Read Full Post »

Доклад на «QA Fest 2016» http://qafest.com в двух частях с прологом.

Пролог от Андрея Мясникова:

Моё дополнение:

Read Full Post »

В 1979-ом году в США появилась книга  «Искусство тестирования программ» (‘The Art of Software Testing’). Автор: Гленфорд Майерс (Glenford Myers), ученый, программист, круто «шарил» в микропроцессорах.

Удивление: её первый перевод на русский язык вышел в СССР [при Брежневе] в 1982-ом, под редакцией Бориса Позина!

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

Там же уточняется, что

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

Там же уточняется, что

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

Перевод терминов местами необычен, так, термин Stress testing полагалось переводить как «тестирование стрессов», но переводчики решили переводить его как «тестирование на предельных нагрузках». А «Комплексное тестирование» (System testing) решили переводить как «тестирование системы». Есть нюансы…

Выводы:

  • предки были не такими уж и «валенками» в программировании и тестировании;
  • современные тестировщики весьма упрощенно воспринимают программирование и тестирование, и местами мы даже не «валенки», а «пляжные тапочки».

Не каждый из нас легко растолкует разницу между стохастическим и не стохастическим тестированием. И даже понятие «детерминированное тестирование» легко вызовет лёгкую дрожь в конечностях.

  • не надо трыднеть о том, что тестирование — молодая отрасль, и терминология не устоялась, и что всё ещё впереди. Надо сперва основы осваивать, чтобы под ногами почва не шаталась.
  • тестирование всё ещё остаётся искусством, в котором требуется проявление личностных качеств. Это означает, что каждому новичку необходимо тренироваться личностно, а не гуглить в залежах древних книг, бо «уметь» тут важнее, чем «знать».
  • тестирование в глобальном плане изменилось, и QA требуется редко где и когда. QC превалирует.
  • учиться тестировать по книге Майерса не надо. Оно писано для программистов, оно не учит тестированию, оно объясняет некоторые его аспекты.
  • «черный» и «белый» ящики во времена Майерса называются «стратегией тестирования», тогда как это всего лишь метафоры, а не стратегии.

Read Full Post »

Говорил тут с младшим коллегой про вечные ценности, про Negative и Positive testing.

Ну, он и запутался в разнице между добром и недобром… Бывает.

Я на листочке написал:

«Negative ————- Normal ————— Positive»

и говорю, мол, вот три основных вида тестирования, давай говори детально, что каждый из них означает…

Он по-серьезному начал придумывать, что означает ‘Normal testing’. И почти даже сумел придумать.

Ну не прекрасная ли я сволочь?! 🙂

Говорю: «Если примешь за постулат существование «нормального тестирования», следовательно, все остальное тестирование будет называться ненормальным…»

Как видим, теория тестирования пухнет и расширяеццо. Будем ее пухнять и расширять этим летом в Виннице, в тесных рамках QA Boot Camp 2016.

Be equipped for QA Engineer position in Astound Commerce!

QA Boot Camp is an amazing opportunity to join worldwide ecommerce leader — Astound Commerce! Only the best talents will start career in international professional team to perform and deliver interesting projects.

QA Boot Camp will be conducted during the evening time on workdays. Participants will be granted with diplomas after successful completion.

Participation is free of charge.

В класс допускаются домашние животные.

Read Full Post »

Priority

Приоритет показывает степень важности выполнения задачи ДЛЯ БИЗНЕСА.

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

Рекомендуется использовать всего три уровня приоритета:

  1. Приоритетно,
  2. Не приоритетно,
  3. .

Все очень просто, не так ли? Или задача приоритетна, или нет. Tertium, кагбэ,  non datur.

Если еще более по-взрослому говорить, то приоритизация означает не простое «Давайте расположим все по-важности и будем выполнять последовательно». Оно означает необходимость от чего-то отказаться, чтобы выполнить самое важное [подробности], но это уже слишком сложные материи…

(далее…)

Read Full Post »

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

А загляните в череп опытного заказчика ПО — он требования прописывает сам. Всегда. Да, общепонятно, что через требования он хочет получить хотя бы именно, что было заказано, но засада не в том, что «без ТЗ результат ХЗ» (можно ваять ПО и без предварительного малевания ТЗ). Проблема в коммуникациях. Чем более опытным становится заказчик, тем сильнее он эту проблему осознает и начинает решать.

(далее…)

Read Full Post »

***: Я вчера с другой стороны на Бейзера посмотрел. Именно с той, про которую ты говорил, что это «объяснение тестирования для программистов«. С учетом их мышления и специфики.

>>>: И как оно?

***: Просто по другому.
Не Савин.
Не Копленд.
Не Канер.
єто как Достоевского и Пелевина сравнивать.

В ту же оперу ходил и Гленфорд Майерс, до речі. ‘Art of Software Testing‘ написана для программистов, и учиться по ней классическому функциональному тестированию /того же карандаша/ крайне сложно.

(далее…)

Read Full Post »

Older Posts »

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