In Software Engineering, there seems to be a general acceptance that as long as there is software then there will always be software bugs.
Bugs in software are defects that produce incorrect or unexpected results or cause the software to behave in unintended ways. The majority of bugs in software arise from errors written in developers’ source code; yet it is generally the primary task of QA testers to find said bugs.
Nonetheless, testing for bugs in software should be the responsibility of the entire team: developers typically focus on unit testing to exercise units of source code in isolation whereas testers concentrate more on functional testing to verify the correctness of software end-to-end.
Developers benefit from unit testing simply because it allows them to find problems in the source code quicker: they can zone in on code at the lowest (unit) level and assert the code functions as expected.
It also facilitates difficult-to-reproduce scenarios, such as database offline, by using mock frameworks developers can fake external dependencies, and ensure the code is resilient to unhandled exceptions.
To summarize: the earlier bugs are detected, the cheaper they are to fix.
Writing testable code allows developers to push the boundaries and effectively "break their software". By proactively breaking their software, developers identify defects before anyone else does. These defects can, and should, be fixed immediately before any further work continues. This way, the software is more robust: stability is built into the code base and quality software can be delivered at speed as you code with confidence.
Test Driven Development is a formal way to break your software: you do not write one line of production code unitl you have written a test that fails. Implement the code to make the test pass and no more. Rinse and repeat. This style of programming does come at a cost but the additional time spent during development should be supplemented by a reduced QA cycle as fewer bugs are reported.
One final thought: in a world of abundant choice, people pay for quality in products and services that are important to them. Software is no exception. So go ahead: break your software (before anyone else does) and deliver the best software you can.
Subscribe to:
Post Comments (RSS)
3 comments:
Hi Steven, great post, I agree with almost everything you say. As long as there is software there will always be bugs, the challenge we face however is to ensure that we address the most prominent customer impacting bugs in an efficient manner within the constraints(time generally) of the project. Where I think our opinions may differ is in our definitions of what a bug is, in my opinion, a bug is anything that bugs a customer. Writing all the units tests in the world does improve the quality of a solution if the solution in question does not solve the customers core problem or pain point. So it's our responsibility to understand the customer, their specific problem before we start worrying about the technical Implementation.
Good post. Developers have to take responsibility for their code. Some people think our job is done as soon as it looks like it runs okay...if there are problems, QA will find it. This does not work! Or scale! As you point out, developers are uniquely positioned to think about how their code may break. It is so much harder for QA to do this.
Thanks for sharing this information. InnovationM is the best website design agency and mobile app development company in London, UK. Top andoid app developers and iOS app developers, web designers in birmingham and Software development company in UK. Best legal website design company in Birmingham, London, Luton, Derby, Sheffield, UK.
Post a Comment