“QA-Gramotno” – откровения, “постановка мозгов” и открытия, которые должен делать каждый тестировщик.
Подразумевается, что плох тот QC, который не хочет стать QA, но что для этого нужно? Грамотный подход нужен…
Домен
Был выбран после прочтения официального документа “О тестировании” в одной из компаний, в которой я работал. Сам процесс тестирования там был описан достаточно подробно и толково, но в самом конце этого документа, было написано: The time consumed for testing should be as short as possible.
Автор
Алексей Лупан, тестировщик.
Заместитель гл. редактора Software-testing.ru.
Жрец храма Панбагон.
Skypе: astenix
Е-mаil: astenix@testitquickly.com
RSS (регулярность обновления – нерегулярно)
Когда работаю в Windows-environment, много записей о Unix не предполагается. И наоборот.
Всегда рассматриваю интересные предложения о работе в любых режимах.
В моем профиле в LinkedIn есть много интересных людей (доступно при тамошней регистрации).
Специализация
Ручное тестирование веб-ориентированных аппликух:
- интернет-магазины,
- трейдинг ценными бумагами (и неликвидными тоже),
- социальные сети (так уж получилось).
По мере необходимости использую Selenium IDE как подспорье в ручном тестировании, особенно в сфере regression testing.
Когда-то решил стать опытным тестировщиком, и целенаправленно учился тестированию комплексных веб-систем.
Свободно работаю в Windows и Unix, в том числе и без GUI.
Опытным путем научился бережно относится к уже работающим процессам в компании, и умею внедрять процесс тестирования без резких изменений.
Рабочее предложение
Поскольку постоянное тестирование необходимо не всем и не всегда, а дело это недешевое, я продаю трехчасовые тест-сессии:
- пришел на три часа в офис (или удаленно),
- провел пару раундов тестирования,
- написал подробный отчет о состоянии приложения и о проделанной работе.
По стоимости работочасов мои услуги стоят столько же, сколько и работа постоянного тестировщика. Но поскольку я прихожу лишь при действительной необходимости, такой подход обходится проекту В РАЗЫ дешевле, а результаты иногда сопоставимы с работой full-time работников.
География
Кишинев, Киев, Москва.
Тэги
- Ability to work within tight deadlines
- Agile,
- Aircraft Services
- Apache,
- Complex Distributed and Client-Server Application (especially in back-end side)
- Content Management Systems
- CSS
- HTML
- International Finance, Trading,
- Jira, Mantis, Bugzilla
- Jmeter, Grinder
- Managing test-team
- Manual testing,
- Mercury TestDirector (v. 8.0)
- Mobile wap-portals
- MySQL, PostgreSQL
- Performance testing,
- Reuters 3000 Xtra
- Selenium
- SVN
- Ubuntu and Red Hat Linux systems (Gnome and KDE environment)
- Vista mazdai
- Web-oriented applications,
- Wiki systems
- Window 95/98/2000/XP/Vista
Открытая страница из моего гугловского блогридера – записи с тэгом “Тестировщики”.
Переводы
Читаю блоги о тестировании на английском, французском и румынском языках (румынские тестировщики предпочитают жить в Канаде и писать в сети только на английском пиджине). Иногда что-то из прочитанного перевожу для себя.
Не стремлюсь передать текст полностью; чаще это пересказ, зачастую – тезисный.
Запись чужих выступлений
Мне удобнее и быстрее прочитать текст, нежели прослушать или просмотреть видео с чьим-то выступлением на тему тестирования.
Поэтому те выступления, интервью и презентации, которые мне очень интересны, я собственоручно “перевожу” в текст. Это занимает много времени, несмотря на все мои уловки и хаки, но результат важнее.
После согласования текста с автором “звука”, я публикую итоговый материал у себя в разделе Переводы. Согласование необходимо потому, что “слова на бумаге” иногда выглядят неадекватно, даже у самых адекватных людей.
Живьем
Прочитать текст с плаката.
This page has the following sub pages.
Комрад, порадовал коллегу !
Спасибо!
Твои тексты – как свежий ветер в этой долбанной индустрии
Приятно читать.
Вдохновляет.
а можно поныть в жилетку ?
вот у меня … сейчас что я делаю знаешь ?
есть больше сотни багов исправленных программерами
мне нужно перепроверить что они исправлены
читаешь описание , воспроизводишь , пишешь да или нет
+ свои комменты
берёшь следующий
как рабочий на заводе
взял заготовку, выточил гайку напильником, положил её в ящичек
взял другую заготовку и так дальше …. ВСЮ ЖИЗНЬ
а денег – гавно (это самый интересный аспект)
Направь, Отче !
Адеса – Мама, специально для вас есть уникальное заграничное средство. Даже два, хотя они весьма полярны по своему свойству. Следует выбрать одно и не “слезать” с него до самого финиша.
“Просветлин”
- быстро и не оглядываясь чекаем баги, закусывая их чем-то вкусным (рулет с халвой, например). Главное тут – скорость. Потому что реально скучно…
- в процессе чеканья ищешь по-наитию места, где могут быть ещё не обнаруженные баги. Менеджеры и программисты к такому не готовы, и начнут ныть, что дэдлайн и вообще пора домой. И начнут бояться страшного тестировщика, который даже в процессе банального багчеканья находит новые дефекты. Вероятно, они покумекают и незаметно подкинут ещё рулета, чтобы тестировщик расслабился…
Цель этого средства: превратить пациента в самого главного тестировщика, который надсматривает за теми, кто лишь недавно начал возиться с гайками и напильниками.
Тут главное – чтобы программеры не поймали вечером где-то на Степовой улице и не побили за все баги и рулеты с халвой разом.
“Нирванин”
- Жизнь есть страдание. Страдание есть получение зарплаты. Зарплата есть сплошное страдание. Сколько ни напрягайся, будет не зарплата, а одно страдание.
Собственно, ясно, отчего многие рабочие уважают культуру неумеренного пития? Весь день возишься с заготовками, и к вечеру сам как заготовка.
Могу честно сказать, что на уровне менеджеров наличествует та же мантра, но в слегка ином обличье.
И программисты тоже могут изрядно порассказать о долгих часах своей бессмысленной работы, когда надо кодить, кодить, кодить, кодить, кодить, кодить, кодить, кодить, спеки – пространные мифы древних греков, тим-лид – зверь, а продакт-менеджер с ним заодно…
ЗЫ Самый интересный аспект непропорционально увеличивается в зависимости от разности выполняемых задач и наработанных умений эти самые задачи выполнять. Еще раз: непропорционально, но увеличивается если растет количество и качество умений.
Ишшо один вариант поведения описан в Почему тестировщиков всегда будет мало
С удовольствием полазил по сайту и почитал статьи. Нашел для себя много полезного. Но смутило отсутствие очень привычной и полезной кнопки подписки по RSS..
Спасибо.
Сейчас сделаю.
Алексей, спасибо! Очень свежо и интересно! Буду чаще заглядывать.
С уважением.
Спасибо! Прикольно =)
Отличный сайт!
Здравствуйте, Алексей!
Хочу предложить Вам следующую статью для раздела “переводы”.
Top Five (Wrong) Reasons You Don’t Have Testers
(http://www.joelonsoftware.com/articles/fog0000000067.html)
Примечателен пункт 4: Anybody qualified to be a good tester doesn’t want to work as a tester.
Хорошо перекликается с Вашей статьей “Почему тестировщиков всегда будет мало”.
- Albert
Спасибо.
Эта статья уже переведена.
Оригинал на русском Джоэле.
К слову, хорошим тестировщиком истинный программист Джоэль считает тетю, которая находила какие-то хитрые комбинации (“Она нажала Alt!”). А это свойство весьма осбуждаемо. Оно очень полезно ПОСЛЕ того, как проверена корректность работы всех требований и спецификаций… Хотя и весьма способствует ореолу “Эти хитрые тестеры как-то не так кнопки нажимают…”
“ПОСЛЕ того, как проверена корректность работы всех требований и спецификаций…”
Тут бы самое время заявиться Майклу Болтону (который не певец, а бизнес-партнер Джеймса Маркуса Баха) с авторитетнейшим утверждением: “тестеру никакие требования (requirements) и спецификации (test specifications) не нужны! В процессе тестирования правильный настоящий тестер сам во всем разберется! Эксплоратори тестинг форева, и все айда на мой платный курс рапид тестинга. “
Реально неуравновешенного Болтона мы будем побивать Джо Страццерой, который аж в 2006 году сказал, что “There are ALWAYS Requirements“…
Э, нет, уже не получилось однажды. Был у меня такой блогодиалог (http://automationbeyond.wordpress.com/2009/11/25/7-questions-on-testing-vs-checking/) с Майклом Болтоном, и я ссылался как раз на указанный пост (“There are ALWAYS…”). Но этот увертливый тип заявил, что я все не так понял, и requirements и specifications вообще противоположные понятия.
Цитирую.
“Execution steps are specification. That is, execution steps are specific actions to take or ideas to follow. I think you’re confusing requirements (documents) with specification.
Testers don’t need requirements documents or specifications to discover or reveal or infer requirements. Testers can then compare their discoveries or inferences with the client’s actual requirements—the advantage being that testers can alert clients to requirements of which they were not previously aware.”
Спасибо, много интересного для себя почерпнул.