Подяка за хорошу статтю!
Питання: як боролися з овертаймами? Для написання автоматизації потрібно знаходити час, а коли команда завалена роботою — це непроста задача. Бачив кейс, коли тести писалися ввечері дома після роботи) Такий кейс можна назвати умовно успішним :)
+! У мене теж подібний режим. Нещодавно помітив, якщо на вихідних не виходити за рамки режиму — понеділок і п’ятниця проходять набагато легше і продуктивніше.
-! Складно проводити час з дружиною) Вона любить лягати близько 01 і вставати близько 10...
Вангую, що кандидат проходив курси в «Тренинговый центр QATestLab». Там всіх дрюкають на такий формат репортів
Хорошая статья. Спасибо
Дяки за хорошу статтю!
Не думали в бік підтримки Лінукс?
Так, це негативне тестування. Але чи негативне тестування — це креш тестування?
Хоча, стосовно визначення вами преведеного, ви маєте рацію.
Дякую)
Проведення певних маніпуляцій над тестуємим продуктом з метою викликати його збій.
Це моє особисте бачення цього питання. І я не претендую в данному випадку на авторитетність
от із визначення Soft Serve IT Academy, яке в коментарі вище, моє бачення підпадає під стресове тестування. А в визначеннях stress testing SWEBOK, stress testing IEEE 610, з коментаря нижче, взагалі не вказано про падіння продукту
Я говорю про людей які працюють в сфері QAздається ви пишете ЗА людей, які працюють в сфері QA
давайте до конструктивного діалогу без давління авторитетом. без образ))
особисто мені подобається вислів: «документація придумана для тих, хто неспроможний самостійно приймати рішення»
Звісно це жарт, але в ньому доля глузду, інакше б QA не займалися тестуванням технічної документації і не вводили туди поправки
Знову спробую донести свою думку, що задокументований прецендент не виключає наявність незадокументованого прецендента.
да, собственно, собеседование прошел)
Дякую, змістовна відповідь.
Так, якщо я намагаюсь досягнути креша, то
найбільш очікувана поведінка — система впадеАле, коли я проводжу стресове тестування, то я очікую, що система витримає. Падіння системи в такому випадку, для мене небажана поведінка.
Згоден, креш тестування — це негативне тестування. Але негативне — це не тільки креш.
Я теж проймаюся глибокою повагою до ISTQB, але дух бунтарства з мене ще не вивітрився)
Ще не дуже зрозуміло, кого ви маєте на увазі пишучи «ми»
ми на неї посилаємось і вважаємо її одним з найавторитетніших баз знань
Я не претендую на експертність в данному питанні. Але в той же час не прихильник інцеклопедійних знань. Оскільки в джерелах записані знання, які вже колись були застосовані, але це не виключає наявність інших знань.
Визначення, які я давав дуже спрощенні і приблизні. Продукт має вести себе адекватно при стресовому тестуванні тому, що я очікую, що робота продукта буде стабільною і/або він зможе самовідновитися. Якщо мої очікування не виправдалися, значить я виявив баг.
Проте, при крешовому тестуванні, я очікую, що продукт крешнеться, щоб виявити слабкі місця.
Переїжджайте в Черкаси. р. Дніпро, розвинута ІТ сфера, активний громадський простір, просте планування міста = простий трафік, садочок за системою Монтессорі, «Друг» опікується бродячими собаками, дороги в області не дуже, в місті йде капремонт, кримінал — не чули, мова переважно російська і місцева.
Переїхав 8 років тому з Києва, вважаю місто одним з найкращих.
Дорога Вінниця-Умань достатньо хорошанавіть на 3 не тягне, їхали там два тижні тому. Місцеві кажуть там завжди така дорога. Одна смуга в один бік, видавлені кишки, обігнати когось нереально
Я готовий працювати безкоштовно на реальних проектах, навіть сам інколи шукаю таку можливість. Але тільки у вільний час і тільки в цілях розвитку. Теорія класно, книги можна читати, але реальна практика розвиває в рази швидше
У нас немає розділення на автоматизатори і мануальщики, тому активність на автотести треба просто вкладати в план. На щастя у нас і спринтів немає, інакше було б тяжко)