ਜੇਕਰ ਕੋਈ ਵੀ ਤੁਹਾਡੇ ਟੈਸਟ ਸੂਟ ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ (failures) 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦਾ, ਤਾਂ ਉਹ ਬੇਕਾਰ ਹੈ। ਟੀਮਾਂ ਹੋਰ ਟੈਸਟ, ਵਧੇਰੇ ਡੈਸ਼ਬੋਰਡ, ਜਾਂ ਪੈਰਲਲ ਐਗਜ਼ੀਕਿਊਸ਼ਨ (parallel execution) ਜੋੜਦੀਆਂ ਹਨ, ਫਿਰ ਵੀ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਲਾਲ ਬਾਕਸ ਦੇ ਗਾਇਬ ਹੋਣ ਦੀ ਉਮੀਦ ਵਿੱਚ ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਣਾ ਪੈਂਦਾ ਹੈ। ਇਹ ਆਦਤ ਇੱਕ ਸੰਭਾਵੀ ਕੀਮਤੀ ਸਿਗਨਲ ਨੂੰ ਮਹਿੰਗੇ ਸ਼ੋਰ (noise) ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ ਹੈ।

ਅਸਲ ਸਮੱਸਿਆ ਭਰੋਸੇ ਦੀ ਹੈ, ਕਵਰੇਜ ਦੀ ਨਹੀਂ

ਜ਼ਿਆਦਾਤਰ ਇੰਜੀਨੀਅਰਿੰਗ ਗਰੁੱਪ ਟੈਸਟਾਂ ਦੀ ਕਮੀ ਜਾਂ ਅਧੂਰੇ ਬ੍ਰਾਊਜ਼ਰ ਕਵਰੇਜ ਨੂੰ ਦੋਸ਼ੀ ਮੰਨਦੇ ਹਨ। ਅਸਲ ਵਿੱਚ, ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਸ਼ੋਰ (noise) ਵਜੋਂ ਲਿਆ ਜਾਂਦਾ ਹੈ। ਡੈਸ਼ਬੋਰਡ 'ਤੇ 96% ਪਾਸ ਰੇਟ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਤੁਹਾਨੂੰ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ 4% ਅਸਫਲਤਾਵਾਂ ਨੇ ਅਸਲ ਖਾਮੀਆਂ (defects) ਲੱਭੀਆਂ ਜਾਂ ਉਹਨਾਂ ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਣ ਲਈ ਕਈ ਵਾਰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਲੋੜ ਪਈ। ਜਦੋਂ ਡਿਵੈਲਪਰ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹਨ, ਤਾਂ ਟੈਸਟ ਸੂਟ ਫੈਸਲੇ ਲੈਣ ਵਿੱਚ ਮਦਦ ਕੀਤੇ ਬਿਨਾਂ ਸਮਾਂ ਅਤੇ ਕੰਪਿਊਟ ਰਿਸੋਰਸਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

ਪਾਸ ਰੇਟ ਗੁੰਮਰਾਹਕੁੰਨ ਕਿਉਂ ਹੋ ਸਕਦੇ ਹਨ

ਪਾਸ-ਰੇਟ ਮੈਟ੍ਰਿਕਸ ਸਾਰੇ ਨਤੀਜਿਆਂ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਨੰਬਰ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਦੋ ਮਹੱਤਵਪੂਰਨ ਸਵਾਲ ਛੁਪ ਜਾਂਦੇ ਹਨ:

  • ਕੀ ਅਸਫਲਤਾਵਾਂ ਨੇ ਅਸਲ ਖਾਮੀਆਂ ਨੂੰ ਪ੍ਰਗਟ ਕੀਤਾ? ਇੱਕ ਫਲੇਕੀ (flaky) ਟੈਸਟ ਜੋ ਕਦੇ ਵੀ ਬੱਗ ਨਹੀਂ ਫੜਦਾ, ਕੋਈ ਮੁੱਲ ਨਹੀਂ ਜੋੜਦਾ।
  • ਕਿੰਨੀ ਵਾਰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ (retries) ਕਰਨ ਦੀ ਲੋੜ ਪਈ? ਇੱਕ ਸੂਟ ਜੋ ਤਿੰਨ ਆਟੋਮੈਟਿਕ ਰੀਟ੍ਰਾਈਜ਼ ਤੋਂ ਬਾਅਦ ਪਾਸ ਹੁੰਦਾ ਹੈ, ਉਹ ਭਰੋਸੇਯੋਗ ਨਹੀਂ ਹੈ, ਭਾਵੇਂ ਅੰਤਿਮ ਪਾਸ ਰੇਟ ਉੱਚਾ ਹੀ ਕਿਉਂ ਨਾ ਹੋਵੇ।

