Автоматизація сама на проектах не з’являється, її хтось має писати.
Ця картинка знайома багатьом. Але як зрушити справу з мертвої точки? Якщо, навіть, не для проекту, а для свого розвитку?
Ми чуємо від керівництва "На даному етапі нам не потрібна автоматизація."
І це так!
Їм не потрібна автоматизація саме тих перевірок, що Ви їм запропонували, якщо її будете робити Ви замість тієї робити, на яку Вас найняли, та ще й так недолуго, як Ви зараз це робите.
З їхньої точки зору - суцільні мінуси!
На початку завжди важко і повільно, бо якість коду прямо залежить від кількості годин зосередженого вдивляння в цей код. Тому:
1. Автоматизація тестів API (апі), так званий та добре знаний Back-end.
Якщо ви вже щось тямите в автоматизації, негайно робіть спроби "продавати" свої навички вашому роботодавцю! Покажіть на якомусь прикладі, як автоматизований контроль рятує дупи/гроші/час. Ви можете сто разів це розказувати, але люди рідко задумуються над тим, що не торкається їх особисто.
Знайдіть штуку, яка постійно ламається, і напишіть тести, що будуть постійно її моніторити, щоб як найраніше знати, коли воно зламається наступного разу. Добрий тестер має швидко визначати вузькі місця процесу та контролювати їх.
3. Те, що не часто змінюється
Якщо Ви вже покрили автотестами усі точки з попередніх пунктів, то можна братися і за UI. Знайдіть щось, що із найменшою імовірністю попаде під зміни у найближчий час. Тобто, найбільш стабільну та незмінну частину.
Ви можете спитати:
Навіщо перевіряти щось, що ніколи не ламалось?
Зворотнє питання:
Скільки збитків понесе проект, якщо зламається те, що ніколи не ламалось?
Перше питання підсвідомо передбачає, що перевірок не може бути нескінченна кількість у скінченний час, тобто, що перевірка займає час та коштує гроші. Це безперечно так для мануальних перевірок. Але вартість автоматизованої перевірки порівняно із вартістю ручної прямує до нуля.
Чим частіше ми запускаємо автоматизовану перевірку, тим меншою стає її питома вартість.
4. Все, що вважаєте за потрібне
Багато хто починає автоматизацію саме звідси. І дарма. Бо Ваші пріоритети та очікування дуже часто геть не співпадають із пріоритетами замовника, не дивлячись на те, що тестувальник "має думати як бізнес".
Менеджери дивляться на Ваші кволі спроби зробити щось, потреби у чому вони зараз не бачать, і що можливо матиме якусь користь у невизначеному майбутньому... WTF?!
І ми чуємо "На даному етапі нам не потрібна автоматизація."
І це так! Їм не потрібна автоматизація тих перевірок, що Ви їм запропонували, якщо її будете робити Ви замість тієї робити, на яку Вас найняли, та ще й так недолуго, як Ви це робите зараз.
З їхньої точки зору - суцільні мінуси!
То ж треба:
- Вам навчитись писати код добре;
- знайти ті перевірки, що приноситимуть користь бізнесу;
- ускладнити та розширити перевірки разом із своїми навичками.
Ця картинка знайома багатьом. Але як зрушити справу з мертвої точки? Якщо, навіть, не для проекту, а для свого розвитку?
Ми чуємо від керівництва "На даному етапі нам не потрібна автоматизація."
І це так!
Їм не потрібна автоматизація саме тих перевірок, що Ви їм запропонували, якщо її будете робити Ви замість тієї робити, на яку Вас найняли, та ще й так недолуго, як Ви зараз це робите.
З їхньої точки зору - суцільні мінуси!
На початку завжди важко і повільно, бо якість коду прямо залежить від кількості годин зосередженого вдивляння в цей код. Тому:
1. Автоматизація тестів API (апі), так званий та добре знаний Back-end.
- Це нескладно, бо є тільки код. Без UI, локаторів та інших аджаксів.
- Це розумно, тому що API змінюється набагато рідше за UI.
- Це перспективно! Чи ви бачили у вимогах на вакансію тестера слова REST, SOAP, XML, JSON? Так отож! За вміння легко десереалізувати JSON-об’єкти будь-якою мовою програмування зараз непогано платять.
Якщо ви вже щось тямите в автоматизації, негайно робіть спроби "продавати" свої навички вашому роботодавцю! Покажіть на якомусь прикладі, як автоматизований контроль рятує дупи/гроші/час. Ви можете сто разів це розказувати, але люди рідко задумуються над тим, що не торкається їх особисто.
Знайдіть штуку, яка постійно ламається, і напишіть тести, що будуть постійно її моніторити, щоб як найраніше знати, коли воно зламається наступного разу. Добрий тестер має швидко визначати вузькі місця процесу та контролювати їх.
3. Те, що не часто змінюється
Якщо Ви вже покрили автотестами усі точки з попередніх пунктів, то можна братися і за UI. Знайдіть щось, що із найменшою імовірністю попаде під зміни у найближчий час. Тобто, найбільш стабільну та незмінну частину.
Ви можете спитати:
Навіщо перевіряти щось, що ніколи не ламалось?
Зворотнє питання:
Скільки збитків понесе проект, якщо зламається те, що ніколи не ламалось?
Перше питання підсвідомо передбачає, що перевірок не може бути нескінченна кількість у скінченний час, тобто, що перевірка займає час та коштує гроші. Це безперечно так для мануальних перевірок. Але вартість автоматизованої перевірки порівняно із вартістю ручної прямує до нуля.
Чим частіше ми запускаємо автоматизовану перевірку, тим меншою стає її питома вартість.
4. Все, що вважаєте за потрібне
Багато хто починає автоматизацію саме звідси. І дарма. Бо Ваші пріоритети та очікування дуже часто геть не співпадають із пріоритетами замовника, не дивлячись на те, що тестувальник "має думати як бізнес".
Менеджери дивляться на Ваші кволі спроби зробити щось, потреби у чому вони зараз не бачать, і що можливо матиме якусь користь у невизначеному майбутньому... WTF?!
І ми чуємо "На даному етапі нам не потрібна автоматизація."
І це так! Їм не потрібна автоматизація тих перевірок, що Ви їм запропонували, якщо її будете робити Ви замість тієї робити, на яку Вас найняли, та ще й так недолуго, як Ви це робите зараз.
З їхньої точки зору - суцільні мінуси!
То ж треба:
- Вам навчитись писати код добре;
- знайти ті перевірки, що приноситимуть користь бізнесу;
- ускладнити та розширити перевірки разом із своїми навичками.
Немає коментарів:
Дописати коментар