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

Archive for the ‘Озарения’ Category

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

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

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

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

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

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

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

Ну, и чо?

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

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

(далее…)

Read Full Post »

Robert C. Martin написал книгу «Clean Agile: Back to Basics».

Любомир Геревич не знает, кто дядя Боб. Так вот, это один из тех семнадцати чуваков, которые собрались в феврале 2001-го в Snowbird ski resort в Юте для того, чтобы потрындеть о том, как можно было бы обустроить жизнь программистскую.

На этом фото Роберт Мартин третий слева.

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

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

Read Full Post »

В наше время считается нормой учиться тестированию и при этом НЕ учиться программированию. Но ведь тестирование само по себе не имеет смысла — это подчинённый процесс, придуманный программистами для программирования.

Старые книги

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

(далее…)

Read Full Post »

The main ability of a tester is to have no fear for discuss requirements and asking for

  • whole picture first,
  • details.

The main behaviour of a tester is do not rush with any conclusions about software and to always start with

  • Stop! Explain this software, even if it looks understandable. What are the purposes of this software? Why this functionality is needed? How it should work?
  • Stop! I need a time for think (analyze this).
  • Stop! What are the final expectations?

The basic skill of a tester is to imagine (and to write them as scenarios) a chain of situations

  • where the software is intended to work ‘as expected’ (correct user login),
  • those that may happen, and should be tolerated by software (wrong user login),
  • those that should not be tolerated, even if they are possible (wrong data encoding).

Read Full Post »

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

Read Full Post »

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

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

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

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

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

Read Full Post »

Техник разработки тестов очень много, и каждый тестировщик может придумать свою технику. ©

Триста раз «ха-ха-ха»!

Read Full Post »

Зачитано на «QA Fest 2016» http://qafest.com в Киеве 1 октября 2016.

Видео после текста.

— Будем рассуждать о том, во что превратилось обучение тестировщиков в наше время, и что с ним будет в ближайшем будущем.

В 2014 году в Киеве было под тридцать курсов по тестированию. И ещё плюс в Одессе и во Львове. Для Украины это было не так, чтобы мало, и большое количество курсов обещало то, что (наконец-то) на рынке появится много обученных тестировщиков. Их можно будет брать на работу и кидать на проекты — бизнес пошёл! Ожидалось, что количество будет переходить в качество.

И вот вам 2016 год. Сколько сейчас курсов для начинающих тестировщиков? Ну, чуть меньше. Но все равно их много. В Украине сегодня много тестировщиков. Много начинающих тестировщиков. Много плохих тестировщиков. Спасибо всем причастным к созданию этой ситуации (я среди них, безусловно).

(далее…)

Read Full Post »

Бо нет предела.

Read Full Post »

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

То свистит.

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

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

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

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

(далее…)

Read Full Post »

— …Вообще, поскольку терминология у нас англоязычная, то англоязычные англоязычники её воспринимают вообще иначе, нежели мы. Например, «Regression testing» наши изначально воспринимают как «Блаблабла тестинг», и просто ждут её определения (любого), бо звуки ничего не подсказывают. А они понимают слова по-отдельности, и эти слова по-отдельности очень многое подсказывают сами по себе. Как мы легко расшифровываем термины вроде «минсоцоблтруда». Бо контекст есть.

— Ну это-то то понятно.

— Понятно-то понятно… Например, ты знаешь про самую крутую технику тест-дизайна — редбрик тестинг?

— Нет. Рассказывай.

— Был бы ты англоязычным человеком, ты уже спросил бы «Что за ерунда, бро, какое ещё красно-кирпичное тестирование?». А так… можно любой фуфломицин всучить под этим редбрик тестингом, и никто не будет сомневаться. Будут потом на конференциях доклады об этом делать.

— Ты сволочь.

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

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 »

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

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

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

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

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

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

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

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

Выводы:

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

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

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

Read Full Post »

Обложка книги "Тестирование черного ящика"

Обложка книги «Тестирование черного ящика»

В начале декабря 2015-го я неосторожно пообещал Никите Макарову (папа автоматизации тестирования в «Одноклассниках») объяснить, почему книга Бориса Бейзера — это про тестирование, но не для тестировщиков, а для программистов, поэтому и читать ее надо не так, как Канера.

Судя по календарю, я невероятно шустр и быстр, а Никита — неизменно крут и терпелив.

Итак, да, изрядное кол-во любопытных тестировщицких зубов обломалось о книгу Бориса Бейзера «Тестирование черного ящика», йо-хо-хо!

Мои там тоже остались 😦

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

Перевод там гнилой, что ли?

Ну…

(далее…)

Read Full Post »

Таки додумался, почему State Transition testing не вызывает моментального ой-вэй эффекта у большинства увязнувших в тестировании.

State-Transition Testing

Вот это самое «State-Transition Testing»

Трабла уже описана профессором Преображенским в соответствующей литературе в качестве первопричины разрухи.

Тут надо думать «исходное Состояние системыДействиеиное Состояние системы».

А мы с «деццва» учимся продумывать тест-кейсы как «ДействиеРезультат действия».

Вот «кружочки» и не получаются.

А получается что-то вроде ‘Product available in the CartProceed to CheckoutCheckout Page opened‘. Бред-то какой, полюбуйтесь на вашего Полиграфа…

Ну а потом начинается извечная шумерская жалобная песнь для успокоения сердца (просто выберите любимое и добавьте воды):

  • У нас нет времени на тест-дизайн…
  • На нашем проекте это не используется…
  • Никто на проекте не говорит, какую именно технику надо использовать…
  • Я тестирую только экивалентность и границы значений, и этого достаточно…
  • Пожалуйста, спасите-помогите…
  • Все эти техники — для задротов, реально они ничего не приносят…
  • Я буду это применять, если это реально поможет уменьшать количество тестов…
  • Тест-кейс — это когда надо проверить, что по шагам надо выполнять, и софт работает…
  • Я клоун…

Что надо сделать

  1. определить happy path — их может быть несколько.
  2. определить другие сценарии и ветвления к ним.
  3. выводить в отдельные ветки всё, даже если они подразумевают переход к одному и тому же состоянию (есть множество исключений, но это должно быть основным подходом; впоследствии он сэкономит силы и нервы).
  4. стрелка — действие. Круг — состояние, а не результат действия, как мы привыкли писать в тест-кейсах.
  5. не запихивать всё в один рисунок. Пусть будет много рисунков. Переключайтесь между листами.
  6. если что-то пошло не так и надо перерисовывать — будете материться, а не ерзать ластиком. Проще будет быстро нарисовать правильную последовательность заново, поэтому рисуйте без детальной детализации.

Read Full Post »

Older Posts »

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