ਇੱਕ ਟੈਸਟ ਸੂਟ ਜੋ 99% ਸਫਲਤਾ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ ਪਰ ਵਾਰ-ਵਾਰ ਚੈੱਕਆਊਟ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਮਿਸ ਕਰ ਦਿੰਦਾ ਹੈ, ਉਹ ਉਸ ਸੂਟ ਨਾਲੋਂ ਕਿਤੇ ਬੁਰਾ ਹੈ ਜੋ 92% ਸਮੇਂ ਪਾਸ ਹੁੰਦਾ ਹੈ ਪਰ ਹਰ ਰੈਵੇਨਿਊ-ਪ੍ਰਭਾਵਿਤ ਬੱਗ ਨੂੰ ਫੜ ਲੈਂਦਾ ਹੈ। ਟੀਚਾ ਕੋਈ ਉੱਚਾ ਪ੍ਰਤੀਸ਼ਤ ਪ੍ਰਾਪਤ ਕਰਨਾ ਨਹੀਂ ਹੈ; ਇਹ ਜੋਖਮ ਬਾਰੇ ਬਿਹਤਰ ਫੈਸਲਾ ਲੈਣਾ ਹੈ।

ਮਹੱਤਵਪੂਰਨ ਮੈਟ੍ਰਿਕਸ

ਪਾਸ-ਰੇਟ 'ਤੇ ਧਿਆਨ ਦੇਣ ਦੀ ਬਜਾਏ ਅਜਿਹੇ ਮਾਪਦੰਡਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ ਜੋ ਸੂਟ ਦੀ ਉਪਯੋਗਤਾ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ:

  • ਅਸਫਲਤਾ ਦੀ ਦੁਹਰਾਓ (Failure recurrence) – ਇੱਕੋ ਟੈਸਟ ਲਗਾਤਾਰ ਚਲਾਉਣ 'ਤੇ ਕਿੰਨੀ ਵਾਰ ਫੇਲ ਹੁੰਦਾ ਹੈ।
  • ਖਾਮੀ ਦੀ ਪਛਾਣ ਕਰਨ ਦੀ ਦਰ (Defect detection rate) – ਅਸਫਲਤਾਵਾਂ ਦਾ ਉਹ ਹਿੱਸਾ ਜੋ ਪੁਸ਼ਟੀ ਕੀਤੇ ਗਏ ਬੱਗ ਬਣ ਜਾਂਦੇ ਹਨ।
  • ਨਿਦਾਨ ਲਈ ਲੱਗਣ ਵਾਲਾ ਸਮਾਂ (Time to diagnosis) – ਇੱਕ ਫੇਲ ਹੋ ਰਹੇ ਟੈਸਟ ਨੂੰ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਸਮਝਿਆ ਅਤੇ ਉਸ 'ਤੇ ਕਾਰਵਾਈ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।
  • ਰੀਟ੍ਰਾਈ 'ਤੇ ਨਿਰਭਰਤਾ (Retry dependence) – ਉਹਨਾਂ ਟੈਸਟਾਂ ਦੀ ਬਾਰ-ਬਾਰਤਾ ਜਿਨ੍ਹਾਂ ਨੂੰ ਪਾਸ ਹੋਣ ਲਈ ਆਟੋਮੈਟਿਕ ਰੀ-ਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
  • ਐਸਕੇਪਡ ਰੈਗਰੈਸ਼ਨ (Escaped regressions) – ਉਹ ਖਾਮੀਆਂ ਜੋ ਸੂਟ ਦੇ ਬਾਵਜੂਦ ਨਿਕਲ ਜਾਂਦੇ ਹਨ।

