How to estimate effort for unit testing?
Is that a right question to ask at all during effort estimation stage? When taking workshop with software developers involved SCRUM methodology, I came across some of the following answers in relation with effort estimation vis-a-vis unit testing: No task was created for unit tests and hence, no effort was estimated. Thus, we didn’t write any unit tests. We had to deliver and we were running short of time; hence, we skipped unit testing? There are effort estimation done for functional tests by QA engineers; Then, why unit tests? Interestingly, some stakeholders on client end said about of software developers on offshore side not asking for tasks to be estimated …
Unit Tests & What do they say?
Ask software developers about what do they mean by unit testing, and if they believe in it? And, the answer you get are some of the following: Unit testing is about writing tests for each of the method of the class. It is written only when you get some extra time after the code completion? Unit testing is done only when we are asked by our customers. Unit testing takes additional time and hence, done only if time permits. Test-driven development… What is that? Not sure if there are any benefits by writing unit tests? Test coverage… What is that? Why do we write unit tests when we are software …
What are Functional & Non-Functional Requirements?
When gathering requirements for software application/module development, requirements gathering remain as one of the key challenges for stakeholders at different levels including project manager, tech lead, software developers and test engineers. Interestingly, due to inefficient requirement gathering, most of the project fails. Following is definition of functional requirements as per wikipedia: In software engineering, a functional requirement defines a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs (see also software). Functional requirements may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish. Read further here. …
ISO/IEC Standards for Software Quality Compliance
What are various different ISO/IEC standards related with software quality compliance? ISO/IEC have published a set of standards useful for Software QUAlity Requirements and Evaluation also termed as SQUARE. SQuaRE is a series of International Standards (25000-25099) edited by the ISO/IEC organisation and related to Systems and Software Quality. Following are different ISO/IEC standards under SQUARE umbrella: ISO/IEC 25000 — Guide to SQuaRE ISO/IEC 25001 — Planning and management ISO/IEC 25010 — System and software quality models ISO/IEC 25012 — Data quality model ISO/IEC 25020 — Measurement reference model and guide ISO/IEC 25021 — Quality measure elements ISO/IEC 25030 — Quality requirements ISO/IEC 25040 — Evaluation process ISO/IEC 25045 — …
Source code complexity: Operability Indicator
The complexity of source code can be used to represent the operability of source code. Before we look into various different techniques to measure code complexity, lets briefly understand the operability of source code. Operability is also one of the key characteristic of software quality requirements and evaluation standards (SQUARE). What is Source Code Operability The operability of source code can be defined in terms of ease of understandability and learn ability of the code. That, in turn, can represented in terms of how complex the code is, or, simply speaking, the code complexity. In another words, if the code is complex, it is difficult to understand & learn and …
I am not sure about the quality of software I delivered?
This is what I got to hear from average software developers across many workshop sessions that I have been undertaking recently in India. Ask a software developer (on an average) if he could make out whether he has delivered a piece of high quality code for required functionality, and the answer that may be expected is YES. The second question that you ask is “How do they know that they delivered a high quality piece of code?”. The answer you get is related with defects primarily against the functional requirements. All they say is that their piece of code has not been found with any bug in Dev/QA/UAT & production …
What is Software Maintainability?
What did software developers say about software code Maintainability? Software developers were found to emphasise more about changeability aspect of software source code when asked to define the Maintainability. Most of them were found to be unaware of Testability aspect. What is Software Maintainability? Maintainability of a software in terms of source code maintenance is considered to be one of the key criteria for acceptance of software delivery. This is also defined as one of the key characteristic of software quality as per ISO/IEC 9126, ISO/IEC 25010 standard specification. What may make a piece of code maintainable? Changeability: The code should be easy to change. This, in turn, may also …
Can Software Quality Be Measured?
With customer stakeholders complaining about the the quality of software being delivered, the challenge in front of delivery/project manager was to find a way in which software quality can be measured. Before going into how can the software quality be measured, one needs to understand why at all the software quality need to be measured? The need to measure software quality has arisen due to following: Customer:Customer stakeholders needed a ways and means to ensure that software delivered to them by partner vendors are of high quality. Software Service Providers: Stakeholders such as software developers needed to be governed on regular basis to ensure consistent & predictable delivery of high …
Software Quality & Varied Perceptions
As part of software quality workshops that I have been taking recently, I asked various attendees about how would they define “Software Quality”. It was found that everybody gave different answers on this, and most of them could said to be partially correct. What did the trainees (primarily, software developers) say? Following were some of the common answers: It is about how fast a software screen loads? Is the software secured enough? There should be as minimum defects as possible? If one looks above, they belong to following characteristics of a software product: Efficiency Security Functionality While interacting with end customers which primarily included the developers and team leads/scrum masters, …
I found it very helpful. However the differences are not too understandable for me