Развлекуха, длиной в жизнь, применимо к АЙты, когда отрицательный результат является желанным
Законченные мысли
1. Баг — это отклонение фактического результата от ожидаемого.
2. Главный источник ожидаемого результата — спецификация.
3. Спецификации сами не без греха, и в этом случае, как и в случае
полного их отсутствия, у нас есть здравый смысл, устоявшиеся
стандарты, опыт работы, статистика, авторитетное мнение и др.
QA призвано улучшить ПО через улучшение процесса
разработки ПО;
• тестирование — через обнаружение багов.
Качество (как и его отсутствие) — это результат
• деяний всех участников процесса разработки ПО, а также
• отлаженности и настроек самого процесса.
1. Цель тестирования — это нахождение багов до того, как их найдут пользователи.
2. Нехватка ресурсов не позволит стопроцентно протестировать сколько-нибудь сложное ПО.
3. Не имеет никакого значения, сколько багов было найдено до релиза.
4. Статистика багов, найденных после релиза, и ее последующий анализ могут помочь идентифицировать проблемные участки процесса разработки ПО. Сопоставление статистики от релиза к релизу дает, как правило, устойчивый паттерн проблемы, если
таковая существует.
5. QA направлено на превентирование багов, тестирование — на поиск багов.
6. Тестировщики одни не могут обеспечить качество ПО. Обеспечение качества — это задача всех участников процесса разработки ПО. Важными факторами, влияющими на качество,
являются отлаженность и настройки самого процесса разработки ПО.
Перечисляющиеся в тест-кейсе шаги должны быть объективно четкими и ясными.
Нужно помнить, что ожидаемый результат — это информация, на основании которой (вкупе с фактическим результатом) мы принимаем решение об исходе тесткейса. Следовательно, точность и четкость в формулировке ожидаемого результата играют наиважнейшую роль.
Тестирование — это процесс творческий и, следовательно, подразумевает поиск. Ищите, пока не найдете то, что эффективно работает именно в вашей компании и в конкретной
ситуации.
Тест-кейс — это инструмент тестировщика, предназначенный для документирования и проверки одного или более ожидаемых результатов.
2. Шаги (procedure) — это часть тест-кейса, ведущая исполнителя тест-кейса к фактическому результату (выводу). Излишняя детализация может осложнить поддержку, а излишнее
абстрагирование привести к непониманию того, как исполнить тест-кейс.
3. Шаги для повторяющихся сценариев можно вынести в отдельный документ в локальной сети, и в тест-кейсе мы даем лишь ссылку на этот документ.
4. Исполнение тест-кейса завершается либо положительным (pass), либо отрицательным (fail или баг!!!) результатом. Причем именно отрицательный результат является желанным, так как
мы нашли баг.
5. Исполнение тест-кейса не является завершенным, если исполнитель не смог "пройти" все шаги.
6. Тест-кейс должен быть независим от других тест-кейсов из того же или любого другого тест-комплекта.
7. Наиполезнейшими вещами являются следующие атрибуты тест-кейса:
• уникальный ID, который уникален в пределах всех существующих в компании тест-кейсов;
приоритет, чтобы все знали, кто здесь главный;
• идея, которая на простом языке объясняет предназначение тест-кейса;
• подготовительная часть, которая... ну, в общем, подготавливает нас к исполнению тест-кейса;
• история редактирования, которая помогает указать на друзей, испортивших наши идеальные тест-кейсы и наших легковерных попугаев.
8. Поддерживаемость тест-кейса — это легкость и удобство, с которыми он может быть изменен. Поддерживаемость тест-кейса — одна из основных формальных вещей при создании или модификации тест-кейса.
9. Тест-кейс "проверяет" не более одной идеи. При этом два и более ожидаемых результата легитимны, если истинность идеи вытекает из одновременной истинности этих ожидаемых
результатов.
10. К плохому стилю относятся:
а) зависимость тест-кейсов друг от друга;
б) нечеткая формулировка шагов;
в) нечеткая формулировка идеи тест-кейса и/или ожидаемого
результата.
11. Тест-кейсы объединяются в тест-комплекты (как правило, один тест-комплект — это один файл).
12. Как правило, тест-комплект включает тест-кейсы, родственные друг другу тем, что они проверяют определенный участок нашего интернет-проекта или вещи, описанные в определенном спеке.
13. Хорошим стилем является создание нового тест-комплекта для новых тест-кейсов.
14. Тест-кейсы, написанные после проработки спека (до того, как представилась возможность "пощупать" написанное по нему ПО), являются сырыми, и никто не посмеет бросить в тестировщика камень осуждения, если он впоследствии изменит тест-кейсы по мере их исполнения.
15. Создавая или модифицируя тест-кейсы, мы всегда должны помнить о том парне, который будет их исполнять после нас.
16. Состояние тест-кейса: "У них все, как у людей. Рождаются, изменяются и умирают..." — "Новый", "Измененный", "Более недействителен". Хорошая практика — не удалять (remove)
отжившие свой век тест-кейсы (или целые тест-комплекты), а переносить их (move) в отдельную директорию, специально созданную для таких пенсионеров.
17. Важно понять, что в сегодняшнем разговоре речь шла о форме, а не о содержании тест-кейсов. Содержание конкретного тест-кейса — это отражение методологии нахождения багов
применительно к конкретной ситуации, и этой методологии будут посвящены отдельные беседы.
почерпнуто из увлекательных повестей Романа Савина
Законченные мысли
1. Баг — это отклонение фактического результата от ожидаемого.
2. Главный источник ожидаемого результата — спецификация.
3. Спецификации сами не без греха, и в этом случае, как и в случае
полного их отсутствия, у нас есть здравый смысл, устоявшиеся
стандарты, опыт работы, статистика, авторитетное мнение и др.
QA призвано улучшить ПО через улучшение процесса
разработки ПО;
• тестирование — через обнаружение багов.
Качество (как и его отсутствие) — это результат
• деяний всех участников процесса разработки ПО, а также
• отлаженности и настроек самого процесса.
1. Цель тестирования — это нахождение багов до того, как их найдут пользователи.
2. Нехватка ресурсов не позволит стопроцентно протестировать сколько-нибудь сложное ПО.
3. Не имеет никакого значения, сколько багов было найдено до релиза.
4. Статистика багов, найденных после релиза, и ее последующий анализ могут помочь идентифицировать проблемные участки процесса разработки ПО. Сопоставление статистики от релиза к релизу дает, как правило, устойчивый паттерн проблемы, если
таковая существует.
5. QA направлено на превентирование багов, тестирование — на поиск багов.
6. Тестировщики одни не могут обеспечить качество ПО. Обеспечение качества — это задача всех участников процесса разработки ПО. Важными факторами, влияющими на качество,
являются отлаженность и настройки самого процесса разработки ПО.
Перечисляющиеся в тест-кейсе шаги должны быть объективно четкими и ясными.
Нужно помнить, что ожидаемый результат — это информация, на основании которой (вкупе с фактическим результатом) мы принимаем решение об исходе тесткейса. Следовательно, точность и четкость в формулировке ожидаемого результата играют наиважнейшую роль.
Тестирование — это процесс творческий и, следовательно, подразумевает поиск. Ищите, пока не найдете то, что эффективно работает именно в вашей компании и в конкретной
ситуации.
Тест-кейс — это инструмент тестировщика, предназначенный для документирования и проверки одного или более ожидаемых результатов.
2. Шаги (procedure) — это часть тест-кейса, ведущая исполнителя тест-кейса к фактическому результату (выводу). Излишняя детализация может осложнить поддержку, а излишнее
абстрагирование привести к непониманию того, как исполнить тест-кейс.
3. Шаги для повторяющихся сценариев можно вынести в отдельный документ в локальной сети, и в тест-кейсе мы даем лишь ссылку на этот документ.
4. Исполнение тест-кейса завершается либо положительным (pass), либо отрицательным (fail или баг!!!) результатом. Причем именно отрицательный результат является желанным, так как
мы нашли баг.
5. Исполнение тест-кейса не является завершенным, если исполнитель не смог "пройти" все шаги.
6. Тест-кейс должен быть независим от других тест-кейсов из того же или любого другого тест-комплекта.
7. Наиполезнейшими вещами являются следующие атрибуты тест-кейса:
• уникальный ID, который уникален в пределах всех существующих в компании тест-кейсов;
приоритет, чтобы все знали, кто здесь главный;
• идея, которая на простом языке объясняет предназначение тест-кейса;
• подготовительная часть, которая... ну, в общем, подготавливает нас к исполнению тест-кейса;
• история редактирования, которая помогает указать на друзей, испортивших наши идеальные тест-кейсы и наших легковерных попугаев.
8. Поддерживаемость тест-кейса — это легкость и удобство, с которыми он может быть изменен. Поддерживаемость тест-кейса — одна из основных формальных вещей при создании или модификации тест-кейса.
9. Тест-кейс "проверяет" не более одной идеи. При этом два и более ожидаемых результата легитимны, если истинность идеи вытекает из одновременной истинности этих ожидаемых
результатов.
10. К плохому стилю относятся:
а) зависимость тест-кейсов друг от друга;
б) нечеткая формулировка шагов;
в) нечеткая формулировка идеи тест-кейса и/или ожидаемого
результата.
11. Тест-кейсы объединяются в тест-комплекты (как правило, один тест-комплект — это один файл).
12. Как правило, тест-комплект включает тест-кейсы, родственные друг другу тем, что они проверяют определенный участок нашего интернет-проекта или вещи, описанные в определенном спеке.
13. Хорошим стилем является создание нового тест-комплекта для новых тест-кейсов.
14. Тест-кейсы, написанные после проработки спека (до того, как представилась возможность "пощупать" написанное по нему ПО), являются сырыми, и никто не посмеет бросить в тестировщика камень осуждения, если он впоследствии изменит тест-кейсы по мере их исполнения.
15. Создавая или модифицируя тест-кейсы, мы всегда должны помнить о том парне, который будет их исполнять после нас.
16. Состояние тест-кейса: "У них все, как у людей. Рождаются, изменяются и умирают..." — "Новый", "Измененный", "Более недействителен". Хорошая практика — не удалять (remove)
отжившие свой век тест-кейсы (или целые тест-комплекты), а переносить их (move) в отдельную директорию, специально созданную для таких пенсионеров.
17. Важно понять, что в сегодняшнем разговоре речь шла о форме, а не о содержании тест-кейсов. Содержание конкретного тест-кейса — это отражение методологии нахождения багов
применительно к конкретной ситуации, и этой методологии будут посвящены отдельные беседы.
почерпнуто из увлекательных повестей Романа Савина
Немає коментарів:
Дописати коментар