ਇਹਨਾਂ ਸਿਗਨਲਾਂ ਨੂੰ ਟ੍ਰੈਕ ਕਰਨ ਨਾਲ ਤੁਹਾਨੂੰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਅਸਫਲਤਾ ਇੱਕ ਚੇਤਾਵਨੀ ਹੈ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਕਾਰਵਾਈ ਕਰ ਸਕਦੇ ਹੋ ਜਾਂ ਇਹ ਸਿਰਫ਼ ਇੱਕ ਫਲੇਕ (flake) ਹੈ।

ਰੱਖ-ਰਖਾਅ (Maintenance) ਦੀ ਲੁਕੀ ਹੋਈ ਲਾਗਤ

ਇੱਕ ਟੈਸਟ ਜਿਸਨੂੰ ਲਿਖਣ ਵਿੱਚ ਦਸ ਮਿੰਟ ਲੱਗਦੇ ਹਨ ਪਰ ਮਹੀਨੇ ਵਿੱਚ ਉਸਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਤਿੰਨ ਘੰਟੇ ਲੱਗਦੇ ਹਨ, ਉਹ ਇੱਕ ਮਾੜਾ ਨਿਵੇਸ਼ ਹੈ। ਰੱਖ-ਰਖਾਅ ਦੀ ਲਾਗਤ ਉਦੋਂ ਵਧ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਟੈਸਟ ਨਾਜ਼ੁਕ ਹੁੰਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਲਗਾਤਾਰ ਡੇਟਾ ਅਪਡੇਟ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜਾਂ ਉਹ ਅਸਥਿਰ UI ਸਿਲੇਕਟਰਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ। ਜਦੋਂ AI ਟੈਸਟ ਬਣਾਉਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਖਰਚਾ ਬਹੁਤ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ ਬਣਾਏ ਗਏ ਟੈਸਟ UI ਬਦਲਣ 'ਤੇ ਹਰ ਵਾਰ ਟੁੱਟ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਟੈਸਟ ਬਣਾਉਣ ਦੀ ਰਫ਼ਤਾਰ ਦਾ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਰਹਿ ਜਾਂਦਾ।

AI-ਨਿਰਮਿਤ ਟੈਸਟਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦੇ ਸਮੇਂ, ਇਹ ਪੁੱਛੋ:

  • ਟੈਸਟ ਨੂੰ ਕਿੰਨੀ ਵਾਰ ਮੈਨੂਅਲ ਐਡੀਟਿੰਗ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ?
  • ਇਹ ਕਿੰਨੀ ਸਪੱਸ਼ਟਤਾ ਨਾਲ ਦੱਸਦਾ ਹੈ ਕਿ ਇਹ ਕਿਉਂ ਫੇਲ ਹੋਇਆ?
  • ਅਸਫਲਤਾ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਇੱਕ ਇਨਸਾਨ ਨੂੰ ਕਿੰਨੇ ਸੰਦਰਭ (context) ਦੀ ਲੋੜ ਹੈ?

ਜੇਕਰ ਜਵਾਬ ਵਾਰ-ਵਾਰ ਮਨੁੱਖੀ ਦਖਲਅੰਦਾਜ਼ੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ, ਤਾਂ ਆਟੋਮੇਸ਼ਨ ਦਾ ਫਾਇਦਾ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ।

ਆਬਜ਼ਰਵੇਬਿਲਟੀ (Observability): ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਕਾਰਵਾਈਯੋਗ ਬਣਾਉਣਾ

4,000 ਲਾਈਨਾਂ ਵਾਲਾ ਲੌਗ (log) ਜਿਸ