22 htop’a, 22 прихлопа

Команда htop в перезагрузочном тестировании под Убунтой рулит неимоверно. Иначе и быть не может.

htop - это interactive process viewer.

Для сравнения два экрана прямо из консоли:

• первый экран - результат работы команды top.
• второй - результат работы команды htop. Обе запущены одновременно и отображают работу одного и того же компьютера.

Good programmers are really smart people

“Qualities of a Good Tester” by Boris Beizer

Back in the 60’s, there were many studies done to try to predict the ideal qualities for programmers.

There was a shortage and we were dipping into other fields for trainees. The most infamous of these was IBM’s programmers’ Aptitude Test (PAT).

Strangely enough, despite the fact the IBM later repudiated this test, it continues to be (ab)used as a benchmark for predicting programmer aptitude.

What IBM learned with follow-on research is that the single most important quality for programmers is raw intelligence - good programmers are really smart people - and so are good testers.

QA vs/and Developers

What QA needs from Developers

Information

1. What the product is and how it works
2. How the product is intended to be used
3. What parts of it are at greater risk of failure
4. The schedule for remaining development
5. Status and details of any changes or additions to the product
6. Status of reported problems

Services

1. Provide timely information to the testers
2. Respond quickly to reported problems
3. Stay synchronized with the project schedule
4. Collaborate to set an appropriate standard of quality
5. Involve testers in all decisions that may impact them
6. Seek to understand the test process

What Developers need from QA

Information

1. Problems found
2. What will be tested
3. Schedule for testing
4. Status of the current test cycle
5. What information testers need to work effectively

Services

1. Provide timely information to development
2. Seek to understand the general process of creating software
3. Seek to understand the product and it’s underlying technologies
4. Respond quickly to new builds
5. Stay synchronized with the schedule, don’t delay the project
6. Collaborate to set an appropriate standard of quality

Excerpted from “Working With Testers” by James Bach Copyright 1997, Satisfice, Inc. http://www.satisfice.com

Мое больше начальство тоже ушло в отпуск

Это религия

1. В то время программисты приступили к Тестировщику и сказали: кто лучше работает - тот, кто багов не плодит, или тот, на чье имя в Mantis до черта багов заведено?
2. Тестировщик, призвав джуниор-программера, поставил его посреди них
3. и сказал: истинно говорю вам, если не обратитесь и не будете как дети джуниор-программеры, не войдете в будущую Корпорацию Загребающих Баблосы;
4. и тот, кто беспокотся о количестве багов, занесенных в Mantis на его имя, не войдет в будущую Корпорацию;
5. ибо даже если багов в Mantis будет не менее 1000 - это не означает, что программиста надо бить батогами нещадно,
6. особенно, если разрабатываемая версия всего лишь 1.0.
7. Как вам кажется? Если бы у кого было сто овец, и одна из них заблудилась, то не оставит ли он девяносто девять в горах и не пойдет ли искать заблудившуюся?
   

   Хотя не, это из другой оперы…

8. Дык вот, все баги, найденные нами (девелоперами и тестировщиками) в софте - просто библиотека, которая содержит информацию о ВОЗМОЖНЫХ проблемах, которые мы будем учитывать во время будущей работы. Истинно вам говорю.
9. И кто примет одно такое соображение, тот принимает Качество продукта;
10. а кто соблазнит одного из малых сих, верующих в Качество, тому лучше было бы, если бы повесили ему мельничный жернов на шею и потопили его во глубине морской.
11. Вот если баги будут находить только пользователи, а не мы - тогда достойны мы все быть битыми, бедными и бледными;
12. ибо уже сто раз сказано - there are no best practices, there are only good practices in some context.

Усталые, но просветленные, программисты возвращались к рабочим машинам, писать свой глючный и корявый софт. Особенно если разрабатываемая версия - всего лишь 1.0…

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

Exploratory Learning

1. Plan to explore the product with each iteration.
2. Look for bugs, missing features and opportunities for improvment.
3. We don’t understand software until we have used it.

Парадоксы времени

Неделя ушла на подготовку нагрузочного тестирования.

Сегодняшний рабочий день составил 12 часов - беготня между машинами, наладка, доводка и все такое прочее согласование.

А сам тест-убийца занял ровно 15 минут. На уровне 200 threads сервер начал “задыхаться” уже через минуту. Затем отключился

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

“Скоропостижно скончался сиг“…

Это из Шефнера…

Что такое Performance testing

Краткая поясняющая записка.

Performance testing может ответить на такие вопросы:

• Скорость – Как быстро откликается приложение на запросы любопытных тестировщиков?
• Масштабируемость^* – Меняется ли производительность приложения в зависимости от количества тестировщиков, которые хотят ее растерзать?
• Стабильность – Грудью ли выдерживает система внезапное изменение количества запросов, или в страхе падает перед могучим исследовательским гением тестировщиков?
• Уверенность – Как долго система выдерживает продолжительный набег тестировщицких орд? Вы уверены?

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

Нагрузка на мозг

green

Работы по нагрузочному тестированию можно условно разделить на четыре этапа:

1. Разработка моделей нагрузок и проектирование тестовых сценариев. Это работа аналитика.
2. Разработка и отладка тестовых скриптов. Работа программиста.
3. Организация и проведение нагрузочных тестов. Эта работа требует неплохих знаний системного администратора.
4. Проведение анализа результатов тестирования. Неплохо бы иметь вкупе навыки и знания архитектора, системного аналитика, DBA.

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

Для Москвы нормальный уровень стоимости услуг составляет порядка 50-100 долларов за час работы (зависит от объема, сложности, кто представляет программу для тестирования и еще многих вопросов). При этом речь идет не о работе одного человека, а команды, которая проводит комплексное исследование и выдает результат не на уровне “померить быстродействие системы”, а с анализом и рекомендациями об устранении “узких мест”.

“Тестирование” - шо це таке?

(с) Автор мне неизвестен.

План проверки двери

1. Функциональные проверки.

1.1. Проверить, что дверь открывается.
1.2. Проверить, что дверь закрывается.
1.3. Попытаться закрыть уже закрытую дверь.
1.4. Попытаться открыть уже открытую дверь.

2. GUI (интерфейс пользователя)

2.1. Проверить табличку на двери.
2.2. Проверить покраску двери.
2.3. Проверить наличие дверной ручки.

3. Permissions

3.1. Проверить, что правильным ключом дверь открывается.
3.2. Проверить, что неправильным ключом дверь не открывается.
3.3. Проверить, что закрытую на ключ дверь нельзя открыть.
3.4. Проверить, что не закрытую на ключ дверь можно открыть без ключа.
3.4. Позвонить в дверь. Если там никого нет, дверь не должна открыться сама.
3.5. Постучать в дверь. Если там кто-то есть и он спросит “кто?”, ответить “Полиция”. Дверь должна открыться.

4. Stress/Loading

4.1. Открывайте и закрывайте дверь со скоростью 120 циклов в минуту
4.2. Открывайте и закрывайте дверь со скоростью 6 раз в минуту на протяжении 48 часов.
4.3. Стучите в дверь с частотой 1200 стуков в минуту.
4.4. Стучите в дверь с частотой 10 раз в минуту на протяжении 24 часов.
4.5. Открывайте и закрывайте дверь ключом на протяжении 12 часов.

5. End to end

5.1. Постучать в дверь. Позвонить в звонок. Открыть ключом. Открыть дверь. Закрыть дверь. Закрыть ключом. Прочитать табличку на двери. Ничего не отвалилось, не звякает, не взрывается?

6. Usability

6.1. Проверить, что ручка двери помещается в ладонь.
6.2. Проверить, что ручка находится именно на двери, а не на соседней стене на высоте 20 см.
6.3. Проверить, что высота двери больше человеческого роста
6.4. Проверить, что усилие для поворота ключа в двери в пределах допустимого
……..

* Проверить функциональность двери при температуре 38, 45 и -15 градусов Цельсия.
* Проверить функциональность двери при различной относительной влажности, днем и ночью, в июле и с декабре.
* Проверить, что пол и социальное происхождение открывающего никак не влияют на результаты.

Добавка

1. Начать с использования двери одним человеков. Увеличивать количество пользователей с шагом 5 человек в 5 сек. Увеличивать нагрузку, пока дверь не сломается.

2. Проверка документации к двери - инструкции пользователя, технического паспорта..

3. Проверка сердцебиения и давления открывающего. Действия по открыванию-закрыванию не должны пожирать все ресурсы пользователя.

4. Проверить влияние функционирования двери на появление трещин в стене.

5. White box tests: проверить волокна древесного полотна на параллельность. Проверить отдельные элементы (классы) на предмет избыточности (а может там 6 замочных скважин). Проверка алгоритма запирания двери.

В релизе не проверено

• Отсутствуют проверки на стрессовость (удар ногой или головой)
• Отсутствуют проверки на крепеж двери к косяку
• Отсутствуют проверки соседнего модуля - косяка (зазоры между ним и дверью)
• Отсутствуют проверки между дверью и полом.
• Отсутствуют проверки на …