Skip to main content
Software Quality Assurance & Testing

Return to Answer

Copy edited (e.g. ref. <https://english.stackexchange.com/questions/4645/is-it-ever-correct-to-have-a-space-before-a-question-or-exclamation-mark#comment206109_4645> and <https://www.youtube.com/watch?v=1Dax90QyXgI&t=17m54s> ). "logic" is an uncountable noun in this context.
Source Link
edit approved Jun 17, 2020 at 4:40
Peter Mortensen
edit approved Jun 17, 2020 at 4:40
Peter Mortensen
  • 171
  • 7

Just add on to the answer, a peer review is not just about the code review, it. It helps in  :

  1. Identifying improvements in code logicslogic

  2. Identifying improvements or missed application logicslogic in the test script.

  3. Identifying easier test approaches to improve test coverage

  4. Identifying better approaches to solve a problem  .

and so on,.

weWe all will have mind block and author bias when we code, so it is always good to have a second opinion. It doesn't make us look bad, but it gives aan opportunity to learn.

For example, in the initial coding days iI used to write test focused on feature features. Example For example, for a payment system iI will test whether a field throws an error for invalid inputs and shows a proper message for valid inputs. but iBut I missed to validate whether the payment works for all the valid inputs, and instead iI was testing it with one valid input and assumed everything else will also worksworked.

I was just validating the message feature and not the actual flow.

During code review one colleague suggested testing the end to end-to-end flow for all valid inputs and guess what !!?! theThe system was failing for one corner case.

Just add on to the answer peer review is not just about the code review, it helps in  :

  1. Identifying improvements in code logics

  2. Identifying improvements or missed application logics in the test script.

  3. Identifying easier test approaches to improve test coverage

  4. Identifying better approaches to solve a problem  .

and so on,

we all will have mind block and author bias when we code, so it is always good to have a second opinion. It doesn't make us look bad but gives a opportunity to learn.

For example, in initial coding days i used to write test focused on feature . Example , for a payment system i will test whether a field throws an error for invalid inputs and shows proper message for valid inputs. but i missed to validate whether the payment works for all the valid inputs, instead i was testing it with one valid input and assumed everything else will also works.

I was just validating the message feature and not the actual flow.

During code review one colleague suggested testing the end to end flow for all valid inputs and guess what !!! the system was failing for one corner case

Just add on to the answer, a peer review is not just about the code review. It helps in:

  1. Identifying improvements in code logic

  2. Identifying improvements or missed application logic in the test script.

  3. Identifying easier test approaches to improve test coverage

  4. Identifying better approaches to solve a problem.

and so on.

We all will have mind block and author bias when we code, so it is always good to have a second opinion. It doesn't make us look bad, but it gives an opportunity to learn.

For example, in the initial coding days I used to write test focused on features. For example, for a payment system I will test whether a field throws an error for invalid inputs and shows a proper message for valid inputs. But I missed to validate whether the payment works for all the valid inputs, and instead I was testing it with one valid input and assumed everything else will also worked.

I was just validating the message feature and not the actual flow.

During code review one colleague suggested testing the end-to-end flow for all valid inputs and guess what!?! The system was failing for one corner case.

deleted 17 characters in body
Source Link
PDHide
PDHide
  • 11.1k
  • 2
  • 16
  • 43

Just add on to the answer peer review is not just about the code review, it helps in :

  1. Identifying improvements in code logics

  2. Identifying improvements or missed application logics in the test script.

  3. Identifying easier test approaches to improve test coverage

  4. Identifying better approaches to solve a problem .

and so on,

we all will have mind block and author bias when we code, so it is always good to have a second opinion. It doesn't make us look bad but gives a opportunity to learn.

For example, in initial coding days i used to write test focused on feature . Example , for a payment system i will test whether a field throws an error for invalid inputs and shows proper message for valid inputs. but i missed to validate whether the payment works for all the valid inputs, instead i was testing it with.

Instead i was using only one valid input to check the full flow , forand assumed everything else iwill also works.

I was just validating the message feature and not the actual flow.

During code review one colleague suggested testing the end to end flow for all valid inputs and guess what !!! the system was failing for one corner case

Just add on to the answer peer review is not just about the code review, it helps in :

  1. Identifying improvements in code logics

  2. Identifying improvements or missed application logics in the test script.

  3. Identifying easier test approaches to improve test coverage

  4. Identifying better approaches to solve a problem .

and so on,

we all will have mind block and author bias when we code, so it is always good to have a second opinion. It doesn't make us look bad but gives a opportunity to learn.

For example, in initial coding days i used to write test focused on feature . Example , for a payment system i will test whether a field throws an error for invalid inputs and shows proper message for valid inputs. but i missed to validate whether the payment works for all the valid inputs i was testing it with.

Instead i was using only one valid input to check the full flow , for everything else i was just validating the message feature and not the actual flow.

During code review one colleague suggested testing the end to end flow for all valid inputs and guess what !!! the system was failing for one corner case

Just add on to the answer peer review is not just about the code review, it helps in :

  1. Identifying improvements in code logics

  2. Identifying improvements or missed application logics in the test script.

  3. Identifying easier test approaches to improve test coverage

  4. Identifying better approaches to solve a problem .

and so on,

we all will have mind block and author bias when we code, so it is always good to have a second opinion. It doesn't make us look bad but gives a opportunity to learn.

For example, in initial coding days i used to write test focused on feature . Example , for a payment system i will test whether a field throws an error for invalid inputs and shows proper message for valid inputs. but i missed to validate whether the payment works for all the valid inputs, instead i was testing it with one valid input and assumed everything else will also works.

I was just validating the message feature and not the actual flow.

During code review one colleague suggested testing the end to end flow for all valid inputs and guess what !!! the system was failing for one corner case

Source Link
PDHide
PDHide
  • 11.1k
  • 2
  • 16
  • 43

Just add on to the answer peer review is not just about the code review, it helps in :

  1. Identifying improvements in code logics

  2. Identifying improvements or missed application logics in the test script.

  3. Identifying easier test approaches to improve test coverage

  4. Identifying better approaches to solve a problem .

and so on,

we all will have mind block and author bias when we code, so it is always good to have a second opinion. It doesn't make us look bad but gives a opportunity to learn.

For example, in initial coding days i used to write test focused on feature . Example , for a payment system i will test whether a field throws an error for invalid inputs and shows proper message for valid inputs. but i missed to validate whether the payment works for all the valid inputs i was testing it with.

Instead i was using only one valid input to check the full flow , for everything else i was just validating the message feature and not the actual flow.

During code review one colleague suggested testing the end to end flow for all valid inputs and guess what !!! the system was failing for one corner case