I have been studying software engineering for the past six years now, and my fascination with how broad this field is, is still growing. I had my undergraduate degree from King Saud University, one of the most prestigious schools in the Middle East. Nevertheless, I felt my undergrad degree barely scratched the surface of the software engineering field. Therefore, my enthusiasm and interest in discovering more about this area had led me to pursue my Master's degree in software engineering at George Mason University. Pursuing my master's degree in software engineering has indeed opened my eyes to more critical and widely discussed subjects in the software engineering field. Among these topics, two have grabbed my attention more, software testing, …show more content…
Thomas LaToza at George Mason University has taught me, during the User Interface design and development class, one of the big ideas of software engineering that made me think of a new way to solve the quality versus complexity problem in software testing. This big idea is computers and developers should know each other's interpretation of the code. For instance, developers use UML and other techniques to understand the way the computer going to execute their code. On the other hand, developers write test suites to tell the computer their interpretation of the code. Thus, if there are bugs or low-quality test suites, there must be some conflicts on how developers and computers interpret the code. Thinking about this big idea drives a new question in my head. What if we improve the communication between developers and computers, would that improve the development experience as well as the quality of test …show more content…
Hence, I went and worked in some of the open source projects [2] to observe any possible flaws in the way developers and computers interact during the process of software testing and development. After a while, I have noticed a fundamental problem in the way we approach software testing. My observation was that software testing is usually done before or after the software implementation, TDD vs. the traditional way of testing. This could be the reason for why software testing feels sometimes hard. In other words, because both approaches treat software testing and implementation as different phases, developers build their tests suites with a lower level of understanding of the problem comparing to the original level of understanding of the same problem they have while they are coding. Therefore, the differences in the level of understanding in both stages often yields insufficient test