Рейтинг
+9.61
голосів:
9
avatar

Quality Assurance  

Про один баг

Недавно дізнався про одну цікаву історію.
В 1983 році коли холодна війна була чимось значно реальнішим чим вона є зараз, відбулась цікава подія. 26 вересня система раннього оповіщення СССР повідомила про наближення 5 міжконтинентальних балістичних ракет. В той час командував пан Станіслав Петров.
Холодно подумавши, він вирішив не запускати систему зворотнього удару та не повідомляти керівництво, хоча мав би це зробити без обдумувань. Тим самим він спас світ від Третьої Світової. Через декілька місяців виявили збій в системах сповіщення.

А мораль історії така:
* шановні ембеддед розробники! будьте уважні, через ваші баги можуть загинути люди!
* деякі фічі за деяких умов є насправді багами
* якщо б це була повністю автоматична система, ми б зараз не обговорювали її баги =)

Чому тестування вимагає так багато часу?

Сага в двох томах Серія із двох записів від Майкла Болтона (Michael Bolton) дають пояснення, чому часто тестування займає більше часу, ніж було заплановано. На простому прикладі він показує, що проблеми у продукті мають великий вплив на можливіть забезпечити достатнє тестове покриття.

Частина перша: Why Is Testing Taking So Long? (Part 1)

Частина друга: Why Is Testing Taking So Long? (Part 2)

Sad story about quality

  • +8
  • 25 листопада 2009, 15:06
  • lemon
  • 8+8

Кілька слів про тестування Chrome OS від Google Testing Blog тема-посилання

Сім абзаців про те, як відбувається тестування Chrome OS у Google, які засоби і підходи використовують. Обіцяють продовження. Будемо відслідковувати.

Ідея подарунка для тестувальника

Сьогодні 19 листопада, а отже через місяць наші офіси пахнутимуть мандаринками, а більші ніж звичайно збіговиська людей біля кавових автоматів обговорюватимуть, що знайшли під подушками цієї ночі. Якщо ви ще не визначилися, що дарувати колезі-тестувальнику або чим з нагоди свята потішити себе — нижче є ідея.

( Читати далі )

Моя уніфікована теорія вад

Пропоную вам переклад статті одного з інженерів Google, який спеціалізується на автоматизації тестування програмного забезпечення.

Я гадаю, що вади можна поділити на три основні категорії.

* Логічні. Логічні вади є основними, і найчастішими. Це ваші if'и, цикли та інша логіка в коді. Вони на сьогоднішній день є найбільш поширеним видом помилок у програмному забезпеченні. (Думка: це є неправильно).
* Вади взаємодії. Вади взаємодії — це коли два різних об'єкти не правильно взаємодіють один з одним. Наприклад, вивід імені у полі «прізвище». Також яскравим прикладом є ситуація, коли один об'єкт дає на вихід не те, чого від нього очікує інший.
* Вади відображення. Вади відображення — це коли вивід (зазвичай, якийсь ГК або репорт) відображається некоректно. Ключовий момент — у тому, що правильність і неправильність відображення визначає людина. (Думка: вигладає неправильно).

ЗАУВАЖЕННЯ: Деякі розробки гадають, що з часів, як вони почали використовувати графічний користувацький інтерфейс, усі вади стали вадами відображення! Під вадами відображення розуміються помилки, на кшталт, виходу тексту на кнопці за її межі. Якщо ж ви натискаєте на кнопку, і відбувається щось неправильне — це швидше за все, вада взаємодії або ж логічна вада. Вади відображення є досить рідкими.


( Читати далі )

Principles of automated testing

Principles of automated testing
Automated Testing is the use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions Commonly, test automation involves automating a manual process already in place that uses a formalized testing process.
In general, Automated Testing can be divided into two groups:

— Functional testing
— Performance testing



( Читати далі )